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.
First Last Prev Next    This bug is not in your last search results.
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 tree / graph
 
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
Add an attachment (proposed patch, testcase, etc.)

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.
First Last Prev Next    This bug is not in your last search results.

Navigation
Links