views.settings config object should not be used to cache list of available plugins

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

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

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.

Thanks.

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

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..

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

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?

catch → credited Lendude → .

catch → credited scott_euser → .

catch → credited smustgrave → .

Marked 🐛 Views display extenders should only save enabled extenders Needs review as duplicate.