>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3618900. --> Reported by: [marcelovani](https://www.drupal.org/user/854220) >>> <h3>Problem/Motivation</h3> <p>Testing 8.x-1.x against Drupal 10.6.15, 11.4.5 and 12.0-dev turned up seven defects. Three of them lose or corrupt site content.</p> <p><strong>1. Token edits never appear on cached pages.</strong> <code>hook_tokens()</code> adds nothing to the <code>BubbleableMetadata</code> it is handed, so a page that embeds a config token is cached with no dependency on <code>config_token.tokens</code> or <code>config_token.settings</code>. Editing a token's value leaves every cached page showing the old value indefinitely.</p> <p><strong>2. A value whose allowed token was deleted overwrites another token.</strong> On <code>/admin/config/system/config_tokens</code> each row's token is a <code>&lt;select&gt;</code> limited to the currently allowed tokens. Once a token is removed from the allowed list its row has no matching option, so the browser submits the first option instead. Pressing Save with nothing edited rewrites the orphaned value onto whichever token sorts first.</p> <p><strong>3. Two rows on the same token silently overwrite each other.</strong> Both admin forms key their config by token name. Pointing a second row at a token another row already uses overwrote that row's value and dropped this row's token, with no warning.</p> <p><strong>4. Token names are never validated.</strong> A name like <code>not a valid name!</code> was accepted and written to config, even though <code>[config_token:not a valid name!]</code> can never resolve. The site ends up with dead config and no hint why the token does nothing.</p> <p><strong>5. The help page is empty and logs a warning on every view.</strong> <code>hook_help()</code> read README.md relative to the hook class, i.e. <code>src/Hook/README.md</code>, which does not exist. <code>/admin/help/config_token</code> rendered an empty <code>&lt;pre&gt;&lt;/pre&gt;</code> and each request wrote a <code>file_get_contents()</code> warning to watchdog. The settings form links to that page.</p> <p><strong>6. ConfigTokensForm never called parent::__construct().</strong> <code>ConfigFormBase::$typedConfigManager</code> is a typed property, so leaving it uninitialized makes any access a fatal <code>Error</code>. Latent today because the form uses no <code>#config_target</code>, but core reads it in <code>validateForm()</code>.</p> <p><strong>7. foreach over NULL</strong> in <code>hook_token_info()</code> and <code>hook_tokens()</code> when the config has not been imported yet.</p> <p>Separately, <code>check_markup()</code> is deprecated in drupal:11.4.0 and removed in drupal:13.0.0, and <code>core_version_requirement</code> claimed <code>&gt;=8</code>.</p> <h3>Steps to reproduce</h3> <p><strong>Stale cache (1)</strong></p> <ol> <li>Enable config_token and token_filter; enable Token filter on Basic HTML.</li> <li>Create a node with <code>[config_token:example_phone]</code> in the body.</li> <li>View it anonymously twice &mdash; the second is <code>X-Drupal-Cache: HIT</code>.</li> <li>Change example_phone's value at <code>/admin/config/system/config_tokens</code>.</li> <li>View the node again: still HIT, still the old number.</li> </ol> <p><strong>Overwritten value (2)</strong></p> <ol> <li>At <code>/admin/config/system/config_tokens/allowed_tokens</code>, delete the example_phone row.</li> <li>Go to <code>/admin/config/system/config_tokens</code> and press Save configuration without editing anything.</li> <li><code>config_token.tokens</code> now has example_email set to 02070000000.</li> </ol> <p><strong>Empty help (5)</strong></p> <ol> <li>Enable the Help module and visit <code>/admin/help/config_token</code>.</li> <li>The page body is empty; dblog shows a <code>file_get_contents()</code> warning.</li> </ol> <h3>Core version support</h3> <p><code>core_version_requirement</code> claimed <code>&gt;=8</code>. Measured against every version it claimed:</p> <ul> <li><strong>Drupal 8.9.20 (PHP 7.4)</strong> &mdash; <code>ParseError</code> on the <code>: static</code> return type. The module cannot be installed at all.</li> <li><strong>Drupal 9.5.11</strong> &mdash; installs and token replacement works, but the allowed tokens page is a WSOD: <code>Class "Drupal\Component\Utility\DeprecationHelper" not found</code> (that class is 10.1+).</li> <li><strong>Drupal 10.6.15</strong> &mdash; all tests pass.</li> <li><strong>Drupal 11.4.5</strong> &mdash; all tests pass.</li> <li><strong>Drupal 12.0-dev</strong> &mdash; all tests pass.</li> </ul> <p>Narrowed to <code>^10.3 || ^11 || ^12</code>, which is also what drupal/token 1.16 requires, so the dependency cannot pull the module onto a core version it does not work on.</p> <h3>Proposed resolution</h3> <ul> <li>Add both config objects as cache dependencies in <code>hook_tokens()</code>, and collect the cacheability the text format contributes.</li> <li>Keep an orphaned token selectable in its own row so the value round-trips, and warn which tokens are affected.</li> <li>Reject duplicate tokens and invalid token names in <code>validateForm()</code> on both forms. Names already in config are exempt from the pattern check, so a site that stored an unusable name is not locked out of editing the rest of the table. Delete skips validation, otherwise the user could neither save nor clean up.</li> <li>Build the help page from translatable strings the way core modules do, with real headings, a definition list and links resolved from routes. Nothing reads README.md any more &mdash; dumping it into <code>&lt;pre&gt;</code> also meant none of the help could be translated.</li> <li>Call <code>parent::__construct()</code> from both form constructors.</li> <li>Default the config lookups to an empty array.</li> <li>Replace <code>check_markup()</code> with the <code>processed_text</code> render element, and the <code>DeprecationHelper</code> / <code>filter_formats()</code> shim with the injected entity type manager &mdash; which also removes the last <code>\Drupal::</code> call from a form that phpstan flagged.</li> <li>Rewrite the README around what the module is for, following the drupal.org README template.</li> </ul> <h3>Testing</h3> <p>15 tests across one kernel and five functional classes. Each regression test was confirmed to fail against the unfixed code for the right reason before the fix was applied &mdash; the cache test on a missing <code>config:config_token.tokens</code> tag, the orphan test on example_email coming back as 02070000000, the constructor test on the uninitialized typed property.</p> <p>Verified on Drupal 10.6.15, 11.4.5 and 12.0-dev: 15/15 tests, a 22-check admin UI walkthrough, a 10-check validation walkthrough, the cache reproduction above, and an empty watchdog after exercising the UI. phpcs and phpstan clean under drupal.org's own ruleset.</p> <h3>CI</h3> <p><code>OPT_IN_TEST_NEXT_MINOR</code> and <code>OPT_IN_TEST_NEXT_MAJOR</code> only add those variants' jobs to the pipeline. Whether they run is decided by <code>_AUTORUN_NEXT_MINOR</code> and <code>_AUTORUN_NEXT_MAJOR</code>, which both default to <code>none</code> &mdash; so the next-minor and next-major jobs sat there as manual actions, never executed, and the pipeline still reported green. Both are now set, and phpcs and phpstan no longer allow failure.</p> <h3>Remaining tasks</h3> <p>Because the per-row Delete buttons come first in the DOM, pressing Enter in any text field implicitly submits Delete on row 1. This issue fixes the server-side half &mdash; a submission carrying no recognized button no longer deletes anything &mdash; but reordering the buttons is a UI change rather than a bug fix and is left for a follow-up.</p> <h3>User interface changes</h3> <p>The values form warns about tokens that still have a value but are no longer allowed, and keeps them selectable rather than silently reassigning them. Both forms now reject duplicate tokens, and the allowed tokens form rejects names that could never resolve. The help page shows real, translatable help instead of the README source.</p> <h3>API changes</h3> <p>None. <code>ConfigTokensForm</code> and <code>AllowedConfigTokensForm</code> constructors gained arguments; both are instantiated through <code>create()</code>, so this only affects code that constructed them directly.</p> <h3>Data model changes</h3> <p>None.</p>