Last modified: 2013-06-18 13:27:19 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 12433 - better $wgReadOnlyFile lock file naming
better $wgReadOnlyFile lock file naming
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Documentation (Other open bugs)
1.16.x
All All
: Lowest trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-28 00:21 UTC by Dan Jacobson
Modified: 2013-06-18 13:27 UTC (History)
4 users (show)

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


Attachments

Description Dan Jacobson 2007-12-28 00:21:54 UTC
In DefaultSettings.php, please add this to the comments:
   /***
    * If this lock file exists, the wiki will be forced into read-only mode.


                              ^and has a size greater than zero!!!


    * Its contents will be shown to users as part of the read-only warning
    * message.
    */
   $wgReadOnlyFile         = false; /// defaults to "{$wgUploadDirectory}/lock_yBgMBwiR";

(Also note using the filesystem this way precludes multiple wikis using
a read-only filesystem, etc...)

Also kindly add comments at
   $wgReadOnly             = null;

E.g.,
/*
  To lock the database, one can also use e.g.,
  $wgReadOnly="Cleaning up a mess; try again real soon." Don't just
  use just use $wgReadOnly==true, which will lock it but look bad:
  "1". Nor should "" be used, as that will... */

Also comment the neighboring
$wgDebugComments        = false;
$wgLogQueries           = false;
and other variables you forgot to comment in DefaultSettings.php, please.

By the way, shouldn't files like these give an error when executed from the
command line?
$ php SpecialLockdb.php; echo $?
0
$ php Title.php ;echo $?
0
Should I open a separate bug? Thanks.
Comment 1 Dan Jacobson 2007-12-28 00:24:38 UTC
s/==/=/ above. Also test what happens with ""...
Comment 2 Aaron Schulz 2008-12-29 18:54:45 UTC
Please make a patch file
Comment 3 Dan Jacobson 2008-12-29 19:25:26 UTC
I am only 1/4 sure of what to say, so I pass this on to others.
Comment 4 Aaron Schulz 2009-01-02 11:24:53 UTC
Added size blurb in 45313. Other stuff seems fine as of 1.14.
Comment 5 Brion Vibber 2009-01-06 22:07:59 UTC
Existence of the lock file really ought to trigger read-only mode, even if it's empty...
Comment 6 Chad H. 2009-03-12 16:17:01 UTC
(In reply to comment #5)
> Existence of the lock file really ought to trigger read-only mode, even if it's
> empty...
> 

This doesn't seem to be the case. We're checking the boolean return from file_get_contents(). If the file is empty (''), then we'd be returning false.
Comment 7 Dan Jacobson 2009-05-20 14:02:34 UTC
Well you had better change it soon if you are going to change it at
all, as the indeed very bad way has set up camp as a documented
standard, "growing more established by each day that passes."

Or else click the Close Bug button and surrender to a life of ugliness.
Comment 8 Dan Jacobson 2009-05-26 12:50:32 UTC
One [low priority] day if somebody wants to work on this:
it seems instead of saying in Setup.php:
>if( $wgReadOnlyFile === false ) $wgReadOnlyFile = "{$wgUploadDirectory}/lock_yBgMBwiR";
and in DefaultSettings.php:
>/***
> * If this lock file exists (size > 0), the wiki will be forced into read-only mode.
> * Its contents will be shown to users as part of the read-only warning
> * message.
> */
>$wgReadOnlyFile         = false; ///< defaults to "{$wgUploadDirectory}/lock_yBgMBwiR";
it would be better to say just once in DefaultSettings.php:
>$wgReadOnlyFile = $wgUploadDirectory . '/' . wfWikiID() . 'lock_wiki';
and also say there (and implement) that an empty file will also lock the wiki.
*lock_wiki is easier to remember than lock_yBgMBwiR.
*using wfWikiID() means we are now
http://www.mediawiki.org/wiki/Manual:Wiki_family safe, no longer
stepping on each other's toes. It's the same idea as used in
maintenance/generateSitemap.php.
Comment 9 Alexandre Emsenhuber [IAlex] 2009-08-24 15:40:49 UTC
You can't call wfWikiID() from DefaultSettings.php since this function is in GlobalFunctions.php and that file is not loaded when DefaultSettings.php is executed.
Comment 10 Chad H. 2011-11-11 00:50:20 UTC
Not really sure what else to do here...

$wgReadOnly and $wgReadOnlyFile have comments about their contents being used as the message, and $wgReadOnlyFile has a comment about it needing to be > 0 for it to work. $wgDebugComments has comments now and $wgLogQueries.

I'm not going to leave this open for "other variables [we] forgot to comment in DefaultSettings.php," and the comment about executing files from the command line has nothing to do with this.

Closing FIXED.

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


Navigation
Links