1 - first when I edit the regions multiple times (saving, editing, changing their position and size, etc) at some point the system shows a message saying that the layout was not found. After that the layout goes into draft mode and I can not edit it anymore. I get the message “layout not found”
2 - When I export a layout and try to import it again, I get the message “Internal server error”. I tried several layouts but I could not import any of them
Had the same problem (the second problem). Exported my layouts in 1.8.12 and tried to import all of them in 2.0.1, but constantly got ‘internal server error’ messages. Imported some layouts I exported in januari, not a single problem.
So for now I’m stuck with the ‘old’ layouts I exported in januari.
We’ve seen this happen once so far, and we’re actively trying to understand what the process is to replicate it so that it can be addressed. If you have a method to trigger this reliably then please let us know as it will speed up getting that addressed. You can recover that layout by getting the layout ID, and running the following SQL. update `layout` set publishedstatusid=1 where layoutid=xxxx limit 1; where xxxx is the layout ID to recover. Running SQL on Docker-based installs is covered here:
It’s important you only run that SQL in that scenario. Running it in other scenarios will cause data loss, so be very sure that you run it only against that one specific layout, and the issue is exactly as outlined above.
Is a known issue already logged. It will be fixed in 2.0.2 release due out next week. It is already patched for Cloud Customers.
Hi Alex,
The method to trigger this, in our test, is simple resizing a clock widget multiple times. At some point this will broke the layout.
Hope this help.
Its correct. I’m resizing the region .
First we resize the region and them publish. The checking out is made in designer page.
About 3 times doing this the problem appears.
I’ve just tried that multiple times and can’t recreate it.
Please can you run through the report fault wizard on your CMS. When it asks you to recreate the issue, open a new tab, and then go through your process until you get the problem to occur.
Then return to the original tab and finish up the report fault process.
Every time you click Publish, the layout will get a new layout ID number, so if you try and reload the page part way through the publish process, or click back after clicking publish, then what you’re seeing is absolutely expected.
In the video, the user publishes a layout change, and then clicks back. Doing so takes the browser to the layout designer for the version of the layout that was just deleted by the publish operation, and correctly the system says that the layout does not exist.
Similarly, the user clicks refresh in the browser immediately after clicking publish. The system has at that point published the new layout, and is in the process of redirecting the user to the new version of the layout when it is interrupted, and so it correctly says that the layout ID that was just deleted by the publish operation is no longer available.
In both cases, going back to the layout list will allow the layout to load correctly.
Thanks for clearing things up about Layout ID changes.
I do not know why but this error, although it shows that the layout was not found, is not the same as it occurred to me before. I will continue to use version 2.0.1 with more intensity and if I find something I will come back here.