Continuation Add Views EntityReference filter to be available for all entity reference fields

smustgrave → credited apaderno → .

smustgrave → credited catch → .

smustgrave → credited caspervoogt → .

smustgrave → credited ankithashetty → .

smustgrave → credited jksloan2974 → .

smustgrave → credited Murz → .

smustgrave → credited jhedstrom → .

Moving over credit. Last comment from @Lendude that need to be addressed

@catch asked me to look at this again, mostly the test coverage. The test coverage seems mostly good, but ran into some other issues.

calculateDependencies is untested and should be since this is different than the Term plugin
The 'sort by' field is empty on initial adding of the filter (the field widget does something ajaxy when selecting bundles, the views widget does not, might be it?)
Grouped autocomplete filters don't work/save (but don't work for taxonomy ref filters either), please find the related issue or open it (should be one I think)
Description "as a Reference filter" feels a bit vague, did we get UX feedback on this?
Should we add this new filter for taxonomy terms too, or should we skip those since it is unclear what the difference is now when have to chose between the two different filters
I can create a circular reference by creating an Entity reference View that uses itself as the filter, not sure what goes wrong (mostly getting an empty filter after saving), but that sounds iffy
Maybe related : Managed to click my way into "Warning: Undefined array key "reference_views" in Drupal\views\Plugin\views\filter\EntityReference->submitExtraOptionsForm() (line 440 of /app/drupal/core/modules/views/src/Plugin/views/filter/EntityReference.php)"
Node titles in the select element are double escaped
Exposed filters on the chosen entity reference view are also shown on the view

smustgrave → credited nuez → .

smustgrave → credited gambry → .

smustgrave → credited heddn → .

smustgrave → credited dawehner → .

smustgrave → credited BramDriesen → .

smustgrave → credited seanB → .

smustgrave → credited DiDebru → .

smustgrave → credited Taran2L → .

smustgrave → credited Graber → .

smustgrave → credited Berdir → .

smustgrave → credited scott_euser → .

smustgrave → credited mparker17 → .

smustgrave → credited Kasey_MK → .

smustgrave → credited mr.york → .

smustgrave → credited joachim → .

smustgrave → credited gbirch → .

smustgrave → credited C.E.A → .

smustgrave → credited das-peter → .

smustgrave → credited mdolnik → .

smustgrave → credited DamienMcKenna → .

smustgrave → credited oriol_e9g → .

smustgrave → credited _Archy_ → .

smustgrave → credited klaasvw → .

smustgrave → credited muriqui → .

smustgrave → credited akalam → .

smustgrave → credited rlmumford → .

smustgrave → credited yogeshmpawar → .

smustgrave → credited Krzysztof Domański → .

smustgrave → credited johnwebdev → .

smustgrave → credited xjm → .

smustgrave → credited RoSk0 → .

smustgrave → credited ckaotik → .

smustgrave → credited jsst → .

smustgrave → credited anmolgoyal74 → .

smustgrave → credited Lendude → .

smustgrave → credited dww → .

smustgrave → credited Lukas von Blarer → .

smustgrave → credited Pancho → .

smustgrave → credited willpepsi → .

smustgrave → credited andypost → .

Copied over MR from original issue to here.

Link to original MR https://git.drupalcode.org/project/drupal/-/merge_requests/3086#note_150528

Tag from original issue.

(fixing comment number in issue summary)

Sidenote: I recommend editing #49 to get those list bullets back in, for readability.

I found another issue when trying to use the new entity_reference filter on a user reference field.

Steps to reproduce

1. Enable the entity_reference filter for the node uid field

/**
 * Implements hook_views_data_alter().
 */
function my_module_views_data_alter(array &$data): void
{
    $data['node_field_data']['uid']['filter']['id'] = 'entity_reference';
}

2. Add the Author filter (category Node) to a node view, changing Selection type to Select list.
3. Open the view. The dropdown has no options.

The reason this happens is because target_bundles is set to an empty array. The reason target_bundles is set to an empty array is because validateExtraOptionsForm failed, namely the following line:

