Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
The current implementation of drupalSettings updating is kind of a hack that could break easily. Essentially, each Turbo page load inserts a new drupalSettings element because Turbo doesn't know there should only be one of these; the current solution is to remove all but the last one in the DOM during a Turbo render as that's assumed to be the most recent, but this feels like a code smell due to the assumption that the last element will always be the most recent.
Steps to reproduce
👀
Proposed resolution
Implement some explicit method of identifying the drupalSettings for the current response.
This is a bit of a challenge as Turbo seemingly merges in changes to the <head> before it triggers the turbo:before-render event.
We've settled on a solution that decorates the asset.resolver service so that we can alter the output of the AssetResolver::getJsAssets() method to ensure the footer always contains the current page's drupalSettings so there's zero ambiguity and we can find and identify it reliably.
Previous stuff follows, which is partially out of date.
Our MutationObserver implementation fails in certain cases where the observer either does not find a new element at the time it checks, or then finds more than one on subsequent navigations:
- 4xx errors seem to result in this
These failures are mostly likely due to timing issues since our implementation is a bit of a hack. Unless Turbo adds some API or event we can hook into to be informed of new contents to the <head> being added, we'll have to implement our own solution/workaround.
A short term quick and dirty but reliable solution may be to read the fetch response text and render the response body into a document via That's actually not necessary - see update above.DOMParser.parseFromString(), then search the <head> element within that for the new drupalSettings script element of which we can be reasonably sure will only ever be one.
Ideally, we would implement a server-side solution that allows the front-end JavaScript to reliably receive the drupalSettings for a given response. If Turbo doesn't implement some way to get notified of what <head> changes were made for a given response, we may have to resort to either forcing the drupalSettings <script/> element into the footer or outputting a copy into the footer (which isn't great but gzip should completely negate the network transfer at least) - in both cases this means we can easily identify the correct drupalSettings as it'll be the only one in the <body>.
The subsequent paragraphs are retained for historical purposes but no longer the proposed solution.
One potential solution is to mark the <script> element with an ID and a data-turbo-permanent attribute (see Persisting Elements Across Page Loads) but that would only solve part of the problem because Turbo is probably not going to update the contents, and actually altering that specific element is a bit tricky as it's buried in JsCollectionRenderer::render() so we would probably need to decorate that service and wrap that method. Note that whether the settings element is output to the <head> or in the footer is determined in AssetResolver::getJsAssets() (search for the $settings_in_header variable).
A simpler way to handle this may be to simply use a MutationObserver to watch for any new <script type="application/json" data-drupal-selector="drupal-settings-json"> inserted as direct children of the <head> and remove all other direct children of the <head> matching the script[type="application/json"][data-drupal-selector="drupal-settings-json"] selector. Note that care must be taken to match the full selector and only direct children of the <head> to harden against potential XSS exploits, i.e. an element like this injected into site content or nested in something in the <head> that can include user-entered data such as meta tags, etc.
Remaining tasks
TBD.
User interface changes
None.
API changes
None?
Data model changes
None.
Comments
Comment #2
ambient.impactComment #3
ambient.impactComment #4
ambient.impactComment #6
ambient.impactComment #7
ambient.impactComment #8
ambient.impactComment #9
ambient.impactReopening since this still has some edge cases, namely when using the back button, that result in errors in not finding a new Drupal settings element.
Comment #11
ambient.impactReworked proposed resolution with render
<head>ourselves solution because theMutationObserverapproach still fails in some cases and it's basically a hack anyways.Comment #12
ambient.impactExpanded short term and long term solutions.
Comment #14
ambient.impactReworked issue summary to include new solution involving decorating the
asset.resolverservice.Comment #16
ambient.impactComment #17
ambient.impactMarking as fixed with the most recent commit above.