Make Block config entities fully validatable

Repurposing this to add validation constraints; the original issue summary no longer makes sense because the scope/approach of 📌 Configuration schema & required values: add test coverage for `nullable: true` validation support Fixed evolved.

Well this is interesting… AFAICT block.block.*:provider is dead/completely unused, but block.block.*:settings.provider is used.

Ah, I finally found the explanation for why status, info and view_mode are part of the generic type: block_settings (and hence apply to ALL block plugins!).

The answer: it's simply an oversight that occurred in #2274175: Block plugin schema should be defined separately from the entity → . 😄👍 (\Drupal\block_content\Plugin\Block\BlockContentBlock landed >1 year earlier, but the tight coupling only was removed ~6 months earlier, in #1927608: Remove the tight coupling between Block Plugins and Block Entities → . Arguably at least there this should've been rectified, but that was at the height of the "we must get D8 done yesterday!" era, so it totally makes sense.)

So this issue is definitely cleaning up some very old technical debt, that's caused confusion for every person who has ever looked at the exported YAML for blocks! 🚀

Great find! Would be great to have CR for that change somehow as I bet some contrib already using the same pattern

#6: this will absolutely need a change record — probably multiple!

Wow, with #5 fixed, plus one small fix to the ExtensionExists constraint, we went from 788 failures to 115 failures! Suddenly this became doable 😄

Yay, and after refining the constraints for the sole block (the search block) whose settings I've added validation constraints to: 115 → 56 failures.

Reduced scope by:

1. Undeprecating the (unused and useless) provider exported property in Block config entities around dropped us to 52 failures
2. Undeprecating the status and info settings for "content block" blocks dropped us to 51 failures

Rewrote issue summary 👍

GREEN!

Update path tomorrow.

Very satisfied that I got this to green with just 18 files, +138, -49 in less than a day 🥳🚀 With this in, we could seriously accelerate config validation adoption, and Recipes indirectly!

2 of the 3 follow-ups created.

Update path test pushed.

Update path pushed.

3rd follow-up created (with MR!).

Two blockers created:

• 📌 Add config validation for weights (blocks, filters, etc. all use weights) Fixed
• 🐛 ExistsConstraintValidator should ignore NULL values and treat `core` as a valid module Needs review

… both with a ready-to-review MR that's green. 😊

Ready for final review! But please help land the two (trivial!) blockers first 😄

📌 Add config validation for weights (blocks, filters, etc. all use weights) Fixed is in! Will update this MR in the morning.

Next up: 🐛 ExistsConstraintValidator should ignore NULL values and treat `core` as a valid module Needs review .

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

MR now on top of 📌 Add config validation for weights (blocks, filters, etc. all use weights) Fixed 👍

🐛 ExistsConstraintValidator should ignore NULL values and treat `core` as a valid module Needs review is in too.

Will update this MR.

I found one tiny nitpick.

I started added explicit validation logic for all of the properties on Block config entities. I just pushed the test coverage for theme.

But then I noticed that block.block.*:region doesn't have a validation constraint just yet! So this definitely needs more work before it is ready for final review. Will continue this next week.

Marked NR for initial review.

This is looking good but still needs some changes...

A few questions but overall I think this looks pretty good.

Two very minor things (basically just rewordings), otherwise I think this is OK.

Feedback addressed

No objections here.

I read the issue summary, the comments and the MR (not a code review). The find in #5 is great!

I resolved the low hanging comments, leaving 7 to look at. I did find one unanswered question in the MR, I have the same question, so let's get that answered. Setting to NW.

I think it would help if the issue summary explained why BlockInvalidRegionTest, testRebuildInvalidBlocks() are deleted

I also question the need to shout at the reader in comments. I am referring to the use of 'TRICKY', a word that also have negative connotations. If we need to draw people's attention to something there is always the use of "Note that ...". There may be other options. This is not meant to block progress on this issue. This conversation may be more suitable for a separate issue.

Forgot to add, that all the followup are made, with complete issue summaries and the links in the MR are correct.

