Updated: Comment #12
Problem/Motivation
Our route machine names in routing.yml files are not standardized. Some are module_name_sub_name, some are module_name.sub_name, and some may even be following other conventions. It's kind of a mess.
Proposed resolution
Core should standardize on one format, even though it is not technically required by Symfony.
The proposed standard is
module_name.sub_name
where sub_name uses lower-case and underscores only. This appears to be what Symfony CMF does for cases where there is a concept of "module" (Symfony documentation itself does not appear to have a convention like this, as it has no moudles). See comment #6.
Remaining tasks
1. Agree upon the convention.
2. Document the convention as a coding standard.
3. Patch core to agree with this convention.
User interface changes
None.
API changes
Route machine names would change, so if anyone already has alter hooks or any code that depends on specific machine names, that code would break.
Related Issues
(A list of related issues.)
Original report by webchick
If you grep for 'route_name' in 8.x right now, you see a lot of ones that look like this:
./core/modules/language/language.module: 'route_name' => 'language_negotiation_url',
and a few ones that look like this:
./core/modules/views_ui/views_ui.module: 'route_name' => 'views_ui.list',
The easiest thing to do is convert the views ones to under_scores, but I actually prefer the dot-convention myself, because it makes it clear that these are not callback functions, which they kind of look like.
Comment | File | Size | Author |
---|---|---|---|
#28 | route-names-1981368-28.patch | 1.66 KB | tim.plunkett |
#24 | route-names-1981368-23.patch | 231.63 KB | tim.plunkett |
#24 | interdiff.txt | 6.24 KB | tim.plunkett |
#22 | route-names-1981368-22.patch | 225.39 KB | tim.plunkett |
#22 | interdiff.txt | 7.74 KB | tim.plunkett |
Comments
Comment #1
webchickCouple of more tags...
Comment #2
Crell CreditAttribution: Crell commentedI think the really early conversions were using dots, and then somewhere along the line we switched to underscores for, um, I don't recall why.
IMO, this is an obvious bikeshed issue for which we should simply follow existing Symfony convention in order to avoid the bikeshed discussion. I don't know off the top of my head what the Symfony convention is, but it's easy enough for us to find out.
Comment #3
Dustin@PI CreditAttribution: Dustin@PI commentedIn light of: https://groups.drupal.org/node/315498, lets get this one fixed.
It appears that this is moving to "module_routename":
(1) New routes all seem to be using underscore: http://drupalcode.org/project/drupal.git?a=search&h=refs%2Fheads%2F8.x&s...
(2) Which matches the examples from symphony2: http://symfony.com/doc/current/book/routing.html & http://symfony.com/doc/current/components/routing/introduction.html
I'll create the issues and patches for the other the remaining modules.
Comment #4
webchickAwesome, thanks for looking into that!
Let's do it all in one patch, here in this issue. The "100000 individual issues that each do one small part of an overall thing" approach adds significant overhead to patch creators, reviewers, and committers.
Comment #5
tim.plunkettCan we please do module.foo_bar?
Meaning, we namespace it, and then have underscores for any spaces after that.
Here were some of the very first routes done, and I wish we had kept to that standard, and now we have a chance!
Comment #6
webchickActually, hold the phone.
Mark and Tim brought up that the reason Views does it the way it does it is it's following a "namespace.route_name" pattern. While the Symfony docs don't really do this, that's because they're not dealing with a concept like Modules. Symfony CMF, on the other hand, does. Here's a code sample from http://symfony.com/doc/master/cmf/book/routing.html illustrating this:
Given there's precedent for this in the Symfony world, I actually think we should switch to this convention, since it's going to be a much better guarantee of unique route names across core/contrib.
Comment #7
webchickSlight clarification.
Comment #8
Crell CreditAttribution: Crell commentedI'm +1 on modulename.some_key. It's very easy to tell module it comes from, and it avoids most name collision issues.
Comment #9
jhodgdonJust a note that the examples in #5, such as "views_ui.settings.basic", do not follow the convention that is being proposed here, right? It should be views_ui.settings_basic ?
Comment #10
tim.plunkettViews UI was the first module to use routes, so I had no convention to follow.
I chose
module.optionalNamespace.someDescription
, only using underscores for the module nameThe views_ui.edit, views_ui.settings, and views_ui.form prefixes all have multiple routes, and I used that as a subnamespace beyond the module name.
But by what we discussed on IRC, that would lead to
And that seems less good.
--------
It would be good to have consensus here by tomorrow, so that we can get a patch for this done right as we're switching gears on the route conversions.
Comment #11
webchickI maintain we need to do what Symfony/Symfony CMF does here so people familiar with those things see familiar stuff in Drupal. Symfony does not use camelCase. It also does not mention multiple namesapces. So module.underscore_separated_thing.
Comment #12
jhodgdonSorry about the tags. :(
I just wanted to make sure we were agreeing to a standard of
module_name.whatever_you_want_to_put_with_underscores_only
I think that is what is being proposed... I'll make an issue summary. :)
Comment #13
jhodgdonSummary updated. All in favor of proposal in summary? Opposed?
Comment #14
tim.plunkettRelated: #2055857: [policy, then patch] Standardize service names
Comment #15
Crell CreditAttribution: Crell commented#12 is fine by me. Views is (as usual) an edge case but I think views_ui.form_config_item_group is an acceptable route name. Consistency with Symfony CMF makes sense, as it's probably the most similar project in the Symfony-verse.
Comment #16
tim.plunkettWorking on this. Sorry @Dustin@PI.
Comment #17
dawehnerPlease wait for this until the simple wscci conversions start, as there it is not worth to break existing patches for that.
Comment #18
webchickActually, I'd prefer to do it before they start, so we don't have yet more crap to go back and clean up. Tim and I are planning to work on this on Sunday.
Comment #19
tim.plunkettI'll still have to do another pass tomorrow after all the remaining conversions go in, but I wanted to post this as a start.
Locally I have this split up as a commit per module, and then commits for the test modules. Just in case we want to break it up.
Comment #21
tim.plunkettAlways good to get the easy stuff out of the way :)
Comment #22
tim.plunkettRerolled after the last set of conversions.
Let the record show that I think this is a shame :)
However, having everything prefixed properly is a definite gain here.
Comment #23
webchickYeah, we could always discuss re-introducing "sub-namespaces" later, and come up with some guidelines on when we do/do not do that. But this is a fairly non-controversial first step towards consistency and sanity.
Comment #24
tim.plunkettMissed a spot!
Comment #25
webchickHere are some examples as a counter-point of our current seemingly random usages of dots. :) There's also some camelCase in the old code sporadically, too.
There are still a few outstanding consistency items like this. However, I feel like we maybe don't need to get that anal about whether it's "module.admin_add" everywhere or whether it's "module.thing_add" and just leave it up to module developers to do whatever makes sense for them.
So I've read through this entire patch and it does what it says on the tin. Fixes some indentation issues in a YAML file or two as it goes along. This patch makes my brain go "Ahhhhh" and sip a cool glass of ice tea on a beach.
Marking RTBC, and I'll commit it shortly so we have a baseline against which to do the remaining WSCCI conversions.
Comment #26
webchickIt's green! It's green! OMG! It's green!
Committed and pushed to 8.x. YEAH.
Needs a change notice. I'll also alert the meta conversion issue.
Comment #27
webchickAdded a change notice here: https://drupal.org/node/2089605
Also updated https://drupal.org/node/1800686 and and https://drupal.org/node/1953346 and https://drupal.org/node/2004268. https://drupal.org/node/1851490 was already using that convention. Couldn't find any others.
Comment #28
tim.plunkettReally sorry about this, but I actually changed a couple form IDs (they matched the route name and I was sloppy).
This would ruin someone's day if they tried to hook_form_alter those
Comment #29
dawehnerPerfect
Comment #31
webchickCommitted and pushed that to 8.x.
Comment #32
YesCT CreditAttribution: YesCT commented@tim.plunkett says we will want to use the same dot separator modulename . whatever for the local_tasks.yml
I updated the change record there. https://drupal.org/node/2044515/revisions/view/2847981/2850471
And opened #2095613: Convert all plugin IDs in local_tasks.yml to 'module_name.foo_bar' naming convention to match routing convention
Comment #33
YesCT CreditAttribution: YesCT commentedmaybe some were missed or are new. examples in #2095271-30: Add default tabs for routes expected by config_translation
Comment #33.0
YesCT CreditAttribution: YesCT commentedAdd issue summary
Comment #34
tim.plunkettComment #35.0
(not verified) CreditAttribution: commentednoting which patches committed.
Comment #36
effulgentsia CreditAttribution: effulgentsia commentedPeople who worked on this may also be interested in #2178725: Make all core menu link machine names and the corresponding route names match, where it's being discussed whether to stick with what was committed here for routes, or change the pattern.