🇦🇺Australia @geoffreyr

Migrated usage docs for token_element_validate

Linked to Token contrib module documentation.

Noting also that the old Token module handbook at https://www.drupal.org/documentation/modules/token → has some extra functionality that our guide doesn't yet cover such as using token_element_validate in #element_validate. I think I'd probably want buy-in from the module maintainers themselves before I consider adding that -- don't want to duplicate their entire handbook without their say so beyond what's necessary to say what about Token module makes Token API really click.

Thinking about how https://www.drupal.org/node/390482 → provides a comprehensive list of D7 tokens with a lot of examples of chained tokens, but trying to replicate this would get very long and would be tedious to write. I wonder if there's some way to write a JS tool that does the same thing as Token module's Token Tree that lets people explore the list of default/Token module tokens and generate ones with the appropriate nesting... probably not something that would be hostable on drupal.org though.

I had a bit of free time and ended up starting work on the Token API guide. Here's what I have so far.

• Homepage →
• Overview →
• Usage info for devs →
• Hooks →
• Tokens provided by Drupal core →
• The Token contrib module →
• Upgrade guides →

The bits that I'm hoping will be most useful are the lists of available tokens and the hook implementation guides. It's pretty hard to generate lists of tokens in pretty-printed documented form so hopefully the former shouldn't change too much.
I thought that we couldn't really explain the Token system without having some info about Token module, since it provides entity field tokens which are pretty critical for extending the functionality of Token API itself.

I spent some time going over the Token API codebase and reviewing the ins and outs of each section, so hopefully it's reasonably accurate. I'd say there are more passes to do before it fully fits the "voice" of the Drupal community, but hopefully it's useful.

Added tokens provided by Token module.

Added File tokens.

Fixed typos in PHP examples.

Moving documentation on the internals of Token::replace into here so the hooks can have their own dedicated document. I'll need to do one for Token::generate too.

geoffreyr → created an issue.

Given that Drupal 7 has reached its End Of Life → , this issue should be closed.

Please upgrade to a supported version and feel free to reopen the issue on the new version if applicable.

Thanks for all the hard work you've done in documenting Tokens for D7!
Even now in 2025 I reckon that the Token subsystem could really use some work on the documentation front, especially given the new documentation structure on drupal.org. I'm interested in trying to figure out how to improve it, and might give it some thought before opening up a new issue focusing on D11+.

Given that Drupal 7 has now reached End Of Life → , this issue should be closed.

Please upgrade to a supported version and feel free to reopen the issue on the new version if applicable.

There's actually been some work done on this on the D8+ front. Take a look at issue 919760 ✨ Add a [current-page:object:?] dynamic token Needs work and the contrib module Current Page Entity Tokens → .

Given that Drupal 7 has reached its end of life → , this issue should be closed.

Please upgrade to a supported version and feel free to reopen the issue on the new version if applicable.

Based on the D7 code, it looks like only nodes are added to the context for the mail action: https://git.drupalcode.org/project/drupal/-/blob/7.x/modules/system/syst...
Interestingly, in D11, it appears as though this issue might be extant: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...
This may be worth investigating for newer versions of Drupal, but it should be done as a new ticket for D11+.

Given that Drupal 7 has reached its end of life → , this issue should be closed.

Please upgrade to a supported version and feel free to reopen the issue on the new version if applicable.

For D8+, \Drupal\Core\Utility\Token::replace can take a langcode option that should replace your token with respect to the translation you want.

Given that Drupal 7 has reached its end of life → , this issue should be closed.

Please upgrade to a supported version and feel free to reopen the issue on the new version if applicable.

Given that Drupal 7 has reached its end of life → , this issue should be closed.

Please upgrade to a supported version and feel free to reopen the issue on the new version if applicable.

If you're still on D7 it might be worth a try to implement hook_tokens_alter and adjust your custom module's priority to run after everything else. You could also apply a custom patch to implement this change using Composer or Drush Patchfile.

Given that Drupal 7 has reached its end of life → , this issue should be closed.

Please upgrade to a supported version and feel free to reopen the issue on the new version if applicable.

Thanks for putting the patch together. It looks good, but people who will want to use it should apply it to their D7 codebases using Composer or Drush Patchfile.

Given that Drupal 7 has reached its End Of Life → , this issue should be closed.

Please upgrade to a supported version and feel free to reopen the issue on the new version if applicable.