$subform_state->setValue([
  'settings',
], $subform_options);

And that fails because SubformState::getValues fails: $this->getParents('#parents') returns ['reference_default:user'] and the array returned by parent::getValues() does not have a reference_default:user key, it does have an options key. That's as far as I got while debugging.

@DieterHolvoet: I just happened to bump up against a similar situation. In my case it's a custom entity type that has no bundles.

I think the issue is actually in DefaultSelection, which I do not think is being touched by this patch. I suspect that only users of this patch would be trying to use DefaultSelection with a bundle-less entity, so maybe that is why it hasn't been an issue before? I'm not entirely sure.

In DefaultSelection::buildEntityQuery, there is this snippet:

    // If 'target_bundles' is NULL, all bundles are referenceable, no further
    // conditions are needed.
    if (is_array($configuration['target_bundles'])) {
      // If 'target_bundles' is an empty array, no bundle is referenceable,
      // force the query to never return anything and bail out early.
      if ($configuration['target_bundles'] === []) {
        $query->condition($entity_type->getKey('id'), NULL, '=');
        return $query;
      }
      else {
        $query->condition($entity_type->getKey('bundle'), $configuration['target_bundles'], 'IN');
      }
    }

And in DefaultSelection::buildConfigurationForm, there is this condition:

    if ($entity_type->hasKey('bundle')) {
      // ..code removed for comment..
    }
    else {
      $form['target_bundles'] = [
        '#type' => 'value',
        '#value' => [],
      ];
    }

So I think that '#value' => []needs to become '#value' => null, but I am not entirely sure that is the best solution or what other impact that change would have elsewhere. Alternatively, EntityReference::buildExtraOptionsForm could be modified to set target_bundles to null if the entity type does have have bundles.

As a workaround, I ended up writing a custom EntityReferenceSelection plugin that extends DefaultSelection and changes target_bundles to null, when the entity has no bundles, inside ::buildEntityQuery. A little messy, but gets the job done (for now).

Every instance of self::WIDGET_SELECT_LIMIT and self::ALL_VALUE should be static::.

The use of self prevents any extending classes from overriding these uses, for example via replacing the filter class via hook_views_plugins_filter_alter().

The use of static accommodates this use.

Per my update in #55, I think something like this is needed in EntityReference::validateExtraOptionsForm. This will be to handle entities with no bundles and possibly for selecting no bundles on the subform.

    // If no checkboxes were checked for 'target_bundles', store NULL ("all
    // bundles are referenceable") rather than empty array ("no bundle is
    // referenceable" - typically happens when all referenceable bundles have
    // been deleted or when an entity type has no bundles).
    if ($subform_options['target_bundles'] === []) {
      $subform_options['target_bundles'] = NULL;
    }

    // Store the sub handler options in sub_handler_settings.
    $form_state->setValue(['options', 'sub_handler_settings'], $subform_options);

Good to see this issue moving.again

@smustgrave please do ...
and thanks a lot

Was afraid of that. Think a new MR for 11.x will have to be started.

here's the MR before it got messed up.

@vasike if you're working on this issue would recommend you start the branch so you have control of it.

@smustgrave
it seems there is an issue with with 11.x ... and 11.0.x it doesn't seem "a real one" ...

