For the Drupal 7 version of this issue, see #2010898: Use tokens for entity selection view arguments.

Entity Reference allows using a View of a specific display type to set the available options. This is good.

It's also possible to set arguments (contextual filters) on that view from the ER field config screen. This is also good.

Those arguments must be completely static. This is not good.

Rather, it should be possible to have dynamic, context-aware arguments. The most obvious is "the node that this is on", allowing the view to filter based on the node itself. Ideally, other "relational" contexts (Panels-style, or maybe just via token if that's easier) should be possible, such as "the author of the node this is on", "the OG of the node this is in" (my actual use case), etc.

That would greatly expand the potential flexibility of that view to do all sorts of context-aware select lists.

Of course, there's the obvious problem of what to do when creating a node (or user, or whatever other entity) the first time, since there is no "this" yet to refer to. I see two possible ways to address that:

1) Allow for a default value, or a different context to pull from if null. Eg, if there's no node owner, default to the current user. This would be configurable.

2) Punt that question to the View, where there is already fairly sane default argument capability. As long as we are able to do relational arguments, so that the contextual filter on the View doesn't have to be the entity type that it is on, that's probably sufficient and easier to implement anyway.

In my specific use case, I want to have an ER from a node to other nodes of type Foo that are in the same OG as the node being edited; if the node is being added, default to the user's OGs. The same concept would apply in many other situations, of course, such as related posts by the same author, etc.

(The current alternative involves writing a completely new custom views default argument plugin for every use case, which is highly sub-optimal.)

Thinking about it, I believe tokens would likely be the most straightforward way to specify such values.

So:
1) Is this feature something that would be accepted?

2) I MAY be able to get some time to work on this for the client project that requires it, if I knew it would be accepted so that we're not working with a project fork. :-) Is this doable? (If not, we'd have to fall back to the one-off above.)

CommentFileSizeAuthor
#258 interdiff-255-258.txt1.04 KBmariacha1
#258 1699378-258.patch12.61 KBmariacha1
#255 1699378-255.patch12.54 KBameymudras
#254 1699378-254.patch12.36 KBandreastkdf
#253 1699378-allow-views-token-D9.5.9-1.patch12.39 KBSocialNicheGuru
#252 1699378-allow-views-token-D9.5.9.patch12.51 KBSocialNicheGuru
#249 1699378-249.patch12.44 KBmariacha1
#247 1699378-247.patch12.41 KBmariacha1
#247 interdiff_245_247.txt646 bytesmariacha1
#245 1699378.patch12.53 KBJon Pugh
#244 interdiff_243_244.txt1.5 KBameymudras
#244 1699378-244.patch12.86 KBameymudras
#243 1699378-243.patch12.63 KBameymudras
#241 1699378-241.patch12.63 KBmaurizio.ganovelli
#239 1699378-239.patch12.56 KBcgrader
#235 interdiff_1699378_233-235.txt655 bytesankithashetty
#235 1699378-235.patch12.74 KBankithashetty
#233 1699378-233.patch12.75 KBaludescher
#225 interdiff-1699378-222_225.txt3.28 KBGauravvvv
#225 1699378-225.patch13.54 KBGauravvvv
#223 1699378-223-9.2.x-core-allow-tokens-in-entity-reference-views-selection-args.patch13.75 KBbarrio
#222 1699378-222-9.2.x-core-allow-tokens-in-entity-reference-views-selection-args.patch13.53 KBNigel Cunningham
#221 210-221-interdiff.txt7.09 KBNigel Cunningham
#221 1699378-221-core-allow-tokens-in-entity-reference-views-selection-args.patch12.82 KBNigel Cunningham
#220 210-219-interdiff.txt7.51 KBNigel Cunningham
#220 1699378-219-core-allow-tokens-in-entity-reference-views-selection-args.patch13.27 KBNigel Cunningham
#218 1699378-218-core-allow-tokens-in-entity-reference-views-selection-args.patch12.84 KBNigel Cunningham
#217 1699378-217-core-allow-tokens-in-entity-reference-views-selection-args.patch13.39 KBNigel Cunningham
#216 core-allow-tokens-in-entity-reference-views-selection-args.patch11.59 KBNigel Cunningham
#212 1699378-210--on-90x.do-not-test.patch9.96 KBmparker17
#212 1699378-210--on-89x.do-not-test.patch10.05 KBmparker17
#210 interdiff_208-210.txt3.88 KBnikitagupta
#210 1699378-210.patch9.53 KBnikitagupta
#208 drupal-dynamic_views_arguments_via_tokens-1699378-208.patch8.23 KBanushrikumari
#204 interdiff-196-200.txt763 bytesjungle
#200 drupal-dynamic_views_arguments_via_tokens-1699378-200.patch9.87 KBQandeel
#198 drupal-dynamic_views_arguments_via_tokens-1699378-198.patch..diff9.89 KBQandeel
#196 drupal-dynamic_views_arguments_via_tokens-1699378-196.patch9.74 KBfrega
#195 drupal-dynamic_views_arguments_via_tokens-1699378-195.patch9.8 KBfrega
#194 drupal-dynamic_views_arguments_via_tokens-1699378-194.patch9.75 KBfrega
#189 drupal-dynamic_views_arguments_via_tokens-1699378-189.patch10.87 KBcolan
#188 interdiff-1699378-184-188.txt1.45 KByogeshmpawar
#188 1699378-188.patch9.12 KByogeshmpawar
#184 drupal_dynamic_views_arguments_1699378-184.patch9.45 KBandeersg
#174 1699378_172-174_inter.diff695 bytesPancho
#174 drupal_dynamic_views_arguments_1699378-174.patch9.96 KBPancho
#173 1699378_172-173_inter.diff698 bytesPancho
#173 drupal_dynamic_views_arguments_1699378-173.patch9.96 KBPancho
#172 token_module_followup_1699378_172.patch1.05 KBPancho
#172 1699378_169-172_inter.diff751 bytesPancho
#172 drupal_dynamic_views_arguments_1699378-172.patch9.91 KBPancho
#169 interdiff-1699378-156-169.txt2.38 KBPQ
#169 entity_autocomplete_1699378_169.patch9.41 KBPQ
#156 interdiff-1699378-148-156.txt6.33 KBmanuel.adan
#156 entity_autocomplete_1699378_156.patch8.75 KBmanuel.adan
#149 interdiff-1699378-145-148.txt906 bytesandreyks
#148 entity_autocomplete_1699378_148.patch4.56 KBandreyks
#145 entity_reference_views_token-1699378-145.patch4.21 KBhowards
#142 drupal_8_4_0_entity_reference_views_token_patch.patch5.49 KBThomasHuong
#139 entity_reference_views_token-1699378-139.patch6.19 KBvalidoll
#135 druapl_8_3_2_entity_reference_views_token.patch5.48 KBbrtamas
#134 drupal_8_3_2_entity_reference_views_autocomplete_token.patch3.8 KBbrtamas
#130 drupal-1699378-130-dynamic_views_arguments.patch2.86 KBpk188
#128 drupal-1699378-128-dynamic_views_arguments.patch2.86 KBpk188
#120 drupal-1699378-120-dynamic_views_arguments.patch2.87 KBkurowski
#118 drupal-1699378-118-dynamic_views_arguments.patch2.89 KBkurowski
#110 drupal-1699378-110-dynamic_views_arguments.patch2.82 KBhowards
#106 drupal-1699378-106-dynamic_views_arguments.patch2.84 KBhowards
#104 drupal-1699378-104-entity-ref-views-arg.patch7.56 KBgapple
#101 drupal-1699378-101-entity-ref-views-arg.patch7.53 KBgapple
#99 drupal-1699378-98-entity-ref-views-arg.patch6.33 KBgapple
#97 drupal-1699378-97-dynamic_views_arguments.patch2.82 KBgapple
#94 drupal-1699378-94-dynamic_views_arguments.patch3.27 KBgeek-merlin
#73 1699378-token-replacements-for-entity-reference-views-selection-arguments-72.patch3.44 KBjpstrikesback
#75 1699378-token-replacements-for-entity-reference-views-selection-arguments-75.patch3.54 KBjpstrikesback
#71 token-replacements-for-entity-reference-views-selection-arguments.patch3.44 KBjpstrikesback
#63 view-argument-as-token-1699378-63.patch5.31 KBdysrama
#61 Screen Shot 2013-04-10 at 8.50.48 AM.png37.43 KBStriky2
#46 view-argument-as-token-1699378-46.patch5.6 KBjpstrikesback
#43 view-argument-as-token-1699378-43.patch5.6 KBMegaChriz
#26 Skærmbillede 2012-10-29 kl. 07.14.28.png156.19 KBlsolesen
#26 Skærmbillede 2012-10-29 kl. 07.14.57.png29.33 KBlsolesen
#26 Skærmbillede 2012-10-29 kl. 07.15.28.png104.37 KBlsolesen
#27 view.txt16.23 KBlsolesen
#41 view-argument-as-token-1699378-41.patch4.6 KBlsolesen
#31 view-argument-as-token-1699378-31.patch4.87 KBlsolesen
#33 view-argument-as-token-1699378-32.patch4.88 KBlsolesen
#30 view-argument-as-token-1699378-30.patch4.36 KBlsolesen
#29 view-argument-as-token-1699378-29.patch4.3 KBlsolesen
#28 view-argument-as-token-1699378-28.patch4.31 KBlsolesen
#23 Error.JPG151.78 KBjadsam
#19 view-argument-as-token-1699378-19.patch4.33 KBguile2912
#17 view-arguments-as-token-1699378-17.patch3.86 KBguile2912
#14 view-arguments-as-token-1699378-14.patch3 KBguile2912
#7 1699378-token-arguments.patch3.74 KBCrell
#4 view-arguments-as-token-1699378-4.patch3.12 KBguile2912

