Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.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
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | drupal-n3387596-3.patch | 5.12 KB | damienmckenna |
Issue fork drupal-3387596
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
damienmckennaIs there any practical benefit for being able to disable display extender plugins without uninstalling the module they come from?
Comment #3
damienmckennaThis won't work, but it's a start to remove that functionality entirely.
Comment #4
damienmckennaComment #5
damienmckennaComment #6
longwaveTo 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.
Comment #7
damienmckennaThanks.
I'm going to work on the test coverage a little more.
Comment #8
damienmckennaI've been looking at two tests related to this, so figured I'd look into it more:
Comment #9
gilmordmakes 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
I use both of those modules and get the same error as described when installing the website on the fresh database.
Comment #10
castor-designs commentedHello everyone. I ran into this very problem when trying to upgrade any module after this iteration:
Is there a workaround in the meantime to "unbreak" the site or prevent it in the first place?
Here's my exact error: https://pastebin.com/Lnc9LGbj
And here is a Screenshot Series of what I am doing step by step: https://imgur.com/a/frC5mEA
Comment #14
catchMarked #3460063: Views display extenders should only save enabled extenders as duplicate.
Comment #16
bbralaAdded #3440962: Add validation constraints to views.settings since this blocks that through a jump issue that was closed as 'duplicate' of this.
Comment #17
bbralaComment #19
ptmkenny commentedI started running into this issue from 11.2.x when initializing a site. Up to 11.1, I didn't have any errors, but from 11.2, I started getting this error:
Applying the MR allows me to initialize my site (clear the database and install Drupal, then run
drush cim).Comment #20
longwaveFixed up the tests, will need an upgrade path to remove the config.
Comment #21
godotislateNot showing up in the junit, but there are failures in
Drupal\Tests\views\Unit\Plugin\display\PathPluginBaseTestthat look like this:Comment #22
longwaveFixed the test, deleted the config and schema, added an update hook and a test for that.
Comment #23
godotislateLooks like there are additional test failures to address now. Some performance tests need tweaks, but there are other are functional test failures having to do with config validation and/or UI issues.
MR changes otherwise make sense.
Also tagging Needs change record for the code deprecation and the removal of the extenders checkboxes from View UI form.
Comment #24
longwaveI spot checked some and they were all schema validation issues, let's see if this fixes everything. Also added a basic change record.
Comment #25
godotislateThere are a few more performance test numbers that need updating, but otherwise I am +1 for RTBC. I also looked at the CR, and it looks fine.
This was tagged 'Needs subsystem maintainer review' in #6. Is that still outstanding?
Comment #26
longwaveWe should try to get @lendude's signoff, will ping in Slack.
Comment #28
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #29
longwaveRebased, not sure about the performance figures, let's see what CI says.
Comment #30
longwavePerformance tests still need work