Fix all PluginExistsConstraint constraint violations in tests

Migrating Pittsburgh 2023 to Pittsburgh2023 tag for cleanup

heh this one had more challenges in the functional than kernel/unit. Okay, will work on this later

No longer postponed, can be rerolled.

This looks great, probably should be mentioned in the CR for 📌 Fix all ConfigExists constraint violations in tests Fixed as well. Waiting for rtbc on the testbot status.

32 failures, on it!

AFAICT 100% of test failures are related to block config entities pointing to block_content content entities.

Related: 📌 Implement fallback plugin for Block plugins Fixed , 🌱 [meta] Deploying configuration that depends on content Active .

We just need to support FallbackPluginManagerInterface in PluginExists and all should be well. Not doing that would also be hugely disruptive.

This conflicted with 📌 `type: mapping` should use `ValidKeys: ` constraint by default Fixed ! Should be good again now :)

Still one fail

It's unfortunate, but due to the way 📌 Implement fallback plugin for Block plugins Fixed was implemented, we must expect NO validation error when an invalid block plugin ID is specified. Even if it's not pointing to a block_content:<uuid> plugin ID.

It'd have been better if #2249303 had special-cased block_content:* plugin IDs. OTOH, this means that other content-like block plugins that would otherwise run into 🌱 [meta] Deploying configuration that depends on content Active , also fall back automatically.

Improving that by narrowing when it falls back is the responsibility of the Block module, and would have a significant disruption risk, so it's out of scope here. The aim of this issue is to ensure all config is valid. And referencing a non-existing block plugin ID in a block config entity is valid ever since #2248369, unfortunately.

Created 🐛 BlockManager is too eager in providing fallback to "Broken" block: it obscures genuine problems Active for this.

Addressed the last failure, with expanded test coverage: one specifically for block_content:* that should not trigger a validation error now nor after 🐛 BlockManager is too eager in providing fallback to "Broken" block: it obscures genuine problems Active , and one test case that should trigger a validation error after #3377709.

Change looks good to me and all green.

The MR needs to be rebased

Done. Trivial conflict in core/lib/Drupal/Core/Config/Schema/SchemaCheckTrait.php thanks to 📌 Fix all type: machine_name constraint violations in tests Fixed having landed.

Committed 4cb1084 and pushed to 11.x. Thanks!

lauriii → closed merge request !4152

Automatically closed - issue fixed for 2 weeks with no activity.