Closed (fixed)
Project:
Facets
Version:
3.0.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
23 Aug 2026 at 14:24 UTC
Updated:
16 Sep 2026 at 18:15 UTC
Jump to comment: Most recent
Problem/Motivation
In Drupal 11.4, the way the 'EntityType' constraint is declared has changed. 'EntityTypeConstraint' received a '#[HasNamedArguments]' constructor, and core now passes it as an array instead of a plain string:
- Drupal 11.3.14: '->addConstraint('EntityType', $settings['target_type'])'
- Drupal 11.4.5: '->addConstraint('EntityType', ['type' => $settings['target_type']])'
Currently, two processors in this module decide if they apply by strictly comparing this constraint against a plain string:
- 'TermWeightWidgetOrderProcessor::supportsFacet()' compares against 'taxonomy_term'
- 'UidToUserNameCallbackProcessor::supportsFacet()' compares against 'user' (in both of its branches)
Because 'getConstraint('EntityType')' now returns an array (like '["type" => "user"]') on Drupal 11.4, these strict comparisons fail.
The impact:
- The "Transform UID to user name" option is not offered at all.
- The "Sort by taxonomy term weight" option disappears for facets whose data definition is 'field_item:entity_reference'.
- This is also the root cause of the 'HierarchicalFacetIntegrationTest::testWeightSort' failure. (Note: the term weight half was fixed for the 2.0.x branch in #3552832).
Proposed resolution
- Update both processors to accept both shapes of the constraint (the old plain string and the new array format).
- Add unit test coverage for the 'supportsFacet()' method in both processors (neither of them has any test coverage for this right now).
Remaining tasks
Review the MR.
Note for reviewers: The MR remains fully compatible with older core versions. The new tests explicitly assert both the array form and the plain string form, and both properly fail without the fix.
Issue fork facets-3618692
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:
changes
Comments
Comment #3
peri22 commentedJust a quick cross-reference! You can actually see the user-visible symptom of this bug happening right now over in the pipeline for #3618817: REST tests fail: config entities need ConfigEntityResourceTestBase, and the XML charset changed (which handles the REST failures on the '3.0.x' branch).
In that pipeline, the 'HierarchicalFacetIntegrationTest::testWeightSort' test is failing with this error:
'Form field with id|name|label|value "facet_sorting[term_weight_widget_order][status]" not found.'
That missing field is exactly the "Sort by taxonomy term weight" option disappearing from the facet form, which is exactly what my MR here fixes!
Comment #4
joelpittetAlmost RTBC'd this but when reviewing the code the similarity between
userandtaxonomy_termcaught my eye so changing to needs work.Comment #5
joelpittetThe pipeline's failures are unrelated REST-test failures tracked in #3618817: REST tests fail: config entities need ConfigEntityResourceTestBase, and the XML charset changed BTW not this issue.
Comment #6
peri22 commentedThanks, back to needs review.
Comment #7
ressaThank you both of you for all your great efforts with Facets and other modules, I really appreciate it. For some time now, the Facets maintainers have been under pressure to keep up with all the changes, so perhaps one or both of you could consider becoming co-maintainers? Or if it would not make any difference, and the flow of issues and releases is steady, of course disregard my suggestion :)
(I do see 22 RTBC issues ... so maybe it's worth considering?)
Comment #8
joelpittetSorry, should have set to "needs work" again to address the unresolved comments
Comment #9
peri22 commentedComment #10
peri22 commentedThanks @joelpittet! I addressed this in the latest commit. The helper and the logic switch are now gone, so the change is just two lines per call site and completely identical across both processors. I kept the 'instanceof' check because 'phpstan' still requires it.
Tested this locally: 'phpcs', 'phpstan', and both unit test classes are all clean.
Back to needs review.
Comment #11
joelpittetOk I think that is RTBC now, the tests are all the REST ones that are fixed elsewhere #3618817: REST tests fail: config entities need ConfigEntityResourceTestBase, and the XML charset changed
Comment #12
joelpittet@ressa, considering your vote of confidence in #7, I’m giving it some thought, though I have plenty of other modules that need my attention. :)
I also see that mikeker created Facets. He was a good friend, a fellow event mentor, and of course of BEF fame, so that gives me another reason to consider it.
The project is already seeking co-maintainers, so perhaps there’s room for more than one of us. @peri22, you already maintain a related module with a Search API sorting widget, so Facets might be a natural tie-in with some of what you’re already maintaining?
Comment #13
peri22 commentedThanks for the offer, and to @ressa for bringing this up, I would be glad to help out.
To be completely upfront about my availability, I can't commit to release management or taking full ownership of the issue queue. That being said, I can regularly help with core compatibility work (like this issue), reviewing incoming MRs and setting them to RTBC, and generally triaging the queue.
So yes, I am definitely interested if the maintainers feel this scope of work would be useful, though that is entirely their call to make, of course. In the meantime, I am happy to keep reviewing alongside you either way.
Comment #14
ressaThank you so much for the positive feedback from both of you, and sorry I jumped into this issue.
I totally understand how much energy it can take to keep the code updated, write tests, juggle issues and then even also do releases, and handle support requests. But sometimes a module gets stuck (like Search API Sorts Widget, thanks @peri22!), maybe because the maintainers have left Drupal, or are busy elsewhere. So simple fixes can linger a long time, and ready-to-commit solutions from bug fixers and expert coders -- such as you two -- get stuck, sadly. If you just had the commit and release permission, you could unclog the river, and allow the module to flourish.
And I understand that you can't promise a big engagement, but every little bit counts, and I am sure the users of the Facets module would very much appreciate it if both of you applied for co-maintainership. Ideally, all of us who are using a contrib module (such as Facets) should help where we can, triaging issues, testing patches, writing documentation, etc. And thank you for mentioning @mikeker, it's good to remember that we are all standing on the shoulders of the community members, who in the past created amazing things.
Comment #17
joelpittetThanks @peri22 and @ressa, there is still a test failure that @mradcliffe pointed out on Slack that is related to body fields is better suited for this issue #3618182: Expand and fix testing.
This puts the term weight ones to bed!
Comment #19
ressaFantastic news, both here in this issue, and about getting the co-maintainer role, congratulations @joelpittet! 🎉 It's very satisfying to see issues getting committed immediately afterwards.