Copy Post: Editor seems to revert title and content changes when saving

[pauljacobson]

Quick summary

There's a confusing user experience issue when copying posts in the WordPress dashboard. When a user copies a post and modifies the title of the copy, the interface appears to revert to the original title, making it seem like the changes weren't saved. However, the changes are actually being saved to a new draft post with a different post ID. This creates confusion because while the URL shows an updated post ID, the visible title doesn't reflect the changes made, leading users to question whether their modifications were preserved.

Here is a video in which I demonstrate the issue using a test WordPress.com site on a free plan:

20241215.Copy.post.UX.issue-optimized.mp4

Steps to reproduce

1.	Open the WordPress dashboard and navigate to the list of posts.
2.	Select a post you want to copy, and note its current URL slug and post ID.
3.	Click the three dots next to the post, and choose Copy Post.
4.	In the post editor, rename the copied post (e.g., change the title to “Some Other Post Copy”).
5.	Save the draft - Observe that the title in the editor sometimes reverts to the original post’s title.
6.	Exit the editor and navigate to the Drafts list - Note that a new draft post is created with an updated post ID, but the title may not reflect the changes you made.
7.	Repeat the process by copying the newly created draft post - Observe similar behavior where the copied post has an updated post ID, but the title and slug behavior remain inconsistent.

What you expected to happen

When copying a post, the copied post with changes that are made to the copy should be preserved in the editor window that the user sees.

What actually happened

When a user copies a post and modifies the title of the copy, the interface appears to revert to the original title, making it seem like the changes weren't saved. However, the changes are actually being saved to a new draft post with a different post ID.

Impact

Most (> 50%)

Available workarounds?

No but the platform is still usable

If the above answer is "Yes...", outline the workaround.

No response

Platform (Simple and/or Atomic)

Simple

Logs or notes

This was reported in 9177618-zen and reproduced in a test site on a free plan.

This issue persists irrespective of browser used. Our customer experienced this issue using Brave, Microsoft Edge and Firefox. I reproduced the issue using Microsoft Edge on macOS 15.2

[github-actions]

Support References

This comment is automatically generated. Please do not edit it.

• 9177618-zen
• 9176633-zen
• https://wordpress.com/forums/topic/bug-copied-posts-cannot-be-edited-saved
• 9196413-zen
• 9177509-zen
• 9196053-zen
• 9204899-zen
• 9206635-zen
• 9206492-zen
• 9235851-zen
• 9240262-zen
• 9242094-zen
• 9243440-zen
• 9287475-zen
• 9300637-zen

[jordesign]

I have a user reporting something similar - Even when they make changes to the post titles in the editor - they revert.
9176633-zd-a8c

[jordesign]

Plenty of examples in this Forum thread too:
https://wordpress.com/forums/topic/bug-copied-posts-cannot-be-edited-saved/?view=all#post-4066835

And it appears it effects the content of the post/page as well. Not only the title.

[supernovia]

📌 REPRODUCTION RESULTS

• Tested on Simple – Replicated
• Tested on Atomic – Replicated
• Replicable outside of Dotcom – Yes, but only after updating Gutenberg

📌 ACTIONS

• Triaged
• Pinged Jetpack; we may need to transfer repos as well: p1734447112673469-slack-CDLH4C1UZ

[jeherve]

@youknowriad This seems to have been caused by WordPress/gutenberg#62304, but I don't quite understand the concept of "editor rendering mode" and how it could impact the Copy Post feature. Do you think you could take a look?

For reference, we populate the editor with data from the original post in this class:

jetpack/projects/plugins/jetpack/modules/copy-post.php

Line 40 in fdfff59

add_action( 'wp_insert_post', array( $this, 'update_post_data' ), 10, 3 );

This still works well, and folks can still edit the original content just like before, but upon saving, the new data gets saved properly but the post editor reverts to the original state in which it was open, with the original data, even though in the db we now have updated data.

Do you have any idea about what in that PR could have caused this?

Thank you!

[supernovia]

Noting I bumped into a case of this that I would not have identified as this bug had I not been aware of it:
9196413-zd-a8c

[aisajib]

Also noted here: 9177509-zd-a8c

The user shared these steps:

1. I copy a post (which I have to do to save a lot of time)
2. Try to edit the title (it keeps reverting to the original unedited title)
3. I'm unable to view a lot of images in the editor view and can't view white text if the image background (cover) is missing, for example. 

I'm not sure about the third point above, so I'm asking for more details.

[Mamaduka]

@jeherve, do you have a minimal code example to reproduce the bug? I'm working on some follow-ups for #62304 and can also look into this.

[jeherve]

@Mamaduka You could upload this little plugin to a site using Gutenberg, and then go to the Posts screen and hit "Copy" in the actions links when hovering a published post. In the new post editor that opens, make a few changes to the copied post (change the title for example) and then hit "Save draft". You'll see your changes disappear, even though they were properly saved in the db. Get back to the Posts list, and you'll see the new draft saved properly.

copy-post-test.zip

Let me know if that helps!

[aisajib]

Another report here: 9196053-zd-a8c
The user would like to be notified if it's fixed.

[TeniCola]

Another report in 9204899-zen -- the user would like an update, but we did find a temporary workaround:

After the first revert behavior, refresh the post in the editor (click "Reload" without saving changes, if the brower prompts you) -- the changes should reappear. Then, continue to make new changes without using the “restore a backup” prompt, and the revert behavior should stop moving forward.

There is an internal video of this same behavior and workaround -- p1734902819761479-slack-C02FMH4G8

[CodeAllNightNDay]

Another case here:
9206635-zen

[youknowriad]

Thanks for the ping @jeherve and sorry for the delay (AFK).

So the PR itself indeed introduced the bug but it was IMO a secondary change that shouldn't have been done in that PR. So I'm pushing a fix here. I would appreciate some testing. WordPress/gutenberg#68273

[radtechgh]

user copies post, renames and saves draft. Title reverts. 9206492-zen

[galakhyati]

Another case here: 9235851-zd-a8c

[supernovia]

9240262-zd-a8c

[jp-imagines]

Also reported here: 9242094-zd-a8c (from duplicate bug report).

[cat-og]

Another report here: 9243440-zd-a8c
Simple site, premium plan.

Another workaround that worked for me:

• Save draft; it will appear to revert the content. Close the post/page, you'll see a prompt that you have unsaved changes. You can confirm that you'd like to leave without saving the changes, then reopen the post or page from the Draft list, the page will open with those initial changes correctly saved (you do have to dismiss the notice about unsaved changes, because clicking the option to restore will revert to the initial copy). From here, the page or post can be managed as expected.

[jeherve]

Warning

This should be fixed once the next version of the Gutenberg plugin (20.0) is released and then updated on WordPress.com. The release is currently planned for Thursday, January 9th.
-- https://wordpress.slack.com/archives/C02QB2JS7/p1734981362775539

[filipanoscampos]

Another case here 9287475-zd-a8c

[SiR-DanieL]

another report in 9300637-zd-a8c