PluginNotFoundException: "The "views_view:view.comment.page_published" plugin does not exist. Valid plugin IDs for Drupal\Core\Menu\LocalTaskManager are...

The last submitted patch, 2: fix-views-route-name-3354054-1.patch, failed testing. View results →

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Seems valid, since these routes are indeed prefixed with "view" and not "views", thanks for finding this and proposing a fix.

We do need test coverage for this though, the existing Unit tests are clearly to tightly connected to the implementation since they were testing the wrong routes too.

So I feel we need at least a kernel test to make sure this is working well.

+++ b/core/modules/views/tests/src/Kernel/Plugin/DisplayPageTest.php
@@ -235,6 +235,8 @@ public function testEmptyRow() {
 
+    \Drupal::service('router.builder')->rebuild();
+

If this is indeed needed now, it would be good to know why. Because it sounds bad that we need to rebuild the routes now.

Hello,

I have the same behavior happening with me but with a different view name (scheduler_content), the error was fixed after clearing the cache and then returning to show the same error. and I need to clear the cache each time.

Here's the error

Drupal\Component\Plugin\Exception\PluginNotFoundException
The "views_view:view.media.media_page_list" plugin does not exist. Valid plugin IDs for Drupal\Core\Menu\LocalTaskManager are:

can anyone help me if this patch will help in my case? as I'm not able to reproduce the error now.

We've run into this error, and are testing the patch. We haven't figured out a reliable way to trigger it to happen, so we just have to wait and see if it stops happening.

When it does happen, instead of a full cache clear, just re-saving the view in question seems to work.

There's an existing issue that seems to overlap this one: 💬 Drupal 10 updating issue - Drupal\Component\Plugin\Exception\PluginNotFoundException: The "" plugin does not exist Needs work

Should we close this issue and work on the other one?

FWIW we ran into this on a site with the following error:

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "views_view:view.media.media_page_list" plugin does not exist.

Go a similar issue:
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "views_view:view.media_library.page" plugin does not exist.

But on Drupal 9.5.11

Could be related to https://www.drupal.org/project/drupal/issues/3402447 🐛 RouteProvider pretends no routes if database connection lost, poisoning cache downstream Active
If the definitions for LocalTaskManager get regenerated whilst database is offline (maybe cache went offline too and triggered cache miss rather than exception) and when it finishes the cache is online it could store a poisoned cache which is missing some or all of the view plugins depending on when the database connection dropped.

Not sure the patch here would fix it as it only removes a route - and the issue here is missing plugin in cache - the existence of the original route shouldn't cause too much a problem I think?

Currently, I encounter the same error while visiting

/admin/content/files

We've encounterd this issue and applied the patch in comment 9.
Its been working well so far and not had a reoccurance of this issue, though there is a strange side effect that may be related.

After a cache clear, our editors told us they could not access /admin/content anymore. This was due to a PHP error

Symfony\Component\Routing\Exception\RouteNotFoundException: Route "view.block_content.page_1" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 206 of /mnt/www/html/docroot/core/lib/Drupal/Core/Routing/RouteProvider.php).

As this patch removes routes that start with view. if they override an admin listing (entitiy collection), I believe this is now getting removed by this patch. Not sure why this would then not work like the other admin views that override entity collections?

We can work around this issue by disabling the content block view, which we don't use content blocks anyway.

We started using patch #9 on a site that ran into the problem described in #17. Just this morning we ran into the problem noted in #22. Should it remove the views.$view_route_name route *and* view.$view_route_name?

My idea from #23.. will see if this works.

Seemed to cause some test faiures.

Hello.

We have applied patch #9, but sometimes we have this error when go to Content dashboard

Uncaught PHP Exception Symfony\Component\Routing\Exception\RouteNotFoundException: "Route "view.block_content.page_1" does not exist." at /mnt/www/html/docroot/core/lib/Drupal/Core/Routing/RouteProvider.php line 206

Seems patch #9 doesn't fix the issue as well(
Workaround, clearing Drupal caches...