Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
From #2905922-61: Implementation issue for Layout Builder:
- Does a layout in progress go into a tempstore like Views? Seems like the kind of thing where it would really suck to lose your work when leaving the page. I couldn't tell whether it did or not when playing with it.
- On that note, would be good to have a message like "You have unsaved changes" like Views does. Otherwise I can get lost in the page and not know if I actually changed something or not.
- IANAD (I am not a designer) but it seems like it would be good to have visual feedback on when a layout is saved or not.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#35 | 2919795-tempstore-35-interdiff.txt | 2.92 KB | tim.plunkett |
#35 | 2919795-tempstore-35.patch | 11.22 KB | tim.plunkett |
#35 | 2919795-tempstore-35-x30.patch | 13.38 KB | tim.plunkett |
| |||
#34 | x30-2919795-34.patch | 17.5 KB | tedbow |
| |||
#34 | interdiff-32-34.txt | 951 bytes | tedbow |
Comments
Comment #3
tim.plunkettComment #5
tim.plunkettComment #6
dead_armComment #7
dead_armDoes a layout in progress go into a tempstore like Views?
Yes it does, verified by testing using the following steps:
Views uses both a message of "You have unsaved changes.", and a state change of adding an asterisk on the display button that is modified and not saved to indicate unsaved configuration changes.
Applying that same idea to the layout builder using the message, and adding an asterisk to the title would like this:
Comment #8
tim.plunkettThis does the yellow block part.
It has two classes for the default styling (
'messages', 'messages--warning'
) and one for additional CSS needs ('layout-builder--changed'
).Also had to expand LayoutTempstoreRepository to add a
has()
method, sinceget()
will always return a viable object and cannot be used to check for existence.Comment #9
dead_armAdding some CSS to adjust spacing.
Comment #10
dead_armAdds rtl CSS for the message.
Comment #11
dead_armAdds the inline /* LTR */ comment for the initial CSS change. The 8px value applied for left and right margin alignment styling mimics styling that Seven theme applies to the messages class. The 30px margin bottom value is adopted from the margin bottom of .block-help.
Comment #12
tedbowGreat improvement!
This will affect all messages on the page not just layout builder. Maybe add
.layout-builder--changed
. I think the only thing we target is the#layout-builder
which I know we are not supposed to use. Could we put a class on the same element as that id?This will be more important after our ancestors commit #77245: Provide a common API for displaying JavaScript messages as there might other messages on other parts of the page we don't want to affect.
Why can't we do this
This seemed to work
Comment #13
tim.plunkett12.2 is a great idea. And we don't even need to manually add it to the markup, it will be duplicated.
And now by using the default styling (instead of copying from Views UI) we don't need custom styling.
Comment #14
tedbowIf we don't add the markup you don't get the message until you reload the page or come back to it because the layout builder is loaded with an ajax replace which doesn't show messages.
If we have the mark up I don't see it duplicated. We need test for this message because right now it doesn't display after you add a block unless you reload the page.
Comment #15
dead_armComment #16
tim.plunkettNW for the tests
Comment #17
tim.plunkettWorking on this. Also this is a stable blocker.
Comment #18
tim.plunkettNot sure how best to test this until #2924201: Resolve random failure in LayoutBuilderTest so that it can be added to HEAD is resolved. Maybe a one-off test is justified.
Either way, here's the fix to allow seeing the message during an AJAX flow without duplicate messages during a regular page load.
Comment #19
tim.plunkettHere's a test. Since it's in the wrong namespace but really useful, I repurposed
\Drupal\Tests\layout_builder\Functional\LayoutBuilderTest::assertTextAppearsOnce()
as\Drupal\Tests\WebAssert::pageTextContainsOnce()
, to match the existing\Behat\Mink\WebAssert::pageTextContains()
The FAIL patch is equivalent to the interdiff.
Adding credit for @tedbow for the above review and also the pointer to assertTextAppearsOnce()
Comment #21
jibranThis part of the UI always fascinates me. :D The patch looks ready to me. Screenshots can be seen in #9.
Comment #23
webchickThe patch does what it says on the tin. :) (Well, the yellow message anyway, which I think is sufficient... we don't "asterisk" the title of e.g. nodes or other places, so it would look out of place here.) Thanks for the screenshots and steps to reproduce in #9. SUPER helpful. Test coverage appears to be intact.
Committed and pushed to 8.7.x. Thanks!
Comment #26
tim.plunkettForgot to add @xjm as the entire IS is based on her original feedback.
Comment #27
alexpottReverting this because unfortunately this caused random fails in Drupal\Tests\layout_builder\FunctionalJavascript\LayoutBuilderUiTest
See https://www.drupal.org/pift-ci-job/1086096 and https://www.drupal.org/pift-ci-job/1086188
Comment #29
tedbowThis where it fails. We already do
assertWaitOnAjaxRequest()
by guess is somehow the off-canvas is still on the page and it is in the way of the "Save layout" link.Adding a wait for the link to be gone.
no_transitions_css
module to avoid these types of problem.but also fix that module because it was actually attaching the
settings_tray_test_css/drupal.css_fix
library. Just a copy and paste error.Comment #31
tedbowOk this is the same random failure problem I was running into in #2957425: Allow the inline creation of non-reusable Custom Blocks in the layout builder
I found this before it was committed and actually working on this random problem here #2977515: [ignore] Test Package manager core merge because the issue was already super long.
For some reason clicking "Save Layout" seem to have no effect.
I made a solution in
\Drupal\Tests\layout_builder\FunctionalJavascript\InlineBlockTestBase::assertSaveLayout()
with a @todo that we should really redo these tests in nightwatch #2984161: Convert Layout Builder Javascript tests to NightWatchHere is that same fix.
Lets see if it works.
Comment #32
tedbowOk I don't think we actually need
waitForNoElement()
.Also if we are going to use
assertSaveLayout()
here which should only have a instance of this method so makingLayoutBuilderTestBase
Comment #34
tedbowCan remove this
Forgot to remove this call.
Also forgot to test locally, whoops
Comment #35
tim.plunkettMy hesitation with the above approach is that there is nothing special about saving layouts here. It just happens to be the action we perform after the long-running AJAX request of adding the section and waiting for the rebuilt UI.
The flow of that modification is not essential here, Cancel and Save should work the same.
So here's a patch that sidesteps the random failure by moving the modification to a dedicated (and safer method).
It also clarifies the test a bit better, to show what we actually care about testing, and which part are just necessary set-up.
Here's a (hopefully) committable patch as well as a x30 run version.
Interdiff is against #19.
Comment #36
tedbowThis look like a better solution to be. RTBC. Assuming will pass tests since x30 patch passed.
Comment #38
webchickOk, hopefully second time's a charm ;)
Committed and pushed to 8.7.x. Thanks!
Comment #40
webchickSorry; backported to 8.6.x as well.