Auto Drafts can overwrite one another

[dd32]

Steps to reproduce:

1. Open "New Post", Open "New Post" in a background tab (Time between actions: doesnt matter, Only the order of the below steps matters)
2. Enter a Title/Content into the First window, and publish the post, Wait for the "Post Published!" confirmation
3. Switch to the 2nd tab, Enter Title/Content into 2nd instance, and Publish the post, Wait for Confirmation
4. Check the post listing, You'll only find the 2nd post.
5. Check the revision for that post, You'll see the 2nd post overwrote the 1st post.

I'm able to reproduce it every time.. As long as 2 new post windows are opened at the same time (before either being published) publishing either form will overwrite one another.

2 solutions:

• NEW autodraft created for EVERY instance of the post-new screen, rather than just re-using the last unused autodraft
• Upon first save of a Autodraft:
  • Has Autodraft already been saved by another process? Give it a New ID, and update the form to recognise that

[dd32]

The reason I'm finding this, Is that for a old-style physical-paper Newspaper, the current process is to open a tab, paste in article 1, hit publish, switch to next tab, add article, publish, etc.

The reasoning behind that is the host they're using has a ~15second post publish time, I'm not sure why, but thats a separate issue.

[Denis-de-Bernardy]

3rd solution is to use uuids.

[dd32]

Yes, You could use a UUID. But WordPress uses Post ID's as a unique identifier, not a UUID. end of story.

[Denis-de-Bernardy]

I wish you were right. But more bugs related to this same issue will show up eventually. Such as the yet to be reported rollover/collision bug, and its potential security implications. Or those introduced by multiple-server environments.

uuids were designed to work around limitations and issues introduced by sequential numerical ids. And for our purpose it's the only long-term, rock solid solution. Nuff' said.

[nacin]

Replying to dd32:

• NEW autodraft created for EVERY instance of the post-new screen, rather than just re-using the last unused autodraft

That's what we do now, though. Check get_default_post_to_edit(), $create_in_db -- we clean up really old auto-drafts (7 days), then generate a fresh one.

I think this is a plugin you have, to be honest.

[dd32]

I think this is a plugin you have, to be honest.

The site in question had no post-related plugins, At first i thought it was the dog-slow MySQL backend (Think shared hoster who should have a farm of MySQL jamming everything onto the previous sysadmin's desktop)

However, I did just reproduce it on trunk on my local dev machine.

The post_ID field in the HTML form is the same in both tabs, resulting in the 2nd tab overwriting the first post.

[dd32]

..This appears to be a Browser bug, Specifically, an Opera bug.

If you load 2 pages at the same time only one HTTP request is performed, so the same content is delivered to 2 separate tabs, resulting in this exact scenario.

You can achieve something similar by opening the edit post window for an existing post twice and modifying the content differently in each..