Not only 3 years ago, as well now with the new release.
The issue you found as 3 years old, is another.
That is solved usually by updating WordPress, Toolset and the Browsers.
However this new issue is the same "ghost" (we cannot really replicate this until now) and I have seen it solved by:
- ensuring the server does support Toolset:
https://toolset.com/toolset-requirements/
==> Specially mbstring and eval
- ensuring server does not block AJAX
- sometimes, there was a field's corruption, which when resolved, solved this issue to
- usually the very same site presenting the issue, if duplicated to another server one by one, did not present the issue (pointing to server issues)
- the very last case I know of, was due to Parent and Child Layouts being used (Child Layout Cell).
In this last case, we need to interact with the database, find the parent layout ID’s and then call them one by one in the WP Admin with this URL:
hidden link
(where you replace 1788 with the ID of the parent layout)
Then remove the Child Cell.
This should bring back the List of Layouts, and then you can proceed re-adding a Child Cell.
The issue is usually caused by an Infinite Loop in layouts assigned to each other recursively.
So - we have many options to start with.
On a live site this makes no sense, unless you want to eventually backup and restore it.
I suggest, if you can, to deploy a staging instance and try the (to you possible) steps above.
Where you need help, let me know and I'll help you directly.
Now, there is something very important as well to check:
The tabs, of the new Layouts screen order the Unassigned Layouts in the 4th tab from the left.
So when you load the Screen you show me, you will NOT see the Layout you created for the login form, because the one is not assigned to any content.
Similar, for other Layouts.
You need to be sure, that the published layouts you "miss", are not in the other tabs.
Only then, then steps above make sense, of course.