[DEFECT] Layout editor changes making unexpected changes to pre-existing content on the page

[DeanGonzalez]

Problem Statement

layout editor changes and re-orders of rows causes content to shift containers or disappear completely from edit mode.

Steps to Reproduce

Video Screencast:

layout-editing-content-shift.mov

1. Create a new page or copy an existing page on the current evergreen version. Add content in at least three containers and in one container use both the system container and the default container - maybe banner in the top full row, then activity content in a 60/40 row underneath that. Save and Publish.
2. Edit the layout of the page, and add a new row both above and below the bottom row and add the default container again to both of them. Do not wait for the default saving to finish before adding the rows, work quickly as I do in the video.
3. Go back to the content view on the page and see if content either disappears or switches position on the page.

Acceptance Criteria

Regardless of how fast the edits are made on the layout view, the view that is present when clicking back to the content view should be respected and content should stay in the container it was placed in originally. Containers should not shift positions when new rows are added to the layout editor.

dotCMS Version

Latest Evergreen on demo.dotcms.com: 25.12.16-01

Severity

Medium - Some functionality impacted

FreshDesk Support Ticket

https://dotcms.freshdesk.com/a/tickets/34279

[rjvelazco]

Note

The video below shows how to reproduce this issue 100% of the time:

video.mov

[rjvelazco]

Findings

I think this issue could involve both Frontend and Backend, so I’ve outlined my findings below.

Frontend Side

1. The first thing I noticed is that we are not sending the historyUUIDs in the payload when saving the template. (That might be needed)
2. The issue appears when the internet connection is slow (for example, when throttling to 3G or using demo.dotcms.com). If a save is triggered and the user makes another change immediately after, we may be hitting a race condition where a second save is sent before the first one is fully processed by the backend.

Possible fixes:

• When a save is already in progress and the backend hasn’t responded yet, queue or postpone subsequent saves until the first one completes.
• Alternatively, disable the UI while saving (although I don’t think this is the best approach UX-wise).

Backend Side

On the backend, this also looks like a race condition, or possibly the endpoint returning 200 before reindexing has completed.

We may need to support the indexPolicy=WAIT_FOR query parameter on this endpoint:
/api/v1/page/{pageId}/layout

What I’m seeing is:

• When two saves are triggered quickly (or under slow network conditions), the backend returns the same historyUUIDs for both saves.
• When waiting a bit between saves, the backend returns different historyUUIDs, as expected.

Video explaining the backend issue

https://drive.google.com/file/d/1unWJ42fgtcGWAD7l9T_UA99mx0KyP0X6/view?usp=sharing