Reset plugin discovery when a module/theme is installed

Created on 14 March 2017, over 7 years ago
Updated 16 July 2023, 12 months ago

Problem/Motivation

When modules are installed, plugin definitions are cleared.
Breakpoints and Layouts also allow themes to provide plugins, they need to be cleared as well.

Any manager using YamlDiscovery has to pass in the list of directories to search, and these are not updated.
Additionally, the %container.namespaces% parameter is updated by the DrupalKernel, but is also cached by the discovery

Proposed resolution

Reset the discovery in \Drupal\Core\Plugin\DefaultPluginManager::clearCachedDefinitions()
Adjust \Drupal\Core\Extension\ThemeInstaller::resetSystem() to match \Drupal\Core\Extension\ModuleInstaller

Remaining tasks

Reroll
Review
Commit

User interface changes

N/A

API changes

N/A

Data model changes

N/A

🐛 Bug report
Status

Needs work

Version

11.0 🔥

Component
Plugin 

Last updated 1 day ago

Created by

🇺🇸United States tim.plunkett Philadelphia

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

    Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

  • 🇮🇳India Nikhil_110

    Attached patch against Drupal 10.1.x

    Patch #34 is not applied for Drupal 10.1.x so Inter-diff file is not added.

    Checking patch core/lib/Drupal/Core/Entity/EntityTypeManager.php...
    Checking patch core/lib/Drupal/Core/Extension/ThemeInstaller.php...
    Hunk #1 succeeded at 300 (offset -4 lines).
    Checking patch core/lib/Drupal/Core/Plugin/DefaultPluginManager.php...
    Hunk #1 succeeded at 198 (offset 6 lines).
    Checking patch core/modules/breakpoint/tests/src/Kernel/BreakpointDiscoveryTest.php...
    error: while searching for:
    
      protected function setUp(): void {
        parent::setUp();
        \Drupal::service('theme_installer')->install(['breakpoint_theme_test']);
      }
    
    
    error: patch failed: core/modules/breakpoint/tests/src/Kernel/BreakpointDiscoveryTest.php:24
    error: core/modules/breakpoint/tests/src/Kernel/BreakpointDiscoveryTest.php: patch does not apply
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.1 & MySQL 5.7
    last update about 1 year ago
    29,364 pass, 1 fail
  • 🇬🇧United Kingdom alexpott 🇪🇺🌍
    1. +++ b/core/lib/Drupal/Core/Extension/ThemeInstaller.php
      @@ -300,6 +300,13 @@ public function uninstall(array $theme_list) {
      +    // Clear plugin manager caches.
      +    \Drupal::getContainer()
      +      ->get('plugin.cache_clearer')
      +      ->clearCachedDefinitions();
      

      This dependency should be injected - all the others are in class already.

    2. +++ b/core/lib/Drupal/Core/Extension/ThemeInstaller.php
      @@ -300,6 +300,13 @@ public function uninstall(array $theme_list) {
      +
      +    $this->themeHandler->refreshInfo();
      

      Why is this necessary? Both install and uninstall are already calling $this->themeHandler->reset();

  • 🇦🇺Australia alex.skrypnyk Melbourne

    #34 states that #19 was addressed in #21, but it is not actually clear whether #21 meant that in a context of initially provided patch or in general:

    That will clear the cache of definitions, which is fine. But that already happens due to a call to \Drupal::service('plugin.cache_clearer')->clearCachedDefinitions();.
    This issue is about the actual discovery object itself.

    So #19 is not actually addressed if the patch is not applied and it can be an easier solution.

    https://www.drupal.org/node/3204271 has a similar issue that is possible caused by already cached definitions.

    For example, for LayoutPluginManager, adding of the cache tag based on the installed extensions resolves the issue

    $this->setCacheBackend($cache_backend, $type, ['config:core.extension']);
    
Production build 0.69.0 2024