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.
Postponed until 8.1.x is open for development.
Problem/Motivation
Beta phase evaluation
Issue category | Task because it improves DX |
---|---|
Issue priority | It is not major because it is something people have to get along anyway. There is no way that people just remember the service IDs |
Disruption | Changing any service NAME breaks contrib modules. On top of it, this requires a lot of changes all over the place in core. |
--------------------
Follow up for #1943846: Improve ParamConverterManager and developer experience for ParamConverters
Problem/Motivation
There is no standard for naming services.
Proposed resolution
Come up with standards around service name and update core code base and document accordingly.
Remaining tasks
Discuss
Write standards
Update documents.
User interface changes
No
API changes
No
Original report by @damiankloip
#1943846-112: Improve ParamConverterManager and developer experience for ParamConverters
Comments
Comment #1
dawehnerLinking a related issue: #2057869: Provide an alias for 'plugin.manager.entity' called 'entity.manager'
Comment #2
catchComment #3
tim.plunkettRelated: #1981368: Convert all routes to 'module_name.foo_bar' naming convention
Comment #4
jhodgdonI'm standardizing the issue title and tags for this issue. ;)
Comment #5
dawehnerSo let's use $module.$servicename but skip the $module for the core.services.yml file?
Comment #6
jhodgdonHow about core.$servicename for those core.services.yml services? Then the pattern could be that if the file is called foo.services.yml the service is called foo.something? Just a thought...
Comment #7
tim.plunkettcore.services.yml should use the subsystem/component.
In fact, we do that in most places:
Having core.entity.query is overkill.
Comment #8
jhodgdonHm. entity.query... we have a module called entity, so wouldn't that clash with the modulename.whatever idea? Are there other possible clashes? It seems like this example negates what you are saying about overkill, at least possibly, because I think that we have "subsystems" that are named the same as core (or contrib?) modules.
Comment #9
tim.plunkettentity.module will be renamed entity_ui, AFAIK. We are doing the same for menu and action.
Comment #10
Crell CreditAttribution: Crell commentedI agree that for services they should be namespaced by the system, generally, not the module. In some cases the module is the subsystem (book.manager, etc.), which is fine, but adding core.* to everything in core.services.yml doesn't clarify anything and mostly just makes it more confusing. (Plus, that would require a ton of work to do right now and we've got enough tons of work already.)
Comment #11
dawehnerIt also seems odd for plugins as example, do we really want to have views.plugin.manager.field?
Comment #12
dawehnerPostponed until 8.1.x is open for development.
Problem/Motivation
Beta phase evaluation
On top of it, this requires a lot of changes all over the place in core.
Comment #13
dawehnerComment #14
dawehnermoving.
Comment #16
valthebaldShould this be postponed to 9.x for BC reasons?
Comment #17
Crell CreditAttribution: Crell as a volunteer commentedWe could still alias names in D8, and drop the old names for D9. Assuming anyone still cares about the service names... :-)