Problem/Motivation
Blocks are some of the most widely used config entities. They should be validatable. This would be very valuable for the Recipes Initiative, especially now that Recipes uses config validation (see #3405328: [meta] Make recipes safer to use in the real world by supporting config validation and rolling back a broken recipe for details).
Proposed resolution
This can easily become a huge scope, so limit the scope to be reviewable:
- Make
block.block.*validatable. - Introduce
type: block.settings.block_content:*to fix the accidental leftovers from when content blocks ("custom blocks" in Drupal 7) were split out — see #5 - Make one concrete block plugin with settings fully validatable: the search block (
type: block.settings.search_form_block) - Open blockers for essential problems that are out of scope:
- ✅ Reduction by 11 LoC in this MR: #3426309: Add config validation for weights (blocks, filters, etc. all use weights)
- ✅ Reduction by 1 file/11 LoC in this MR: #3426324: ExistsConstraintValidator should ignore NULL values and treat `core` as a valid module
- Open follow-ups for non-essential problems encountered along the way — see under "remaining tasks"
.
Remaining tasks
- ✅ Implement proposed solution
- ✅ Get tests passing
- ✅ Search module must provide update path for
search_form_blockblocks'page_idsetting - Explicit test coverage for each top-level property of a
Blockconfig entity inBlockValidationTest.
Follow-ups:
- #3426278: Deprecate unused `provider` exported property from Block config entities
- #3426279: Deprecate `null` as valid `weight` for Block config entities
- #3426302: Deprecate and remove `status` and `info` settings from `block_content` blocks
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
TBD
| Comment | File | Size | Author |
|---|---|---|---|
| #34 | 3379725-nr-bot.txt | 10.18 KB | needs-review-queue-bot |
| #15 | 3379725-nr-bot.txt | 90 bytes | needs-review-queue-bot |
Issue fork drupal-3379725
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:
- 3379725-validatable-block
changes, plain diff MR !6938
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