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.When the plugin system first went in, we converted aggregator.module as an example, and decided that the FetcherManager class should be in Drupal\aggregator\Plugin\FetcherManager, not Drupal\aggregator\Plugin\Type\FetcherManager.
Views currently has some manager classes in Drupal\views\Plugin\Type\, but in other issues, tim.plunkett indicated a willingness to move them up a level.
Field currently provides several supporting classes for formatters and widgets, and so provides a subnamespace for each: Drupal\field\Plugin\Type\Formatter\* and Drupal\field\Plugin\Type\Widget\*.
Do we want to standardize on whether to:
- always use Type,
- never use Type,
- or only use Type when wanting to have subnamespaces within it?
Comments
Comment #1
sunYeah, this is terribly confusing.
Let's move them out of the \Type subnamespace.
Comment #2
effulgentsia CreditAttribution: effulgentsia commentedHow should we handle the field.module case, where multiple types are provided, and each one comes with enough supporting classes in addition to the manager to warrant separate directories?
I'm concerned about having
Drupal\field\Plugin\Formatter\FormatterPluginManager, because of possible confusion with the other convention that plugins (rather than plugin managers) live in subnamespaces ofPlugin.I wonder if for plugin managers, interfaces, custom factories, etc., if we want to drop the Plugin part entirely, and just have
Drupal\field\Formatter\FormatterPluginManager, reserving the Plugin subnamespace for the plugins themselves only.Comment #3
Wim LeersNote that some modules put the manager class in the
Drupal\moduleNamenamespace too. I.e. there are essentially three cases, not two:Drupal\moduleName(e.g. ban.module)Drupal\moduleName\Plugin(e.g. edit.module)Drupal\moduleName\Plugin\Type(e.g. block.module)+1
I was going to post exactly that here. Then the purpose is of that directory is always clear, and it's very clear where you look for plugin implementations. Everything else sits at
Drupal\moduleNamethen.Comment #4
sunYeah, sorry, I thought of exactly the same.
That is, however, *cough*, only unless #1847002: Move entity type classes from Drupal\$provider\Plugin\Core\Entity to Drupal\$provider\Entity won't happen full-frontal. If that issue will happen in its entirety, then the actual plugin type implementations will be relocated like this:
In turn, that opens up the \Plugin namespace of its own. And alas, plugin managers are integrating with the Plugin service, so they should be located accordingly.
As a result, there are two possible directions here, depending on aforementioned issue:
For now, I'd recommend to simply move them out of \Type. So much is clear.