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
- Install Drupal (9.4.0-beta1 or later) with the Standard profile.
- Delete the line below from
modules/taxonomy/src/Entity/Vocabulary.php. - Clear caches.
- Visit
/admin/structure/taxonomy/manage/tags. - 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
| Comment | File | Size | Author |
|---|---|---|---|
| #21 | 3285529-nr-bot.txt | 150 bytes | needs-review-queue-bot |
| #18 | entity.node_type.entity_permissions_form-error.txt | 7.98 KB | lkuttner |
Issue fork drupal-3285529
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
benjifisherThe 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.
Comment #4
benjifisherMR 2397 implements the proposed resolution. Let's see whether it breaks anything.
Comment #5
benjifisherCuriously,
FieldUiLocalTaskinjects 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.Comment #6
berdirUnit tests need to be updated. And 9.4.0 is out, so this needs BC in the constructor.
Comment #7
amarlataUnit test updated
Comment #8
amarlataComment #9
spudley commentedI'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.
Comment #10
benjifisher@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.
Comment #11
benjifisher@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:
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.
Comment #14
benjifisherI 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.
Comment #15
lkuttner commentedI 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.
Comment #16
benjifisher@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?
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?
Comment #17
lkuttner commentedThanks @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.
Comment #18
lkuttner commented@benjifisher, here's a file with the error details from the Watchdog table. Thanks.
Comment #19
lkuttner commentedOddly, 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.
Comment #20
benjifisherI am glad the problem went away. Perhaps the router cache was not being cleared.
Comment #21
needs-review-queue-bot commentedThe 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.