Last modified: 2008-10-04 13:44:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T17647, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15647 - edit with basetimestamp fails if the page has been deleted and undeleted since the last edit
edit with basetimestamp fails if the page has been deleted and undeleted sinc...
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
All All
: Normal enhancement (vote)
: ---
Assigned To: Roan Kattouw
Depends on:
  Show dependency treegraph
Reported: 2008-09-19 11:51 UTC by Brad Jorsch
Modified: 2008-10-04 13:44 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

This patch (against r41332) works for me in a local MediaWiki installation (2.37 KB, patch)
2008-09-28 02:29 UTC, Brad Jorsch

Description Brad Jorsch 2008-09-19 11:51:37 UTC
This is regarding r40356, as installed on

If the page has been deleted and then undeleted since the last edit, an attempted edit using the API will fail with an error message "The page has been deleted since you fetched its timestamp". This can happen if an admin is trying to remove vandalism from the public page history: he deletes the page, and then undeletes all but the troublesome revision.

For example, [[en:Talk:Cambrian explosion]] currently shows that it was most recently edited on September 13,[1] while the logs for that page show it was deleted and undeleted on September 16.[2] The timestamp picked up from the rvprop query is of course 20080913031053 from the edit.

If the "touched" date from prop=info would work to prevent edit conflicts, a fix could be to just change the documentation of basetimestamp to suggest using that instead of rvprop's timestamp (unless "touched" isn't really updated by undeletion?). Otherwise, intoken would probably have to return the appropriate basetimestamp explicitly in addition to the edit token.

Comment 1 Roan Kattouw 2008-09-21 19:22:47 UTC
Weird... the API just wraps around EditPage, so there should be no difference between the UI and the API in this matter. I'll investigate.
Comment 2 Brad Jorsch 2008-09-22 02:25:57 UTC
I see in r41137 ApiEditPage.php you set both wpEdittime and wpStarttime to the basetimestamp value, while loading the edit form on sets wpStarttime to the timestamp of when the edit form is first loaded instead. Does the API need to have a starttime value passed in addition to basetimestamp? If so, could it also return the current timestamp in the responses (at least those with an edit token) so we don't have to worry about clock sync issues?
Comment 3 Brad Jorsch 2008-09-28 02:29:36 UTC
Created attachment 5368 [details]
This patch (against r41332) works for me in a local MediaWiki installation

This patch (against r41332) works for me in a local MediaWiki installation. It adds a "starttimestamp" option to the edit action, defaulting to the current behavior if the parameter is not provided. It also adds a "starttimestamp" value to the prop=info output when a token is returned to avoid any clock skew issues.
Comment 4 Roan Kattouw 2008-10-04 13:44:40 UTC
Patch applied in r41649, credit given in r41650

Note You need to log in before you can comment on or make changes to this bug.