so in ... a hurry ... we lost the track ... if i may say so .. :(

I had this issue as well somewhere else because the issue fork got created before the branch existed and is thus not in sync with all other branches. Let me see if I can fix it.

There we go. If anyone is wondering how I usually fix this here is the process.

1. Start gitpod with the "old" 10.1.x branch
2. Checkout 10.1.x
3. Git pull
4. Git fetch origin
5. Git fetch --all
6. Git checkout 11.x
7. Git checkout -b 3347343-11-x
8. -- do the stuff like patch applying, making changes, fixing conflicts --
9. Git commit
10. git push --set-upstream drupal-3347343 HEAD <<< this command changes with each issue fork, it's the last command from the "show commands" section.

Also @vasike

i just noticed something ... for drupal.org
i tried to select new people for credits (including you) ... but it didn''t update the commit message ... hmm

You don't have to include that in your commits. All commits will be squashed anyway when a maintainer commits this and sets the final commit message. Only maintainers of the module (or core in this case) can change the checkboxes.

I’ve been told issue must be committed to 11.x first and then backported. Didn’t mean to cause a road bump

Thanks for resolving!

@BramDriesen very thank you
p.s. this is ... anyway ... witchery ... imho

No problem, let's all be wizards 🧙‍♂️

Updates on MR:
- rebased - using 11.x
- Fix for entities with no bundle - DefaultSelection NULL value - as User
- Complete - Workaround for https://www.drupal.org/project/drupal/issues/2651418 🐛 Non-array values for #ajax RTBC
to support sub-items (for Entities with some fieldset/tree options) - as User
- Use static for const, instead of self ... as suggested.
- Fix tests - remove duplicate (early check) + fix the check for Filter options.

Todo:
- Fix https://www.drupal.org/project/drupal/issues/2651418 🐛 Non-array values for #ajax RTBC - it will cleanup code in the MR.
- Entity with no bundle test - if really needed?!

The last submitted patch, 63: 3347343-63.patch, failed testing. View results →

Unrelated. Will hide that patch, not sure if that stops it from being retested or not.

Tested out on 11.x standard profile

Added an entity reference field to the Article content type, pointing to basic pages
Created a Test view
Added the entity reference filter
Configured and verified it filtered correctly.

One part that was odd to me, won't hold it up, but when adding the filter it let me select the content types to filter by vs using the field settings.

But did notice a bug
I had 2 Articles, 1 with an entity reference value and 1 without
When I use the filter it shows duplicates of the 1 article with a reference. Imagine it would show any number of duplicates based on number of articles.

@smustgrave

One part that was odd to me, won't hold it up, but when adding the filter it let me select the content types to filter by vs using the field settings.

The "Reference selector" it's not a "field setting" ... but a "field instance setting"
Which means a field could be used with different "Reference type" ... on different bundles.
And i think it was discussed and "decided" in the original issue.

But did notice a bug
I had 2 Articles, 1 with an entity reference value and 1 without
When I use the filter it shows duplicates of the 1 article with a reference. Imagine it would show any number of duplicates based on number of articles.

I can't replicate this. Are there other "elements" in your install? Maybe multilingual or something?

@smustgrave checked again on duplicates

the only scenario is when we have multiple valued reference field and also multiple values selected for the filter.
Which is "normal" ... and with Aggregation we could get rid of duplicates.

So i can't see / replicate the bug.

Let's try NR ... so maybe there will find out is close to RTBC or ... not.

small update - FilterEntityReferenceTest for kernel file and class name ... as it's about the filter ... not field.

Tagging for subsystem maintainer as it seems this feature will require aggregation now.

@smustgrave

Tagging for subsystem maintainer as it seems this feature will require aggregation now.

This is usual ... the "same results" you'll get also for a List field with multiple values and filter options selected ...
So it's not about this filter in particular ... but filter multiple values for multiple valued field ...
just saying

Tested this again

Create a simple view of the Article content type with a filter for reference filter.
The filter is exposed and I see it in the preview.
The dropdown looks correct
But when I save the page and check the view page the filter does not appear.

@smustgrave do you mean no filter at all?
Not select input?

Or no select options.

This sound critical ... but could you, please, detail ... maybe screenshots for some steps?
Thanks

Actually not sure what I did wrong. Retested again and the filter appears now.

Think this is good for committer review.

Also not seeing the duplicates, didn't need aggregation.

In #2429699 comment #449 📌 Add Views EntityReference filter to be available for all entity reference fields Closed: duplicate , @Berdir answered the following when someone asked if the patch supports fields which reference configuration entities:

No, that's impossible, content and config entities can't be joined in a relationship, config entities are not stored in a way that allows an SQL JOIN to work.

That doesn't seem to be the case though. If I replace if ($target_entity_type instanceof ContentEntityTypeInterface) { with if ($target_entity_type instanceof EntityTypeInterface) { in core_field_views_data, it seems to work. My use case: I have an entity reference field on a node type, referencing webforms (a config entity type). After applying the patch and the change I just mentioned, I can add an entity reference filter listing all webforms, without issues.

Should we change this so it also works with config entities? I don't see why not.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

This problem also exists in Drupal 9.
I created a patch against 9.5.x based on 2 files from Drupal 11 commits in gitlab

This patch allowed me to add working exposed filter out of entity reference field that references content (nodes).
The probleme does not exist when the field references taxonomy terms.

The views filter should be of type "field_name as a Reference filter"

Updates on MR:
- Fix the CSpell Failures
- And update to Do not limit filters available to Content Entities, use EntityTypeInterface ... as mentioned on #86
But separate filter from relationships condition, as indeed they are not "compatible".
In this way also we have aligned the filter available and Views Filter (getReferencedEntityType(): EntityTypeInterface)

let's try some review.

Tried this out on a site we are developing.

The reference fields appeared correctly as Reference filters
Rendered as expected
Filtering is working perfectly.

Fingers crossed to getting in for 10.2

The to-do list in the summary could use an update as well. 🙂

attached a static patch for builds. This represents the MR 4053 at commit 1bc7bda7.

If we're adding support for config entities here, then we need the equivalent test coverage to confirm it works, so marking needs work and 'needs tests' for that. Another option would be to move that change to a follow-up, although the test coverage shouldn't be too bad to add.

Haven't done an in-depth review of the rest of the patch yet, just noticed this but added a couple of additional points from a quick look.

+++ b/core/lib/Drupal/Core/Entity/Plugin/EntityReferenceSelection/DefaultSelection.php
@@ -200,7 +200,7 @@ public function buildConfigurationForm(array $form, FormStateInterface $form_sta
-        '#value' => [],
+        '#value' => NULL,

This change is not correct, a NULL value for the target_bundles setting means "all bundles are referenceable", while an empty array (the current value in HEAD) means "no bundles are referenceable", so this is a behavior change in the default selection plugin...

@amateescu I agree the change seems odd since it will affect all entity selection handlers.
Here's an audit for the change to "core/lib/Drupal/Core/Entity/Plugin/EntityReferenceSelection/DefaultSelection.php":

• This commit introduced the change in the original MR 3629 before it was converted over to the current MR 4053- commit.
• It appears there was some discussion in #55 that suggested setting it to NULL to fix an issue with a custom entity type. Then it was committed in #73.
• This changed was not in the patch/MR on the original issue 📌 Add Views EntityReference filter to be available for all entity reference fields Closed: duplicate .

about the change

+++ b/core/lib/Drupal/Core/Entity/Plugin/EntityReferenceSelection/DefaultSelection.php
@@ -200,7 +200,7 @@ public function buildConfigurationForm(array $form, FormStateInterface $form_sta
-        '#value' => [],
+        '#value' => NULL,

This is needed in order to get the "bundless" entities - to work.
Without it. there are no "options" for the Referenced entities.

So the question, do we still need to keep this and make it work for entities without bundles.
or this change "won't" harm.

Updated the MR with some tests for Filter of Config Entities References.

The. node type config was used for Entity Reference Testing Field.

Agree with #91 if the issue summary bullets could be looked at.

Just for issue summary and tags update/cleanup.

Updates:

- Updated summary
- Change record draft available
- Remove tags: Needs issue summary update, Needs tests
- Add related issue, as the MR code contains this issue reference https://www.drupal.org/project/drupal/issues/2651418 🐛 Non-array values for #ajax RTBC

vasike → changed the visibility of the branch 3347343-continuation-add-views to hidden.

Appear to have 2 open threads from @catch that need to be addressed.

Thanks

I'm not sure if I've missed something obvious, but this change seems to cause views to pull in the refercenced entity with an inner join. This does not happen with the default NumericFilter where it becomes a left join. I had a cursory look at the code but couldn't find out where/why this happens, but perhaps someone more versed in views can have a look.

There was an attempt to cleanup the code about required "fields" for the selection handler options
https://git.drupalcode.org/project/drupal/-/merge_requests/4053/diffs?co...
And it "works" in the UI without issues.

But it seems the tests fails.
Something it's broken in the Views/Modal forms validations - or at least for required fields/elements.
And the extra code (setRequiredViaStatesOnChildren) helps for tests to pass.

Unfortunately ... there is no "FunctionalJavascript" tests on Filters with extra options (buildExtraOptionsForm)
or at least i couldn't see such tests.
That could help us here ... i'm also not aware on the other core issues related with those things.

So for now i just reverted the change to previous "state".

I still think the code could be cleaned up for both Filter plugin and its test.

Questions:
TaxonomyIndexTid / TaxonomyIndexTidDepth plugin filters do not have "FunctionalJavascript" tests, only "Functional" tests
Could we consider the same here. So maybe we don't need the "extra code" for this new filter?

@sthomen do you mean this change mentioned. could you please check again? as the change was reverted.
thanks

@vasike My apologies, I was just being dumb. Please ignore my comment.

There is a second attempt to clean up the MR code on both Views Filter plugin and its tests.

For Views Filter plugin the cleanup also tries to address/solve the 2 open threads
1. A todo about conditional required - removed the code, i think this "todo" will have small chances to be chased and solved soon
And, for now, it's not used (needed)
Also renamed the method for this setRequiredViaStatesOnChildren -> removeRequiredOfSubformChildrens
2. A "todo" about the extra options form validation. It seems the original issue has a related issue linked ... which it was missed when this new one was created
https://www.drupal.org/project/drupal/issues/3163740 →
So i cleaned up the code there and added the related issue url.
3. Re-arrange some code - to be easier to maintain/read

For tests code
I tried to cleanup - use similar code with existing code on filters ... with the same goal - - to be easier to maintain/read (toghteter with other related tests).

i hope we got closer to an end here

forgot to link the related issue

I needed this on a client site, and noticed that the entity reference filter doesn't show up for base fields.

This is easily solved with the following additional change:

diff --git a/core/modules/views/src/EntityViewsData.php b/core/modules/views/src/EntityViewsData.php
index eb964521af..19e898f12c 100644
--- a/core/modules/views/src/EntityViewsData.php
+++ b/core/modules/views/src/EntityViewsData.php
@@ -645,7 +645,7 @@ protected function processViewsDataForEntityReference($table, FieldDefinitionInt
         ];
         $views_field['field']['id'] = 'field';
         $views_field['argument']['id'] = 'numeric';
-        $views_field['filter']['id'] = 'numeric';
+        $views_field['filter']['id'] = 'entity_reference';
         $views_field['sort']['id'] = 'standard';
       }
       else {

However, changing the filter type (as opposed to adding an extra field in the views data), is not compatible with the current approach taken here.

I am wondering why the approach was changed to add an extra field, it adds a lot of noise to the UI when the 99.99% use case will be to use this filter anyway. I don't see how this can be applied to base fields without either changing the approach, or refactoring EntityViewsData to allow field types to produce multiple fields, or hard coding this reference type in there somewhere.

Also added a couple of review points to the MR.

Apart from those issues, this looks close and it would be great to close it before this continuation issue is as long as the original.

I am wondering why the approach was changed to add an extra field, it adds a lot of noise to the UI when the 99.99% use case will be to use this filter anyway. I don't see how this can be applied to base fields without either changing the approach, or refactoring EntityViewsData to allow field types to produce multiple fields, or hard coding this reference type in there somewhere.

That happened way back here after chatting with lendude at Drupal Dev Days.
https://www.drupal.org/project/drupal/issues/2429699#comment-14472189 📌 Add Views EntityReference filter to be available for all entity reference fields Closed: duplicate

If I remember correctly, without this MR you can set up the reference field to eg find all node IDs >= 1000, but switching to an entity reference you lose the more math related options like that. While it seems like edge case, it is possible users are using the field as is to do such things. So a separate field seemed the only way to not break existing sites.

Some thoughts about the change https://git.drupalcode.org/project/drupal/-/merge_requests/4053/diffs?co...

Why, imho, NULL value will not harm at all (there).

1. It's a form value element for entities that doesn't have a bundle key

    if ($entity_type->hasKey('bundle')) {
       ....
    }
    else {
      $form['target_bundles'] = [
        '#type' => 'value',
        '#value' => NULL,
      ];
    }

2. defaultConfiguration has NULL value

3. The field settings will save actually NULL value for entities without bundle
@see validateConfigurationForm
Result

uuid: 0918c28c-2a5d-49b0-8c33-ee7855dd23a9
langcode: en
status: true
dependencies:
  config:
    - field.storage.node.field_type
    - node.type.article
id: node.article.field_type
field_name: field_type
entity_type: node
bundle: article
label: Type
description: ''
required: false
translatable: false
default_value: {  }
default_value_callback: ''
settings:
  handler: 'default:node_type'
  handler_settings:
    target_bundles: null
    auto_create: false
field_type: entity_reference

4. And of course the "docs" about NULL vs [] "results"

      // For the 'target_bundles' setting, a NULL value is equivalent to "allow
      // entities from any bundle to be referenced" and an empty array value is
      // equivalent to "no entities from any bundle can be referenced".

So my conclusions are:
1. The Change to NULL should not break anything
2. DefaultSelection could be improved for "bundless" entities
3. Subforms and validations not working "great" on Views Filters.

@catch what do think?
thanks

MR updated ... trying new approach to make it work for entities with no bundle.

As part of the conclusions from #112, about DefaultSelection
I noticed that the configuration form validation "imagines" that we have a field settings form.
Which means the validations there won't work in another forms.

So i moved the validations from form validation to elements validations - for portability.
And it should work.

p.s. i still "believe" in things i shared on #112

Unfortunately ... the MR started failing ... PHPStan ... and the last one looks odd ....

If there's anyone that could help with this error?
thank you

That's a tough one, applied locally and even phpstorm isn't picking up on that. Usually phpstorm is good with those kind of pickups.

Fixed the PHPStan errors.
However now we have the "CSpell" CI issue ...
https://www.drupal.org/project/drupal/issues/3401988 🐛 Spell-checking job fails with "Argument list too long" when too many files are changed Active

Re #111, could this be handled as a backwards compatibility break in a major release? Alternatively, I wonder about creating a small contrib module to switch the definition..

@DamienMcKenna with all my respect, I would say that, this is "out of box" issue.

2 things
- Views is in Core
- EntityReference is in core

What's not in core ... is Views and EntityReference "real integration"
This is just a small part to involve more people to help with Views ... is far from "core" ... yet ... imho

But thanks for your thoughts.

@vasike: Apologies that I wasn't clear, I was talking about to the suggestion in #110 to simply change core's field specification to use "entity_reference" instead of "numeric"; could this change be introduced as a breaking change, maybe with documentation on how to use the field as a number?

With regards to 🐛 Spell-checking job fails with "Argument list too long" when too many files are changed Active there is a work around posted to the ticket but I'm not super clear how to best do it.

Re #111 / #116 perhaps best is to:

1. get this in using current approach of additional filter

Then in follow-up (because all the below is a lot of work in itself and big scope increase):

1. deprecate use of original filter math options (ideally specifically the ones nk longer available
2. add change record
3. add update hook to convert the additional filter from this issue back to original name

If that's at all possible / interesting perhaps that discussion can be had in a postponed issue to avoid this issue growing too big again

This issue was hit by the issue mentioned in #119, but also the fact that the branch 11.x wasn't even present in the fork (I think this is another core issue).

I brought 11.x to the fork and the MR should now run. I have no more context on the issue so not sure if it should be back to "Needs review" or still "Needs work".

@catch

I don't understand why this is being done - it adds clutter to the views UI, and the current entity reference filter just looks broken when exposed. When it's not exposed, will there even be a difference?

What are you seeing that appears broken exactly?

@smustgrave I mean that if you expose an entity reference filter in HEAD, then you get an empty text field with no indication of what to put in it, which to me looks broken and I doubt people are using it much as-is. Given that, I think we should consider applying the new behaviour to the existing filter, not adding a separate one alongside. This would also help with applying it to base fields, which the MR currently does not.

There are ways to use it and I've done it before. For example in combination with grouped filters, which obviously doesn't scale, but is a decent workaround when you have for example a config entity reference with only a handful options.

Re #125 you could be using the filter without exposing it though, eg all node IDs >= 1000. Ie, not useful for a visitor but possibly useful for a site builder?

As per my response in #111 that's why chats with @lendude suggested that would be the most realistic way to get this in core.

I would also prefer to not have the extra filters in an ideal world and replace instead if you think we can get away with just a change record but I am concerned this then never gets in as many of us have spent chunks of time on this over the years and the goal-posts changing makes it tough of course.

Would you be the one signing off on this eventually or should we seek review from a different core committer as well?

Asking first because, if we go through route, it's probably a fair amount of work to change the MR but also then possibly further extend the MR to need update hooks (and upgrade tests?). So I think we should probably agree scope and ensure agreed scope has a realistic path to actually making it in before actioning a change of approach... Or agree to keep the current scope

Would love if this doesn't get re-scoped at this point of it. If it could be improved in follow ups +1 for that.

@scott_euser I'll try to get a second and if possible third or more opinion from other core committers so this doesn't get turned around again.

@Berdir same question as #127 - is that exposed to site visitors, or exposed at all?

I open a "thread" on slack
https://drupal.slack.com/archives/C6SQM2J94/p1706633005193429

Also added to summary

And I'm wondering if it's not more efficient for discussions than to "fill-up" issue comments

p.s. maybe it could be a way for drupal.org to have a slack url about discussion on some issues.

just thinking aloud

sorry for the noise.

Updated issue summary to reflect need to add support for base fields into this as per message from @catch in Slack.

Also moving back to Needs Work since there are other items in the list that are not yet completed as well.

Support for base fields added, but needs tests (updated issue summary).

A good example is 'uid' field in default Files view, so an easy way to try this locally:

• Before update: admin/structure/views/view/files only User ID available
• After update: admin/structure/views/view/files only User ID and User ID as a reference available

Problem at the moment is HandlerAllTest::testHandlers() fails on Comment 'Parent ID' base field, its getting allowed to use the new 'entity_reference' filter handler, but then something inside the new filter handler does not like that as a target. I ran out of time at the moment in case anyone wants to pick this up, otherwise I will try to pick it up myself again later.

I suspect sorting that issue will sort out the tests (unless there are further issues with supporting base field).

Okay tests passing now + new test added for base field reference.

So just comments from #49 left to address.

I have this merge request running in a patch on my Drupal 10.1 site. It was running fine until recent updates made to it. Now Composer wont patch it into core using "cweagans/composer-patches". Am i the only one with this issue? What should I do to get this working again the way it was? "https://git.drupalcode.org/project/drupal/-/merge_requests/4053.patch" I'm probably not the only one.

Any thoughts on how to proceed would be appreciated as its currently blocking my monthly maintenance. Thanks.

Hi @Deasly.

The merge request is meant to target Drupal 11 and it needs to continue to do so in order to eventually get in.

In the future, best to be downloading the patch file into your project and committing it, so you reference the local file, see here for details → . It also talks about how you can do a git diff to make your own patch. The challenge here is you need to find the commit id of a version in the merge request that you are happy with then the commit ID eg of latest 10.2 Drupal (which I am guessing you are trying to update to). Then its `git diff new-commit-id old-commit-id > patch-file-name-here.patch. Will see if I can add a bit more to that doc page to help make that more clear.

Hope that helps!

scott_euser → changed the visibility of the branch 10.1.x to hidden.

scott_euser → changed the visibility of the branch 10.2.x to hidden.

scott_euser → changed the visibility of the branch 11.x to hidden.

Sorry for the noise here, not sure an easier way to help others out that want to use this in 10.2.x as I realise its a challenge to resolve conflicts as soon as the 11.x MR starts to become incompatible with 10.2.x like it is.

I created a branch which people should be able to use the diff from to create a local patch BUT please bear in mind the code is just cherry-picked from the Drupal 11 Merge Request code and its therefore very possible that code is referenced that only exists in Drupal 11 and does not exist in Drupal 10 which can lead to errors, so do use with caution.

Regarding #49 I have updated the issue summary with outstanding items. Details below:

calculateDependencies is untested and should be since this is different than the Term plugin

Added tests mimicking the coverage that TaxonomyIndexTidFilterTest::testConfigDependency() provides.

The 'sort by' field is empty on initial adding of the filter (the field widget does something ajaxy when selecting bundles, the views widget does not, might be it?)

I could not spot a 'sort by' when using a field widget on an entity reference field. Is it possible to provide further steps?

Grouped autocomplete filters don't work/save (but don't work for taxonomy ref filters either), please find the related issue or open it (should be one I think)

Here is the related issue I think 🐛 Grouped exposed taxonomy filter fails validation for autocomplete widget Needs work .

Description "as a Reference filter" feels a bit vague, did we get UX feedback on this?

Perhaps this should be dealt with in the deprecation dance when the old filter gets removed. Added as a follow-up task.

Should we add this new filter for taxonomy terms too, or should we skip those since it is unclear what the difference is now when have to chose between the two different filters

We have this as a follow-up now 📌 Convert TaxonomyIndexTid to use new EntityReference filter Active .

I can create a circular reference by creating an Entity reference View that uses itself as the filter, not sure what goes wrong (mostly getting an empty filter after saving), but that sounds iffy
Maybe related : Managed to click my way into "Warning: Undefined array key "reference_views" in Drupal\views\Plugin\views\filter\EntityReference->submitExtraOptionsForm() (line 440 of /app/drupal/core/modules/views/src/Plugin/views/filter/EntityReference.php)"

Needs work - added to issue summary as a task

Node titles in the select element are double escaped

Needs work (I can see this works in TaxonomyIndexTid, so its not a wider problem) - added to issue summary as a task

Exposed filters on the chosen entity reference view are also shown on the view

Needs work - added to issue summary as a task

veggieryangrace → changed the visibility of the branch 10.2.x to active.

smustgrave → changed the visibility of the branch 3347343-10-2-x--do-not-merge to hidden.

smustgrave → changed the visibility of the branch 10.2.x to hidden.

Just to avoid any confusion I hid the other MRs but left a small note in the summary.

Tested out the latest changes

Standard Profile install
Added a content reference to the Article content type, using basic page as the target
Created a few basic page nodes
Created a few article referencing those basic pages
Updated the content view to use Content (field_content) as a Reference filter
I was able to setup as a dropdown no problem
Filters worked as expected
No errors in logs.

+1 RTBC from me but will leave in review for additional eyes.

New commit to remove a "@todo" from code ... about ajax property on Entity Reference Selection plugin.
From related issue https://www.drupal.org/project/drupal/issues/2651418 🐛 Non-array values for #ajax RTBC

please check the latest comments there.

I'm a little confused by this thread (it's quite long and convoluted), but is there a patch/MR that works against D10? I've got a client yelping about this. :D

Under the branches listed at the top, click to show hidden branches and see '3347343-10-2-x--do-not-merge' - is has a port of the 11x merge request for 10x sites.

FYI been using this for about a week on client side on our content view, have a dropdown for a taxonomy field and user reference field.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Solved conflicts and also new CS issues
However it seems there are other things going on for CI
As the new Validatable config job ... which, of course it fails

Probably this should be covered by a child issue
https://www.drupal.org/project/drupal/issues/2869792 🌱 [meta] Add constraints to all config entity types Active
... which seems ... missing
"Not ideal ... to be polite"

I put the issue for Review ... just to gain some attention
As the feeling is that it could become stalled ... as original ... for other years.

p.s. also linked those issues ... maybe there we could have more awareness

Not an input to the issue, just a patch for 10.2.x