Record list fields

[brady-lamansky-gtt]

This resolves #2845 to replace record-list fields with dt-web-components. Filtering functionality was updated to accommodate the new changes & appeared to work properly, but more testing is likely needed.

I updated these things:

• Custom Filter Creation
• Bulk Edit
• Field Selection (for the displayed fields)

@cairocoder01 let me know any suggestions!

Related Components PR: DiscipleTools/disciple-tools-web-components#208

[cairocoder01]

After a brief review manually and bigger Claude review, here's some preliminary things to fix:

The issue may have been misleading about replacing all components in the filters, since some of the filter controls don't match the component normally used for that field.

Filters

Regressions

• Date fields no longer support range selection
• key_select fields no longer support selecting multiple values to search for
• boolean fields no longer support selecting multiple values to search for
• Filter chips display raw keys instead of labels (e.g. Contact Status: active instead of expected Contact Status: Active

Bugs

• Connection fields show the button to add a new connection. No need to add from the filter selection

[cairocoder01]

Here is a full Claude review I did locally while it had access to a dev site running the code:

Code Review: Record List Fields → Web Components (record-list-fields)

Reviewed the diff against origin/develop (source files: archive-template.php,
dt-assets/js/modular-list.js, dt-assets/js/modular-list-bulk.js,
dt-core/utilities/dt-components.php, dt-assets/scss/_components.scss) and
verified the runtime behavior live on dtagent.local (deployed via wp-deploy)
with network capture and the PHP debug log.

---

🔴 High

1. Date filters are silently broken (return unfiltered results)

archive-template.php:994 renders a single dt-date, and in
modular-list.js:1453-1469 date/datetime fields fall through into the generic
"single select" branch, producing val = [customComponent.value].

The list query builder in dt-posts/posts.php:874-884 only applies a date
constraint when the value is an object keyed by start/end. An array key (0)
matches neither, so no WHERE clause is emitted — the filter is silently ignored
and all records are returned.

Verified live — applying a Baptism Date filter posts:

{"fields":[{"baptism_date":["2024-01-15"]}, ...]}
// expected: {"baptism_date":{"start":"2024-01-15"}}

This is also a capability regression: the old UI had Range Start / Range End;
the new one renders one date input, so date-range filtering is gone entirely.

Fix: add a dedicated date branch that emits { [field]: { start, end } } and a
start/end UI (two dt-dates).

---

🟠 Medium

2. render_toggle throws PHP warnings on every list load

dt-components.php:325 does checked( $post[$field_key], '1', false ), but the
new call sites pass an empty $post ([]) — archive-template.php:466 (archived
toggle) and archive-template.php:1005 (every boolean filter field). Confirmed in
debug.log:

PHP Warning: Undefined array key "archivedToggle" in .../dt-components.php on line 325
PHP Warning: Undefined array key "favorite" ...
PHP Warning: Undefined array key "requires_update" ...

Fix: checked( $post[$field_key] ?? '', '1', false ) in render_toggle.

3. key_select and boolean filters regressed to single-value

archive-template.php:964 renders key_select as dt-single-select and
boolean as dt-toggle. Previously these were multi-checkbox groups.
Consequences:

• key_select (e.g. Contact Status): can no longer filter for multiple statuses
  at once, and the explicit "None Set" option is gone. The backend still
  supports value arrays (dt-posts/posts.php:886) — only the UI regressed.
• boolean: the old Yes/No checkboxes are replaced by one toggle, so filtering
  for "No"/unset (0) is no longer expressible.

4. Field-selection save persists stale - delete markers

modular-list.js:890-898 reads $('#field_search_input').val() directly. When a
user removes a column, dt-multi-select marks it as -fieldkey rather than
removing it. Verified live — after removing "Name", the saved value is:

["-name","last_modified","favorite","overall_status","assigned_to","milestones","groups","seeker_path"]

That -name gets written to the fields_to_show_in_table cookie and sent as
fields_to_return. The filter-change handler already strips these
(modular-list.js:1449-1452); save_column_choices should do the same
(.filter(k => k.charAt(0) !== '-')). The now-dead try/catch around it (no JSON
parsing anymore) should also be removed.

5. Filter chips display raw keys instead of labels

For key_select/multi_select/tags, create_name_value_label
(modular-list.js:1735) interpolates the value directly. Verified live the chips
read "Contact Status: active" and "Sources: web,phone" instead of the
translated option labels ("Active", "Web, Phone"). Connections/users/locations are
fine (they use item.label). The change handler should resolve option keys to
labels before building the chip text.

---

🟡 Low / cleanup

(the issue explicitly asks to remove now-unused code)

• Dead field-picker code left behind after the template rewrite: the
  .remove-field-btn handler and #selected_fields_input /
  #enabled_fields_container references (modular-list.js:866-888) and in
  reset_column_choices (modular-list.js:908) — none of those elements exist
  anymore.
• Dead .text-comms-filter-input keyup handler (modular-list.js:1774) — that
  class is no longer rendered (fields are now dt-text), so the old "auto-select
  the default radio while typing" behavior is silently gone. Text filtering still
  works, but confirm this UX loss is intended.
• Dead .clear-date-picker handler (modular-list.js:2323) — those buttons
  were removed from the date template.
• Duplicate/mismatched selector in the modal-close reset
  (modular-list.js:2115): dt-location is listed twice, and dt-location-map is
  in the reset branch's tag list but not in the query selector.
• dt-assets/scss/_components.scss has no trailing newline (line 17) —
  PHPCS/prettier nitpick.

---

What I verified vs. inferred

Live-confirmed on dtagent.local: date query shape (#1), PHP warnings (#2), stale
- markers (#4), raw-key chips (#5), single-select rendering (#3). The
double-labeling I initially suspected for text/comms fields turned out not to
be a bug — the radio handler correctly replaces the change-handler chip (net one
chip). Connection/user/location/multi-select/tags query building looks correct.

[cairocoder01]

Regressions

• key_select fields no longer support selecting "none set" in order to filter by records with no value (screenshot from current theme version before these changes)

old	new

• Connection and users-connections filter previously had a placeholder "Type to search" that we can add back in. Also, we are now showing the field label above that is duplicated and not needed

old	new

• Connections filter previously disabled the input field when the all or none filter was selected. We should re-implement that. That happened on 1691 with the line typeahead.prop('disabled', true); which no longer does anything since there is no typeahead.
• Location or Address shows not unsupported error. Previously showed the standard location grid filter.

old	new

• multi_select previously displayed a list selection instead of a button group. We should match the display type of the field, whether it should show as a standard list select or a button group.

old	new

• Tags filter is showing the option to add a new tag:

• Communication channel and text are missing placeholders
• If I create a date range filter and save it as a custom filter, when I click the edit icon next to the saved custom filter, the filter modal doesn't have the values of the saved filter. The same seems to be true of other saved filters. Claude eventually found it and gave this detail:

modular-list.js:2152 edit_saved_filter still runs on the old typeahead machinery:

• Line 2081 declares let typeaheads_loaded = null; and the code that used to assign it (typeaheads_loaded = load_multi_select_typeaheads()…) was deleted in this PR. It's never reassigned, so line 2154 typeaheads_loaded.then(…) throws TypeError: Cannot read properties of null (reading 'then') the instant you click the edit (pencil) icon on a saved custom filter. The modal opens blank and nothing populates.
• Even if you guard that, the callback body still calls removed APIs: .datepicker('setDate', …) at 2184 and window.Typeahead['.js-typeahead-…'].addMultiselectItemLayout(…) at 2198–2213 — the typeaheads are never created now, so those are undefined.addMultiselectItemLayout() → another throw.

So edit_saved_filter needs to be reworked to populate the dt-* components (set .value), not just cleaned up. This is in-scope for "Custom Filter Creation" and is a genuine regression — worth adding to the review as High.

[cairocoder01]

Looking pretty good. A few things to clean up yet.

[cairocoder01]

Some additional dead code that can be removed after you confirm it is for the old UI and not needed anymore:

Dead code, safe to remove

• 906–909 — #reset_column_choices sets #selected_fields_input and #enabled_fields_container; both were removed from the template (picker is now dt-multi-select). Reset still works via the cookie clear + reload below it.
• 2081 — let typeaheads_loaded = null; (only referenced by the broken line above; drop it as part of fixing edit_saved_filter).
• 2085–2087 — $('#filter-modal input.dt_date_picker').each(...); no .dt_date_picker inputs exist anymore (dates are dt-date, reset in the closed.zf.reveal handler).
• 2094–2096 — .typeahead__query.disabled removeClass loop; no such elements remain.
• 2098–2101 — $('.typeahead__query input').each(function () { let typeahead = …; }); assigns a local and does nothing with it, and matches nothing.
• 2246–2247 — window.Typeahead['.js-typeahead-${field}'].adjustInputSize() in the #filter-tabs change handler; guarded so it won't throw, but it's dead.

[brady-lamansky-gtt]

@cairocoder01 I just updated this PR and it's ready for review again. Thanks!

[cairocoder01]

Looks like everything from the previous reviews has been addressed except for tags fields still showing the add new option.

New Issues

High

• Saved filters for text, communication_channel, textarea, or number aren't populating when trying to edit:
  • [dt-assets/js/modular-list.js:2108] edit_saved_filter was reworked to fix the typeaheads_loaded crash (confirmed — that regression is gone), but its per-label restore loop only handles key_select/boolean/file_upload, date/datetime, connection-type fields, multi_select/tags, and user_select. There's no branch for text, communication_channel, textarea, or number (see the corresponding filter cases at [archive-template.php:1072-1107]). Opening the edit (pencil) icon on a saved filter that includes one of those field types shows the correct chip, but never sets the underlying dt-text/dt-textarea/dt-number component's .value. Since get_custom_filter_search_query() ([modular-list.js:1368]) reads directly from the live DOM component (not from filter.labels), clicking "Save Filter Edits" ([modular-list.js:2202]) — even just to rename the filter — silently pushes an empty value for that field and permanently overwrites the saved filter's real criterion. Fix: add a branch in edit_saved_filter that sets .value on the matching dt-text/dt-textarea/dt-number component for these types (and the filter_by_text_comms_option_* radio state, mirroring the file_upload/key_select handling already there).

[brady-lamansky-gtt]

@cairocoder01 I just made those changes! I also fixed an issue where Input fields weren't being disabled properly when selected "All With" or "All Without" checkboxes on text fields.

[cairocoder01]

Adding tags issue is resolved.

• However, I'm still unable to edit a text or comm-channel filter. For comm-channel, it seems to set the radio buttons but not the text value.
• Also, the Name field shows a required field indicator because it is marked as required in the backend. We need to remove that required attribute for the filter field

[cairocoder01]

• When saving a name filter and going to edit, there is no remove icon in the tag at the top of the filter modal (though it does now populate the name filter correctly). Same for comm-channels. These may have been existing bugs comparing to a site without this updated. So I think we might be able to leave it as-is and call this PR complete

[cairocoder01]

@corsacca Ready for your review

[corsacca]

Hey Guys!

Nice work on these upgrades!

Modal

If i add a location and then remove it, it does not get removed from the added filters:

Same for Assigned to, connection fields (sometimes).

Got
Warning: Undefined array key "icon" in /[path]/wp-content/themes/disciple-tools-theme/archive-template.php on line 1036

Field picker

• "reset to default" does not work
• Dropdown is cut off. (tho i notice this is an existing issue on the bulk edit view)
  We can remove "Add fields" since it is add and remove now.

Other notes

1. Sanitization scope regression in save_user_filter — (wp-content/themes/disciple-tools-theme/dt-users/users.php#L766-L798)
   Replacing deprecated FILTER_SANITIZE_STRING was needed, but the old call recursively tag-stripped every string in the structure (I verified this on PHP 8.4 — nested query, labels, and unknown keys all got stripped). The new code sanitizes only name/type/tab/ID and labels' name/field/id; the entire query subtree and any other keys (labels[].date, arbitrary client-added keys) are now stored raw in user meta. Current render paths escape output (escapeHTML), so I found no direct XSS, but it's a real defense-in-depth loss. dt_recursive_sanitize_array() — already used a few hundred lines up in (wp-content/themes/disciple-tools-theme/archive-template.php#L483) — would preserve the old guarantee with less code.

[brady-lamansky-gtt]

@corsacca Thank you for the review!

For removing location/connection custom filters still showing the labels:

• I made a previous commit to the web-components to fix this issue, adding bubbles: true to the change events, since they weren't being received on _remove(). This worked for me when I updated my local web components! Let me know if anything else is needed: DiscipleTools/disciple-tools-web-components@913c0a9

For sanitization, I updated it originally because the sanitization in filter_var_array( $filter, FILTER_SANITIZE_STRING ); was stripping special characters, like the '<' character, out of '<19' for the Age filter (and the other Age options as well). If I save an "Age <19" filter, I see the correct records. When I refresh the page, no records are displayed. "No records found matching your filter." The same happens with dt_recursive_sanitize_array().

• I went with Gemini's recommended fix back then, but it sounds like that's not what we want. How do you recommend we handle this? Gemini said this, but bypassing sanitization for specific pieces may not be what we want: "To fix both issues, I ran your dt_recursive_sanitize_array() function against the whole payload to secure arbitrary keys, but explicitly bypassed tag-stripping for the query and labels[id] system arrays, enforcing scalar types and unslashing instead." What do you think?

I fixed the other issues and will push the changes once sanitization is figured out!

[corsacca]

Thanks @brady-lamansky-gtt!
I regret that we allowed < in the keys for the age field. It has caused headaches and would be hard to migrate from.

Did some back and forth with claude and i think we can update save_user_filter as so:

Proposed replacement:

public static function save_user_filter( $filter, $post_type ){
    $current_user_id = get_current_user_id();
    if ( $current_user_id && isset( $filter['ID'] ) ){

        // Filter values are structured query data, not HTML: values like the '<19' age
        // key must survive. SQL safety comes from prepare/esc_sql at query time and XSS
        // safety from escaping at render, so only byte-validity is enforced here.
        $filter = map_deep( $filter, 'wp_check_invalid_utf8' );
        $filter['ID']   = is_scalar( $filter['ID'] ) ? (string) $filter['ID'] : '';
        $filter['type'] = sanitize_key( $filter['type'] ?? '' );
        $filter['tab']  = sanitize_key( $filter['tab'] ?? '' );
        if ( ! is_array( $filter['query'] ?? null ) ) {
            $filter['query'] = [];
        }

        $filters = get_user_option( 'saved_filters', $current_user_id );
        ...

$filter = map_deep( $filter, 'wp_check_invalid_utf8' ); Removes anything that is not UTF8, so "<19" will be kept as kept in the filter key and label.

[cairocoder01]

For removing location/connection custom filters still showing the labels:

• I made a previous commit to the web-components to fix this issue, adding bubbles: true to the change events, since they weren't being received on _remove(). This worked for me when I updated my local web components! Let me know if anything else is needed: DiscipleTools/disciple-tools-web-components@913c0a9

@brady-lamansky-gtt Since that component update has been released, you should update the component library version in package.json of the theme to v1.0.2 and npm run build to get those updates included in this branch.

[brady-lamansky-gtt]

@corsacca @cairocoder01 thank you! I Just made those changes

[corsacca]

@brady-lamansky-gtt, i'm not seeing the commit here. Try pushing again?

[brady-lamansky-gtt]

@brady-lamansky-gtt, i'm not seeing the commit here. Try pushing again?

Sorry I committed my changes but forgot to push!

[github-actions]

Reviewed the current PR head (4b2ac56) against the base branch, plus the extensive prior review threads. Skipping everything already raised/tracked above (date-range regression, key_select/boolean multi-value, filter chip labels, field-picker dead code, sanitization, edit_saved_filter, tags "add new", required-attribute, icon-undefined-key warning, etc.) since those are already covered. Found two new issues introduced in the latest commits that don't appear to have been flagged yet:

High

1. DT_Components::render_tags() — allowAdd is now permanently disabled everywhere (undefined variable), not just in filters
dt-core/utilities/dt-components.php:276:

$params['allow_add'] ?? true;

This is a dead statement — the ?? result is discarded, $allow_add is never assigned. Then at line 295:

<?php echo $allow_add ? 'allowAdd' : null ?>>

$allow_add is undefined (PHP warning), evaluates falsy, so allowAdd is never rendered on <dt-tags> — regardless of what's passed in $params['allow_add']. This isn't scoped to the new filter UI: render_tags() is the generic renderer used by dt_render_field_for_display() for every tags-type field across the app (contact/group detail pages, etc. — see dt-core/global-functions.php:640). Previously allowAdd was hardcoded on. Compare with the correct pattern already used a few lines up in render_connection() (dt-core/utilities/dt-components.php:102-106):

$allow_add = true;
if ( isset( $params['allow_add'] ) ) {
    $allow_add = $params['allow_add'];
} else if ( isset( $params['connection']['allow_add'] ) ) {
    $allow_add = $params['connection']['allow_add'];
}

render_tags() needs the same $allow_add = $params['allow_add'] ?? true; assignment. As shipped, users can no longer add new tag values on any tags field anywhere in the app, plus a PHP undefined-variable warning fires on every tags field render.

2. DT_Components::render_user_select() — lost its default single-select behavior, breaking Group "Assigned To"
dt-core/utilities/dt-components.php:352:

<?php echo ( isset( $params['single'] ) && $params['single'] === true ) ? 'single' : '';?>>

Previously single was hardcoded on <dt-users-connection>. Now it only renders when a caller explicitly passes 'single' => true. The only caller passing params is the new filter UI (archive-template.php), which doesn't set single. But render_user_select() is also the generic renderer used by dt_render_field_for_display() for every user_select field (dt-core/global-functions.php:655). Contacts' assigned_to happens to have custom_display => true (dt-contacts/module-access.php:360) so it bypasses this path, but Groups' assigned_to (dt-groups/base-setup.php:138-144) does not — it goes through the generic renderer and will now render as a multi-select picker instead of single-select.

This isn't just cosmetic: the backend (DT_Posts::update_post_user_select() in dt-posts/posts.php:2070-2087) expects a single scalar value per user_select field and returns a WP_Error ("incorrect format for user_select") if given an array. So selecting a second user for a group's "Assigned To" field will fail to save (or otherwise behave incorrectly), where previously the UI only allowed one selection at all.

Fix: default to single unless a param explicitly opts out, e.g. !isset($params['single']) || $params['single'] === true, mirroring how render_tags/render_connection should default allow_add to true.

---

Everything else in this large PR (filters, saved-filter editing, sanitization rework, field picker) looks consistent with the fixes already discussed in the review thread. Once the two render_tags/render_user_select default-param regressions above are fixed, this looks close to mergeable — worth a final smoke test on Groups "Assigned To" and any tags field add-new flow before merging.