Closed (fixed)
Project:
Upgrade Status
Version:
8.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
15 Feb 2022 at 23:26 UTC
Updated:
11 Apr 2022 at 14:39 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
gábor hojtsyBased on https://www.drupal.org/node/3161210 this could be as simple as string searching for
_access_node_revisionand_access_media_revisionin routing.yml files? Or are they potentially extended for more involved access checking?Comment #3
mglamanThey shouldn't be extended. So I guess it could be a simply string scan in the routing.yml, like a code sniff.
Comment #4
gábor hojtsyHere is a quick and untested patch :D Also without automated tests.
Comment #6
gábor hojtsyIt helps to define the service :D
Comment #7
mglamanMobile review and it looks good.
Part of me wants to add something like this to phpstan-drupal, but there wouldn't be a great time to process. Like if we knew the method was for a controller.
But parsing all of the services.yml (~136 on a basic site) takes a few seconds. Not sure how much more routing would do.
Comment #8
mglamanShould we be taking this approach or using \Drupal\Core\Routing\RouteProviderInterface::getAllRoutes to inspect the compiled routes? What if something is dynamically building routes and attaching these.
This doesn't handle dynamically declared routes. Such as routes provided by entity type route handlers.
Comment #9
gábor hojtsyHm, we could obtain the dynamic route information. That would not return useful results for uninstalled extensions though, so we may want to do both depending on if the extension is installed or not?
Comment #10
gábor hojtsyActually an installed extension would still be bundled up with potential uninstalled submodules, so that would still not be good. Maybe we do both and somehow dedupe the results?
Comment #11
mglamanOkay, I realized the problem with \Drupal\Core\Routing\RouteProviderInterface::getAllRoutes is that we cannot filter routes down to the one being provided by an extension. It seems like we need to have a global check versus just per module.
One approach would be to use the RouteProvider but filter out routes that do not begin with the module's name. But that assumes everyone is following the pattern of namespacing route names to the module name.
This also wouldn't fix generated entity routes provided by the modules. So I think we need two checks. One per-extension and also a site-wide check on the known routes.
---
I wrote the above while @Gábor Hojtsy posted. Seems like we really need a mix of both.
Comment #12
mglamanWhat I think we need to do:
- Keep the original patch which globs files and inspects them for individual analysis
- Add a site wide routes check to verify all known routes are OK
Comment #13
gábor hojtsyOk let's keep this for the routing.yml checks, so we can get this in and get moving. Can you open a sibling issue for the dynamic routes? It would still be best if we can somehow figure out a way to dedupe them and associate the dynamic routes to modules, so we can list them under there. But that would be in its own issue now IMHO.
This still needs tests.
Comment #14
gábor hojtsyAdded a simple test. Also figured we need a condition to not fire these deprecation issues on Drupal 8 since we filter the other 10 specific things there too.
Comment #16
mglamanOpened #3267620: Check all registered routes for deprecated requirements.
This is my trick in tests, for phpstan-drupal:
Comment #17
gábor hojtsyThe UI test also needs adjustments of course.
Comment #19
gábor hojtsyLet's go the direct results URL instead of clicking the links, we loose a tiny bit of tested UI but we get more predictability on the tests, regardless of major version.
Comment #21
gábor hojtsyAnd finally adjust the tested warning numbers. Fingers crossed that this will complete it.
Comment #23
gábor hojtsyYay, committed this one!
Comment #24
gábor hojtsyWent onto #3272030: Refactor info/composer file checking into its own class (similar to all other analyzers) to unify / clean up the remainder of the custom deprecation checking code a bit.