Steps to reproduce:
(using Lightning 1.03, Drupal 8.1.8 with all lightning features enabled)
You can go to Revisions and Revert to the previous revision to restore the previous blocks. But basically it seems that the custom layout/blocks of the page are not being transferred to the new revision that is created.
This is a pretty serious issue for users of the workflow and layout system, but not marking it as Major because not everybody is using this combination of features.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 2790699-12.patch | 5.95 KB | balsama |
| #11 | 2790699-11.patch | 5.91 KB | balsama |
| #10 | 2790699-10.patch | 5.9 KB | balsama |
| #9 | 2790699-9.patch | 849 bytes | balsama |
| #7 | vid-2016-08-29_11-59-43.gif | 1.82 MB | ptsimard |
Comments
Comment #2
ptsimard commentedI must report that I just ran into this exact problem. Now I'm unable to Publish the latest draft. This makes Landing page unusable.
When on this tab the IPE shows and I can edit/save with it
But there is no way on this page to set moderation to publish. So if you can't change it from that page, what do you do? You go to the edit draft page and change the moderation state.
But this does not work, it loses your changes and the whole panelized stuff is gone.
I'm setting this to Major, but really it should beCritical because it makes a cornerstone of Lightning distribution (the concept of Landing pages as nodes) totally unusable.
I will work around them now by building one-off pages via Block layout visibility rules instead for now.
If I'm doing something wrong (with my drupal config) please let me know.
Comment #3
ptsimard commentedComment #4
balsamaInteresting. I couldn't reproduce this with HEAD of Lightning. Trying 1.03 now.
Comment #5
balsamaWe must be missing something in the STR (or I misread). mpotter/ptsimard, can you confirm the steps?
We can add a test for this, but let's see if there isn't a real bug we should be testing and fixing first.
Comment #6
mpotter commentedI tracked down the difference between my test and the one shown in #4.
In my test, when initially creating the landing page, I selected "Single Column" in the Full Content dropdown menu. After adding the custom block and clicking Edit, this field stays at the Single Column setting.
Whereas in the working test in #4, you used the "Current default display" for the Full Content and after adding the custom block and clicking Edit draft, it updated the Full content field to show "Custom Override".
When you initially select a Full Content value other than "Current default display", the "Custom override" is never available as an option when you edit the node.
Comment #7
ptsimard commentedHere I captured the broken workflow using vanilla lightning 1.03 on simplytest.me
I hope this helps. The gif is wide so to see better you might want to open it in its own tab.
Comment #8
balsamaThanks everyone. It looks like the cause of this was over in #2664682: Implement admin UI for editing Panelizer defaults.
TODO:
Comment #9
balsamaHere's a patch that should fix the problem as a workaround until we can get this committed. Setting back to normal since we have a workaround.
Note: this patch is against panelizer, not lightning. So make sure to apply it there and not to lightning.
Comment #10
balsamaPatch for lightning including test attached.
Comment #11
balsamaFixed test assertion.
Comment #12
balsamaRemoved @failing tag from tests which now passes.
Comment #13
balsamaTravis is happy. I'm going to commit this.
Comment #15
balsamaComment #17
balsama