Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
Drupal core is inbetween using paths and routes for things, but moving towards routes and route parameters. Entities are still stuck somewhere between the two with 'route_base_path' and uri() methods, while work is ongoing to change the links to routes instead (see #2133469: Replace path-based entity links with route names).
Proposed resolution
Figure out the best way for entities to provide routes and route parameters themselves instead of uri()s directly to match with Drupal 8's route based reality.
Remaining tasks
- Discuss.
- Implement.
- Review.
- Commit.
User interface changes
None.
API changes
Likely uri() may go away and new methods may be added.
Comments
Comment #1
Gábor HojtsyComment #2
tstoecklerI think we might not even need the route (as in the route object) but simply have a route_name instead of 'route_base_path'. What I would like more, though, is if we would check for what 'route_base_path' is currently used for in core and determine whether we couldn't use entity links for that.
I.e. we could simply add a separate entity link for the 'entity-type-edit-form' (yes, this is a really bad name...).
Field UI currently uses 'route_base_path', to attach the manage fields/... screens at the right place.
I had the following thought: We currently have the 'bundle_of' property which NodeType and Vocabulary use. The 'edit-form' link of NodeType and Vocabulary coincide with the 'route_base_path' path of Node and Term, respectively. And it seems this is not just a coincidence, but it makes a lot of sense conceptually. So we could just leverage the 'bundle_of' property for those entity types that have it.
That would not cover 'user' and 'comment', but there it seems we could just define another route link.
What we need in any case, though is a way of getting the route parameters from an entity. If we go with entity links, it should probably take $rel as an argument. Thinking about that having such a function makes sense in any case, IMO.
Comment #3
tstoecklerSo to make that more clear, and in light of #2133469: Replace path-based entity links with route names: We should definitely deprecate uri($rel) in favor of routeName($rel) and routeParameters($rel) (or a bikeshed thereof). But we also need to consider 'route_base_path'. As I've tried to elude in #2 I *think* we can also move that to entity links, thereby combining those two issues into one.
Edit: I guess routeName() is a better method name than route()
Comment #4
amateescu CreditAttribution: amateescu commentedI've been working on converting field_ui local tasks to a plugin derivative and I arrived at the same conclusion that 'route_base_path' needs to switch to a route name. I hope to post that patch tomorrow and I'll link it here.
Comment #5
amateescu CreditAttribution: amateescu commentedOk, so 'route_base_path' is taken care of (killed!) in #2111823: Convert field_ui / Entity local tasks to YAML definitions. Is there anything else to discuss here?
Comment #6
tstoecklerAwesome, thanks for that pointer, thanks! We can actually resolve the @todo's in config_translation even without that. I posted #2139209: Use EntityTypeManager::getRouteInfo() in ConfigFieldInstanceMapper::getBaseRouteParameters() for that.
I still think we probably want to move to routes for the non-admin paths as well, i.e. deprecate uri() in favor of routeName() and routeParameters().
Comment #7
h3rj4n CreditAttribution: h3rj4n commentedIs this still something that needs to be done? Uri is changed to Url right now or isn't it?
See issue #2167641: EntityInterface::uri() should use route name and not path