Problem/Motivation
From #2959493: Allow Layout Builder live previews to be toggled to allow easier drag-and-drop item 5
When live preview mode is disable in the Layout Builder UI, the placeholder labels are added via Javascript. When live preview mode is re-enabled, the labels are removed from the DOM by javascript. It would be simpler for maintainers and other developers if these labels were always present and conditionally visible based on a parent class.
Proposed resolution
Figure out a way to add the labels to Layout Builder blocks inside the UI that have a structure consistent enough to facilitate visibility based on only CSS rules. Currently, the content of .layout-builder-block .content is not consistent enough to safely target with CSS, and sometimes includes child elements that are not wrapped in tags.
This will be made much easier if the placeholder labels are siblings of .layout-builder-block .content instead of children.
The current placeholder logic is in JS and BlockComponentRenderArray::onBuildRender.
Remaining tasks
Determine the best approach to add a consistently structured content-preview-disabled placeholder label in Layout Builder blocks. Make these conditionally visible based on the the presence of .layout-builder--content-preview-disabled wrapping the Layout Builder UI Implement, then remove the JS and other code responsible for adding/removing the labels previously.
User interface changes
UI will remain the same
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
| Comment | File | Size | Author |
|---|---|---|---|
| #20 | 3043215-20.patch | 11.21 KB | klu |
| #17 | 3043215-nr-bot.txt | 143 bytes | needs-review-queue-bot |
| #6 | 3043215-6.patch | 34.84 KB | bnjmnm |
| #6 | interdiff_3-6.txt | 32.01 KB | bnjmnm |
| #3 | 3043215--3.patch | 17.01 KB | bnjmnm |
Issue fork drupal-3043215
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:
Comments
Comment #2
bnjmnmComment #3
bnjmnmThis significantly reduces the JS part of the content preview toggle functionality. This required adding wrappers to a few elements, which seems like a fine tradeoff for reducing JS.
For the reviewer:
.layout-builder-block__content-preview-showvisibility class was not proper BEM. Figured it was fastest to post as-is and find out what needs changing in the review$layoutBuildervariable with direct calls to$('#layout-builder')to address an issue caught by tests. After dragging blocks to a new position, the$layoutBuilderwould become stale. Referencing a fresh$('#layout-builder')took care of it.Comment #5
bnjmnmComment #6
bnjmnmThe version in #3 attempted to control visibility based only on the presence of a wrapper class. It became apparent this approach would not work after testing with the Search form block. The CSS for the Search form block includes setting several elements to
display: inline. This overrides the css-based visibility rules. While it was tempting to just open a followup for the search block, this would still be a problem for any block that has elements withdisplay:explicitly set. To hide content reliably, using.hide()and.show()in javascript is required. The Search form block was added to tests since it exposed problems that needed to be addressed.This patch does successfully make the preview labels a part of the render array instead of dynamically created/removed via javascript. This approach required additional test coverage to account for structural differences in default layouts vs overrides and the need to explicitly address block titles.
Comment #7
bnjmnmComment #8
tim.plunkettUnassigning and tagging to get some reviews
Comment #10
tim.plunkettNot as much a feature request as a task
Comment #17
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #19
cboyden commentedThe placeholder labels still cause an issue when trying to style the LB interface. Is the approach in this ticket still being considered, or are there other proposed solutions?
Comment #20
klu commentedThanks for your work on this, @bnjmnm! The changes in your patch would be really helpful for us. I’ve taken a stab at re-rolling for 10.3.x based on patch 3 and the interdiff. It appears to work for me and is a significant improvement for doing our styling. I’m attaching the patch that I’m using, but I did not try to update the tests (my apologies; I’m newly coming back to Drupal development).
Comment #21
danielvezaHey @klu, could you please create a merge request from the patch that you've created against the 11.x branch?
There is some documentation here about how to create merge requests for Drupal issues.
Thanks!
Comment #22
cboyden commentedI've created an issue fork from 11.x and ported the changes from patch #20. Still needs updated tests.
Comment #25
cboyden commentedMerged changes from 11.x branch to MR.
Comment #26
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. The merge request has merge conflicts and cannot be merged. 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.