Last modified: 2010-05-15 15:33:59 UTC
I did a section edit on [[EMD E-unit]] on en-Wikipedia, on the section 'Trucks'. When I clicked on save, the entire article was replaced by just the section I had edited. I have reverted the change, but it's in the history.
I can confirm this bug on the local installation. Only occurs when "open preview on first edit" is on. As a temporary workaround, disable this option in the php-code.
Works for me.
*** Bug 1288 has been marked as a duplicate of this bug. ***
*** Bug 1806 has been marked as a duplicate of this bug. ***
I seemed to have also had a case of this. I had clicked the edit link on the "Strong monochrome" section of the page. I had previewed my change. After I saved it. I noticed the section had replaced the entire page. (I reverted it.) I hadn't been using "open preview on first edit" option, but had previewed the change. The history entry for the edit is at http://en.wikipedia.org/w/index.php?title=Wikipedia:Template_standardisation&diff=12810897&oldid=12810669
*** Bug 325 has been marked as a duplicate of this bug. ***
We have just had a couple more reports of this on Wikipedia EN. I believe this bug is caused as follows: Someone 1) Uses edit section. 2) Makes changes to the article and uses show preview. 3) The preview looks alright, but the page is slow to load. 4) They hit save page before the page is fully loaded. As the section editting token "wpSection" is one of the very last things to load on the edit page (well after the save button), I believe that during slow page loads, people are occasionally managing to save the page before the section token has been included in the form. By default this leads the server to interpret the data as an attempt to save the entire page. Bugginess ensues. Solution: Move all the hidden fields on the edit form to somewhere before the save button is rendered. -DF
A save will fail in that case because the hidden fields at the end are missing.
Brion, Your expectations are reasonable but not entirely correct. I've done some testing by saving local copies of edit pages and removing the hidden fields. The following events can occur. 1) Edit a section. 2) Lose the hidden fields. Presumably in practice this could occur by hitting save or preview before the page is completely loaded, but I just removed them from a local copy of the page. 3) If the hidden fields are "lost" in this way the next load will be a preview screen and the hidden values are set to "" for wpStarttime, wpSection, and wpEdittime. Remarkably the lost EditToken was actually restored to the same value it had before I removed it (is this stored in the session?) So now I have a preview screen with a valid edit token but no knowledge of what version or section I started editting. If I save again, the software will either a) give an edit conflict, if someone other than myself was the last edit, b) save the edit and replace the entire page with the contents of the section I was editting. The b scenario only occurs if I was also the last person to save the page. I assume this is an example of edit conflicts with self being cancelled, so that even though the software doesn't know what version I started editting from, it doesn't care and saves anyway. Regardless, it really shouldn't be possible to reach an edit screen where the section and version information have been thrown away. I would again suggest that the hidden fields should be part of the edit page HTML before save/preiew/etc buttons are loaded. -DF
So, you've got a broken page with a bunch of missing text, and you decide to save it?
It is clear from this example, http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical% 29#Editing_a_page_and_the_Insert_Box_causing_saving_errors that the guy was hitting save before the page had completed loading, and hence submitting an incomplete form.
In that case the edit would fail, and show a preview. He would then have to continue with a second page save. Is this what he's doing?
remember there have been periods when wikipedia has repeatedly gone to preview when trying to save so many of us just hit the save button if we see an unwanted preview. we aren't that likely to notice if the word section in brackets dissapears from the preview page.
*** Bug 3919 has been marked as a duplicate of this bug. ***
In my case, the problem occurred because I had closed the browser (Firefox 2) after I hit preview, the re-opened it. The page had obviously lost some information. Perhaps it would help if you put the section that is currently being edited as a GET field? Don't know if it would work for the other scenarios that lead to this bug, though.
(In reply to comment #8) > We have just had a couple more reports of this on Wikipedia EN. > > I believe this bug is caused as follows: Someone 1) Uses edit section. 2) > Makes changes to the article and uses show preview. 3) The preview looks > alright, but the page is slow to load. 4) They hit save page before the page is > fully loaded. > > As the section editting token "wpSection" is one of the very last things to load > on the edit page (well after the save button), I believe that during slow page > loads, people are occasionally managing to save the page before the section > token has been included in the form. By default this leads the server to > interpret the data as an attempt to save the entire page. Bugginess ensues. > > Solution: Move all the hidden fields on the edit form to somewhere before the > save button is rendered. > > -DF wpSection now loads before the textarea
Hidden fields checked in r42037. The edit conflict "skip-if-last-editor" bug was fixed in r42034.
I've reverted r42037 in r42569. I don't think this check has any real benefit, since in the form the fields appear before the text box there's basically no way to submit the form without them. However the more stringent checks are causing disruption to bot edit tools, which annoys people, so I'm backing it out for the time being. The moved fields should already have fixed the base issue, so leaving bug resolved.
Reopening - seems to still be a problem with the live version (r43634) see http://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AFeatured_picture_candidates&diff=256999377&oldid=256996105 . What I remember doing was waiting a long time, show preview, waited another long time then saved.
(In reply to comment #20) > Reopening - seems to still be a problem with the live version (r43634) see > http://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AFeatured_picture_candidates&diff=256999377&oldid=256996105 > . What I remember doing was waiting a long time, show preview, waited another > long time then saved. > What were you trying to do?
Fix in r45809
