Problem/Motivation

This was discovered while working on #3332593: Adopt PluginExists validator in relevant places.

It turns out that there are a good number of views in core (mostly test views, but some are part of modules' shipped config) that reference invalid handler plugin IDs. Apparently these are converted to supported plugin IDs at runtime (or install time? I'm not really sure), but that still means the config we're shipping is invalid.

At the moment, the only reason tests don't fail is because we are allowing Views config schema to accept invalid plugin IDs, and considering the fallback plugin IDs as valid, just so we don't have to fix all those views in #3332593: Adopt PluginExists validator in relevant places. That work should be done in a separate scope (this issue).

Steps to reproduce

If you remove the allowFallback: true lines from Views' config schema, you'll start to get test failures due to various views using invalid handler plugin IDs.

Proposed resolution

Remove all of the allowFallback: true lines and fix the views which cause trouble.

Remaining tasks

Do that, and commit it.

Issue fork drupal-3387325

Command icon 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:

About issue forks

Comments

phenaproxima created an issue. See original summary.

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
CreditAttribution: phenaproxima at Acquia commented
Title: Views' config schema should not consider fallback plugin IDs as valid » [PP-1] Views' config schema should not consider fallback plugin IDs as valid
Status: Active » Postponed
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: wim leers at Acquia commented
Issue tags: +Configuration schema, +validation
phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
CreditAttribution: phenaproxima at Acquia commented
Title: [PP-1] Views' config schema should not consider fallback plugin IDs as valid » Views' config schema should not consider fallback plugin IDs as valid
Status: Postponed » Active

Blocker is in.

phenaproxima opened merge request !6526

phenaproxima’s picture

phenaproxima
he/him
Primary language English
Location Massachusetts
CreditAttribution: phenaproxima at Acquia commented
Status: Active » Needs work

Okay, I got the ball rolling here by fixing (I think) nearly all of the kernel tests. Functional tests are probably still going to fail. But I think what I have already got is a good start for someone else to pick up.

bbrala made their first commit to this issue’s fork.

bbrala’s picture

bbrala
Location Netherlands
CreditAttribution: bbrala as a volunteer and at SWIS commented
Status: Needs work » Needs review

All green.

  1. Skip validation on an intentional broken view.
  2. Fix multiple views where plugins were not existing.
  3. Adjust one test which seemed reasonable to have that as output. Think that is no BC

Think this is good to go.

smustgrave’s picture

smustgrave CreditAttribution: smustgrave at Mobomo commented
Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs Review Queue Initiative

Searched for allowFallback: true in views and all 6 instances appear to be addressed.

Assuming if any views were missed they would of got picked up, so assuming this is good to go

quietone’s picture

quietone CreditAttribution: quietone at PreviousNext commented

Skimmed through this and there are no questions unanswered. Rather straightforward actually.