Views with broken handlers still return results even if the results might be incorrect

Making the view return no results could be very disruptive, because if existing sites have broken handlers then updating to a release where this was fixed would make pages that were returning content suddenly return no content. Throwing an error to end users would be even more disruptive. So I'm not really sure what to do here.

There are all really good points, mhhh

Here is just a list of further ideas we might or might not apply partially ...

• Trigger an error. Production sites will not see them, other sites will, hopefully have enabled them
• Always at least provide some logging
• We could have a flag for more paranoid sites to opt into returning no results
• Could we do some validation everytime someone executes a config import? I would personally deny importing configuration which might cause a broken view, like for example when you uninstall a module, but the view, for whatever reason, didn't had the dependencies in the first place?

This issue has come up again in #2915383: The moderation_state base field is added to all revisionable entity types even if they do not have moderation enabled as a potential blocker. Another idea might be an error on the status report?

Making the view return no results could be very disruptive, because if existing sites have broken handlers then updating to a release where this was fixed would make pages that were returning content suddenly return no content.

Some additional ideas to minimise this disruption would be to decide which plugins are concerned with integrity/access and only hide results if those are broken. I think if we can combine that with an obvious status report entry with a clear message on how to resolve the issue, it could be an acceptable behavioral change. Where a handler is broken and no longer relevant, a user is required to edit and remove the offending plugin. Where a handler is broken incorrectly, it's a good prompt to review the view for integrity issues.

The handlers I'd consider access/integrity concerned are:

• access
• argument
• argument_default
• argument_validator
• cache
• display_extender
• exposed_form
• filter
• join
• query
• relationship

It would be great to get some further input on this.

There is only a limited number of 'broken' handlers, any other handler type that has a missing plugin will just break/fatal.

If I remove the 'none' access handler:
The website encountered an unexpected error. Please try again later.Drupal\Component\Plugin\Exception\PluginNotFoundException: The "none" plugin does not exist. in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 52 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

So this would only apply to handlers that we actually provide a broken handler for:
\Drupal\views\Plugin\views\relationship\Broken
\Drupal\views\Plugin\views\field\Broken
\Drupal\views\Plugin\views\sort\Broken
\Drupal\views\Plugin\views\argument\Broken
\Drupal\views\Plugin\views\filter\Broken
\Drupal\views\Plugin\views\area\Broken

The fact that Views allows you to work with broken config in the first place is incredibly lenient. It's broken, so break.... I don't know of any other config entity that actually allows you to work with it while it's knowingly broken.

This might be too radical for D8 but I could definitely get behind deprecating the broken handlers and the underlying logic that provides that fall back. It's broken, we know it's broken, you know it's broken, fix it and be merry!

Once we have #2832558: Add a 'disabled' section to config changes page when removing config I like @xjms idea to disable the Views. It might be an idea to run an update and disable all Views that have broken handlers, and maybe just not allow Views that have broken handlers to be enabled. And when we hit the current 'broken' logic, we disable the View. Yes this is disruptive, but since it's almost impossible to judge the impact of a broken handler it would be the safe thing to do. Like the IS states, a broken filter could lead to an information disclosure (although unlikely, unless we break the node status filter), but best to be safe I think.

As I rely on the functionality, that views with broken handlers still return a result, I would prefer this to be configurable.

I understand the broken filter handler might be a serious issue. But displaying a view with broken field handler is a useful feature on multisites (or sites using the same codebase), as the view works regardless if the field exists or not.

Suggested solution: Do not display insecure views.
Views with
\Drupal\views\Plugin\views\relationship\Broken
\Drupal\views\Plugin\views\argument\Broken
\Drupal\views\Plugin\views\filter\Broken
should not return any results

Views with
\Drupal\views\Plugin\views\field\Broken
\Drupal\views\Plugin\views\sort\Broken
\Drupal\views\Plugin\views\area\Broken
should still return results.

For D10 display an error message instead of the result, for views with any broken handler. Allow to configure/override in contrib.