Problem/Motivation
When adding an empty extra field in Layout Builder, the resulting page will always render the wrapping div of ExtraFieldBlock even when the extra field has empty content.
Details
ExtraFieldBlock.php's build() method will always return a placeholder render array if an extra field is present. While BlockComponentRenderArray.php's onBuildRender() methods attempts to screen out empty blocks, the extra field block will always pass because of the placeholder. This causes it to add the block for rendering ($build = ['#theme' => 'block', ...). When time comes to render the contents, since core/lib/Drupal/Core/Render/Renderer.php's doRender() method will always render arrays with a #theme present, it renders the wrapper div, even when it contains no content.
When rendering the page without using Layout Builder, the extra field just doesn't exist in the render array and no wrapper div is rendered.
Unsure whether this is expected behavior or not for Layout Builder. But I do expect that it would behave similar to how it did without using Layout Builder.
References:
- https://github.com/drupal/drupal/blob/9.0.0/core/modules/layout_builder/...
- https://github.com/drupal/drupal/blob/9.0.0/core/modules/layout_builder/...
- https://github.com/drupal/drupal/blob/9.0.0/core/lib/Drupal/Core/Render/...
Steps to reproduce
- Add an extra field on a node using
hook_entity_extra_field_info(). - Add the
hook_ENTITY_TYPE_view()for the extra field, but don't add anything to the$buildarray. - Create a node type with Layout Builder enabled on Full Content.
- Add that field into the type's layout.
- Create a page of that node type.
- View the page.
Proposed resolution
Add a pre-render callback to ensure empty extra_field blocks are not rendered.
Remaining tasks
Update summary
User interface changes
No empty div is printed when extra field is empty.
API changes
None.
Data model changes
None.
Release notes snippet
N/A
| Comment | File | Size | Author |
|---|---|---|---|
| #48 | 3152281-10.2-48.diff | 6.14 KB | herved |
Issue fork drupal-3152281
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:
- 3152281-extra-field-blocks
changes, plain diff MR !6384
Comments
Comment #2
larowlanMy suggestion here would be to create your own block plugin instead of using the extra fields API if you're moving to Layout Builder - is that possible in this case?
Comment #4
msnassar commentedI could reproduce this using some core extra fields e.g. "Moderation control"
Steps to reproduce:
- Enable layout builder for any content type that has moderation enabled.
- Add new section
- Add "Moderation control" to the section
- Add new "published" content
The resulting page will always render the wrapping div!
Comment #5
herved commentedI'm having the same issue.
I suggest to add a pre_render and apply the same emptiness logic as
\Drupal\block\BlockViewBuilder::preRenderComment #6
richgerdes+1 for the patch. This patch worked for me and successfully cleared the extra block from our layout.
I think @larowlan's solution makes sense, however in our case the extra fields are used in layout builder but also other display modes which don't use layout builder in the site, so it having them as extra fields simplifies the project. That being said, the block approach would likely be a simpler solution if it would work for all displays.
Comment #10
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.
For this issue to move forward next it will need a test case showing the problem.
Thanks.
Comment #11
herved commentedHere is a minimal test which should highlight clearly the issue.
Test only patch should fail of course, and the other one includes the pre_render from #5.
About #2 and #10: Extra fields are used in many places now. Modules like https://www.drupal.org/project/extra_field rely on it.
If the render array is NULL or only contains #cache, it is only logical to hide the container div completely.
In my case, those empty divs are really problematic when assessing the emptiness of layout builder regions which sometimes have specific styles applied on them.
Comment #13
smustgrave commentedSo tried replicating
On Drupal 10.1 with standard install
Enabled layout builder for Basic page
Added section
Added Moderated Control block
Create a basic page node (published)
The section markup appears with and without the patch
I do not see an empty div for blocks with or without the patch
Am I missing a step?
Comment #14
herved commentedAre you sure?
I just tried with 9.5.x and 10.1.x and was able to reproduce in both cases.
Indeed the section markup still shows up but this issue only resolves the extra field markup.
For sections I think this is up to layouts to check for emptiness and not render if that's the case.
The markup for a published node is as follows:
Comment #15
smustgrave commentedSo tried retesting and seems like this does work but doesn't fix existing pages. Should we have an upgrade path for those?
Comment #16
herved commentedThere is no upgrade path needed, only a clear cache is required.
Did you clear caches after applying the patch?
Thanks
Comment #17
smustgrave commentedCleared cache a few times and it finally took.
Thanks for baring with me on that one haha.
Comment #19
herved commentedSetting back to RTBC.
It looks like the testbot had some issues a few days ago which seem completely unrelated to this patch... after re-queuing the patch the errors disappeared.
https://www.drupal.org/pift-ci-job/2604971 for reference.
Comment #20
tim.plunkettAn empty post_update hook will force the caches to be cleared, it's worth adding that IMO
Comment #22
pfeiffer commentedI rerolled the patch on comment #11 to Drupal 10.2
Comment #23
chrisolofAdding interdif.
Comment #24
chrisolofI tried applying the patch from #22, but ran into errors due to the removal of Drupal\Core\Security\TrustedCallbackInterface. I think the removal of TrustedCallbackInterface was likely unintentional.
Attached is a re-roll of the patch in #11 against 10.2.x, with the requested post_update hook added so a cache clear is forced.
Comment #25
smustgrave commentedManually triggered #24 bur appears to have a failure. Didn't do a full review but recommend switching to MR.
Comment #28
hardik_patel_12 commentedComment #29
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 #30
chrisolofComment #31
smustgrave commentedLeft a nitpicky but a comment on the tests if possible to also get a positive assertion.
Comment #32
smustgrave commentedDidn’t mean to change status
Comment #33
smustgrave commentedBeen a few days so moving to NW for the small comment.
Comment #35
vaish commentedI resolved the merge conflict and addressed the nitpicks. Moving to needs review.
Comment #36
smustgrave commentedCleaned up the issue summary some.
Appears close but moving to NW to update the missing pieces of the summary, left TBD in there.
Comment #37
mlncn commentedUpdated summary.
Comment #38
smustgrave commentedFeedback appears to be addressed.
Comment #39
quietone commentedTriaging the RTBC queue. I didn't find any unanswered questions and the comments in the MR are clear.
Leaving at RTBC.
Comment #40
nod_Code seems reasonable, not a subject I'm comfortable committing though. RTBC +1
Comment #41
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 #42
shalini_jha commentedComment #43
shalini_jha commentedI have checked this MR and found some conflicts, which I have addressed. The pipeline was failing due to an unknown word. For fixing this issues , reviewing the existing test method for same word, so same way I added it to the cspell:ignore , and the pipeline passed successfully. After that, I revalidated the test coverage, and it is working as expected.
Kindly review.
Failing test :
Comment #44
shalini_jha commentedMoving this for NR.
Comment #45
smustgrave commentedRebase seems fine.
Comment #47
alexpottI think we need to add a positive test in some way - at least the test fails without the fix but this is very fragile as we're depending on the CSS class names for the test - which are not API - therefore I think we need to go to the effort of a positive test case somehow - suggestion left on MR
Comment #48
herved commentedI rebased the MR and added test assertions to address #47.
Attaching static patch for composer that applies on 10.2.x.
Comment #49
herved commentedphpcs fails, some more work needed
Comment #50
herved commentedComment #51
smustgrave commentedAll feedback appears to be addressed
Test-only gives
Comment #52
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 #53
herved commentedMR rebased
Comment #54
smustgrave commentedSeems like a good rebase.
Comment #55
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 #56
shalini_jha commentedComment #57
smustgrave commentedRestoring previous status.
Comment #58
catchWe generally don't add empty updates purely to clear render caches - updating core may run other updates anyway, or if this ends up being the only update that gets run, then sites can clear caches on deployment. Went ahead and removed that prior to commit.
Committed/pushed to 11.x and cherry-picked to 11.3.x, thanks!