Enable token browser for the page variant title field

Seems to work for me:

[node:title]
[site:name]

This really needs a token browser like #2561947: Use token browser for "Page title" field

For starters, even changing the description under the field would help. Instead of this:

Configure the page title that will be used for this display.

This:

Configure the page title that will be used for this display. You may use tokens inside brackets. Example: [node:title]

I have a variant for a node type. That node type has a field called field_title (not to be confused with node:title). I enter the following into the title field in my variant:

[node:field_title] [node:title]

This should render to something like:

Dr Bob Smith

but instead renders to

[node:field_title] Bob Smith

I have checked that this is the correct token for my field.

Am I doing something wrong, or are node tokens other than [node:title] not supported in the title field?

I tried to set the variant's title with taxonomy_term:name and [taxonomy_term:name] but never the term name is used in title - just exactly the characters which should be used as a token are used as the title

Tokens for taxonomy terms have "term" as the token type ID. So the right token for that is [term:name], see #737726: Unify token types with entity type names (taxonomy_term vs term) that hopefully will be solved by #2163027: Type token returns in a typed data recognizable format.

I enter the following into the title field in my variant:

[node:field_title] [node:title]

This should render to something like:

Dr Bob Smith

but instead renders to

[node:field_title] Bob Smith

@millionleaves, probably there were two (or more) contexts with the "node" type. Tokens work only for the last one. Please, @see #2851663: Multiple contexts of same type - all but one ignored for page title tokens.

Patch from #2561947-12: Use token browser for "Page title" field could be ported here.

Hi, I prepared port of patch from #2561947-12.
Please review.

This needs some coding standards cleanup but does seem to work. Thanks for the patch @lamp5. Would you mind indenting 2 spaces? And add that same comment:

// @todo Simplify this when token and typed data types are unified in
// https://drupal.org/node/2163027.

Thanks, @joelpittet for your review.

@lamp5 much better via the coding standards!

There is a new problem that I ran into recently with menu_block. Core can change the __constructor as it's @internal implicitly and if we extend from things we break them.

+++ b/src/Form/PanelsContentForm.php
@@ -28,16 +28,27 @@ class PanelsContentForm extends FormBase {
-  public function __construct(SharedTempStoreFactory $tempstore) {
+  public function __construct(SharedTempStoreFactory $tempstore, ModuleHandler $moduleHandler) {

There is a couple ways to fix them, still a bit torn on which way is best:

1. Decorate using the decorator pattern #2968049-18: Dependency Injection issue
2. Trick out the create method to let the parent's create's static call add the argument. https://www.previousnext.com.au/blog/safely-extending-drupal-8-plugin-cl...

I've done both ways in patches on this issue for reference: #2968049: Dependency Injection issue

Curious to know your thoughts?

@joelpittet I do not especially know what is the reason in this case that we should use decorator or extra method to inject this service. PanelsContentForm has already constructor to create SharedTempStoreFactory so if in the future FormBase constructor will change, this object constructor will also have to be changed.

Reroll to the latest dev.

@lamp5, I agree. Committed and pushed to the dev release.

I guess if anybody extends this class with their own dependencies they may need to tweak things in the constructor.