Contrib.social

views.settings config object should not be used to cache list of display extenders

Open on Drupal.org →
Created on 15 September 2023, 9 months ago
Updated 22 May 2024, about 1 month ago

Problem/Motivation

When a module has Views plugins, e.g. a display extender, its presence in the system is listed in the views.settings config objects in the "display_extenders" element. When

Steps to reproduce

Install Metatag Views, which is part of Metatag. Alternatively, install the views_test_data test module.
Enable the new display extender.
Export the configuration to an install profile.
Install a new site using the install profile.

What should happen:
The site installs properly and the display extender is enabled as expected.

What actually happens:
An error will be shown and the installation will fail with an error like the following:

Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginException: "Plugin (metatag_display_extender) instance class "Drupal\metatag_views\Plugin\views\display_extender\MetatagDisplayExtender" does not exist." at core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php line 97

Proposed resolution

Remove Views' ability to enable or disable display extender plugins, so that they're always available.

Remaining tasks

Work out the best approach to fix this.

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

TBD

🐛 Bug report
Status

Needs work

Version

11.0 🔥

Component
Views  →

Last updated about 4 hours ago

Created by

🇺🇸United States DamienMcKenna NH, USA

Live updates comments and jobs are added and updated live.
  • Contributed project blocker

    It denotes an issue that prevents porting of a contributed project to the stable version of Drupal due to missing APIs, regressions, and so on.

  • Needs subsystem maintainer review

    It is used to alert the maintainer(s) of a particular core subsystem that an issue significantly impacts their subsystem, and their signoff is needed (see the governance policy draft for more information). Also, if you use this tag, make sure the issue component is set to the correct subsystem. If an issue significantly impacts more than one subsystem, use needs framework manager review instead.

Sign in to follow issues

Comments & Activities

  • Issue created by @DamienMcKenna
  • Comment 9 months ago →
    🇺🇸United States DamienMcKenna NH, USA

    Is there any practical benefit for being able to disable display extender plugins without uninstalling the module they come from?

  • Status changed to Needs review 9 months ago
  • Open in Jenkins → Open on Drupal.org →
    Environment: PHP 8.2 & MySQL 8
    last update 9 months ago
    Custom Commands Failed
  • Comment 9 months ago →
    🇺🇸United States DamienMcKenna NH, USA

    This won't work, but it's a start to remove that functionality entirely.

  • Comment 9 months ago →
    🇺🇸United States DamienMcKenna NH, USA
  • Comment 9 months ago →
    🇺🇸United States DamienMcKenna NH, USA
  • Comment 9 months ago →
    🇬🇧United Kingdom longwave UK

    To me I don't see the point in this config option so +1 for the deprecation/removal of it; tagging for subsystem maintainer review for more input.

  • Assigned to DamienMcKenna
  • Status changed to Needs work 9 months ago
  • Comment 9 months ago →
    🇺🇸United States DamienMcKenna NH, USA

    Thanks.

    I'm going to work on the test coverage a little more.

  • Comment 9 months ago →
    🇺🇸United States DamienMcKenna NH, USA

    I've been looking at two tests related to this, so figured I'd look into it more:

    • core/modules/views/tests/src/Kernel/Plugin/DisplayExtenderTest.php - Checks the logic around enabled display extenders. This currently fails because the new logic makes all display extenders appear enabled by default. Updating the test to the correct the number seems a little redundant.
    • core/modules/views_ui/tests/src/Functional/DisplayExtenderUITest.php - Checks that display extenders can be enabled. The new logic results in the test shows that when it saves the form it hits \Drupal\views_test_data\Plugin\views\display_extender\DisplayExtenderTest3::validator() and fails with the message "Display extender test error". Which seems like it's by design. Hrm..
  • Comment 9 months ago →
    🇺🇦Ukraine gilmord 🇺🇦Ukraine

    makes sense for me, if the Metatag Views or the Simple XML Sitemap (Views) is enabled - I`d expect the display extenders to be enabled without changes to views.settings config

  • Comment about 1 month ago →
    🇨🇭Switzerland Castor-designs

    Hello everyone. I ran into this very problem when migrating from drupal 9 to drupal 10 and running updates.
    Is there a workaround in the meantime to "unbreak" the site or prevent it in the first place?

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024