Problem/Motivation
In many scenarios it can be useful to access the current page's entity as a token within contexts that would not normally allow it. For example, if a Webform is displayed as a block on a node page, it could be useful to obtain the node's ID to submit in the form.
Proposed resolution
Add the current route's entity available as the token [current-page:ENTITYTYPE], e.g. [current-page:node] for a node, etc.
Remaining tasks
Working code solution.Test coverage.Reviews.
User interface changes
New token structures are added to the [current-page] token structure based upon the current route so that if the current page is the canonical route for an entity that entity will be available as [current-page:ENTITYTYPE] and its child tokens will be available as [current-page:ENTITYTYPE:TOKENNAME], e.g. on a node page [current-page:node:title] would be available, on a taxonomy term page [current-page:taxonomy_term:name] would be available, etc.
API changes
n/a
(new tokens are added, but no new APIs are added)
Data model changes
n/a
Release notes snippet
TBD
Original report by Dave Reid
It might be really cool to add a token for the current object on the page that would use menu_get_object(). That way you could reference the current node on the same page, etc. Something like [current-page:object:node:...].
Comment | File | Size | Author |
---|---|---|---|
#113 | 102-111.txt | 1.48 KB | Ajeet Tiwari |
#111 | 919760-111.patch | 8.9 KB | Ajeet Tiwari |
#102 | token-current_page_object_tokens-919760-102.patch | 8.84 KB | mrinalini9 |
#90 | interdiff_83-90.txt | 8.42 KB | danflanagan8 |
#90 | interdiff_89-90.txt | 6.36 KB | danflanagan8 |
Comments
Comment #1
jamsilver CreditAttribution: jamsilver commentedHere's a patch which opens up the way for the current page node - but is not generalized to any object.
This patch combines with entity_token, allowing any field / property of the current page node to be accessed.
Comment #3
Alan D. CreditAttribution: Alan D. commentedHi Dave
Any interest or ETA for this? With Webform 7.x-4.x, there is normal token support built-in and this would provide a very nice bridge to provide context between the current page and the webform module.
In saying that, it would be nicer to provide current-[entity name here] like "current-node:nid" rather than "current-page:node:nid". If "current-page:node" pattern is used, maybe the title makes more sense for the default token?
Final point, if this pattern is extended out to multiple entity types, it is going to load up the already heavy token tree a bit, so maybe it is worth making these tokens configurable, even if just a variable_get() with no UI.
Cheers
Alan
Comment #4
greenwork CreditAttribution: greenwork commentedThis would benefit me as well. Thank you
Comment #5
rudiedirkx CreditAttribution: rudiedirkx commentedI need this too, so here it is.
I've approached it slightly differently, because Token needs a type for it to be any kind of useful. You could make generic entity tokens like
object:id
,object:type
,object:label
, but not much else. All others require a token type.My patch adds one token per entity type to
current-page
:current-page:node
,current-page:taxonomy_term
etc. (I've not changed "taxonomy_term" to "term" on purpose, because in this case it's the name of the entity type, which should be literal (like the taxonomy token types should have been too)).current-page:node:nid
will return the nid.current-page:node
andcurrent-page:node:title
will return the node title.It's rolled against dev (72f3d17).
I'm not really satisfied with the
switch { default }
token_tokens()
, but I was trying to reuse as much Token logic as possible, while still being somewhat performant, so there it is. This is the limit of my Token skills.Comment #6
rudiedirkx CreditAttribution: rudiedirkx commentedAnd I actually can't seem to load them into my token tree... I tried
#token_types => array('current-page')
but there's no current-page in the resulting tree.Comment #8
rudiedirkx CreditAttribution: rudiedirkx commentedOh wow stupid n00b bug!
Fixed.
Comment #9
Johnny vd Laar CreditAttribution: Johnny vd Laar commentedI think there is an access check missing. When you don't have access to the menu item then there is no $item['map'].
Comment #10
rudiedirkx CreditAttribution: rudiedirkx commentedComment #11
quicksketchI realized I've never commented on this issue, so I wanted to say this would be a huge benefit to Webform users. A *very* common request is being able to make a Webform into a block that is displayed on certain node types. Then users want to prepopulate Webform fields with values from the node on which the block is displayed. This is super-helpful for doing things like feedback forms, contacting the author of the node, recording relevant information, prepopulating node titles in textfields, etc.
How common is this request? Probably a few people every month. Since these requests always end up in the Webform, I thought I'd list the relevant issues to emphasize the commonality of this problem.
#2149463: Setting hidden field to [node:field_email] or [current-page:field_email] - neither work
#2163791: How to use Webform as a replacement for User Contact form: Tokens for User Email?
#1589100: Get the node title into a webform block and change the destination mail address for each node. Is this the right way?
#1620652: I want to create form on each content type "Event"
#1692026: [current-page:url:args] returns "node, 25"
#2061503: Using node field data in emails using tokens?
#2199435: Webform Mail
#2087177: Webform: [node:title] or [current-page:title] tokens display title of webform instead of current page
#1224130: %title token in Webform
#2129199: Node tokes
#2058065: Node Reference form filled in Form
#2213857: Node Tokens from Node into Webform Fields
#1617086: Webform > E-mails: Add "Content values" (ie: node field) support
Needless to say, I would be thrilled if this functionality would be added as it would help a lot of Webform users, and stop the support requests. ;)
Comment #12
rudiedirkx CreditAttribution: rudiedirkx commentedDid #9 do it for you?
Comment #13
JayShoe CreditAttribution: JayShoe commentedquicksketch,
You are right. This is a pretty common requirement and would be an amazing addition to webform. I'll be paying attention to this post to see what happens. Fingers crossed.
In the meantime, for other users searching for this functionality - You can still do it in code. Here is a snippet that worked for me.
Jay
Comment #14
pingwin4egPatch in #9 works. Tested with nodes ([current-page:node:...]) in custom block's body (using token_filter module).
Comment #15
knalstaaf CreditAttribution: knalstaaf commentedI'm using it with Webform, which has on its own a Webform block. This webform block uses a token (of an Entity Reference field) from the node it's being displayed in, and works perfectly on these nodes themselves.
This Webform block also appears on the homepage, which is not a node, nor does it have the token that goes as a default value in the hidden field (contrary to the node described above). As a result I'm getting these errors, only on the homepage:
The token itself looks like this:
[current-page:node:field-sector]
Clearing the Drupal cache does not help.
Comment #16
rudiedirkx CreditAttribution: rudiedirkx commentedYes, bug, sometimes
load_functions
is a string. Weird.Try this one.
Comment #17
knalstaaf CreditAttribution: knalstaaf commented#16 gets rid of the errors, thanks!
One more thing is that the ampersands (and probably other special characters, like in French) are displayed as html-code (
&
) in the results pages of webform (screen). Not sure if this is something that should be addressed in #1665818: Ampersands and other characters are not displayed correctly in <select> widgets instead (applied patch #69, no result).Comment #18
rudiedirkx CreditAttribution: rudiedirkx commentedHTML encoding where it shouldn't is another issue. This issue only adds the objects, not the properties or replacements.
Comment #19
ret5 CreditAttribution: ret5 commented#16 Worked well for me!
Comment #20
rudiedirkx CreditAttribution: rudiedirkx commentedComment #21
jasom CreditAttribution: jasom commented#16 worked for me. May you please commit this patch to the latest token release?
Comment #22
scareyclott CreditAttribution: scareyclott commented#17 Worked for me too. Please commit patch to latest token release
Comment #23
VISIOS CreditAttribution: VISIOS commented#16 works for me too. Thanks to all contributors. :)
Comment #24
Anonymous (not verified) CreditAttribution: Anonymous commentedAlso confirming that #16 is working. Thanks for the patch!
Comment #25
Germanix CreditAttribution: Germanix commentedWorks for me too. Thanks to all contributors !! :)
Comment #26
mvillares CreditAttribution: mvillares commentedNot working, [current-page:node:author:mail] doesn´t working.
Comment #27
jasom CreditAttribution: jasom commented@mvillares I disagree, you did something wrong. I have just checked if there was any update which broke the functionality. No, there was none. Everything works as it should (mails are generated and delivered).
Comment #28
mvillares CreditAttribution: mvillares commentedOops my mistake! User role problem. Thanks!!!
Comment #29
marcoka CreditAttribution: marcoka commented[current-page:node:author:mail] works if you display the form on the user page like /user/2
confirmed. works. love it. thank you.
Comment #30
caw67 CreditAttribution: caw67 commentedpatch works!
Comment #31
marcoka CreditAttribution: marcoka commentedok i teste that with another site and i updated the system first. now [current-page:node:author:mail] doesnt work when shwoing the form on the /user/2 page.
[current-page:title] works. not sure what happened.
@mvillares what was your role problem?
Comment #32
Alan D. CreditAttribution: Alan D. commentedOn a user page, (user/%) there will be no context to a content item (node/%) so [current-page:node:author:mail] is a valid token, but current-page:node is undefined, so you will not get anything shown. If it did, technically you have found a bug :)
Try on a node/NID page and it should work.
Without looking up the token tree [current-page:user:mail] is probably what you are after, the email address of the user being displayed.
[edit]
PS: The forums are probably a better place for help rather than issue threads too.
Comment #33
marcoka CreditAttribution: marcoka commentedYes of course you are right, my bad. My brain thought i used [current-page:user:mail] my hand clicked [current-page:node:author:mail] and my eyes saw [current-page:user:mail] :)
I wasnt looking for like "how to support stuff". I was testing the patch, and it works. I hope they will commit it. Thank you for you work.
Comment #34
Alan D. CreditAttribution: Alan D. commentedExcellent, and sorry for some reason I assumed this was committed already :)
Comment #35
miloshito CreditAttribution: miloshito commentedHello,
I've patched my token module, but now when i got my rule for example and "send email to address" i can't find
[current-page:node:author:mail]
in the list. Any suggestions?Thanks!
Comment #36
jasom CreditAttribution: jasom commentedThere's one suggestion: read this http://www.jasom.net/webform-is-submitted-send-email-to-the-current-node...
Comment #37
miloshito CreditAttribution: miloshito commented@jasom
can you fix images on your site? Also your solution worked! Thanks
Comment #38
AgentJay CreditAttribution: AgentJay as a volunteer commented#16 works great for me. It's using the syntax: [current-page:node:field_name]
Needs to be committed. Awesome work!
Comment #39
GiorgosK#16 works great, should be committed
Comment #40
jimmynash CreditAttribution: jimmynash commentedChiming in. #16 worked perfectly for me to get a current page token into a hidden secure webform component value.
Thanks!
Comment #41
JayShoe CreditAttribution: JayShoe commentedI just tested this and it works for me too.
Please commit this old issue!
Comment #42
mairoulhs CreditAttribution: mairoulhs commented#16 worked for me too! I agree, should be committed.
Comment #43
rwilson0429 CreditAttribution: rwilson0429 commentedPatch at #16 works great and is a huge benefit to the token module users.
Comment #44
Summit CreditAttribution: Summit commentedHi,
Please commit the patch #16!
Greetings, Martijn
Comment #45
Maurice M. CreditAttribution: Maurice M. commented#16 worked! Thanks alot! Please include this in the next version.
Comment #46
Bijanzn CreditAttribution: Bijanzn commentedWhen i enable WEBORM AJAX module, emails will not send !!
Do you have any suggestions ?!
Comment #47
Bijanzn CreditAttribution: Bijanzn commentedWhen i use WEBORM AJAX module, emails will not send !!
Do you have any suggestions ?!?????
Comment #48
JayShoe CreditAttribution: JayShoe commentedBijanzand, don't hijack this thread. Please create a new thread.
Comment #49
kylebehse CreditAttribution: kylebehse commented#16 worked first try. Thanks so much!
Comment #50
redsky CreditAttribution: redsky commentedI'd love to see this committed. It would work well for a bunch of our use cases.
Comment #51
cmseasy CreditAttribution: cmseasy commented#16 works perfect, please commit.
Comment #52
berenddeboer CreditAttribution: berenddeboer at Xplain Hosting commentedPlease commit, great patch.
Comment #53
Vincent_Jo CreditAttribution: Vincent_Jo commented#16 essential for following use case: (for those who are looking for solutions)
Webform (as block) - assigned to content-type ( + email-field)
Add email-field from content type as token to the recipient-field (E-mail to address) in the webform:
In my case:
[current-page:node:field_e_mail]
I can then add the form block to the NID-page (panels in my case) and can send mails to the mail address provided by the node of the content-type (to mention that, because I´ve been confused by the term "node" which is used for the available tokens in webforms too: [node:field_e_mail] )
thanks for the patch, please commit
regards
Vincent
Comment #54
alison+1 would love to have this committed :) Are there any blockers I might be able to help with? Thank you!
[EDIT: Still applies fine against 7.x-1.7, fwiw]
Comment #55
ConradFlashback CreditAttribution: ConradFlashback commented#16 works with 1.7.
Please commit.
Comment #56
JayShoe CreditAttribution: JayShoe commented#16 works.
Very old issue. Very useful feature.
Please commit.
Comment #57
dherbold CreditAttribution: dherbold commented#16 saves the day. Please commit already.
Comment #58
giupenni CreditAttribution: giupenni commentedAwesome, #16 save my day. The patch works for me.
Comment #59
Summit CreditAttribution: Summit commentedPlease..please commit #16! thanks in advance. Greetings, Martijn
Comment #60
goodmuyis CreditAttribution: goodmuyis commented+1 for #16: Even thought its should be committed
Comment #61
chegor CreditAttribution: chegor at OAO Solution Spark commentedCan we commit this at least to the dev branch?
Comment #62
JayShoe CreditAttribution: JayShoe commentedNah, they'll probably just continue to ignore us. :-)
Comment #63
JayShoe CreditAttribution: JayShoe commented@quicksketch
You said it yourself that this is an important feature. Since you are well regarded in this community, maybe you can suggest number 16 get committed.
Comment #64
alisonHear hear! And thank you, everyone :)
Comment #65
Shreya Shetty CreditAttribution: Shreya Shetty as a volunteer and at Trigyn Technologies Ltd commentedJust a minor fix while using multistep the current node object is not reflected from menu_get_item(). So made some changes to the code so we can get the updated node or any entity on the current page
Comment #66
Alan D. CreditAttribution: Alan D. commentedAt a guess, this doesn't work in all cases as it assumes arg(0) = entity type & arg(1) is the ID, as per the comment in the patch.
Not always in arg(1)
So this patch needs work and maybe best left as a followup if yr issue isn't triggering actual PHP errors (as opposed to not working in this use case)?
Patch #16 still rtbtc (as of forever ago)
Comment #67
Bensbury CreditAttribution: Bensbury as a volunteer commentedI would like this to be committed too.
Currently using the custom module snippet from #13 but that does appear to work for the secure hidden fields so leaving email addresses vulnerable is not ideal.
Any suggestions to tweak #13 to get it into the secure field?
I'll try the patch but be nice if it can be added to Dev so won't have to worry about it getting wiped when doing updates.
This functionality is a pretty common request.
Thanks.
Comment #68
frazac CreditAttribution: frazac commentedHello, applying this patch with webform 4.17 does not work... Any idea on alternatives?
Comment #69
Alan D. CreditAttribution: Alan D. commentedPatch #65 or #16?
Patch #65 will not work in many cases, as it assumes something/ID/something.
Comment #70
frazac CreditAttribution: frazac commentedBoth!Edit: #16 works!
I had problem passing CCK Email field because it is passing the tag
<a href="mailto:mail@domain.com...>eccetera
and not the simple emailmail@domain.com
But I have substitued the email field with a simple text field. Not elegant but it works!
Comment #71
robertom CreditAttribution: robertom at bmeme commentedHi sorry for my bad english.
I need this capability also for Drupal 8... attached a proposed patch.
the patch seems to work properly with the nodes and terms, but I have not done any further tests with other entities
P.S. as said by Alan D in #66, the working patch for d7 is #16
Comment #73
robertom CreditAttribution: robertom at bmeme commentedreset to need review because the bot performed the test on drupal 7
Comment #74
robertom CreditAttribution: robertom at bmeme commentedadded a slightly modified version that uses getTokenTypeForEntityType also on token_token_info()
Comment #75
jwilson3Confirming that #74 works great on Drupal 8, with webforms, where I'm embedding a contact form on a Profile page. On this site, user accounts are not publicly visible, but profiles are, and profiles may or may not be related to user accounts, but all profiles have the ability to specify their own email address. With this patch I've setup the webform email handler to send to token:
[current-page:profile:field_user_email]
, then I embedded the webform into the profile twig template with{{ drupal_entity('webform', profile_contact_form') }}
(via Twig Tweak module). Et voila! It Just Worked™! Thanks to everyone who's put hours into getting this working.Comment #76
Grayle CreditAttribution: Grayle as a volunteer commentedWas this tested with page manager? I'm getting Call to a member function id() on string in node_tokens() on a content type that uses page manager.
Comment #77
osopolarTested with Token Filter module, patch from #74 works great for tokens like
[current-page:taxonomy_term:vocabulary:machine-name]
or[current-page:node:content-type:machine-name]
.Comment #78
RumyanaRuseva CreditAttribution: RumyanaRuseva at FFW commentedThank you for the patch, it's really helpful.
Some routes do not have loaded objects as attributes, they have only the ID. That is why Grayle got an error on Page Manager pages, and the same error applies when viewing node revisions for example.
Here is an updated patch which loads the entity object from the ID.
Comment #79
p-neyens CreditAttribution: p-neyens at Sopra Steria commentedFix PHP 7.3 compliance warnings
"continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? token.tokens.inc:810
"continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? token.tokens.inc:822
Comment #80
manuel.adanFeature added to several projects and working fine in multiple scenarios, would be RTBC adding test converage.
Comment #81
danflanagan8I've been using the patch from #79 and I think it's not handing cacheable metadata quite right. Here's the same patch but with the [url.path] context added to the bubbleable metadata at the start of the code that handles the current-page:object token. This is important if we're imagining this token being used in a block that might appear on many different pages.
Comment #82
jrochate CreditAttribution: jrochate at ADJ 3 Sistemas commentedPatch from #81
Working fine at Drupal 8.9.4, Token 1.7
Thanks.
Comment #83
danflanagan8Here's a patch that attempts to add basic test coverage for this new token. I don't think there's much more that we could do without adding a new test class. Is this sufficient?
Comment #84
danflanagan8Comment #85
dat deaf drupaler CreditAttribution: dat deaf drupaler as a volunteer commentedCan confirm patch #83 worked beautifully for me - now I am able to populate ECK title field using Automatic Entity Label within an IEF container on a parent node without the need to rely on populating from the URL.
This is amazing contribuition to token module!! :) :) I've been looking for a solution to handle this kind of approach for a very long time.. very much appreciated! Thank you all for making this possible.
Comment #86
chegor CreditAttribution: chegor at OAO Solution Spark commentedComment #87
Cosmin Hodis-Mindras CreditAttribution: Cosmin Hodis-Mindras commentedPatch #83 works like a charm with fields deeply buried into Paragraphs - catching the parent content type name, note title, etc. and allowing for meaningful file names and folder structure for uploaded images using File (Field) Paths. That's amazing.
Comment #88
BerdirThanks for working on this. Conceptually, this seems fine, just comments on how to improve the code. Should be a relatively simple task to address this.
The type below does use the api through the entity mapper but the first check doesn't, why?
the name and description should use $entity_type->label(), not the ID.
AFAIK, the coding standard requires that inline comments use //, also for multi-line comments.
Variable names could be improved here a bit.
Instead of getDefinitions() and isset, we could just do a hasDefinition($entity_type_id).
Instead of $request->attributes, the recommended API to fetch route parameters is \Drupal::routeMatch()->getRawParameter()
That should also avoid the dynamic cases for being a number or an entity, a raw parameter is always an ID.
Even for content entities, the id could be a string, so I don't think we need to check for an integer, just non-empty. Same for the is object check, a !$entity should be sufficient.
Comment #89
danflanagan8Here's an updated patch with (most of) those comments addressed. I also added better test coverage primarily focused on asserting everything is cached right.
I can't speak to the initial author's intentions, but I'm hesitant to change it at this point. With taxonomy as the example, currently people can use
[current-page:taxonomy_term:field_foo]
. If we start using the mapper the supported token would be[current-page:term:field_foo]
.I wonder what people think about that. Anyone?
Comment #90
danflanagan8Here's a better patch. This one has expanded test that exposed a bug where cache metadata was not being added for unchained current-page:object tokens like
[current-page:node]
. I also updated the test to explicitly show the existing behavior of[current-page:taxonomy_term]
and[current-page:term]
which is relevant to comments in #88 and #89.I also reduced the big comment since the test coverage is increased, and moved the place where the url.path cache context is being added.
I'm attaching a couple interdiffs. Not sure which one will be more helpful.
Comment #91
danflanagan8Comment #92
cmseasy CreditAttribution: cmseasy commentedI am missing patch #16 in the file list for Drupal-7.
Patch #16 has a lot of 'please commit' reactions, so it does not needs a 'needs review' status: please commit patch #16 for D7.
Comment #93
weseze CreditAttribution: weseze as a volunteer commentedHad issues with the patch from #90 not applying correctly against 9.3.0 because of different line numbers.
Rerolled patch without any changes.
Comment #94
kazah CreditAttribution: kazah commentedConfirm, patch #93 works!
Comment #95
mxhSorry for being OT, but maybe this can be helpful: I'm working on a Context Stack, which provides Tokens to access current, parent and root context from entity view and current account scope. If you'd need something even more complicated than retrieving the current node of the page, feel free to try this one out.
Comment #96
Dajka CreditAttribution: Dajka commented#93 works with 9.3.2 just as before! Thanks weseze!
Comment #97
Mitsuko CreditAttribution: Mitsuko commentedhi, just to share my successful experience with this patch
My goal was to build a newsletter (node) with several articles (other nodes).
Newsletter content type has 2 fields : body and "articles" which is an entity reference content field accepting node of type article.
The "articles" field use inline entity formwith the "complex" widget, so articles are created "inside/through" the newsletter edit form.
Article's path inherit of the newsletter/parent path with the following pattern :
/[current-page:node:url:relative]/article/[node:title]
So thank you for this feature.
Maybe we could change the status issue for "Reviewed & tested by the community"...?
Comment #98
cmseasy CreditAttribution: cmseasy commentedDone
#93 for Drupal 8 (and 9)
#16 for Drupal 7
Comment #99
dshields CreditAttribution: dshields at Canadian Blood Services commented#93 wasn't working for me on a multilingual site. This extends #93 to return entity tokens in the active language.
Comment #100
dshields CreditAttribution: dshields at Canadian Blood Services commentedSorry, it seems something has changed upstream and the patch in #99 no longer applies. This seems to apply to the latest dev.
Comment #101
darvanenA couple of nits:
See #88.1, this should use the label not the id.
Code alignment creeping to the left here. That 'break;' should be four spaces to the right of the closing brace for the switch. (The creeping happens at line 904 and 918)
Comment #102
mrinalini9 CreditAttribution: mrinalini9 at Srijan | A Material+ Company for Drupal India Association commentedUpdated patch #100 by addressing #101, please review it.
Comment #103
darvanenReviewed the code, looks good to me.
Core team are going to want a clear issue summary so tagging for IS update and setting NW for that. After that I think it might just be ready for the core team to look at.
Comment #104
kazah CreditAttribution: kazah commentedPatch #102 works like a charm.
For some reason all my tokens stopped working.
Child
[term:name]
- start showing parent name.I just updated the metatag module - and thought it was because of it.
Thank you very much.
Comment #105
ThuleNB CreditAttribution: ThuleNB commentedPatch #102 works well for me. Will this be committed soon?
Comment #106
cmseasy CreditAttribution: cmseasy commentedI agree with ThuleNB.
Maybe we could change the status issue for "Reviewed & tested by the community"...?
...Done
#102 for Drupal 8 (and 9)
#16 for Drupal 7
Comment #107
darvanenThanks @cmseasy, but for an issue to be considered RTBC it needs to pass the whole review process, a working patch is not enough by itself :)
Per #103 this issue still needs an issue summary update.
Comment #108
DamienMcKennaI've updated the issue summary, is that workable?
Comment #109
darvanenI was about to say we need a change record but then I realised this is for the token module, not core.
Thanks everyone for your hard work, let's see what the maintainers think.
Comment #110
BerdirNice work on caching and the tests, I do have a few comments though, some of which you're not going to like I fear :)
missing empty line.
wrong indendation.
this will generate a ton of token types and they will all show up in the token UI in most cases, then.
There's also a risk of conflicts if an entity type were to be called tile, query or another existing token of this type. It will also might result in less experienced users picking the wrong kind of tokens for example for pathauto patterns.
There's one option that will address most of that, at the loss of token suggestions and it's also going to be a pain for everyone using the patch already. A dynamic token type, like [current-page:entity:?] like :query: already is.
There are a number of special routes that will cause problems or not work, what I know:
* node previews.
* node revisions. will use the current default revisions and not the revision
* latest routes from content moderation, will also use the default revision.
What's the reason for not using the loaded parameter? that would handle the third case.
For the first two cases, we have this in a project as a helper function. for node_preview, we could support looking that $entity_type . '_preview' although that's currently a node specific thing.
entity revision routes are becoming more common, we could support $entity_type . '_revision' as well for that.
This should use $entity = \Drupal::service('entity.repository')->getTranslationFromContext($entity, $langcode);. But if we use the loaded entity from the route context it won't be needed I think because that's already in the correct language.
Also, it should be further up if not, because the entity label token is not using the correct translation currently.
Comment #111
Ajeet Tiwari CreditAttribution: Ajeet Tiwari at OpenSense Labs for DrupalFit commentedResolved comments mentioned 1,2 and 5. and uploading patch for the same.
Comment #112
darvanen@Ajeet Tiwari can you provide an interdiff please?
Comment #113
Ajeet Tiwari CreditAttribution: Ajeet Tiwari at OpenSense Labs for DrupalFit commented@darvanen
Comment #114
darvanenThanks @Ajeet Tiwari.
Marking NW for #110 parts 3, 4 and the rest of 5.