Page MenuHomePhabricator

Preview on first edit shows a wrong warning in REL1_6
Closed, ResolvedPublic


Author: rick.denatale

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.

Version: 1.6.x
Severity: minor



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:19 PM
bzimport set Reference to bz6759.
bzimport added a subscriber: Unknown Object (MLST).

rmarks wrote:

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.

jsousa wrote:

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.

rick.denatale wrote:

In response to Jason, on 1.6.7 turning off preview on first edit the problem
DOES NOT occur.

tderouin wrote:

There seems to be a few things happening here, and it has to do with

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)


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.

rotemliss wrote:

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.

robchur wrote:

Issue was fixed in a stable release version; closing.