Problem/Motivation

When a taxonomy term filter is both exposed, using a select input, and has its identifier changed from the default, a saved value is not loaded into the block form when subsequently configuring the block.

Steps to reproduce

  1. Create a view with a block display.
  2. In Block settings, Allow settings, check "Configure filters".
  3. Add an exposed filter and check "Expose operator". Change the filter identifier.
  4. Save the view.
  5. On the Block layout page, add the view block to a region.
  6. Give the filter a value and save the block.
  7. Configure the saved block - the selected filter value will not be loaded. The filter will be set to "All".

Proposed resolution

Correct mistaken use of the filter's machine name in the Block::blockForm() method. The filter's entered identifier should be used, instead.

Remaining tasks

n/a

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Issue fork ctools-3499802

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

apkwilson created an issue. See original summary.

apkwilson opened merge request !78

apkwilson’s picture

apkwilson commented
Status: Active » Needs review

I pushed a commit with just tests, but the pipeline didn't finish running them (it would have failed) before the commit fixing the tested behavior went up and canceled the pipeline.

benstallings’s picture

benstallings commented
Assigned: apkwilson » Unassigned
Status: Needs review » Reviewed & tested by the community

I ran this past Claude Code, which said,

The bug: When a Views exposed filter has a custom identifier (different from the filter's machine name/ID), the ctools_views block configuration form was using the filter ID ($id) to access form elements instead of the configured identifier. This means if someone set their taxonomy filter's identifier to something other than the default, the block config form would break — it'd look for form elements under the wrong key.

The fix (2 commits):

1. 8db730ce — Test update: Changes the test view config so the taxonomy exposed filter uses tags_filter_alternate_identifier instead of field_ctools_views_tags_target_id as its identifier, and updates the functional test assertions to use this non-default identifier. This properly reproduces the bug scenario.
2. ecdc6652 — Code fix in Block.php:
- Moves the $identifier = $handler->options['expose']['identifier'] assignment to where it's actually needed (inside the else block at line 297, after buildExposedForm())
- Replaces three instances of $id with $identifier when accessing form elements (lines 300, 303, 311)
- Removes the now-unnecessary earlier assignment at line 284

Assessment: Clean, correct fix.

- The root cause is clear: $id is the filter's internal ID while $identifier is what the user configured for the exposed form — these can differ.
- The test change is smart — by making the test view use a non-default identifier, it catches exactly this class of bug going forward.
- The $identifier variable is moved to a tighter scope where it's actually used, which is a minor improvement.
- The fix is minimal and focused — only touches the affected lines.

One nit: The typo "thir" on line 310 (// thir defaults manually.) predates this branch, so not a concern here.

Verdict: This looks good to merge. The bug is real, the fix is correct and minimal, and the test coverage properly validates the scenario.