Currently blocked by:

Problem/Motivation

The DefaultPluginMananger, by default, limits plugin discovery within modules only.

This is partially due to #2941757: Extension System, Part IV: Properly register all installed extensions/namespaces during container generation, but also a byproduct of simply creating a new API/system in core knowing that not all real-world scenarios or use cases would be fully realized.

We now know that plugin managers need better control over the specificity in what and how they discover plugins.

Workarounds in contrib result in some rather "hackish" ways just so that themes can be included in plugin discoverability:
http://cgit.drupalcode.org/bootstrap/tree/src/Plugin/PluginManager.php
http://cgit.drupalcode.org/bootstrap_layouts/tree/src/BootstrapLayoutsPl...

Instead of using the arbitrary "namespaces", we should use "provider" based plugin manager that allows both core and contrib alike to specify exactly which providers should be allowed in their discovery.

Yes, there are instances where plugin discovery should be limited to a single provider (@Block -> modules, @Theme -> themes) . However, in most cases, this limitation is unnecessary.

There is also the problem of the current providerExists() method, in which it defaults to checking the ModuleHandler. By abstracting the providers (and their relevant services) into their own objects/services, we can more easily and correctly determine if the provider actually exists.

Proposed resolution

Introduce the concept of plugin "providers" which allows core and contrib plugin managers to extend from.

Example in contrib:
https://cgit.drupalcode.org/plus/tree/plus.services.yml?h=8.x-4.x
https://cgit.drupalcode.org/plus/tree/src/ProviderPluginManager.php?h=8....
https://cgit.drupalcode.org/plus/tree/src/Plugin/BasePluginProviderType....
https://cgit.drupalcode.org/plus/tree/src/Plugin/ChainedPluginProviderTy...
https://cgit.drupalcode.org/plus/tree/src/Plugin/ModulePluginProviderTyp...
https://cgit.drupalcode.org/plus/tree/src/Plugin/ProfilePluginProviderTy...
https://cgit.drupalcode.org/plus/tree/src/Plugin/ThemePluginProviderType...

Remaining tasks

  • Create patch
  • Create tests

User interface changes

None

API changes

No changes, just an addition.

Data model changes

None

Comments

markcarver created an issue. See original summary.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Issue summary: View changes
markhalliwell’s picture

markhalliwell
Primary language English
commented
Issue tags: +Theme System Modernization Initiative

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Title: [PP-1] Create provider type based plugin managers » [PP-1] Create provider based plugin managers
Issue summary: View changes

Both "provider" and "types" really mean the same thing and is redundant to put them together.

markhalliwell’s picture

markhalliwell
Primary language English
commented
Title: [PP-1] Create provider based plugin managers » [PP-2] Create provider based plugin managers
Issue summary: View changes
Related issues: +#2941757: Extension System, Part IV: Properly register all installed extensions/namespaces during container generation, +#3023131: [PP-1] Extension System, Part IV: ExtensionHandler and ExtensionHandlerInterface

Also postponed on this issue.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mr.baileys’s picture

mr.baileys
Primary language Dutch
Location 🇧🇪 (Ghent)
commented
Issue summary: View changes

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

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

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

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.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.