A site of mine randomly ran into this error the other day. I was able to capture a copy of the database before it went away, and copying to my local recreates the issue.
Fortunately, clearing the cache easily fixed the issue. But it left the content people panicked for a bit, and ideally, this doesn't happen at all. Here is the full stack trace:
Symfony\Component\Routing\Exception\RouteNotFoundException: Route "entity.node.vmd_preview_list" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 206 of core/lib/Drupal/Core/Routing/RouteProvider.php).
Drupal\Core\Menu\LocalTaskDefault->getRouteParameters(Object) (Line: 310)
Drupal\Core\Menu\LocalTaskManager->getTasksBuild('entity.node.canonical', Object) (Line: 358)
Drupal\Core\Menu\LocalTaskManager->getLocalTasks('entity.node.canonical', 0) (Line: 95)
Drupal\Core\Menu\Plugin\Block\LocalTasksBlock->build() (Line: 171)
Drupal\block\BlockViewBuilder::preRender(Array)
call_user_func_array(Array, Array) (Line: 101)
Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_render callbacks must be methods of a class that implements \Drupal\Core\Security\TrustedCallbackInterface or be an anonymous function. The callback was %s. See https://www.drupal.org/node/2966725', 'exception', 'Drupal\Core\Render\Element\RenderCallbackInterface') (Line: 786)
Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array) (Line: 377)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 449)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array) (Line: 450)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 65)
__TwigTemplate_ec871c933f9aa26c761e9fd7c5cd4a7c4c02b23d0d521b5166b2f737f7acdafb->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 65)
twig_render_template('themes/gesso/templates/layout/page.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('page', Array) (Line: 436)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array) (Line: 450)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 92)
__TwigTemplate_5d2d6488c1b241d919c1d99d458953d7075dcefccbaf55a9a73de85a7333327e->doDisplay(Array, Array) (Line: 405)
Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
Twig\Template->display(Array) (Line: 390)
Twig\Template->render(Array) (Line: 65)
twig_render_template('themes/gesso/templates/layout/html.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('html', Array) (Line: 436)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
Drupal\Core\Render\Renderer->render(Array) (Line: 162)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 578)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 163)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
call_user_func(Array, Object, 'kernel.view', Object) (Line: 142)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 163)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 80)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 91)
Drupal\shield\ShieldMiddleware->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 717)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 3260465-route-not-found-vmd-preview-list.patch | 3.49 KB | gloriaswebtech |
Issue fork view_modes_display-3260465
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
hartsak commentedThe same thing happened to one of our sites today too. Clearing the caches with drush resolved the error (at least for now).
Any idea what is causing that issue? Just worrying about when it might happen again.
Comment #3
bburgI haven't had the time to try to debug this. It's on my TODO list!
Comment #4
bburgAnother developer and I investigated this issue and haven't been able to recreate it. It looks like the list of routes just broke randomly in core, with this one missing. We might suggest adding a check to see if the route exists before adding new local tasks (in src/Plugin/Derivative/ViewModeDisplayLocalTask.php).
Comment #5
diamondseaI had this happen for the first time last night on our site after midnight which took down our home page. Looking through the logs to when the error started, it happened the same minute that our nightly backup job started, which contains
drush cranddrush sql-dump. This same script has been running for months without issue until last night.Clearing the cache fixed the issue and it has not yet reoccured, even with re-running the backup script. I added an additional
drush crto the end of the backup script to reset the site, just to provide another level of prevention of site impacts.Hopefully a root cause can be identified on this.
Comment #6
skaughtHave had this module running for a good 6mons with not problem, until a few weeks ago myself.
@diamondsea
who is providing hosting for you? i had also had this error very recently on my production site. just wondering from the back of my head. thanks.
Comment #7
diamondsea@SKAUGHT I'm hosted on an AWS Linux instance. I had this happen one more time since, where content pages wouldn't render, but /admin/* and /user/* system pages worked. I was able to log on and clear cache from the web UI, and the site restored normal operation. Unfortunately I was on a plane about to take off and had to do the quick fix and didn't backup the DB first. If it happens again, I'll pull a DB backup before clearing cache to see if I can figure anything out from that.
Comment #8
skaughtthanks. was just wondering.
As I taking a look at how this module adds this tab is unique (derivative). seems like some reworking it would be needed. i don't know this module well enough to know more than that.
Comment #9
dinesh18 commentedIs there any patch to fix the issue?
Comment #10
zach.bimson commentedIm going to try and recreate this, haven't got loads of time but im working on a 3.x release and if i solve this in ill commit to the new dev branch
Comment #11
zach.bimson commentedComment #12
gloriaswebtech commentedI provided a hotfix patch to prevent site errors for those getting this issue seemingly at random. My client's site was getting this error for anonymous users, so it makes me think that this is a local task caching or dependency issue somewhere (the module uses the LocalTaskDefault class from core for it's local tasks). This patch checks if the route exists before providing the local task in the local task deriver class.
Comment #13
zach.bimson commented@gtucker6 thanks for the patch, are you able to open a MR for this please ?
Comment #14
mqannehStill getting the same error using v3.0 and patch #12
Comment #15
dalinUpping to critical since the site basically goes down when this happens.
I'm not sure if this means anything, but I've seen the error on two high traffic sites. We also run this module on smaller sites, and they haven't seen an issue.
Comment #16
dalinAck, we just hit this problem again. Just like @mqanneh the site in question is using v3.0 and patch #12.
I think we'll have to uninstall the module until this is resolved.
Comment #17
robpowellThis is happening to me on deployments in Acquia. After a full cache rebuild, via drush and the Acquia UI, the issue is resolved.
Comment #18
skaught#17
cache clearing is not resolution. it's just a 'stop gap' to get back up.
the problem is not just with an Acquia Deployment that this happens, i know this from my own direct experience in Acquia.
Comment #19
fizcs3 commentedHave had this module installed for quite some time without any issue...
But now, have had a random WSOD a couple times recently, out of nowhere, for which we too are finding these errors in the log...
Cannot seem to figure out how to reproduce it either -- but, clearing cache does fix the issue...
We have multi-site running and it didn't happen on all sites, just on one site WSOD of the many, still obviously not good but odd...
To confirm that this is not just an Acquia issue. We are running on Platform.sh.
This is on D10.2.9, PHP 8.2.24, running
view_modes_display3.0.0.Current stack trace below:
Comment #20
skaughtthanks for confirming your hosting platform. Indeed, this module IS NOT STABLE!!
this module is not maintained!
Comment #21
anybodyMaybe someone here would like to request maintainership for the module?
https://www.drupal.org/docs/develop/managing-a-drupalorg-theme-module-or...
Comment #22
zach.bimson commentedNot sure that’s necessary, I don’t have time to work on a fix currently but I’m happy to review and manage merge requests. No one is yet to propose any changes…
Comment #23
fizcs3 commentedPossibly no one has proposed any changes yet because this is a heck of a random, difficult bug to track down.
I last responded here 5 months ago, and since then have had no issues... until today, BOOM.
We have a multi-site running. Pushed code changes to production. Cache is cleared before AND after config is imported. Despite that, found one site was down with WSOD at completion of deploy. Others were not. Same code base. Go figure. The one site down had dozens of these php errors in the dblog, triggered from completely different location/url's:
Pretty much same message as in this issue's description, except it is on line 208 now (am on D10.3.13).
The funny (and thankful) thing is that if I clear cache yet again to the WSOD site, the site does come back up and WSOD goes away.
I could swear before that this error would just appear out of nowhere, not only after a deploy. I list this deploy example here because everything is fresh and the error still manages to appear.
It's possible that Drupal just shouldn't take that error so hard (can't find a route? who cares, just throw it as a message in the dblog and move on, don't bring the site down for heavens sake, but that's not what Drupal likes to do).
That's all I can share... if it can be of any help.
Comment #24
bburgI feel like this must be some sort of core race condition bug. I just had this happen again today, albeit with a route from a different module. This one was from the Preview Link module, and the error was:
The common traits between these routes is that they are not defined in a normal *.routing.yml file. Instead they are dynamically generated via a "Derivitive" class. Berdir even comments there may be a race condition in his comment here. My guess is that there is a path that allows Drupal to cache it's list of available plugins without calling these dynamic Route providers via Derivitive classes.
Comment #25
bburgI just tried dropping a break point in the PreviewLinkTasks::getDerivativeDefinitions(), to see what calls that. interestingly, in the stack appears the Webform module's implementation of hook_menu_links_discovered_alter() where it calls::
I wanted to see what would call that if webform wasn't there, and added a return statement at the top of webform's hook. It seems that the next in line to call getDefinitions is in LocalTaskManager, but tat is only prompted by BlockViewBuilder in what seems to be well into the rendering process.
I'm not too sure what the overall Drupal philosophy is for rebuilding caches, but at face value, this does seem very bespoke to the instance of when/how/where a cache is being cleared, and I can see room for plugin definitions being loaded in different ways that might lead to this situation of dynamically generated routes not propogating.
Comment #28
zach.bimson commentedsorry this ones been around a while, i made a couple of changes to try and address this, hopefully fixed in dev now.. please give it a whirl and report back!
Comment #29
fizcs3 commentedMuch thanks @zach.bimson
Seems like some exciting changes, including the try/catch guard!
I'd be happy to test this, but I still do not know repeatable steps to get this error to appear... since my last post in March 2025, remarkably, we have not had the error come up. If you or anyone can figure out steps to test, I can try them.
In the meantime, I've applied a patch of #27 to version 3.1.0 of this module (running on D10.6.5), spun through the
/preview/listand/preview/allpages of different content types, and it is working, also finding no errors in the watchdog log...Comment #30
anybody@bburg is this fixed for you in the latest 3.x-dev?
Comment #31
bburgI haven't had any reports of the issue in a while. Like fizcs3 said, this was difficult to reliably reproduce, and my headspace has moved on since my previous comment. I'll be sure to update the module on my projects.
Comment #32
fizcs3 commentedFor whatever its worth, knock on wood, we've had that patch (from #27) running on production (w/view_modes_display 3.1.0) for a few weeks now and no issues...
Comment #33
pcambraI've published 3.1.1 with this commit included :)