 | This page is currently inactive and is retained for historical reference. |
Note: From September 2005 on, due to some minor bugs in the MediaWiki code, article histories may seem to contain anomalies after performing some of the procedures listed below. They are not actual database errors, the underlying data is correct; they are just problems with the information displayed. See #Lost history bug for information about these seeming anomalies, and how to deal with them.
After a history merge, the following peculiarity may be observed: after a successful undeletion, article histories may seem either:
- to be missing the recently restored versions, or
- to show the complete original history after a deletion/partial-restoration cycle, including versions which are actually still deleted.
These errors persist even if the browser's "Refresh" button is clicked. These do not seem to be actual database errors, and the underlying data is correct; they are just problems with the information displayed. Note that there seems to be no consistency as to which (if either) of these bugs will appear—expect to see either, or neither.
For some users, however, the bug can be cleared with a combination of purging and bypassing browser cache.
Work around
To see the correct, current, history of the article, select a different history length, e.g., "last 20" or "last 100", instead of the default 50. (Note that this trick only works once; if you do another restore, and the history is messed up again, you will need to select a different, previously unused length, to see the correct, current, history.)
Also, making an edit on the page just moved will force the correct history to be shown, so if you have to perform an edit on the target page for some other reasons (e.g., to restore the most recent version, step 4.3 above), this will make the correct history appear. Alternatively, if you don't want to leave things so that a naive user will be confused, make a dummy edit to the page, which will update the history.
Previous versions of the Wikimedia software displayed other, similar issues:
- The success of the undeletion may be announced, but its results not be observable for a while, until the slave servers catch up to the master.
- The merged history may have all the versions of the two formerly separate articles, but without the most recent being shown at the top of the history list, and without the most recently edited version being delivered by the server, until a further edit is made to the article.
- It sometimes happens that viewing the history in step 3.1 shows the history of the just deleted page, not the history of the page just moved.
These bugs do not seem to be happening any more, but it's worth keeping an eye out for them.
|
| This page is currently inactive and is retained for historical reference. |
Note: From September 2005 on, due to some minor bugs in the MediaWiki code, article histories may seem to contain anomalies after performing some of the procedures listed below. They are not actual database errors, the underlying data is correct; they are just problems with the information displayed. See #Lost history bug for information about these seeming anomalies, and how to deal with them.
After a history merge, the following peculiarity may be observed: after a successful undeletion, article histories may seem either:
- to be missing the recently restored versions, or
- to show the complete original history after a deletion/partial-restoration cycle, including versions which are actually still deleted.
These errors persist even if the browser's "Refresh" button is clicked. These do not seem to be actual database errors, and the underlying data is correct; they are just problems with the information displayed. Note that there seems to be no consistency as to which (if either) of these bugs will appear—expect to see either, or neither.
For some users, however, the bug can be cleared with a combination of purging and bypassing browser cache.
Work around
To see the correct, current, history of the article, select a different history length, e.g., "last 20" or "last 100", instead of the default 50. (Note that this trick only works once; if you do another restore, and the history is messed up again, you will need to select a different, previously unused length, to see the correct, current, history.)
Also, making an edit on the page just moved will force the correct history to be shown, so if you have to perform an edit on the target page for some other reasons (e.g., to restore the most recent version, step 4.3 above), this will make the correct history appear. Alternatively, if you don't want to leave things so that a naive user will be confused, make a dummy edit to the page, which will update the history.
Previous versions of the Wikimedia software displayed other, similar issues:
- The success of the undeletion may be announced, but its results not be observable for a while, until the slave servers catch up to the master.
- The merged history may have all the versions of the two formerly separate articles, but without the most recent being shown at the top of the history list, and without the most recently edited version being delivered by the server, until a further edit is made to the article.
- It sometimes happens that viewing the history in step 3.1 shows the history of the just deleted page, not the history of the page just moved.
These bugs do not seem to be happening any more, but it's worth keeping an eye out for them.