Issue fork drupal-1699378

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:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kholloway’s picture

I understand your frustration with this and came up with a work around:

I am using OG and needed to make an entity reference field on the Group Node to show all nodes that belong to that group.

There is a view that comes with OG that already does this. The problem is I couldn't pass the group ID (GID) of the current node to the view through the entity reference field.

The default "What to do when Filter NOT found" list wasn't helping at first. Group Context, NID from URL, weren't working.

Basically in the end I inspected the $field_state of the actual edit form itself (Devel or var_dump) and was able to access the auto-complete path inside the fields array:
$field_state->YOURFIELDNAME->...->['settings']['handler_settings']['view']['args'] (Think language ['und'] and [0] are part of the ... part as well).

All that to find that the auto-complete path (which is what the view sees) was:
/entityreference/autocomplete/single/YOURFIELDNAME/node/CONTENT_TYPE_NAME/NID

So, all you have to do to grab the NID (Or any of the other field information you get from that URL) is set your view to use the "Raw value from URL" option if filter is NOT present and set it for the correct offset. In this case NID is 7.

LONG STORY SHORT: (Read the last paragraph).

John Pitcairn’s picture

The ability to use tokens in the entityreference view arguments would be terrific, and I'd certainly use it that it were included in entityreference.

Crell’s picture

deviantpixel: Thanks, that sounds like a clever workaround. It only works for autocomplete-based widgets, though. If I have a select-based widget, there's no autocomplete to draw from.

guile2912’s picture

Status: Active » Needs review
FileSize
3.12 KB

This module is so great and I needed this , so here you go. Using tokens like [current-page:url:unaliased:args:value:1] makes this sooo powerfull :)
This patch if for the dev version, havent tryed it on rc3 yet . Please test it so we can have this included as soon as possible ! Thank you.

elliotttf’s picture

Status: Needs review » Reviewed & tested by the community

The patch in #4 works for me. The token to get a node id feels kind of hackish but I seem to recall that there's not a clean way to get at node tokens on node edit forms.

Crell’s picture

Status: Reviewed & tested by the community » Needs work

The aptch in #4 is lacking any token help. No one I know can write token strings from memory. :-) It needs the token help information attached. I'll work on that and report back.

Crell’s picture

OK, my error. It does include the token selector thingie, but only if token module is enabled. :-) We should probably expose the token functionality only if token module is enabled. The attached patch does so.

Also, this only handles global tokens. Tokens based on the entity the form is on would be even better. However, we can probably save that for a follow-up patch.

Crell’s picture

Status: Needs work » Needs review
robcarr’s picture

Wow! Thanks for working on this. The patch seems to work well, although I'm struggling to work out what the tokens would be for fields on the current form, so can't say how well it works on tokens relating to the current entity being edited. Tested with tokens relating to current user and site - fantastic.

Great feature, so hope it can be committed soon.

Crell’s picture

arrrgh: What you're talking about are contextual tokens, eg, the $node being edited or the $user being edited. That's what I was referring to in #7. The trick there is that on entity add pages those will always be empty, so you need to have some sort of sane default handling or else build your view to have sane default handling. And even then, it would only apply to the node as it was saved previously; dynamically updating the form client-side is a totally different animal.

Damien Tournoud’s picture

Status: Needs review » Needs work

Oooo, nice patch!

+      if (module_exists('token')) {
+        $description = t('Provide a comma separated list of arguments to pass to the view. You may also use the tokens provided below.');
+      }
+      else {
+        $description = t('Provide a comma separated list of arguments to pass to the view. Install the <a href="@url">token module</a> to allow for dynamic values.', array('@url' => 'http://drupal.org/project/token'));
+      }

