Make WordPress Core

Opened 13 years ago

Closed 13 years ago

#14407 closed defect (bug) (invalid)

Auto Drafts can overwrite one another

Reported by: dd32's profile dd32 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Editor Keywords:
Focuses: Cc:

Description (last modified by 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

Change History (8)

#1 @dd32
13 years ago

  • Description modified (diff)

#2 @dd32
13 years ago

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.

#3 @Denis-de-Bernardy
13 years ago

3rd solution is to use uuids.

#4 @dd32
13 years ago

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

#5 @Denis-de-Bernardy
13 years ago

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.

#6 in reply to: ↑ description @nacin
13 years ago

  • Keywords reporter-feedback added; needs-patch dev-feedback removed

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.

#7 @dd32
13 years ago

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.

#8 @dd32
13 years ago

  • Keywords reporter-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed
  • Version 3.0 deleted

..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..

Note: See TracTickets for help on using tickets.