Closed (fixed)
Project:
Drupal core
Version:
11.x-dev
Component:
block.module
Priority:
Major
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
7 Aug 2023 at 15:08 UTC
Updated:
14 Jul 2025 at 03:11 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
wim leersRepurposing this to add validation constraints; the original issue summary no longer makes sense because the scope/approach of #3364109: Configuration schema & required values: add test coverage for `nullable: true` validation support evolved.
Comment #4
wim leersWell this is interesting… AFAICT
block.block.*:provideris dead/completely unused, butblock.block.*:settings.provideris used.Comment #5
wim leersAh, I finally found the explanation for why
status,infoandview_modeare part of the generictype: 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\BlockContentBlocklanded >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! 🚀
The crucial commit: https://git.drupalcode.org/project/drupal/-/merge_requests/6938/diffs?co...
Comment #6
andypostGreat find! Would be great to have CR for that change somehow as I bet some contrib already using the same pattern
Comment #7
wim leers#6: this will absolutely need a change record — probably multiple!
Wow, with #5 fixed, plus one small fix to the
ExtensionExistsconstraint, we went from 788 failures to 115 failures! Suddenly this became doable 😄Comment #8
wim leersYay, and after refining the constraints for the sole block (the search block) whose settings I've added validation constraints to: 115 → 56 failures.
Comment #9
wim leersReduced scope by:
providerexported property inBlockconfig entities around dropped us to 52 failuresstatusandinfosettings for "content block" blocks dropped us to 51 failuresComment #10
wim leersRewrote issue summary 👍
Comment #11
wim leersGREEN!
Update path tomorrow.
Very satisfied that I got this to green with just
18 files, +138, -49in less than a day 🥳🚀 With this in, we could seriously accelerate config validation adoption, and Recipes indirectly!Comment #12
wim leers2 of the 3 follow-ups created.
Update path test pushed.
Comment #13
wim leersUpdate path pushed.
3rd follow-up created (with MR!).
Two blockers created:
… both with a ready-to-review MR that's green. 😊
Ready for final review! But please help land the two (trivial!) blockers first 😄
Comment #14
wim leers#3426309: Add config validation for weights (blocks, filters, etc. all use weights) is in! Will update this MR in the morning.
Next up: #3426324: ExistsConstraintValidator should ignore NULL values and treat `core` as a valid module.
Comment #15
needs-review-queue-bot commentedThe 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.
Comment #16
wim leersMR now on top of #3426309: Add config validation for weights (blocks, filters, etc. all use weights) 👍
Comment #17
wim leers#3426324: ExistsConstraintValidator should ignore NULL values and treat `core` as a valid module is in too.
Will update this MR.
Comment #18
borisson_I found one tiny nitpick.
Comment #19
wim leersI started added explicit validation logic for all of the properties on
Blockconfig entities. I just pushed the test coverage fortheme.But then I noticed that
block.block.*:regiondoesn'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.Comment #21
narendrarMarked NR for initial review.
Comment #22
phenaproximaThis is looking good but still needs some changes...
Comment #23
narendrarComment #24
phenaproximaA few questions but overall I think this looks pretty good.
Comment #25
narendrarComment #26
phenaproximaTwo very minor things (basically just rewordings), otherwise I think this is OK.
Comment #27
narendrarFeedback addressed
Comment #28
phenaproximaNo objections here.
Comment #29
quietone commentedI 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.
Comment #30
quietone commentedForgot to add, that all the followup are made, with complete issue summaries and the links in the MR are correct.
Comment #31
phenaproximaI 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 #3448131: Create flexible config actions to place a block in the admin or default themes is close to ready.
Comment #32
alexpottI 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.
Comment #33
phenaproximaAlright, all done here AFAIK. I did the deprecation dance around non-integer block weights.
Comment #34
needs-review-queue-bot commentedThe 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.
Comment #35
phenaproximaComment #36
alexpottAdded some more review comments. Nice work on fixing up the int-ness of weight @phenaproxima
Comment #37
phenaproximaI think I've addressed all of @alexpott's feedback.
Comment #38
tim.plunkettReviewed
Comment #39
phenaproximaOkay, I agree with you @tim.plunkett; did the deprecation dance around page_id and added a change record.
Comment #40
tim.plunkettGreat work, all!
Comment #41
borisson_I reviewed it again today as well, and the one remark I had was answered. RTBC++
Comment #42
alexpottCommitted 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.
Comment #45
wim leersLet's make more block plugins benefit from this:
Comment #46
larowlanSome more blocks that could benefit here