Postponed (maintainer needs more info)
Project:
Drupal core
Version:
main
Component:
navigation.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
11 Jan 2026 at 01:16 UTC
Updated:
11 Oct 2026 at 11:59 UTC
Jump to comment: Most recent
Comments
Comment #2
nicxvan commentedCan you provide any more details?
Comment #3
rozzi commentedFor our website, the two steps are enough to reproduce the issue every time, on nodes that are blogs and that aren't blogs. I'm running Drupal 11.3.2, but I'm pretty sure the issue was present in 11.3.1 as well, if not earlier. Is there anything specific you'd like me to try or note?
Comment #4
rozzi commentedComment #5
nicxvan commentedAre you using a cdn?
Does this happen locally with ddev?
Edit:
What blocks do you have in the navigation? Just defaults?
Also please keep the template in the issue summary, it's helpful for core maintainers.
If you don't have information for one then you can leave the section blank.
Comment #6
quietone commentedHi, in Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies. The version the problem was discovered should be stated in the issue summary Problem/Motivation section. Thanks.
@nicxvan, thanks for reminder to retain the issue summary! Although, I would add that it is helpful to all contributors, particularly for reviewers so they can easily get up to speed on an issue.
Comment #7
rozzi commentedComment #8
rozzi commentedI'm not entirely sure about the Drupal versions affected, as I enabled Navigation as advised in the Drupal 11.3 blog post after updating to 11.3. We use Cloudflare, but since disabling it has no effect and nodes get updated from clearing the Drupal cache or uninstalling Navigation, I'm quite sure the issue is isolated to the Navigation module. Installing and uninstalling it consistently reintroduces or eliminates the issue. Its only settings are related to its logo, so I'm not aware of any custom blocks at play.
Comment #9
rozzi commentedComment #10
catchAre you able to reproduce this with a clean install of Drupal core? Could use either standard or Umami with toolbar uninstalled and navigation enabled.
Comment #11
godotislateTested locally per #10 with clean install of 11.3.2 core with both Standard and Umami profiles, with toolbar uninstalled and navigation installed. I did not set up any CDN integration, so the outermost caching layer is the Drupal page cache.
After I created an Article in either profile and then viewed it anonymously in a private window, the content appears as expected. If I edit and save changes to the Article body, and then refresh the private window, the content appears update as expected, so if this is a navigation or core-specific issue, it probably has to do with interaction of navigation with contrib or custom modules and themes.
One thing I did notice with the cache debugging headers turned on is that when viewing an Umami article anonymously, there are more cache tags when navigation is installed, specifically these:
All other tags are the same when navigation is installed vs toolbar being installed. I haven't looked into why the tags are added, but it does bring up one possibility if the cache invalidation issue is at the Cloudflare/CDN level: the additional cache tags might cause the purge request exceed the limit on the number cache tags that Cloudflare allows to be invalidated in a request, or something similar.
@rozzi:
A couple things to try:
?{any string of pretty random characters}) to the URL, does it appear correctly?Comment #12
rozzi commentedThanks, godotislate. I didn't have the prerequisites for a local install, so I thought it would be much quicker and easier for someone to test on their own website, even if it weren't a fresh install. I was hoping to go from there.
I switch Cloudflare to the Development mode when testing this, but as noted earlier, the issue is completely unaffected by that but consistently affected by clearing the Drupal cache either via Performance, manually for the test node(s) via a drush command, or by disabling Navigation. The latter immediately fixes the problems.
To comment on your mention of themes and custom modules, switching to a base theme or clearing the .module of our only custom module and refreshing the cache doesn't help either. I'd rather not risk uninstalling the contrib modules in production.
It doesn't look like it. When I access an updated page in an incognito window for the first time, it shows its actual content, even when I don't see it in the main window yet. If I update it, the updates aren't visible on either end, and adding ?1 for example doesn't help.
All of them it seems. I've tested across four types of nodes and a user profile. Moreover, if I have a view inside a block set to display the latest nodes and I remove a node, it's the cached version that shows. I haven't tested this last part extensively though, so we can limit the scope of this to nodes. It's clear the issue is related to caching, so solving one would most likely solve the other.
Comment #13
nicxvan commentedCan you provide a list of modules you have enabled from contrib?
Comment #14
rozzi commentedSure:
The enabled Captcha points are contact_message_personal_form and user_register_form. When I had Navigation enabled, Gin Toolbar was disabled, though keeping it enabled doesn't change the behavior.
Comment #15
godotislate@rozzi
There doesn't seem to be any Purge or Cloudflare modules in that list. Does that mean you are not using Cloudflare as a caching layer (i.e. no caching, but only DNS or WAF)? And presumably no caching layer between Cloudlfare and Drupal?
If so, we can probably try to isolate what Drupal layer the caching issue is occurring at with some testing. With navigation installed and toolbar uninstalled:
Comment #16
rozzi commentedThere is no integration of Cloudflare with Drupal on our end indeed. However, we still do some caching via Cloudflare externally. Of anything that affects the site globally rather than its specific paths unrelated to nodes, there's just this:
(http.request.uri.path.extension in {"7z" "avi" "avif" "apk" "bin" "bmp" "bz2" "class" "css" "csv" "doc" "docx" "dmg" "ejs" "eot" "eps" "exe" "flac" "gif" "gz" "ico" "iso" "jar" "jpg" "jpeg" "js" "mid" "midi" "mkv" "mp3" "mp4" "ogg" "otf" "pdf" "pict" "pls" "png" "ppt" "pptx" "ps" "rar" "svg" "svgz" "swf" "tar" "tif" "tiff" "ttf" "webm" "webp" "woff" "woff2" "xls" "xlsx" "zip" "zst"})(with the theme CSS being exempt via a separate rule)
Uninstalling the two cache extensions you suggested still doesn't solve the problem though.
Comment #17
catch@rozzi there are two other places the node gets cached.
It looks like you're probably using database caching (can't see redis in the module list you posted).
Can you try the following - typing this from memory so the instructions might not be perfect:
TRUNCATE cache_renderThen visit the page you're using to test (only that page).
SELECT cid, created FROM cache_render- try to find the render cache item for the node you're viewing and make a note of the created time.
Then edit the node again.
Then
SELECT cid, created FROM cache_renderAnd see if the cache item you found earlier has a new timestamp.
And then assuming the node hasn't updated, try truncating cache_render again, and visiting the node, and see if it updates then.
If it's the cache_render entry that's the problem, then we'll need to narrow it down further, e.g.:
1. Is it getting invalidated at all when the node is saved
2. If so, is it somehow rendering with the old node values.
You can also do a similar test again with the cache_entity table for the node that you're updating, that's much less likely to go wrong but it's not impossible if a module is doing something very strange within node save.
None of this explains the interaction with the navigation module but it might help us get there.
Comment #18
rozzi commentedHi @catch, I'm not getting consistent results from those queries. Without Navigation, it seems that going to the node page for the first time or editing it immediately updates the timestamps. With Navigation, I remember truncating the table having an effect, however, doing it now and visiting or editing the page does not create any rows in the table.
Comment #19
catchThis will be the case if dynamic page cache and internal page cache are enabled and have warm caches, because the individual node won't get rendered at all in that case.
Comment #20
rozzi commentedWith those two caches disabled again, I saw no updates (or timestamp changes) from editing the node with Navigation enabled, but truncating the render cache updated the node both times I tried.
Comment #22
hongqing commentedI have the cache problem with navigation. Other users can see the Navigation.
Drupal: 11.3.1
Cache: AWS ElastiCache
Clouflare
I find the problem is caused by cloudflare cache. It works after bypass everything, but it does not after bypass uri path start with /admin or url path start with /user. This is resovled by setting TTL to 0 in cloudflare.
Comment #24
mark_fullmerI was able to reproduce this problem on clean Drupal install with just the Redirect contrib module added.
I was able to confirm that the problem only occurs when both the Navigation module and the Redirect module are enabled, and does not occur if I comment out the caching logic in
NavigationRenderer::doBuildNavigation(), or if I perform a cache flush.I've created an issue in #3584029: Cache conflict with Drupal Navigation module, along with four FunctionalJavascript test scenarios that demonstrate the problem only occurs when both Navigation and Redirect are enabled.
I note that the original reporter of this issue encountered the problem on a site where Redirect was enabled, too, per https://www.drupal.org/project/drupal/issues/3566843#comment-16416217
Comment #27
berdirBased on my research in the linked redirect issue, this is a race condition that might fix itself with #3585957: Prevent the navigation sidebar being rendered via big pipe as navigation will no longer be rendered after sending the response.
Comment #28
berdirThat other issue landed in main and 11.x, please report if you can still report any issues now.
Comment #29
rozzi commentedUpdating to Drupal 11.4.9 and doing cr as always did not address the issue for me.