^ The token module is actually only required to display the list of tokens in the UI, let's rewrite this so that it works.

   protected function initializeView($match = NULL, $match_operator = 'CONTAINS', $limit = 0, $ids = NULL) {
     $view_name = $this->field['settings']['handler_settings']['view']['view_name'];
     $display_name = $this->field['settings']['handler_settings']['view']['display_name'];
-    $args = $this->field['settings']['handler_settings']['view']['args'];
+    $args = array_map( 'token_replace', $this->field['settings']['handler_settings']['view']['args'] );
     $entity_type = $this->field['settings']['target_type'];

^ This one is not used and should just go away.

-    $args = $this->field['settings']['handler_settings']['view']['args'];
+    $args = array_map( 'token_replace', $this->field['settings']['handler_settings']['view']['args'] );

^ We should use the proper context we have instead of a global token replacement. The entity type and entity being edited is passed by entity reference to EntityReferenceHandler::getInstance(). We can leverage it here.

Crell’s picture

Since the token module provides the UI, and the token system is basically unusable in a GUI without the token UI (really, does anyone remember token strings by heart? I don't), I think only enabling when token module is available is reasonable.

I left out the contextual instance above on simplicity grounds for now (and because my use case found an alternate approach, so I didn't have much further time to spare on this issue :-( ). Do you want that now, or in a follow-up patch?

guile2912’s picture

Well you should be able to disable the Token UI if you want , and still have the system working (otherwise, I would call this a bug).
So I the token module is available, show the help, otherwise, tell that you can have help if you activate it.

guile2912’s picture

So here is a new patch.
It now manages the fact that the module "token" may not be available as Crell stated, and add a small sentence about it.
I took off what you said what not used.
I also had a deeper look into the context, but I have a bad news about it.

Because the entity reference fields does not know where it is the is nowhere we can get the nodeid being edited for example. So we cannot pass it to the token_replace function to have access to node tokens. I think that we may only be able to access global tokens on this one.

For info, help texts are split on purpose, because those strings may already be translated. If I glue them together, we would have to wait for them to be translated again.

guile2912’s picture

Status: Needs work » Needs review

So I guess it would be nice to have this little working piece of code to start with, and maybe later find a solid way to get the info we miss for now.

Damien Tournoud’s picture

Status: Needs review » Needs work

As I mentioned in #11:

The entity type and entity being edited is passed by entityreference to EntityReferenceHandler::getInstance()

Not having a proper entity in the token data makes this patch essentially useless.

guile2912’s picture

Status: Needs work » Needs review
FileSize
3.86 KB

You are really hard in business !!
I was so near of it before (but my test site uses filed collections, so that make things a little more complex) and here it works.
So here is a working patch with the entity in the token.

Damien Tournoud’s picture

Status: Needs review » Needs work

That's getting closer. Thanks for the hard work!

+          '#token_types' => array($instance['entity_type']) , // The token types that have specific context. Can be multiple token types like 'term' and/or 'user'

You are hardcoding the token type as the entity type here, which is a wrong assumption. For example, tokens for the taxonomy_term entity are called term. The Entity API module provides us with a 'token type' key in the entity info. You need something like this:

$entity_info = entity_get_info($entity_type);
$token_type = isset($entity_info['token type']) ? $entity_info['token type'] : $entity_type;
guile2912’s picture

Status: Needs work » Needs review
FileSize
4.33 KB

That was a good catch. You nearly wrote the whole code ^^
So here it is again, with the use of the entity_get_info everywhere where we need the token type.

MustangGB’s picture

Status: Needs review » Needs work

Basic functionality works on node edit pages, however not on node add pages. This is because, in my case, [node:field-testing:nid] is not tokenified. I think instead "When the filter value is NOT available" should be triggered, so I made the following changes:

public function getReferencableEntities($match = NULL, $match_operator = 'CONTAINS', $limit = 0) {
  ...
+  $args = array_map('token_replace', $this->field['settings']['handler_settings']['view']['args'], array(array($this->entity_type_token => $this->entity)), array(array('clear' => TRUE)));
  ...
+  $result = $this->view->execute_display($display_name, (!array_filter($args) ? array() : $args));
  ...
}

Also it isn't able to pick-up field values that have been set with "entityreference_prepopulate".

How can we link this in with views ajax to get the select list autoupdated when, again in my example, the field-testing field is updated. This is an issue on both node add and edit pages.

Comments should probably be cleaned up as well, spaces after //, start with capital letter, finish with full stop, full sentences rather than fragments, no spaces after ( or before ).

Anonymous’s picture

Thanks for this great patch! Using Drupal 7 with Postgresql, if the module 'Entity tokens' is installed , the process of triggering the field edition interface will run forever until displaying an error message related to memory allocation (http://drupal.org/node/1215630). after switching off the module 'Entity tokens', I got the patch seems to do his wonderful job: I can select the view argument among the tokens ([node:field_leadingorganization]) that will be passed to my entity reference view. But after that I get swamped in the reference view : how do I set the default value for the contextual filter . Do I use 'Raw value from URL' (how to guess the argument nr?) or PHP code?

MustangGB’s picture

So I've been trying to figure out the whole "dynamically updating the form client-side" however upon rebuilding the form the value in $this->entity does not change. Am I right in thinking this is because $this->entity only contains the saved data? If so how can I access the new form data in getReferencableEntities?

jadsam’s picture

FileSize
151.78 KB

Hi,
Thanks for the post # 20

public function getReferencableEntities($match = NULL, $match_operator = 'CONTAINS', $limit = 0) {
...
+ $args = array_map('token_replace', $this->field['settings']['handler_settings']['view']['args'], array(array($this->entity_type_token => $this->entity)), array(array('clear' => TRUE)));
...
+ $result = $this->view->execute_display($display_name, (!array_filter($args) ? array() : $args));
...
}

I currently need this piece of code to add and/or modify nodes, however after applying the changes following the instruccions a got the error included in the Error.JPG file.

I will really appreciate any comment you can provide about this.

Thanks in advance.

willieseabrook’s picture

Wow, what a great patch. #19 is working for me.

I have a URL like: /admin/commerce/orders/8888/message/add

Under Field Settings / Entity Selection / View arguments I have: [current-page:url:unaliased:args:value:3]

And it's working great - passing the 8888 into the view as an argument.

lsolesen’s picture

This comment has been moved into #1826676: Using the wrong id as key in the returned view when using views selection as it turned out it had nothing to do with this patch.

lsolesen’s picture

lsolesen’s picture

Status: Needs review » Needs work
FileSize
16.23 KB

DISREGARD THIS COMMENT.

lsolesen’s picture

Status: Needs work » Needs review
FileSize
4.31 KB

Rerolled. Cleaned up the comments and fixed some whitespace errors.

@akumustang: Could you try to implement your changes proposed in #20 in a changed patch?

lsolesen’s picture

Hm, missed some whitespace.

lsolesen’s picture

Moved comments above lines.

lsolesen’s picture

DON'T USE THIS PATCH.

Status: Needs review » Needs work

The last submitted patch, view-argument-as-token-1699378-31.patch, failed testing.

lsolesen’s picture

DON'T USE THIS PATCH.

MegaChriz’s picture

Status: Needs work » Needs review

@Isolesen #31
There shouldn't be a check for the token module when doing token_replace(), because that function is in Drupal core (since Drupal 7). See also #13 of this thread.

lsolesen’s picture

@MegaChriz One learns something everyday. Thanks. Then #30 is the proposed patch. Though I still haven't been able to solve #25 in the patch.

guile2912’s picture

It seems that the patch #30 does not have the changes the #20 to have the functionnality of views "When the filter value is NOT available" working, Why ? Does it needs more testing ? ( I will give it a go soon )

lsolesen’s picture

@guile2912 Because I was not sure how that worked and was not sure how to test it.

MegaChriz’s picture

In think the changes in #20 are left out in #30 because of the problems noted in #23.

lsolesen’s picture

@MegaChris Though I could not reproduce what was reported in #23 when trying to include that change in the patch.

guile2912’s picture

I am not sure either the #20 was the cause of the error #23 because #23 occurs because the view had problems beeing initialised ($view object does not exist ) and the #23 patch is just a rewrite of the argument string.

#21 is an error of entity_token, so we are good on our side.

I just tested #20 and it works great, providing the "When the filter value is NOT available" view behavior as expected.

So I guess we can put it in a patch and give it a go :)

lsolesen’s picture

Now including comments in #23.

jadsam’s picture

Status: Needs work » Needs review
MegaChriz’s picture

I have tested the patch #41. I've found two problems with it:

  1. An error message is displayed when creating a new node when using [node:nid] as the View arguments.
  2. Only the first argument gets replaced with tokens from the entity.

An error message is displayed when creating a new node when using [node:nid] as the View arguments

I added an Entity Reference field to a node type and I had set the View argument to [node:nid]. When editing an existing node, this lead to the desired results: the Node ID was passed to the View. But when adding a new node, that node doesn't have an ID yet and this resulted into the following error message:

Notice: Undefined property: stdClass::$nid in node_tokens() (regel 112 van /Websites/drupal/drupalsites/drupal7/modules/node/node.tokens.inc).

That leads me to think the following: maybe we should only pass the entity to token_replace() when the entity has an ID?

Only the first argument gets replaced with tokens from the entity

Look at the following piece of code (part of patch in #41):

$args = array_map('token_replace', $this->field['settings']['handler_settings']['view']['args'], array(array($this->entity_type_token => $this->entity)), array(array('clear' => TRUE)));

This will result into that only for the first Views argument the entity will be passed to token_replace(). I have tested to pass two node tokens to Views and this resulted in the following error message:

Recoverable fatal error: Argument 2 passed to token_replace() must be an array, null given in token_replace() (regel 79 van /Websites/drupal/drupalsites/drupal7/includes/token.inc).

So my suggestion is to just use a foreach instead of array_map().

Patch

The attached patch addresses problem 1 and 2 (in addition of the patch in #41). Since token replacement happens in two places, I re-introduced the method handleArgs() (it was previously introduced by lsolesen in #31) where the token replacement takes place.
The entity will only be passed to token_replace() when the entity has an ID. This is checked by calling entity_extract_ids().

derekw’s picture

Disregard

pmichelazzo’s picture

Great! #43 Working like a charm! Thank you!

jpstrikesback’s picture

Quick change to fix a whitespace error, otherwise works.

jpstrikesback’s picture

Status: Needs review » Reviewed & tested by the community

This works wonderfully...I'm going to RTBC this myself as all I changed was whitespace.

sweethilit’s picture

Hi guys
I used the patch and it works fine for me.
The problem I am having now is that the field I am using for the token is another entity selection.
But when I change the selection of the field, the dynamic field does not change.
That is, I have a "location" field and a "Hotel" field.
I want the "hotel" field to populate according to the selection in the "location" field.
The "hotel" field draws its content from Entity selection view with a token argument (The token is the "location" field).
What I am looking for is to achieve an outcome in which the hotel field will change according to the selection in the location field.
Any help will be appreciated
Thanks,
sweethilit

Jelle_S’s picture

Patch works like a charm. #48 looks like it should be in a separate feature/support request. It's out of scope for this patch.

RTBC++

Jelle_S’s picture

Summit’s picture

maxplus’s picture

Wow great, works for me, thanks!

jadsam’s picture

Hi all,
I am a little bit confuse about how to implement this.
The user Crell at the begining of this threat said "The most obvious is "the node that this is on", allowing the view to filter based on the node itself".

If I try to update a content already created the view works fine because receives the contextual parameter (already saved in the database) before showing the content. As a result, the second control loads its content based on the saved value in the first control.

So, what I do not understand is the following, during the content creation, If I have two Entity Reference controls and the second is based on a view that receives a contextual parameter from the first Entity Reference, what would be the trigger for updating the view that loads the control. Currently, I assume that the second control waits for the parameter before showing the content, but it does not receive any value and if I change the value in first Entity Reference control does not make any change because the view is not updated.

I can understand how to make it work.

I would really appreciate any comment on this regard

GiorgosK’s picture

#46 works as advertised RTBC

adellefrank’s picture

Status: Reviewed & tested by the community » Patch (to be ported)

#46 works wonderfully for me, too. Thanks!

jpstrikesback’s picture

Status: Patch (to be ported) » Reviewed & tested by the community
sraborg’s picture

Will these patches be implemented into the next official release? I'm not big on patches in general as I don't want to worry about overwriting them on the next update.

keyiyek’s picture

Would it be possible to have in the Entity Reference view type an option "Argument Input" like the one for Panel Panes?

In this way Arguments would be fed by the context in a very cool way.

bnadem’s picture

bnadem’s picture

Thanks a lot for sharing,
I wonder if there is a way to "fill" the entityreference field with the corresponding view result during "create/edit" mode ?!

Striky2’s picture

Great topic. This is a long-time wished feature improvement. Will try the patch because it would certainly help to solve some of the limitations.
Just one question, why not even trying to jump directly in the full dynamic arguments model, passed in PHP.
Attached a screenshot of what would be the ideal... I tried to realize it but I'm stuck with how this is handled afterwards...

myselfhimself’s picture

Hello I was able to test patch #46 successfully (using the following Views arguments token expression "[node:nid],[node:content-type]") !

Thank you very much for this great new feature !

dysrama’s picture

I was very happy to find this patch, but I don't understand why it's set up only to work for already existing entities?
// Check if the entity has an ID. If not, don't pass the entity to token_replace().

I made a new patch, and it works fine without this condition, and now it also works for adding new entities.
I've attached the slightly modified patch

MegaChriz’s picture

@dysrama
Have you tested to use [node:nid] as a token argument? See also #43.

dysrama’s picture

@MegaChriz
Thanks for your reply, I hadn't seen the comment in #43 and no, I haven't tested with node:nid.
The reasoning behind not replacing tokens at all when the entity is new because of 1 token not working seems flawed to me though? In my usecase for example, it makes the patch useless.

Damien Tournoud’s picture

Project: Entity reference » Drupal core
Version: 7.x-1.x-dev » 8.x-dev
Component: Code » entity_reference.module
Status: Reviewed & tested by the community » Patch (to be ported)

Sorry guys, but at this point we are going to need this to go into core first.

jpstrikesback’s picture

I agree with #65 as the notice seems to me a bug in core's token handling (if it is still an issue). Re: #66, I'll take a stab at 8.x shortly, should the component be views.module as selection plugins now live in their respective modules?

amateescu’s picture

I think it's fine to keep it in the ER component. The problem with a 8.x patch is that it cannot include any of the module_exists('token') parts, which will make it a lot less useful :(

jpstrikesback’s picture

Indeed but right now doesn't the token module handle form alters for adding the token popup/help for core text areas that support replacement? It handles the field description form alter I believe. In that case I think it's fine to (at least attempt to) go in without those items unless I'm missing something (likely)...

amateescu’s picture

It's definitely ok to go with what we can in core and leave Token to do its job, I was just saying that it's unfortunate that core won't/can't provide an experience as nice as D7 contrib.

jpstrikesback’s picture

Status: Patch (to be ported) » Needs review
FileSize
3.44 KB

^^ Indeed...

First pass to see what breaks.

Status: Needs review » Needs work
jpstrikesback’s picture

:) oops guess handleArgs() should be public

jpstrikesback’s picture

How to waste the testbot 101... I need coffee...

jpstrikesback’s picture

Status: Needs work » Needs review
malberts’s picture

Any updates on this?

I don't currently have the time to test the 8.x version, so I am in no position to hurry anyone along. But I would like to know the roadmap/timeline for getting this back to 7.x.

Is this a small(ish), less important issue that needs more eyes? Or is it more complicated on the 8.x side? Does #67 - #70 mean that the backported patch will need to be redone to more closely follow the 8.x patch? Or will it be safe to use the 7.x patch (#46) in the meantime? I realise there's no "upgrade path" between that and the eventual patch, but I assume it should not affect the data that has been entered already?

MustangGB’s picture

Did anyone manage to figure out how to use the value of a previous form element to ajaxly update a views enabled entity reference list yet?

Kazanir’s picture

akamustang: I was just coming here to post about that. The patch in #63 seems to otherwise work fine. I am not really sure where to start to figure this problem out though.

readyventure’s picture

Thanks for the patch works like a charm !

Kazanir’s picture

Okay, I implemented the AJAX discussion on a personal level using a combination of extending the EntityReference_SelectionHandler_Views class to have a setAjaxArgs method and telling its getReferenceableEntities method to prioritize that argument. I put the necessary AJAX code into a form alter and used the appropriate part of the $form_state['values'] to feed the selection handler class and regenerate the options list on every form call. It is clunky but functional.

I'm not sure if something like this is possible at the general level without a LOT of wizardry -- it would involve extending the selection handler class to accept a form_state variable and then doing logic on the fields present in the form_state to see if they somehow "match" the token that is set in the settings form -- it seems quite complex but I'm also not a mad wizard or anything so maybe someone has other (better) ideas.

joemoraca’s picture

@Kazanir .. any way you could share what you did - maybe someone can come up with a better way -- but I would love to just adapt to my needs.

I have two fields on a node add form. I want the second fields view argument to be updated when the user picks a value in the dropdown / checkbox of the first value

Thanks

Laz5530’s picture

Hi,

I have a group MY_GROUP and a content type TASK. TASK has a user-reference field: RESPONSIBLE.
When i make a new TASK i use an autocomplete field to chose the RESPONSIBLE user.

I dont want to assign TASK to anybody outside of MY_GROUP, so i just want to search for RESPONSIBE in user in MY_GROUP.

I set in TASK the field RESPONSIBLE: Entity selection on "Views: Filter by an entity reference view" and i chose the view GroupContributors (where i already defined a display type "Entity Reference".
But the view: GroupContributors needs a contexual filter, so i should give the ID of MY_GROUP from the URL to the field.) and type %1 for field:"arguments". But it does not work.

Have anybody some idea?
Thanx

guile2912’s picture

For D7, #46 still works fine and apply cleanly

aoturoa’s picture

#46 works pretty good. Thanks.
Can I suggest to add an array_filter() before returning the $args.
This will support the 'Display all results for the specified field' option in Views core when the filter value is NOT available. An empty string I also consider as NOT available, but others may disagree.

Here my suggestion on top of D7 patch from #46:

+  protected function handleArgs($args) {
+    // Parameters for token_replace().
+    $data = array();
+    $options = array('clear' => TRUE);
+
+    // Check if the entity has an ID. If not, don't pass the entity to token_replace().
+    if ($this->entity) {
+      list($id, $vid, $bundle) = entity_extract_ids($this->instance['entity_type'], $this->entity);
+      if (!empty($id)) {
+        // Only pass the entity to token_replace() if it has a valid ID.
+        $data = array($this->entity_type_token => $this->entity);
+      }
+    }
+    // Replace tokens for each argument.
+    foreach ($args as $key => $arg) {
+      $args[$key] = token_replace($arg, $data, $options);
+    }
+    return array_filter($args);
+  }
MegaChriz’s picture

Added reference to the same issue for the Drupal 7 version of Entity reference module.

jadsam’s picture

It seems the patch #75 does not work on with the last version of entity reference 7.x-1.1 (2013-Nov-20).
Please could you confirm if there was an update.

Thanks in advance

guile2912’s picture

#75 is for D8, the last D7 patch in this thread is #46

MegaChriz’s picture

Issue summary: View changes

No, see #2010898: Use tokens for entity selection view arguments for the Drupal 7 version of the patch. I've updated the issue summary to clarify this.

Musa.thomas’s picture

#46 is ok for D7 but for my case I must to comment this line (216):

if (!empty($id)) {

in

handleArgs

method.
For my case Ive got line item with reference and I want to send product_id before line_item is create (in add to cart commerce process)

kejmil’s picture

Hello friends,

when I create a new content, I want the "title" (the mandatory fixed field) to have a specific form and to be generated automatically based on the filled fields.

That's why I've set a few nodes in "AUTO NODE LABEL" that generate my page title. It looks roughly like this: [node: field_per_degree_before_n] [node: field_per_first_name] [node: field_per_surname] [node: field_per_degree_after_n], [node: field_per_profession], [node: field_per_narozen]

Between some of that tokens I want to add comma "," but I want the comma to be generated only if token has value (e.c. the field of that token is filled). If not, then I do not want to generate this comma. The reason is that in the case of some no-filled fields I do not want to have commas generated, for example, the title incorrectly generated could look like this:

Ing. Kamil Blazek, , student,

correctly should look like this: Ing. Kamil Blazek, student

Why should be generated like this? Because I left empty field "field_per_degree_after_n" and "field_per_narozen" - so tokens are not added, but the commas yes, because they are as fixed text.

How can I ensure something like this: if "field_per_degree_after_n" haas value Than "," and if "field_per_narozen" has value Than ","?

I do not know PHP codes, so if there is some tool or if someone have solved already this php, could you help me and send me it? Also I have information to use function "implode". Also I do not know how. I am lost...

Please for help.
Thank you

kejmil’s picture

Solved:

[node:field_example]

if ('[node:field_example]')
{ print 'comma after text';}
else {print '';} 
geek-merlin’s picture

Status: Needs review » Needs work
  1. +++ b/core/modules/views/lib/Drupal/views/Plugin/entity_reference/selection/ViewsSelection.php
    @@ -144,11 +144,11 @@ protected function initializeView($match = NULL, $match_operator = 'CONTAINS', $
    +      $result = $this->view->executeDisplay($display_name, (!array_filter($arguments) ? array() : $arguments));
    

    we should not use array_filter() here.

  2. +++ b/core/modules/views/lib/Drupal/views/Plugin/entity_reference/selection/ViewsSelection.php
    @@ -174,11 +174,11 @@ public function countReferencableEntities($match = NULL, $match_operator = 'CONT
    +      $entities = $this->view->executeDisplay($display_name, (!array_filter($arguments) ? array() : $arguments));
    

    same here.

Does anyone remember what they were good for? PHP's == bitchyness will shoot our knee with that:

php > print_r(array_filter(array('1', '0', '2')));
Array
(
    [0] => 1
    [2] => 2
)
php > print(!array_filter(array('0', '0')));
1

(same for 7.x patch)

geek-merlin’s picture

Hmmm, #75 does not apply anymore as quite some code ran away, so doing a manual re-roll.

Then i reverted the array_filter() introduced as a imho unholy hack in #20/23/85. I can now see the original idea to fix special use cases where an empty argumant at the end is taken away, but this will cause ugly things when the argument is not at the end, and in these cases an empty string should be passed which views should treat as unavailable argument (if not please file an issue about that).

(I am still a bit concerned about the argument separator "," as mentioned in #91. Using "/" like on the priview page has similar issues.
Best choice imho might be \n. But the separator is already in the code and this should go into a new isue.)

amateescu’s picture

Version: 8.0.x-dev » 8.1.x-dev

Sorry for not providing any feedback on this patch earlier :( Sadly, feature requests need to wait for 8.1.x now...

guile2912’s picture

So does it mean we wait until we have a final 8.0 and then test this patch again ?

Status: Needs review » Needs work

The last submitted patch, 97: drupal-1699378-97-dynamic_views_arguments.patch, failed testing.

gapple’s picture

Status: Needs work » Needs review
FileSize
6.33 KB

That last patch would do completely nothing at all.

Here's my attempt, which makes the EntityReferenceAutocompleteWidget store the information of the entity which has the reference field in its settings, which can then later be loaded by ViewsSelection.

Status: Needs review » Needs work

The last submitted patch, 99: drupal-1699378-98-entity-ref-views-arg.patch, failed testing.

gapple’s picture

Status: Needs work » Needs review
FileSize
7.53 KB

Last patch didn't handle validation properly, so here's a new one.

Status: Needs review » Needs work

The last submitted patch, 101: drupal-1699378-101-entity-ref-views-arg.patch, failed testing.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

gapple’s picture

Status: Needs work » Needs review
FileSize
7.56 KB

Updated patch for 8.2.x

Status: Needs review » Needs work

The last submitted patch, 104: drupal-1699378-104-entity-ref-views-arg.patch, failed testing.

howards’s picture

Another attempt based on #94 ... hopefully tests will succeed...

gapple’s picture

Status: Needs work » Needs review

Changing to Needs Review for testbot...

Status: Needs review » Needs work

The last submitted patch, 106: drupal-1699378-106-dynamic_views_arguments.patch, failed testing.

geek-merlin’s picture

Thanks gapple for caring about this!

+++ b/core/modules/views/src/Plugin/EntityReferenceSelection/ViewsSelection.php
@@ -288,4 +288,32 @@ public static function settingsFormValidate($element, FormStateInterface $form_s
+    if ($this->entityManager) {
+      $data = array($this->entityManager->getEntityTypeId() => $this->entityManager);
+    }
+

This does not make sense.

Why did you change the original #94 code? This should still work: (or not?)

+++ b/core/modules/views/src/Plugin/entity_reference/selection/ViewsSelection.php
@@ -242,4 +242,32 @@ public function settingsFormValidate($element, FormStateInterface $form_state, $
+    if ($this->entity) {
+      $data = array($this->entity->getEntityTypeId() => $this->entity);
+    }
+

(or did just your IDE's autocomplete trick you? ;-)

howards’s picture

Status: Needs work » Needs review
FileSize
2.82 KB

@axel.rutz quite plainly and simply: I'm an idiot. ;) I was looking through code and noticed between 8.0.x and 8.2.x some code had been removed, and I ... I don't know what the fsck I was thinking. ;)

Patching again with original code in new file. Let's hope tests pass... (It seemed to work in my dev environment.)

Status: Needs review » Needs work

The last submitted patch, 110: drupal-1699378-110-dynamic_views_arguments.patch, failed testing.

geek-merlin’s picture

handleArgs
exception: [Notice] Line 309 of core/modules/views/src/Plugin/EntityReferenceSelection/ViewsSelection.php:
Undefined property: Drupal\views\Plugin\EntityReferenceSelection\ViewsSelection::$entity

OK so it looks like $this->entity ran away too...

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

sylus’s picture

I'm curious why $this->entity no longer works, don't suppose anyone can point to a change record? I'd love to get this tokens working again for 8.x-2.x :)

jonathanshaw’s picture

The entity is made available in drupal/core/lib/Drupal/Core/Entity/EntityReferenceSelection/SelectionPluginManager.php

  public function getSelectionHandler(FieldDefinitionInterface $field_definition, EntityInterface $entity = NULL) {
    $options = array(
      'target_type' => $field_definition->getFieldStorageDefinition()->getSetting('target_type'),
      'handler' => $field_definition->getSetting('handler'),
      'handler_settings' => $field_definition->getSetting('handler_settings') ?: array(),
      'entity' => $entity,
    );
    return $this->getInstance($options);
  }

I wonder if these options get passed into this viewsSelectionHandler in its $plugin_definition argument. I don't really get how these plugins work, but it might be worth kinting $plugin_definition as a first shot.

jonathanshaw’s picture

For what's its worth, $this->entity was removed in #2107243: Decouple entity reference selection plugins from field definitions

howards’s picture

Is this supposed to be postponed based on #2325899: UI fatal caused by views argument handlers no longer can provide their own default argument handling? In other words is the previous issue a "blocker?" I'm an idiot. Please learned me. :(

kurowski’s picture

I've adjusted the patch from #110 to work now that $this->entity is gone. This is my first Drupal patch so please feel free to tell me where to RTFM if I'm doing it wrong :)

Status: Needs review » Needs work

The last submitted patch, 118: drupal-1699378-118-dynamic_views_arguments.patch, failed testing.

kurowski’s picture

Trying again after fixing file paths and trailing whitespace.

kurowski’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 120: drupal-1699378-120-dynamic_views_arguments.patch, failed testing.

The last submitted patch, 120: drupal-1699378-120-dynamic_views_arguments.patch, failed testing.

Pilulu’s picture

After trying without success theses patches, i purpose another way to do it

function YOUR_MODULE_views_pre_view(ViewExecutable $view, $display_id, array &$args) {
  if($view->display_handler->getType() === 'entity_reference') {
    $calling_abs_path = \Drupal::request()->server->get('HTTP_REFERER');
    $fake_request = Request::create($calling_abs_path);
    $url_object = \Drupal::service('path.validator')->getUrlIfValid($fake_request->getRequestUri());

    if ($url_object) {
      $params = $url_object->getRouteParameters();
      $entity_type = key($params);
      $entity = \Drupal::entityTypeManager()->getStorage($entity_type)->load($params[$entity_type]);

      $token_service = \Drupal::token();
      $options = array(
        'clear' => TRUE,
      );
      $data = array($entity_type => $entity);
      foreach ($args as $key => $arg) {
        $args[$key] = $token_service->replace($arg, $data, $options);
      }
    }
  }
}

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

sanci91’s picture

If I try the patch #120 it returns me the following error:

PHP Fatal error:  Cannot redeclare Drupal\rest\Plugin\views\display\RestExport::overrideApplies() in /var/www/*****/docroot/core/modules/rest/src/Plugin/views/display/RestExport.php on line 386

Fatal error: Cannot redeclare Drupal\rest\Plugin\views\display\RestExport::overrideApplies() in /var/www/******/docroot/core/modules/rest/src/Plugin/views/display/RestExport.php on line 386
Drush command terminated abnormally due to an unrecoverable error.                                                      [error]
Error: Cannot redeclare Drupal\rest\Plugin\views\display\RestExport::overrideApplies() in
/var/www/******/docroot/core/modules/rest/src/Plugin/views/display/RestExport.php, line 386

I'm trying it on drupal core 8.3.0

jonathanshaw’s picture

Issue tags: +Needs reroll
pk188’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
2.86 KB

Re rolled.

Status: Needs review » Needs work

The last submitted patch, 128: drupal-1699378-128-dynamic_views_arguments.patch, failed testing.

pk188’s picture

Status: Needs work » Needs review
FileSize
2.86 KB
jonathanshaw’s picture

@pk188 Thanks for the reroll. Is #130 still a reroll? If not, please provide an interdiff.

@pilulu #124 and @sanci #126 can your provide steps to reproduce the problems you're having?

jonathanshaw’s picture

@gapple's work in #99 - 104 was abandoned without discussion. Does anyone know why?

Status: Needs review » Needs work

The last submitted patch, 130: drupal-1699378-130-dynamic_views_arguments.patch, failed testing.

brtamas’s picture

brtamas’s picture

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

liquidcms’s picture

Anyone know status of this for D7?

I see a patch in #46 (which i have been using) but this patch no longer applies and I don't see that it was ever committed. And then this thread got hijacked along the way somewhere for D8.

MegaChriz’s picture

@liquidcms
A fix for the D7 version has already been committed. See #2010898: Use tokens for entity selection view arguments.

validoll’s picture

Fixed the patch #135 due errors during field validation.

jonathanshaw’s picture

Issue tags: +Needs tests

@validoll please provide an interdiff.

This is all going to need tests. @validoll Can you say what the errors were, so we make sure we have test coverage for them.

validoll’s picture

In previous path was added arguments handler

$arguments = $this->handleArgs($handler_settings['view']['arguments']);

in ViewsSelection::validateReferenceableEntities(), but $this->configuration['entity'] is NULL, because handler created without entity arg in ValidReferenceConstraintValidator::validate() because of which we have empty args which has token as value.

I hope it's enough.

jonathanshaw’s picture

@ThomasHuong please provide an interdiff so we can see your improvements

colan’s picture

Yes, when posting patches, please also provide interdiffs, or we can't evaluate them relative to previous patches. See Creating an interdiff for details.

howards’s picture

Status: Needs work » Needs review
FileSize
4.21 KB

Simple re-roll of #139 for 8.5.x, no additional changes.

Status: Needs review » Needs work

The last submitted patch, 145: entity_reference_views_token-1699378-145.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

zerolab’s picture

This needs tests.
Also will fail for ViewsExposedForm (e.g. on /admin/content). Needs to check that $form_object has the getEntity method.

Will try to provide a patch later.

andreyks’s picture

Patch 145 breaks form what doesn't extend EntityForm. Small fix for it.

andreyks’s picture

FileSize
906 bytes

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

howards’s picture

Status: Needs work » Needs review

NR for tests on #148

The last submitted patch, 135: druapl_8_3_2_entity_reference_views_token.patch, failed testing. View results

Status: Needs review » Needs work

The last submitted patch, 148: entity_autocomplete_1699378_148.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

jonathanshaw’s picture

+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldWidget/OptionsWidgetBase.php
@@ -43,6 +43,25 @@ public function __construct($plugin_id, $plugin_definition, FieldDefinitionInter
+    if (isset($form_object)) {

A second occurrence was missed.

Also, isn't Zerolab's suggestion to check that the method exists better than checking this is an EntityForm? Could someone have a custom form class with a getEntity method?

manuel.adan’s picture

#145 nor #148 work for me. As far I can see, the handleArgs method is never called. In #142 it does, so it was lost at some point. The missing diffs are in getReferenceableEntities and validateReferenceableEntities:

-    $arguments = $this->getConfiguration()['view']['arguments'];
+    $arguments = $this->handleArgs($this->getConfiguration()['view']['arguments']);

I fixed it.

Also I did the following:

  • uses injection to get the token service
  • handleArgs refactoring. Tokens for taxonomy terms are in token type 'term', which does not match the entity type 'taxonomy_term'. That particular case is really annoying working with tokens
  • added the check mentioned at #155

This patch is still for 8.5.x, should be ported to 8.6.x.

manuel.adan’s picture

Status: Needs work » Needs review
jonathanshaw’s picture

Status: Needs review » Needs work

Great work @manuel.adan!

@Zerolab said that our check ( he seemed to mean $form_object instanceof EntityForm)

will fail for ViewsExposedForm (e.g. on /admin/content). Needs to check that $form_object has the getEntity method.

But ViewsExposedForm doesn't have a getEntity method, so I'm confused.

I would think we should at least be checking using the interface though:
if (isset($form_object) && $form_object instanceof EntityFormInterface) {

zerolab’s picture

@jonathanshaw the #145 patch did not have any checks whatsoever.The $form_object instanceof EntityForm check should do the trick.

A few notes:

  1. +++ b/core/lib/Drupal/Core/Entity/Element/EntityAutocomplete.php
    @@ -127,6 +128,20 @@ public static function processEntityAutocomplete(array &$element, FormStateInter
    +    if (isset($form_object) && $form_object instanceof EntityForm) {
    

    As @jonathanshaw mentioned, the check should be on the EntityFormInterface. Also, no need to check isset($form_object) because instanceof EntityFormInterface will return false if $form_object is not set.

  2. +++ b/core/lib/Drupal/Core/Entity/Element/EntityAutocomplete.php
    @@ -127,6 +128,20 @@ public static function processEntityAutocomplete(array &$element, FormStateInter
    +      $entity = $form_object->getEntity();
    

    We already check that this is an entity form instance. As such, there will always be an entity, there is no need for the isset($entity) check

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

ZaunerD’s picture

#156 works fine for me, however I noticed one bug:
Suppose you use a token that renders to multiple values and exposes a "join" modifier, you cannot use a comma as "join" parameter.
Example:
[user:roles:join:,]

This ends up in the argument being split at the ",":
Args:
- [user:roles:join:
- ]

jonathanshaw’s picture

re #161 we're just doing using the token service's replace method, I'm not sure it's the fault of this patch.

1kenthomas’s picture

@joemoraca #82: (or anyone else) I just implemented this via AJAX callback and could share example code that is specific to two fields, if helpful to anyone.

kirkdeam’s picture

The patches for this issue, and the solution they give, creates a huge database leak.
In my case, the table key_value size is sky high, and never-ending because of the $selection_settings_key being unique every time I change a field's value on any entity that has the autocomplete field, and never deleting the old record. I'm not sure if this happens because of misuse by my side, or because of the way the patches for this issue handles things. Maybe it's better to save the entity id and type instead of saving the whole entity object.

jonathanshaw’s picture

Re#164 Stashing the whole entity in a setting was introduced in #134 I think; prior versions used the entity type and id.

There are actually multiple different lineages of this patch within this issue, we keep rerolling and improving different versions without discussing which approach is basically right or even getting clarity on what the different approaches are.

Not all versions store anything in a setting.

If anyone wants to work on this issue, I suggest they go back to the beginning and try to understand what the different approaches/choices there are in this issue and write a summary of them.

geek-merlin’s picture

> If anyone wants to work on this issue, I suggest they go back to the beginning and try to understand what the different approaches/choices there are in this issue and write a summary of them.

❤!

PQ’s picture

I've had the patch from #156 in use for some months now but encountered a significant issue today.

If an entity has an entity reference field that uses views selection and has an entity token passed to the arguments e.g. [node:nid], then attempts to update the parent entity via a JSONAPI patch request will cause a leaked metadata error as the entity is validated during early rendering and as part of that, it ends up replacing the token to validate the entity reference field. This causes cache metadata (e.g. the cachetag for "node:x") to be generated during early rendering.

note, I haven't tried this with REST patch attempts yet so I don't know if the issue exists there too.

I'm not a 100% certain if this should be considered a bug in this patch, in the JSONAPI module or in core in general.

PQ’s picture

After discussing it with @gabesullice on Slack, I've raised #3004546: Token generation during $entity>validate() causes leaked metadata in PATCH requests for the above bug in the jsonapi queue.

PQ’s picture

After further discussion with @Wim Leers in #3004546: Token generation during $entity>validate() causes leaked metadata in PATCH requests, it looks like the above point should be dealt with here.

I've added an update to the patch that allows a BubbleableMetadata to be passed into ViewsSelection::token->replace() in order to prevent cacheable metadata from bubbling to the render context, and made this happen when ViewsSelection::handleArgs() is called from ViewsSelection::validateReferenceableEntities() but not ViewsSelection::getReferenceableEntities() which means that the metadata generated from the token replacement should be used when generating the form element but not when validating it's value.

PQ’s picture

Status: Needs work » Needs review

Changed issue status

Wim Leers’s picture

Issue tags: +D8 cacheability
+++ b/core/modules/views/src/Plugin/EntityReferenceSelection/ViewsSelection.php
@@ -284,11 +285,15 @@
-  protected function handleArgs($args) {
+  protected function handleArgs($args, $bubble_cacheable_metadata = TRUE) {

Huh, this is weird, I don't see this in core? It's being added by this issue, of course.

In forms, we don't tend to associate cacheability metadata simply because 99% forms will never be cacheable.

Similarly, when saving or validating entities, we don't tend to do this either, since those are changing the state of Drupal data and hence the response to that request is not cacheable anyway. So this looks fine to me.

Note that if this ViewsSelection class ends up being used by a ViewsArgument plugin like the IS seems to suggest, then it would become necessary to bubble.

Pancho’s picture

While the token browser integration was purposely removed between #63 and #71 (that's Token module's job), the legitimate notice "This field supports tokens." got lost somewhere between #130 and #134. Enclosed patch brings it back.
Other than that, everything seems to work fine, so far.

For convenience I'm also including a followup patch against Token module that brings back proper token browser integration.

Pancho’s picture

As pointed out above in #20 as well as (for D7 entity_reference) in #2830703: Empty token entity selection view arguments break:

An empty token replacement value will be passed to Views as an empty string (""), so the case that "the filter value is NOT available" isn't triggered.

We need to set a NULL value if the token service returns an empty string, to make sure Views considers it an empty argument.

Pancho’s picture

Sorry, last minute variable renames always result in a botched patch. Here's the correct one.

The last submitted patch, 173: drupal_dynamic_views_arguments_1699378-173.patch, failed testing. View results

Pancho’s picture

Instead of #174, we can sanitize the empty string in ViewExecutable which should be the slightly better approach (and the one axel.rutz proposed in #94, if I get him right).

Working patch in #3027640-5: Empty strings ("") passed in as contextual filter argument aren't considered missing. If we prefer this route, we'd stick with #172 here.

jonathanshaw’s picture

opi’s picture

Patch from #174 should probably be rerolled against https://www.drupal.org/node/2174633 (Can't applied #174 patch if 2174633#238 is also applied).

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

hkirsman’s picture

For me latest patch seems to filter the nodes but when saving I get error:

otice: Undefined index: #parents in Drupal\Core\Form\FormState->getError() (line 1112 of /app/web/core/lib/Drupal/Core/Form/FormState.php) #0 /app/web/core/includes/bootstrap.inc(584): _drupal_error_handler_real(8, 'Undefined index...', '/app/web/core/l...', 1112, Array) #1 /app/web/core/lib/Drupal/Core/Form/FormState.php(1112): _drupal_error_handler(8, 'Undefined index...', '/app/web/core/l...', 1112, Array) #2 /app/web/core/lib/Drupal/Core/Form/FormErrorHandler.php(164): Drupal\Core\Form\FormState->getError(Array) #3 /app/web/core/lib/Drupal/Core/Form/FormErrorHandler.php(124): Drupal\Core\Form\FormErrorHandler->setElementErrorsFromFormState(Array, Object(Drupal\Core\Form\FormState), Array) #4 /app/web/core/lib/Drupal/Core/Form/FormErrorHandler.php(124): Drupal\Core\Form\FormErrorHandler->setElementErrorsFromFormState(Array, Object(Drupal\Core\Form\FormState), Array) #5 /app/web/core/lib/Drupal/Core/Form/FormErrorHandler.php(124): Drupal\Core\Form\FormErrorHandler->setElementErrorsFromFormState(Array, Object(Drupal\Core\Form\FormState), Array) #6 /app/web/core/lib/Drupal/Core/Form/FormErrorHandler.php(124): Drupal\Core\Form\FormErrorHandler->setElementErrorsFromFormState(Array, Object(Drupal\Core\Form\FormState), Array) #7 /app/web/core/lib/Drupal/Core/Form/FormErrorHandler.php(124): Drupal\Core\Form\FormErrorHandler->setElementErrorsFromFormState(Array, Object(Drupal\Core\Form\FormState), Array) #8 /app/web/core/lib/Drupal/Core/Form/FormErrorHandler.php(26): Drupal\Core\Form\FormErrorHandler->setElementErrorsFromFormState(Array, Object(Drupal\Core\Form\FormState)) #9 /app/web/core/lib/Drupal/Core/Form/FormValidator.php(201): Drupal\Core\Form\FormErrorHandler->handleFormErrors(Array, Object(Drupal\Core\Form\FormState)) #10 /app/web/core/lib/Drupal/Core/Form/FormValidator.php(119): Drupal\Core\Form\FormValidator->finalizeValidation(Array, Object(Drupal\Core\Form\FormState), 'node_advanced_p...') #11 /app/web/core/lib/Drupal/Core/Form/FormBuilder.php(575): Drupal\Core\Form\FormValidator->validateForm('node_advanced_p...', Array, Object(Drupal\Core\Form\FormState)) #12 /app/web/core/lib/Drupal/Core/Form/FormBuilder.php(318): Drupal\Core\Form\FormBuilder->processForm('node_advanced_p...', Array, Object(Drupal\Core\Form\FormState)) #13 /app/web/core/lib/Drupal/Core/Controller/FormController.php(93): Drupal\Core\Form\FormBuilder->buildForm('node_advanced_p...', Object(Drupal\Core\Form\FormState)) #14 [internal function]: Drupal\Core\Controller\FormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch)) #15 /app/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array) #16 /app/web/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #17 /app/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #18 /app/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) #19 /app/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #20 /app/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #21 /app/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #22 /app/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #23 /app/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(99): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #24 /app/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(78): Drupal\page_cache\StackMiddleware\PageCache-

elpino’s picture

@1kenthomas #163 #1699378-163: Allow tokens in entity reference views selection arguments
I'm interested in your AJAX solution, could you share it? maybe it can even be incorporated

isalmanhaider’s picture

Applied #174 which lead to the following errors, screenshot: http://prntscr.com/ngmzgm
Please note: I am using business rules instead of default entity reference views

steveoriol’s picture

The patch #174 does not apply on the version 8.7.1 of drupal ...

andeersg’s picture

I also had a problem with #174 on 8.7.1 so I tried to fix it.

The problem is that "core/modules/views/src/Plugin/EntityReferenceSelection/ViewsSelection.php" has been altered. I tried to just add the same things as in #174, but in 8.7.1 this part is removed:

use SelectionTrait;

So I did not add this change:

use SelectionTrait {
  // PHP 5.5.9 gets confused between SelectionPluginBase::__construct() and
  // SelectionTrait::__construct() that's why we are renaming the
  // SelectionTrait::__construct() to avoid the confusion.
  SelectionTrait::__construct as private initialize;
}
steveoriol’s picture

Thanks andeersg, it works :-)

marco-s’s picture

Patch #184 works! The ability to use tokens is a great feature! Thanks!

yogeshmpawar’s picture

Assigned: Unassigned » yogeshmpawar
yogeshmpawar’s picture

Removed unused use statement & resolved coding standard issue.

colan’s picture

As per #178, the work here is definitely conflicting with #2174633: View output is not used for entityreference options. Let's get that one in first because it has tests, too many comments, it's blocking other things, and it's hopefully ready.

Here's a quick patch that needs work, but should be able to be applied on top of that one. (Yes, you need to apply that one first.) I can't post an interdiff because it's failing due to the different baselines.

colan’s picture

For those interested in extending this functionality with AJAX, see #3073970: Add AJAX support to fields using Dynamic Views Arguments via Tokens.

kevin.dutra’s picture

FYI, the current solution causes key_value to accrue large amounts of data over time that will never be removed. More info over on #3076407: Use expirable key/value for entity autocomplete, although a solution to this problem is not currently available there. :(

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

colan’s picture

Status: Postponed » Needs work

#189 needs review, but we're at NW because of #191 so setting that status now that #2174633: View output is not used for entityreference options is out of the way.

Edit: Needs a re-roll anyway as the patch doesn't apply to 8.9.x now.

frega’s picture

Rerolled patch so it applies again to 8.9.x (and 8.8.x). Given that #2174633 has been fixed i am setting this to `needs review` again.

frega’s picture

Sorry, i b0rked the patch first time round. Rerolled again, so it applies :/

frega’s picture

Sorry, missed a small use statement in the reroll >.<.

colan’s picture

Back to NW. See #191.

Qandeel’s picture

There is an instance where some time the views execution display throws error on NULL return value; this happens when using conditional fields and one of the field involved in dynamic views argument via token setup is used in conditional fields and when that row is edited it throws following error.

The website encountered an unexpected error. Please try again later.
TypeError: Return value of Drupal\views\Plugin\EntityReferenceSelection\ViewsSelection::getDisplayExecutionResults() must be of the type array, null returned in Drupal\views\Plugin\EntityReferenceSelection\ViewsSelection->getDisplayExecutionResults() (line 290 of core/modules/views/src/Plugin/EntityReferenceSelection/ViewsSelection.php).

to fix this I need to return NULL value as array.

-    return $results;
+    if (is_null($results))  {
+      return (array)$results;
+    }
+    else {
+      return $results;
+    }

To accomodate this I have added this in to the patch.

Qandeel’s picture

Qandeel’s picture

Here is a patch that will work with latest Drupal version

el1_1el’s picture

200 working for me on v8.8.1. Thanks!

colan’s picture

#198: Please provide interdiffs when posting patches. Thanks.

colan’s picture

jungle’s picture

FileSize
763 bytes

Re #202 attaching an interdiff for #200

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

graker’s picture

#200 is working for me in a sense that I can add tokens to entity reference view field configuration. But I can't make much use of it because for my case I need an url part of the page on which the autocomplete is running. But when I look in the form, ['#selection_settings']['view']['arguments'] of my field still contains unprocessed (not replaced) token. And it only gets to be processed later when the url is /entityreference/user/somecache. So the replaced value is build based on the autocomplete route that doesn't contain the data I need.

But from comments in the start of this issue (#4, #24) I gathered that there was a way to process token from original page and pass it to the view (although it seems that it was for Drupal 7). Isn't it the case any more for Drupal 8? Is there a way to pass an argument to the view that is based on a route of the page that has the form field on it rather than an autocomplete route?

Thanks!

rfsbsb’s picture

I can confirm #200 works on Drupal 8.8.1.

anushrikumari’s picture

Rerolled patch for 9.1.x

Status: Needs review » Needs work

The last submitted patch, 208: drupal-dynamic_views_arguments_via_tokens-1699378-208.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

nikitagupta’s picture

Status: Needs work » Needs review
FileSize
9.53 KB
3.88 KB

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

mparker17’s picture

FileSize
10.05 KB
9.96 KB

Here is the patch from #210 rebased onto 8.9.x and 9.0.x (no interdiff because no changes).

geek-merlin’s picture

Let's move this forward.

In #193 this is set to NW as of #191 which states

FYI, the current solution causes key_value to accrue large amounts of data over time that will never be removed. More info over on #3076407: Use expirable key/value for entity autocomplete

That issue states

...settings started being stored in key-value...talking millions upon millions of rows (gigabytes of information),

So when this patch stores current entity in $settings, it worsens an already existing problem.

So we can (rough ideas)
a) Check if we can unset the entity after use OR
b) Find another place to pass around or retrieve current entity OR
d) Reduce the data passed around by e.g. replacing tokens earlier
d) do nothing and rely on the other issue solving that problem

In any case, this needs tests.

geek-merlin’s picture

Title: Dynamic Views Arguments via Tokens » Allow tokens in entity reference views selection arguments

Let's move this forward.

In #193 this is set to NW as of #191 which states

FYI, the current solution causes key_value to accrue large amounts of data over time that will never be removed. More info over on #3076407: Use expirable key/value for entity autocomplete

That issue states

...settings started being stored in key-value...talking millions upon millions of rows (gigabytes of information),

So when this patch stores current entity in $settings, it worsens an already existing problem.

So we can
a) Check if we can unset the entity after use OR
b) Find another place to pass around or retrieve current entity OR
c) do nothing and rely on the other issue solving that problem

In any case, this needs tests.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Nigel Cunningham’s picture

Hi all.

I've tested the patch and found that it doesn't work when the autocomplete you're seeking to use is in a subform. The attached patch addresses this, looking for a closer entity in the form structure. My test case is editing a commerce order item within a commerce order (/admin/commerce/orders/).

In addition to that, I've modified the patch so it doesn't store the whole entity in the settings, but rather just the entity type and id.

The issues mentioned in the previous comment still apply.

Nigel Cunningham’s picture

I've started using views_entity_form_field today, and found in there a use case for extending the patch to handle views as well.

Here's an update.

Nigel Cunningham’s picture

(Correct my malformed patch in the last comment)

jonathanshaw’s picture

@NigelCunningham please post an interdiff, it really helps to understand your changes.

Nigel Cunningham’s picture

Here's an updated version with a fix for a bug in the views support that I discovered this morning.

@jonathanshaw, sure. Attaching vs 210.

Nigel Cunningham’s picture

Ah, I'm having a marvelous start to the day. Accidentally included core/Patches.txt in the last upload, which prevents composer from being able to install it. Right this time. (Patch prepared for 8.9 by the way).

Nigel Cunningham’s picture

barrio’s picture

EDITED: Don't use my patch, use Nigel's 222 one, which is more than right. Mine adds no value, sorry for the confusion.

akalam’s picture

Gauravvvv’s picture

Gauravvvv’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 225: 1699378-225.patch, failed testing. View results

SerShevchyk’s picture

Status: Needs work » Needs review

The patch #225 works fine for me on D 9.2.7

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Nigel Cunningham’s picture

Updated the patch from #225 to apply against 9.4.x and put into a MR. The only rejects were changes already applied in the 9.4.x branch; the patch is otherwise unchanged.

kopeboy’s picture

Sorry for the intrusion, but what's the syntax to be used in the field setting for passing the View argument? Token style or Twig style? How to check available variables?

aludescher’s picture

Updated the patch from #225 to apply against 9.3.x

anruether’s picture

FYI There is also views_tokenized module by @mxh. Not sure though, how much it overlaps.

ankithashetty’s picture

Fixed custom command failure in #233, thanks!

Status: Needs review » Needs work

The last submitted patch, 235: 1699378-235.patch, failed testing. View results

Nigel Cunningham’s picture

@kopeboy there is no syntax - the code figures out what entities apply from the context.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

cgrader’s picture

FileSize
12.56 KB

Removed one code beautifying line from last patch, because it was incompatible the patch from issue https://www.drupal.org/project/drupal/issues/2776571.
The patch is based on Drupal core 9.3.15. Please note that I did not fix the unit test.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

maurizio.ganovelli’s picture

Version: 10.1.x-dev » 9.5.x-dev
FileSize
12.63 KB

Attached a new patch based on Drupal core 9.5.x.

maurizio.ganovelli’s picture

Version: 9.5.x-dev » 10.1.x-dev

Undoing version change.

ameymudras’s picture

Status: Needs work » Needs review
FileSize
12.63 KB
ameymudras’s picture

FileSize
12.86 KB
1.5 KB

Trying to fix the CCF

Jon Pugh’s picture

This breaks when trying to create new nodes with a reference field.

It's because there's no ID yet to pass.

I got it working by altering handleArgs:

- if (isset($this->configuration['entity_info'])) {
+ if (isset($this->configuration['entity_info']) && $this->configuration['entity_info']['id']) {

Status: Needs review » Needs work

The last submitted patch, 245: 1699378.patch, failed testing. View results

mariacha1’s picture

+++ b/core/modules/views/src/Plugin/EntityReferenceSelection/ViewsSelection.php
@@ -8,14 +8,15 @@
-use Drupal\Core\StringTranslation\StringTranslationTrait;

This removal of the "use" statement is throwing an error for me, and it doesn't seem relevant to the rest of the code changes in this file. Maybe this was an accident?

Adding it back to 245 fixes it for me.

very_random_man’s picture

I recently came across this whilst recreating a D7 site (yay, token arguments) in D9 (booo, no token arguments). In case anyone is looking for a workaround for dynamic arguments to entity reference view displays whilst this issue gets resolved, you can specify the arguments in a form_alter like this:

  $form['field_something']['widget'][0]['target_id']['#selection_settings']['view']['arguments'][0] = $arg_thingy;
mariacha1’s picture

FileSize
12.44 KB

Here's a reroll of the patch for 9.5.9.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

SocialNicheGuru’s picture

Rerolled JonPugh #245 for Drupal 9.5.9

SocialNicheGuru’s picture

FileSize
12.39 KB

in #245 and #252 this line is removed:
-use Drupal\Core\StringTranslation\StringTranslationTrait;

I had to add this line back in. I had fatal error:
"PHP message: PHP Fatal error: Trait "Drupal\views\Plugin\EntityReferenceSelection\StringTranslationTrait" not found in /drupal9.5.9/html/core/modules/views/src/Plugin/EntityReferenceSelection/ViewsSelection.php on line 32

ameymudras’s picture

Couldn't generate the interdiff, changes to fix the issue with above patch and compatibility

smustgrave’s picture

Status: Needs review » Needs work

Seems to have test failures.

Also was previously tagged for tests and issue summary which appear to still be needed.

chucksimply’s picture

for 10.1.6, #247 failed. #254 applied and works as needed.

mariacha1’s picture

Here's a quick reroll. I D10 I was seeing errors about there being no value for "$element['#array_parents']" on regular node forms for any select or radio fields added directly to the top-level of the form. This updated patch just wraps the foreach that loops through array_parents in an if statement.