I removed the unnecessary test coverage, but as far as I can tell, this is otherwise good to go. I'm going to go ahead and boldly restore RTBC here, and if there's anything further to fix, let's get it over the line. This issue is even more imperative since ✨ Create flexible config actions to place a block in the admin or default themes Needs review is close to ready.

I don't think that config validation issues shoudl just in a type widening for used values. Weight is always an integer once a block has been saved because config casts the value.

Alright, all done here AFAIK. I did the deprecation dance around non-integer block weights.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. 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.

Added some more review comments. Nice work on fixing up the int-ness of weight @phenaproxima

I think I've addressed all of @alexpott's feedback.

Reviewed

Okay, I agree with you @tim.plunkett; did the deprecation dance around page_id and added a change record.

Great work, all!

I reviewed it again today as well, and the one remark I had was answered. RTBC++

Committed 1c21864 and pushed to 11.x. Thanks!

Given where we are at in the 11.0.0 release cycle we can't commit this to 11.0.0 and have to target 11.1.0 instead. I've updated the deprecation messages and tests on commit.

diff --git a/core/modules/block/src/Entity/Block.php b/core/modules/block/src/Entity/Block.php
index 2effc409b7..68582e48f0 100644
--- a/core/modules/block/src/Entity/Block.php
+++ b/core/modules/block/src/Entity/Block.php
@@ -349,7 +349,7 @@ public function preSave(EntityStorageInterface $storage) {
     parent::preSave($storage);
 
     if (!is_int($this->weight)) {
-      @trigger_error('Saving a block with a non-integer weight is deprecated in drupal:11.0.0 and removed in drupal:12.0.0. See https://www.drupal.org/node/3462474', E_USER_DEPRECATED);
+      @trigger_error('Saving a block with a non-integer weight is deprecated in drupal:11.1.0 and removed in drupal:12.0.0. See https://www.drupal.org/node/3462474', E_USER_DEPRECATED);
       $this->setWeight((int) $this->weight);
     }
 
diff --git a/core/modules/block/tests/src/Kernel/BlockValidationTest.php b/core/modules/block/tests/src/Kernel/BlockValidationTest.php
index 9a1a2412d6..2456e7fb57 100644
--- a/core/modules/block/tests/src/Kernel/BlockValidationTest.php
+++ b/core/modules/block/tests/src/Kernel/BlockValidationTest.php
@@ -176,7 +176,7 @@ public function testWeightValidation(): void {
   public function testWeightCannotBeNull(): void {
     $this->entity->set('weight', NULL);
     $this->assertNull($this->entity->getWeight());
-    $this->expectDeprecation('Saving a block with a non-integer weight is deprecated in drupal:11.0.0 and removed in drupal:12.0.0. See https://www.drupal.org/node/3462474');
+    $this->expectDeprecation('Saving a block with a non-integer weight is deprecated in drupal:11.1.0 and removed in drupal:12.0.0. See https://www.drupal.org/node/3462474');
     $this->entity->save();
   }
 
diff --git a/core/modules/search/search.module b/core/modules/search/search.module
index 8d5b1e330d..0944c53dcf 100644
--- a/core/modules/search/search.module
+++ b/core/modules/search/search.module
@@ -428,7 +428,7 @@ function search_block_presave(BlockInterface $block) {
   if ($block->getPluginId() === 'search_form_block') {
     $settings = $block->get('settings');
     if ($settings['page_id'] === '') {
-      @trigger_error('Saving a search block with an empty page ID is deprecated in drupal:11.0.0 and removed in drupal:12.0.0. To use the default search page, use NULL. See https://www.drupal.org/node/3463132', E_USER_DEPRECATED);
+      @trigger_error('Saving a search block with an empty page ID is deprecated in drupal:11.1.0 and removed in drupal:12.0.0. To use the default search page, use NULL. See https://www.drupal.org/node/3463132', E_USER_DEPRECATED);
       $settings['page_id'] = NULL;
       $block->set('settings', $settings);
     }

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