Allow attribute-based plugins to discover supplemental attributes from other modules

Created on 27 April 2024, 3 months ago
Updated 5 July 2024, 8 days ago


Currently, the set of properties for a particular plugin type is only defined in one place - previously the plugin type's annotation class, and now the plugin type's attribute class.

This leads to some problems, such as:

- The long-standing problem where the EntityType annotation/attribute defines a 'field_ui_base_route' which is actually for field_ui, an optional module
- The long-standing feature needed for Views, where we'd like to add a property to FieldType plugins for Views, which is, again, an optional module -- πŸ“Œ Allow @FieldType to customize views data Needs work

Proposed resolution

Allow supplementary third-party modules attributes on plugins. e.g.:

  id: 'myfieldtype',
 views_data_provider: 'SomeClass',
class MyFieldType {}

The discovery system should NOT allow a 3rd-party plugin attribute to replace a property in the main attribute, unless there is a deprecation marked.

Remaining tasks

User interface changes


API changes

Modules can define attributes for plugin types they do not invent. They can then retrieve values for these properties for plugins from plugin definitions as normal.

Data model changes

Release notes snippet

✨ Feature request



11.0 πŸ”₯

PluginΒ  β†’

Last updated about 9 hours ago

Created by

πŸ‡¬πŸ‡§United Kingdom joachim

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @joachim
  • Pipeline finished with Failed
    3 months ago
    Total: 649s
  • πŸ‡¬πŸ‡§United Kingdom joachim

    Pushed the work I did on πŸ“Œ Convert entity type discovery to PHP attributes Needs review to a MR.

    Still to do:

    - > unless there is a deprecation marked.

    Bikeshedding: what do we call these?

    - I initially went for 'extending plugin attributes' but I think that's misleading because there is no class inheritance going on
    - '3rd party' doesn't apply, I feel, because with config 3rd party settings, those properties are completely controlled by another module - they are set, and read. Here, the properties are set by modules that implement plugins, and read by the module providing the extra attribute
    - additional plugin attribute?
    - supplemental plugin attribute?

  • πŸ‡¦πŸ‡ΊAustralia mstrelan

    - I initially went for 'extending plugin attributes' but I think that's misleading because there is no class inheritance going on

    Maybe not extending the plugin attribute, but you are extending the plugin. So maybe just rearranging the words to "plugin extension attributes" or something to that effect.

  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    How about `Non-discovery attributes` ?

  • πŸ‡§πŸ‡ͺBelgium kristiaanvandeneynde Antwerp, Belgium

    I'd go with Third-Party for two reasons:

    1. We already have that naming pattern for config
    2. While you're right that the implementing module doesn't set the data like they do with field_ui_base_route, it's arguably still a third-party piece of information that more often than not is added via a hook_entity_type_build/alter. The Field UI base route is more the exception to the rule than the rule itself. I wouldn't get too hung up on that.
  • Pipeline finished with Failed
    3 days ago
    Total: 172s
  • Pipeline finished with Failed
    3 days ago
    Total: 165s
Production build 0.69.0 2024