Last modified: 2008-03-13 01:09:50 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 T13114, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 11114 - Undefined property and missing lock reason if wiki is r/o
Undefined property and missing lock reason if wiki is r/o
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.11.x
All All
: Normal normal (vote)
: ---
Assigned To: Brion Vibber
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-29 17:10 UTC by Raimond Spekking
Modified: 2008-03-13 01:09 UTC (History)
2 users (show)

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


Attachments

Description Raimond Spekking 2007-08-29 17:10:40 UTC
During the latest breakdown of the WMF servers I found a bug:

1. Trying to _edit_ in r/o mode results in an error message w/o lock reason: 

   The administrator who locked it offered this explanation: $1


Trying to _delete_ a page results in an error message with lock reason:

   The administrator who locked it offered this explanation: Emergency maintenance, should be back in a few minutes


2. Investigating this bug in my local wiki (based on r25292) I found another bug:

<b>Notice</b>:  Undefined property:  EditPage::$edit in <b>F:\xampp\htdocs\wikitest\includes\EditPage.php</b> on line <b>335</b><br />

Adding 
  			$this->edit      = false;

near line 550 of EditPage.php fixes the notice but not the bug mentioned in 1.
Comment 1 Brion Vibber 2007-08-29 18:11:29 UTC
Regression caused by the new permissions error reporting system.
For read-only case, the read-only text didn't get passed back with the message from Title::getUserPermissionsErrors().
The text is either originally set in $wgReadOnly or gets loaded into it from $wgReadOnlyFile during wfReadOnly(), so pulling that it now gets passed back as expected.
Other functions using $wgOut->readOnlyPage() would have still got the original, still working, behavior.


Fixed in r25293

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


Navigation
Links