Two editors changing one CMS record: how to prevent overwritten changes

Resolve CMS editing conflicts safely by checking the record version at save time and stopping changes based on an outdated copy. The editor must also see what a colleague changed and retain a way to recover their own work. A notification that someone else has opened the record does not, by itself, prevent overwriting.

Imagine a content team updating a service description in one afternoon. One editor corrects the pricing conditions; another adds to the heading in the same record. Both work carefully, but the second has an older copy open. After their save, the pricing conditions revert to the earlier wording. The interface reports a successful save, so the error is noticed only after publication.

The problem lies in the saving contract between browser and server. It can be tested with a reproducible scenario rather than speculation about editors' attentiveness. This article helps prepare that test and acceptance requirements for improving an existing or custom-built CMS.

Where a colleague's correction disappears

When a record is opened, the browser receives its content. While the person writes, a newer version may be saved on the server. If the browser later sends the entire original record together with its changes, the server must distinguish a current edit from restoration of an old copy.

Displaying an update date is insufficient. The date may be informational while saving still accepts any submitted content. Ask the developer a specific question: does the server refuse writes based on an outdated version even when the user interface omits the check?

Separate tabs opened by one person can also conflict. An import, integration or automatic data update may be another writer. If protection works only between visible CMS users, it may disappear through another saving route. Test every route that modifies the record concerned.

First agree on the protected unit too. It may be an entire content page, one language version or a defined data block. An overly broad unit creates unnecessary conflicts. An overly narrow one allows incompatible fields to be combined, such as a price and the conditions under which it takes effect.

Checking the version at save time

HTTP offers conditional saving through If-Match. The client sends the previously received ETag, and the server checks whether it matches the current representation. If the condition fails, a typical response is 412 Precondition Failed. The mechanism and strong-comparison requirement are described in MDN's If-Match documentation.

A CMS can also use its own version field if it provides equivalent safe saving logic. The outcome matters: there must be no gap between checking and changing that lets another request overwrite the record unnoticed. The developer chooses the specific database or application mechanism to suit the existing system.

An ETag identifies a representation version; it is not a person's name or access permission. Authentication and authorisation checks remain separate requirements. The version marker must also reflect what you save. If it does not represent changes to protected fields, the comparison will not prevent that conflict. See MDN's ETag explanation.

Do not replace checking a specific version with a general condition that the record exists. For example, If-Match: * does not prove the editor worked from current content. A browser-only check cannot guarantee server-side saving safety either. The HTTP semantics specification defines evaluation of conditions before the method's action.

A warning, a lock or collaborative editing?

A warning about another editor helps coordination. It helps someone decide whether to start now. However, a colleague's session may end without a clean close or their connection may fail. A presence indicator must not become the only data protection.

Exclusive locking can suit a short, consequential edit that only one person should make at a time. Define when the lock expires, how an active session renews it and who may take over stuck work. After losing a lock, the old session must not continue saving as though it were still the sole editor.

Optimistic locking lets people work in parallel and checks for conflicts on saving. It is useful when conflicts are not constant and the interface helps resolve them. If the team writes simultaneously in one text every day, collaborative editing may be justified. Implementing that is a broader task than a simple warning window.

Choose according to the work. Do editors usually change independent fields? Do they need to work on the same sentence in real time? How dangerous is an incorrectly combined price and description? There is no need for the most complex mode if an understandable version check and conflict-resolution flow provide safety.

What to show people when a conflict occurs

The message should say that work was not saved, why, and what can happen next. For example: “This record has changed since you opened it. Your text has been retained as a local working copy. Compare changes before saving again.” Promise a local copy only when it has genuinely been created safely.

The original, current and editor's own versions help comparison. Showing only the latter two may make it difficult to identify which difference belongs to the editor and which to a colleague. Highlight specific fields rather than asking the person to reread the whole page without guidance.

Independent edits in different fields can sometimes be merged automatically. But field names alone do not determine relationships. A product name, image and specification may describe one set. Define safe merging rules from the meaning of the content, retaining a human decision in ambiguous cases.

Treat an “Overwrite everything” button with particular caution. If such an action is needed at all, show which current version it will replace and retain recoverable history. A new server edit may occur during comparison too. Saving the merged version requires a fresh current-version check.

A two-editor scenario matrix

The following is an acceptance-test example, not a description of built-in features in a particular CMS. Use a test record and two independent sessions so the test itself does not change published company information.

For every test, record session order, starting version, submitted action and server result. A screenshot of a warning helps, but does not prove nothing was overwritten in the database. Check the actual saved content and history after refreshing too.

Autosave must not hide a failure

Editors need to distinguish local typing, sending, server-confirmed saving and a conflict. If the same tick represents every situation, they cannot know whether it is safe to close the tab. A short status message is often more valuable than a subtle animation.

Autosave requests can overlap. A late response to an older request must not overwrite the interface status of newer work. Artificially delay responses during development testing and check the reverse arrival order too. This may reveal a fault invisible on a fast office connection.

After a timeout, do not automatically assume saving did not occur. The server may have completed the action even though the browser received no response. Establish the current version and inspect the saved result first. Blindly resending an old request is not a safe recovery strategy.

Recovering unsaved text

A local working copy must be bound to the specific record, user and starting server version. When restoring work, the interface can offer comparison rather than immediately submitting it to the server. Define deletion and retention policy for the copy too, particularly on shared devices or when handling sensitive information.

A leaving-page warning alone cannot be relied upon. MDN notes that beforeunload is not reliably fired in every situation, including certain mobile-use sequences. See limitations of the browser's leaving-page event. Preservation of work must be designed throughout the editing process.

Test recovery under the team's actual working conditions: connection loss, session expiry and reopening the browser. “Work restored” must not merely mean an old server copy was loaded. The person needs to see which of their changes were recovered and which remain unsaved.

What to require when accepting a CMS improvement

Agree on observable outcomes: an outdated version cannot silently overwrite a newer one, the conflict message preserves work, and recovery does not skip the current-version check. Tests must also cover delayed responses and integration changes. The team needs brief instructions for choosing and merging revisions.

Is version history enough?

History helps recover content already lost, provided the relevant version was retained. Conflict controls prevent a silent error at save time. The mechanisms serve different purposes, and history does not remove the need to tell the person clearly about a conflict.

Does this problem require a new CMS?

Not always. Inspect the existing saving route, data versions and interface capabilities first. A local improvement may suffice. If the system cannot protect all writing routes consistently, assess broader changes against specific risks.

If edits disappear within the team, prepare one reproducible scenario and its expected result. It can be used to assess the scope of custom CMS development or improvements to an existing system. Content-field structure is explained separately in the CMS content model, and software releases in staging environments and rollback planning.