Last modified: 2010-05-15 15:56:52 UTC
At least on 1.6.7 and 1.6.8, if a user is logged on, and has "preview on first edit" turned on in his user preferences, attempting to edit a page will fail showing a message that session data has been lost. Turning the preference off allows editing. I discovered the workaround for this via a google search, in a posting to mediawiki-l Brion asked another user who was having a problem with losing session data whether he had the preference turned on. Bug 6477 might be a duplicate of this but it seem to have more preconditions.
For my 1.6.8 installation, I have never had the preference "preview on first edit" enabled. The error message I see when editing a page that has not been created before is Sorry! We could not process your edit due to a loss of session data. Please try again. If it still doesn't work, try logging out and logging back in.
In 1.6.7 this problem will occur with the "preview on first edit" preference disabled because whether it is enabled or not, mediawiki tries to show you a preview. I'm not sure if it's exactly the same in 1.6.8. Either way, it seems to be resolved in 1.7.1. Hope that helps.
In response to Jason, on 1.6.7 turning off preview on first edit the problem DOES NOT occur.
There seems to be a few things happening here, and it has to do with EditPage:getPreviewText. EditPage:tokenOk is never called in this situation, so tokenOk is false when getPreviewText is called. Perhaps this should be changed from if ($this->mTokenOk) to if ( $this->tokenOk($wgRequest) ) And there's never a wpEditToken passed through the request in this situation, since no form is posted, only the edit page is displayed. What should happen isn't clear, perhaps a special case should be added to getPreviewText to detect a POST, and if there's no post, there's no reason to check the token. if (!$wgRequest->wasPosted() || $this->tokenOk($wgRequest) ) This seems to fix the problem on our site.
It was already fixed for REL1_7 (which means 1.7.0 and 1.7.1) and trunk, apparently in r14633. Naturally, I can reproduce this bug in REL1_6 (1.6.8), but neither in REL1_7 (1.7.1) nor in trunk. I'm not sure if r14633 should be backported to REL1_6. If you don't upgrade, you can just edit the page, regardless this warning - it doesn't prevent editing.
Issue was fixed in a stable release version; closing.
