Thanks for your report.
- 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.