Problem

Here are some route names in Drupal 8 right now (taken from the Node module as an example) and their corresponding paths:

node.add_page:
  path: '/node/add'

node.add:
  path: '/node/add/{node_type}'

entity.node.version_history:
  path: '/node/{node}/revisions'

node.revision_show:
  path: '/node/{node}/revisions/{node_revision}/view'

There is no consistency or predictability at all.

Therefore, if I know the path that I want to link to (obviously a common occurrence) and I want to use Url::fromRoute() to do it, I need to stop what I'm doing and go look up the route name somewhere else.

Proposed fix

Change all route names so they use some kind of pattern that is easily-derivable from the canonical path. Anything is fine really, as long as it's consistent and easy to derive.

Impact/Disruption/Whatever

Disruption would be pretty high, I think.

The impact on developer experience could be pretty high as well. However the exact impact depends on the outcome of #2405551: Add a method to support UIs where users enter paths instead of route names and other valid use cases.

Comments

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented
Issue summary: View changes
David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented
Title: Route names should have some kind of logical relationship to the canonical paths » Route names should have some kind of logical relationship to their canonical paths
Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented

FYI: #2350503: Add route generation handlers for entities brought a big step forward in terms of having logical route names.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented

And #2350509: Implement auto-route generation for all core entities and convert all of the core entities. is the next step, actively being worked on.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented

Good to hear :) That will help. Unfortunately it's not just about entities, though. For example, in System module:

system.admin:
  path: '/admin'

system.admin_config:
  path: '/admin/config'

system.admin_config_media:
  path: '/admin/config/media'

So far so good (although the "system" part is not 100% obvious if you don't happen to remember which module controls it).

system.file_system_settings:
  path: '/admin/config/media/file-system'

Sigh :(

Basically the inconsistencies seem to be almost everywhere, in one form or another.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented

Unfortunately it's not just about entities, though.

Indeed :( There's no way for us to enforce things there. This is another reason paths were nice: it forced us to be logical and consistent.

effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia commented

Would having a Drush command and/or Symfony console app that allows you to do something like:
drush show_route_name_and_parameters '/admin/config/media/file-system'
be sufficient? Or is this issue still needed regardless to support developers who don't use CLI? A web-based version via devel or similar module could also be made. Neither fully addresses the "I need to stop what I'm doing and go look up the route name somewhere else" problem, but what if that "somewhere else" were easy to get to?

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented

That would definitely help, to have a way to look up the route name quickly. But yeah, I don't think it fully solves it. Being interrupted while in the middle of writing code is pretty annoying; it breaks flow, etc.

In Drupal 7 as an experienced site builder you can just do url('node/add') without thinking about it. Or even if you're not experienced enough using Drupal to have the URLs memorized, at least if you're linking to a page it's probably because you just visited that page in your web browser, so the URL's right there in front of you in short term memory anyway :)

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Priority: Normal » Major
Issue tags: +DX (Developer Experience)

I think the DX benefits of doing this are pretty significant, so raising to major.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

I agree with effulgentsia - though I envisioned having a little helper widget on the admin toolbar.

imho - this should be a "won't fix"

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

I think the DX would be horrible, because this is just magic.

That would definitely help, to have a way to look up the route name quickly. But yeah, I don't think it fully solves it. Being interrupted while in the middle of writing code is pretty annoying; it breaks flow, etc.

Note: One thing which already helps a lot is that the webprofiler module provides you a toolbar which shows you the route name of the current request.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

Can we add some version of that toolbar to core?

effulgentsia’s picture

effulgentsia CreditAttribution: effulgentsia commented

system.file_system_settings:
path: '/admin/config/media/file-system'
Sigh :(

An advantage of the above route name not containing the path structure is that in D9, we can move it from /admin/config/media/ to /admin/structure/media/, or whatever other organization might make sense at that time, without changing the route name. So one less thing to break for modules porting from 8 to 9.

Basically the inconsistencies seem to be almost everywhere, in one form or another.

Looking through system.routing.yml, I actually see pretty good consistency of route names containing only the minimum words needed to describe what function the page serves rather than where in the path structure it happens to be for this particular Drupal version. The only exceptions that jump out at me are the system.admin_config_* route names, but those are listing pages for a particular subgroup, so I don't have a suggestion for better names.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented

@pwolanin, do you think this should be "won't fix" because of the disruption it would cause at this point in the release cycle, or some other reason?

An advantage of the above route name not containing the path structure is that in D9, we can move it from /admin/config/media/ to /admin/structure/media/, or whatever other organization might make sense at that time, without changing the route name. So one less thing to break for modules porting from 8 to 9.

This is true; however I think a one-time replacement when converting a module from Drupal N to Drupal N+1 (which is essentially just a search+replace) is a small price to pay for a better developer experience throughout the Drupal N cycle :)

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

@David_Rothsetin - as machine names I think the route names should reflect the module that provides them, and otherwise have descriptive names, rather than mimicking the path.

Crell’s picture

Crell CreditAttribution: Crell at Palantir.net commented
Status: Active » Postponed (maintainer needs more info)

Concur with pwolanin. $module_name.$something_meaningful is the convention. A 1:1 mapping to the path is counter-productive, as we DO want those to be distinct.

Is this a won't fix at this point? I'm voting yes...

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein as a volunteer commented
Status: Postponed (maintainer needs more info) » Active

URLs are meaningful (at least one hopes!) so basing the route name off the canonical path would meet the above criteria.

Unfortunately this issue probably needs to be bumped to Drupal 9 at this point.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin as a volunteer and at Acquia commented
Version: 8.0.x-dev » 9.x-dev
Status: Active » Postponed

yes, seems so.

At this point I'm not sure adopting any of the symfony routing was actually a good idea, but I also don't think we are going to feasibly rip it out now or in 9, and renaming lots of routes in 9 doesn't seems like it's going to be that useful

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch as a volunteer commented
Category: Task » Plan
Priority: Major » Normal
Issue tags: +Needs issue summary update

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm at Acquia commented
Version: 9.0.x-dev » 9.1.x-dev
Status: Postponed » Active

Fiddling with route names is a pretty big disruption, so this would be a minor-only change and would need some sort of BC... Since 8.9.x and 9.0.x are now in beta, I'm moving this to 9.1.x. It's not postponed on anything specific, so setting to active. Thanks!

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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.