* Added a new config variable, $wgSessionHandler to control what value the save_handler is set to
* Setting to null allows you to disable setting it entirely, which was the primary complaint of the two bugs, but it also allows you to set it to whatever you'd like
diff and cur links are now created using raw HTML instead of link(),
which they didn't really need anyway. I didn't see any other obvious
candidates for conversion to raw HTML, since other things tend to need
fancy classes and have lots of other logic. It's possible link() could
be made faster, too.
While having the parser functions in the message strings work is a laudable goal, the problem here is that it'll *also* execute parser functions it finds in the replaced parameter strings, which may include, say, comment plaintext talking *about* parser functions.
A better fix for this is probably to expand the message placeholders when the parameters are passed in to the parser functions.
* Take out some hard coded pipe characters. Replace by message or Language::pipeList
* Take out a hard coded comma list SpecialIpblocklist.php. Replace by Language::commaList
XXX: The code seems to more or less work, but it obviously needs more testing, regarding both stability and memory usage. In particular, I have not tested file uploads yet -- there may be consistency issues there.
Doesn't seem like a proper fix here... At best, this'll be dumping random crap to some random file unless the user has a local copy of the /dev/null device file, which seems.... wrong. :)
For anything generating command lines, it probably won't make any difference (assuming exec() is enabled at all!) since open_basedir won't be searching through the command line (I think).
Assuming the core use case actually happens (open_basedir is set, but proc_open() is available to run tidy), a more correct fix is probably to go ahead and read in stderr and toss the results, or maybe better pass it through to PHP's stderr FD instead of opening /dev/null ourselves. Tidy has a -q option which should suppress random "hi i'm tidy version XYZ" if it's currently present.
Uses $dir in extension files, and assumes that it remains unchanged in require_once( 'maintenance/commandLine.inc' ).
In fact, it is likely that '$dir' will be set when setting up command-line, as some extensions will use the same var.
Recommended fix: Use $CentralAuth_dir, $EmailPage_dir, etc.
NOTE: the old code used to ignore the umask by explicitly forcing the permissions with chmod(). If this is desired behavior, it can be achieved by temporarily setting the umask to 0, as in:
$oldmask = umask( 0 );
$rv = mkdir( $dir, $mode, true );
umask( $oldmask );
return $rv;
However, I can't see why we'd want to do this. In the worst case, users with excessively tight umasks can find themselves with unusable directories, but the proper solution to that is to fix the umask rather than to
ignore it. In the best case, we've just plugged a security hole the user didn't realize they had (because they assumed their umask would Just Work).
Since we're only checking for exact strings, an exact match is just fine and it stops the whinging. (Saw no such problem on 5.2.6.)
Example whinge:
Notice: Object of class Language could not be converted to int in /Library/WebServer/Documents/trunk/includes/GlobalFunctions.php on line 742
Previously we only passed on if we were interface or content, but if we're rendering for some third alternative it didn't get used.
Note that parse and parseinline are probably still wrong.... some better model may be required here.
Also it may be wrong in the case of fallbacks ... if you get an English message, is it right to use the Czech magic word parsing?
Hmm.
Might back it out if there's a better way. :)
* Two callers of wfArrayMerge() were bugs, both assuming strange and complex behaviour in wfArrayMerge() which has never been present or documented.
* Introduced wfMergeErrorArrays() to remove duplicates from merged error arrays, e.g. from getUserPermissionsErrors().
* Rewrote the remaining callers of wfArrayMerge() to use array plus. It makes the code clearer, assuming the reader knows more about basic PHP operators than GlobalFunctions.php. Considering the two bugs discussed above, this seems like a fair assumption. If you don't know PHP, you shouldn't be writing MediaWiki code.
* Improved blob_tracking.sql docs
* Allow testCompression.php to run until happy instead of a specified revision count
* Added docs for some debugging globals in DefaultSettings.php
In experimental script recompressTracked.php:
* Fixed crippling bugs, seems to work now. Needs more testing.
* Improved usage documentation
* Use DiffHistoryBlob by default if available
* Set a process-specific log prefix, added more debugging output
* Optimised commit() slightly by merging the locking read queries using IN()
* Fixed finishIncompleteMoves() so doPage() acts on only that page. Also run finishIncompleteMoves() for orphan lists.
