Page MenuHomePhabricator

better $wgReadOnlyFile lock file naming
Closed, ResolvedPublic

Description

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.


Version: 1.16.x
Severity: trivial

Details

Reference
bz12433

Event Timeline

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

s/==/=/ above. Also test what happens with ""...

I am only 1/4 sure of what to say, so I pass this on to others.

Added size blurb in 45313. Other stuff seems fine as of 1.14.

Existence of the lock file really ought to trigger read-only mode, even if it's empty...

(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.

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.

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.

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.

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.