Problem/Motivation
We're using drupal_block() to render the page title, but when the page title is updated, it's still rendering the previous title. It seems to be displaying a cached version of the block, and doesn't update until the render cache is cleared.
Steps to reproduce
1. Verify that your render cache is not disabled in a settings.php file with
$settings['cache']['bins']['render'] = 'cache.backend.null';
Comment out that line if necessary.
2. Add this to a twig template such as node--page--full.html.twig:
{{ drupal_block('page_title_block', { label_display: false }) }}
3. You should now have two page titles on the page. (The default one and the one manually rendered in the twig template.)
4. Edit the page and change the page title.
5. View the edited page and note that the default page title has been updated, but the twig title is still showing the previous title.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | Screenshot From 2026-02-08 22-04-40.png | 56.63 KB | boddy |
Issue fork twig_tweak-3569103
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
richarddavies commentedComment #5
nickolajThe `url` cache context added for TitleBlockPluginInterface was not bubbling up to the parent render array. This patch merges cache metadata from `$build['content']` to ensure contexts are properly applied.
Comment #6
richarddavies commentedI applied this patch, but I'm still having the same issue.
Comment #7
boddy commentedComment #8
boddy commentedFixed the drupal_block title cache issue
If the block is TitleBlockPluginInterface, tried to get the entities from $this->routeMatch, grab their cache tags, and copy those tags into a 'content' child element.
Comment #9
richarddavies commentedThank you! I've confirmed that the MR now resolves this issue. The updated page title is correctly displayed.
Comment #10
anybodyCould we have a test for this to ensure it doesn't break again in the future and works as expected?
Comment #11
anybodyNeeds to go into 4.x first
Comment #12
anybodyNeeds rebase