For what it's worth, Auto Nodetitle replaces tokens with respect to the Node entity type, meaning that there wouldn't be any reason to have a top-level Files token category. You'd probably want to drill down into a field belonging to that specific node that links a file entity, maybe something like [node:field_document:basename] using what Token module gives you. There is a module named File Extra Tokens → that might give you what you want.

Drupal 7 has now reached its End Of Life → . The issue is closed for this reason.

Please upgrade to a supported version of Drupal and feel free to reopen the issue on the new version if applicable.

Given that Drupal 7 has now reached its End Of Life → , this issue should be closed.

Thanks for all your hard work on this one. @joshmiller's patch in #28 is probably the approach you want to take to resolve this for your D7 sites, and can probably be managed within your codebases via Composer or Drush Patchfile, but it won't be merged into the Drupal 7 codebase.
This issue no longer applies in Drupal 8+ due to \Drupal\Core\Utility\Token::scan() being strongly typed.

I've put up a first pass based on what we have going. I think it's pretty rudimentary compared to what we want to accomplish. I'd rather avoid modifying the template too much, as I'm assuming a lot of site builders make their own edits to the template.

That said, if we're changing the template, I wonder whether we should consider using <details> tags for the facet containers... this would allow us to set the open attribute on them and make the facet containers collapsible.

geoffreyr → created an issue.

Adding a bit more to the description. I want to take a look at config changes before we look at RTBCing -- might be difficult to merge given how much else is coming through.

Got a draft MR in, which is what we've been using in production for a little while now, but I don't feel that it's ready to be merged back into this project yet. I think we'll need to add the config.factory service to funnelback.querystring and clean up the services before we're good to go. There's also still the question of passing the tracking URL to the node view mode, which I haven't thought about yet.

geoffreyr → changed the visibility of the branch 3460721-add-support-for to hidden.

Marking #3435248 🐛 Inconsistency between general_settings.results and general_settings.pagesize Needs work as related because we depend on the config schema being present.

I reckon we should continue working on PHP Codesniffer fixes in the issue that has the merge request attached 📌 Fix issues reported by PHPCS Active .

One change I added in the latest version of the MR is to give the attribute merging its own dedicated method PasswordConfirm::combineAttributes to merge the attribute arrays. This allows us to reuse the same merging code across both pass1 and pass2, but also to normalise the autocomplete attribute for both.

The reason why I think we have to normalise autocomplete is because the Nightwatch tests appeared to pick up a case via Axe where pass1 on the user edit form was invalid. After some investigation, I found that pass1 was rendering with the attribute autocomplete="off new-password", which appears to be invalid. To this end, I've tried to pick up the "off" value within either the array or string values of this attribute, and if it's found, reduce it to just autocomplete="off".

A good example of where this might be set is in \Drupal\user\AccountForm::form. This obviously makes handling attributes more complicated, and I'm wondering if this too is the right approach.

With Drupal 7 reaching End Of Life in January 2025 → , this issue is now outdated. Drupal 8+ supports image style tokens via the Token module using a token format along the lines of, say, [node:field_image:thumbnail:url].

Issue summary updated as of #60.

Issue summary updated as of #79.

Might have a crack at rolling the most recent patch into 11.x.

Started a new MR based on @mortim07's patch in #39. I added support for default_revision and keep_untranslatable_fields arguments in the createRevision call; this means that we can do things like keep a revision published while updating the entity with a new draft revision.

I reckon it'd be pretty good to be able to add a revision log message and UID, but I'm not sure of the best way to do it yet. I'll have a think and see what could be done.

geoffreyr → made their first commit to this issue’s fork.

The latest version of the MR now has a dedicated form and test case for Password Confirm widgets, and the hook to modify the User Registration form has been removed.

@smustgrave Thanks for your checks. I've updated the issue description to try and conform to the current template. I don't know much about upgrade path tests but I'll try and figure this out while I'm working on this issue.

I might also see about adjusting the MR and tests further to add functionality. I'd like to ensure we've got an "on demand" setting that lets the field remain empty as long as we need it to.

geoffreyr → made their first commit to this issue’s fork.

I think I've fixed the TimestampTest by ensuring that $this->fieldName gets set. I still see a lot of tests failing but none of them relate to the timestamp widget.

