Problem/Motivation

After #3253955: Let modules opt in to the bundle-specific permissions form, a bundle entity type can declare a route provider and link template in its class annotations in order to create the "Manage Permissions" tab.

When creating local tasks, Drupal\user\Plugin\Derivative\UserLocalTask::getDerivativeDefinitions() checks for the link template but does not check for the route. If the link template is there and the route is not, then any page where the local task is added throws an exception.

Steps to reproduce

  1. Install Drupal (9.4.0-beta1 or later) with the Standard profile.
  2. Delete the line below from modules/taxonomy/src/Entity/Vocabulary.php.
  3. Clear caches.
  4. Visit /admin/structure/taxonomy/manage/tags.
  5. Get a WSOD with the message, 'Route "entity.taxonomy_vocabulary.entity_permissions_form" does not exist.'
 *       "permissions" = "Drupal\user\Entity\EntityPermissionsRouteProvider",

Proposed resolution

Inject the route provider into the local task deriver. Check that the route exists before using it.

Remaining tasks

User interface changes

None

API changes

This adds a parameter to the constructor for the local task deriver Drupal\user\Plugin\Derivative\UserLocalTask.

Data model changes

None

Release notes snippet

N/A

Issue fork drupal-3285529

Command icon 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

benjifisher created an issue. See original summary.

benjifisher’s picture

The Contact Storage module ran into this bug: #3285384: Drupal 9.4: Route "entity.contact_form.entity_permissions_form" does not exist. That issue already has a patch that does not rely on this issue.

If we fix this issue before releasing 9.4.0, then we do not have to worry about BC because the local task deriver is introduced in that version. I am not counting on that, but that is why I have set this issue to target 9.4.x.

The alternative is to add the route provider as an optional parameter to the constructor, then deprecate using the constructor without that parameter.

Are there other local task derivers that should also inject the route provider? If so, then we might want to introduce a base class and fix them all at once. Then we can expand the scope of this issue and there is no mad rush to get it fixed.

benjifisher’s picture

Assigned: benjifisher » Unassigned
Status: Active » Needs review

MR 2397 implements the proposed resolution. Let's see whether it breaks anything.

benjifisher’s picture

Curiously, FieldUiLocalTask injects the route provider but never uses it. So that class could easily check that the route exists before creating the local task, but it does not.

berdir’s picture

Status: Needs review » Needs work

Unit tests need to be updated. And 9.4.0 is out, so this needs BC in the constructor.

amarlata’s picture

StatusFileSize
new1.05 KB

Unit test updated

amarlata’s picture

Status: Needs work » Needs review
spudley’s picture

I'm getting this issue after upgrading to 9.4.

It is blocking me from doing any work on my taxonomies. Is there a work-around I can use while I wait for this patch to be released?

Re the steps to reproduce, I've not made any changes to core files, so the "permissions" line does still exist in my Vocabulary.php file.

I have installed this patch on my local development system, and I can confirm it does fix the crash. Installing it manually on our production system is not an option though.

benjifisher’s picture

@Spudley:

You should not run into this error using just Drupal core. Are you using some contrib module that triggers the error?

The only one I am aware of is Contact Storage. I mentioned in #2 that there was already a patch for that module. That issue has since been fixed, and there is a new release. If that is the problem on your site, then upgrading Contact Storage should fix it.

benjifisher’s picture

Version: 9.4.x-dev » 9.5.x-dev
Issue tags: +DCCO2022

@amarlata:

Thanks for working on this issue!

It looks as though the patch you attached to #7 is meant to apply on top of the MR that I opened. When you attach a patch to an issue, it should include all changes from the current branch, such as 9.4.x or 9.5.x.

I updated the MR for this issue:

  • Rebase on the 9.5.x branch, since this issue should now target that version.
  • Apply the patch from #7.
  • Further update UserLocalTaskTest.

The route provider is needed to check that a route exists, and the mocked version in the unit test has to support that. This test now passes when I run it locally. I think there are some other failures reported by the testbot.

This issue still NW for #6, but I am keeping the status at NR to see what the testbot has to say.

benjifisher’s picture

Version: 9.5.x-dev » 10.1.x-dev

I added a deprecation to the constructor as requested in #6. Since new deprecations should target 10.1.x, I closed the original MR and opened a new one, and I am updating this issue to target 10.1.x.

This issue is now really NR.

lkuttner’s picture

I am getting a WSOD with the logged error Symfony\Component\Routing\Exception\RouteNotFoundException: Route "entity.node_type.entity_permissions_form" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 206 of .../core/lib/Drupal/Core/Routing/RouteProvider.php) whenever I try to view or edit content types migrated from D7. It seems like this is related to this issue, so I installed the patch in #7, but have no change after. We are on 9.4.5 using PHP 7.4.30. Any guidance would be much appreciated. Thanks.

benjifisher’s picture

@LKuttner:

As far as I know, this issue does not cause any problems with just Drupal core. (Step 2 in the issue description intentionally makes a change to expose the bug.) Perhaps your site has a contrib module (such as Contact Storage) that exposes the bug.

See my comment in #11: the patch in #7 is not expected to solve this problem. Try getting a patch from the merge request instead. And make sure to clear caches after applying the patch. I am hiding the patch in #7 to help others avoid the same mistake.

Can you give some more details?

... whenever I try to view or edit content types migrated from D7

Can you list the paths you used to view and edit? For one thing, I want to be clear whether you were viewing content of those types or viewing the types.

Can you attach a text file with the full stack trace?

lkuttner’s picture

Thanks @benjifisher. It is when I try to edit the actual content types (manage fields, manage display, etc), not edit content created from them.
I just enabled Devel to get a stack trace, but then starting getting an error Symfony\Component\Routing\Exception\RouteNotFoundException: Route "devel.configs_list" does not exist in Drupal\Core\Routing\RouteProvider->getRouteByName() when I try to access admin pages. There seems to be more to this problem.

lkuttner’s picture

@benjifisher, here's a file with the error details from the Watchdog table. Thanks.

lkuttner’s picture

Oddly, the Route "entity.node_type.entity_permissions_form" does not exist issue seems to have resolved itself after fixing seemingly unrelated issues with Devel and removing two views plugins that were causing Drush to be terminated abnormally when running cache rebuild. I had not applied the changes that were in the merge request. I wish I could tell exactly what made the difference, but hopefully the problem will not return.

benjifisher’s picture

I am glad the problem went away. Perhaps the router cache was not being cleared.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new150 bytes

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

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

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.