Behavior seems a bit hard to predict, as far as what's going to go in the header and what in the browser window etc. Pulling it back for further testing and discussion.
Let's avoid making up our own syntax that nobody will know or think to try...
Lucene, Google, Yahoo!, and Windows Live search all understand "red OR lion" but see nothing special in "?red ?lion". If we're going to add it, let's make the OR thing work. :)
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.
Fatal error: Call to a member function insertOn() on a non-object in /Library/WebServer/Documents/trunk/includes/specials/SpecialImport.php on line 305
Now such titles are skipped. You can probably force import of the page by forcing the target namespace...
Better long-term solution might include title renormalization, adapation of remote namespace names (eg Wikipedia -> Project), etc.
* Changed Article::updateRestrictions()'s $cascade parameter to a reference which is set to false if cascading protection isn't allowed
* Used this in ApiProtect
* Expand help message for &cascade a bit
It was noted that the existing code could fail for unusual article path settings including a suffix if only the 'articleUrl' was available. Pretty corner case, and probably breaks a lot of other things, but who knows. :)
Went ahead and refactored this a bit to handle the case and feel a little cleaner to me...
Dropped the private getDescBaseUrl() method since this seems a little easier to handle directly in getDescriptionUrl() now.
extract() is pretty much the devil and shouldn't ever be used for safe, legible code because it makes it much more difficult to analyse the code -- you have to run around trying to track down the source of local variables and there's generally a lot of pain.
Removing the FIXME comment isn't a substitute for fixing it. ;)
NOTE: Wikimedia's secure.php needs to be updated to use the new variable. It might be possible to retire the fixupSquidUrl() hack once this is done, though I'm not sure if anything else relies on it.
Also simplify URL construction: old code used to call Title::getInternalURL() to build the URLs and then undo most of the work with preg_replace().
(TODO: Maybe consider introducing new global $wgIRCLineURLPrefix to optionally override the $wgInternalServer.$wgScript prefix?)
* Append the reason with a colon rather than wrapping in parens
* Rearrange the file-upload portion of the Special:Import form a bit
* Using one message for the comment field since it'll be identical in both parts of the form
More tweaks:
* Add labels for the transwiki import portion too
* Make the forms proper for RTL wikis