BTW hi @man-1982 long time no see (:

We're now using this in a production deployment and are happy with the way it's been working.

geoffreyr → made their first commit to this issue’s fork.

We've been working with patch #17 in this issue for some time. I've rerolled #30 against the 9.0.x branch and created a merge request.

geoffreyr → changed the visibility of the branch 3008580-impossible-to-index to hidden.

geoffreyr → made their first commit to this issue’s fork.

We're interested in getting AGLS 2.0.x going so we can upgrade our Metatag installations. I might try it out as is at our end, but is there anything you might want a hand with?

geoffreyr → created an issue.

geoffreyr → created an issue.

Might want to look at odata_client.odata_server schema errors 🐛 odata_client.odata_server schema errors Active first before we add anything new to the schema.

geoffreyr → created an issue.

geoffreyr → created an issue.

This one doesn't merge with 1.1.2 or the current DEV; might try and re-roll.

@dalin Thanks for the feedback! I appreciate that adding a whole plugin system does run the risk of overcomplicating things. Perhaps this sort of functionality might be more useful attached to Crop module itself -- that way, it could work with other methods of cropping, such as cloud solutions that provide smart crop bounding boxes instead of focal points. This might also help get around the issues with Image Widget Crop pre-emptively removing the Focal Point crop.

In our hook implementation we check $crop->isNew() before updating the coordinates, so perhaps I should update the patch with either the same behaviour or explicitly check whether the crop coordinates have changed, as you suggested.

Lot to think about here. I'll see what I can do to make this more useful.

mingsong → credited geoffreyr → .

We needed to do this for our use case, so we patched Focal Point to allow us to hook into the focal point values before they get saved. This might allow for some variety of solutions, whether they be backend, remote, or frontend.

geoffreyr → made their first commit to this issue’s fork.

geoffreyr → created an issue.

Very curious that these phpcs issues weren't picked up by the GitLab CI pipeline, which should cover that. I'll take a look.

Looking to address this one in #3435248 🐛 Inconsistency between general_settings.results and general_settings.pagesize Needs work , since we'll need it for keeping track of the new general_settings.results setting.

Targetting to 2.0.0-beta4.

Targetting to 2.0.0-beta4.

Targetting to 2.0.0-beta4.

Updated MR with a post-update hook, as well as a module schema file.

Updated MR with a post-update hook, as well as a module schema file.

geoffreyr → created an issue.

This was released in 2.0.0-beta3.

That took a little while, but I finally got a merge request going with a PHPUnit test for the FB16 data. This code is already running in our PROD environment but if anyone wants to review by all means go for it. I might line up a new beta release featuring this update -- the good news is that it should be backwards-compatible.

Here it is: https://www.drupal.org/project/funnelback/releases/2.0.0-beta3 →
I mucked up my own contrib on 3441681, so I'll make sure to do future merges through d.o so I don't lose anyone else's.

Merged and closing.

I might have a second look at this later -- we probably don't want that event change and I could reuse $hashElem.

geoffreyr → created an issue.

Thanks Lee! Given you prefer frequent releases, I might look at doing a 2.0.0-beta3 for the issues that are already committed to 2.x, and do additional ones for individual features as you suggested. The CI/CD one would be a good one to get in so we can start testing all changes yet to come.

geoffreyr → created an issue.

Added a Composer requirement for drupal/core matching the info.yml file.

geoffreyr → made their first commit to this issue’s fork.

MR ready. If you want to set 3.0.1 as being for 10.3 and above you won't want to merge this, but anyone else who finds this issue can use the plain diff source to download it and use it in their sites.

geoffreyr → created an issue.

geoffreyr → created an issue.

I've been trying this out with an implementation that uses IEF Table View Mode and so far it's working well. Much more concise and reliable than patching IEF to remove the sort elements. I'm not going to RTBC it until we test and deploy it, but this looks really promising.

I've tried rerolling #18 against the latest 2.x. It seems to work but I reckon it needs a bit of a look. If anyone else wants to check the branch out and make changes that's all good.

MR available for review.

I've got a case where I have a CSV with a lot of line breaks in the cells that I'd like to convert to HTML <br /> markup (nl2br style). This feature might allow for what I want to achieve, so I'll see if it's possible to render out the cells with a text filter set.

You're quite right. Sorry!

I've uploaded a patch to let Linkchecker ignore non-numeric content entity IDs when deleting. This is a hack at best so I'm not putting it through as a proper merge request, it's more to let people who use Entityqueue or modules that do similar things with entities use Linkchecker alongside it.

I recommend that we identify and implement a proper solution.

geoffreyr → created an issue.

@vaish Thanks, will do.

We've been using this one in PRODUCTION for the past two months, so moving to RTBC.

We've been using #11 in PRODUCTION for some time so I'm also +1 for RTBC.

geoffreyr → created an issue.

MR is in. I should review the existing tests to see if the behaviour is already covered or not.