* And some adjustments to documentation (sentence ended with "use the wikis", adjusted to "use the wikis' content language")
[svnblameutil:] r97136,r88447,r86368,r81597,r72134,r2969
Sep 16 20:07:28 10.0.2.193 apache2[28441]: PHP Warning: socket_sendto() [<a href='function.socket-sendto'>function.socket-sendto</a>]: unable to write to socket [90]: Message too long in /home/wikipedia/common/php-1.17-test/includes/GlobalFunctions.php on line 464
Sep 16 20:07:29 10.0.2.193 apache2[26511]: PHP Warning: socket_sendto() [<a href='function.socket-sendto'>function.socket-sendto</a>]: unable to write to socket [90]: Message too long in /home/wikipedia/common/php-1.17-test/includes/GlobalFunctions.php on line 464
$wgDeferredUpdateList[] = new HTMLCacheUpdate( $title, "sometable" );
I kept b/c with $wgDeferredUpdateList for now, but seeing as only 3 exts in svn use it (FileSearch, FlaggedRevs and WikiScripts), I'd like to deprecate it pretty soon :)
Document $limit parameter
Pass $limit parameter through if $limit && php > 5.4.0
Else false back to the default version, which sets the same parameters
* Introduce a boolean parameter to wfUrlProtocols() which, if set to false, will cause '//' to be dropped from the returned regex so it doesn't match protocol-relative URLs
* Introduce wfUrlProtocolsWithoutProtRel() as a wrapper for wfUrlProtocols( false ). The latter should not be used directly because the former is much clearer
* Use this new function in Parser::doMagicLinks() to fix the original bug. Also use it in ApiFormatBase::formatHTML() and CodeCommentLinker::link(), which probably had similar bugs
* Fix a bug in rNNNNN where URLs like '/wiki/Foo' weren't expanded completely if $wgServer was protocol-relative. This caused bug NNNNN.
* Add an optional second parameter to wfExpandUrl(), which takes one the PROT_* constants. This allows the caller to determine which protocol should be used if the given URL is protocol-relative, or the given URL is domain-relative but $wgServer is protocol-relative. The options are PROT_HTTP (use http), PROT_HTTPS (use https), PROT_RELATIVE (keep the URL as protocol-relative), and PROT_CURRENT (use http if the current request is http, or https if the current request is https; this is the default).
* Factor the protocol/port detection part of WebRequest::detectServer() out into detectProtocolAndStdPort(), and add detectProtocol() as a wrapper. The latter is used by wfExpandUrl() in PROT_CURRENT mode.
* Rewrite the test suite to test all possible combinations of $wgServer, $defaultProto, $url and HTTP/HTTPS mode. This means the test suite now has 120 test cases rather than 4.
The only two usages left since r91590 are php version checks for index/load/api.php, and $wgAPIEnabled check in api.php. Consolidate all of the "bailing for invalid version" into PHPVersionError.php. Leaving $wgAPIEnabled as the only user was silly, so just echo and die like wfDie() would've done
Suppressing all warning output from unserialize() in ExifBitmap::formatMetadata will hide actual errors; we're now checking explicitly for the bad-metadata and no-metadata markers so the case this was added for should not happen.
Also:
* Introduce classes mw-float-end, mw-float-start so we don't have to use inline css depending on wfUILang()/$wgLang (see HistoryPage and SpecialFileDuplicateSearch)
* Add direction mark to protection log
* Remove specialpageattributes as it is obsoleted by this commit (also fixes bug 28572)
* Add two direction marks in wfSpecialList, which makes ltr links on rtl wiki (and vice versa) display nicely as well (only on those special pages however)
* Revert r91340 partially: use mw-content-ltr/rtl class anyway in shared.css. Both ways have their [dis]advantages...
* Set the direction of input fields by default to the content language direction (except buttons etc.) in shared.css
The only problem is that all the indexes have to be set, thus "key[]=value" won't get parsed correctly and array( 'key' => array( 'value' ) ) will transform to "key[0]=value".
Related bug 28928 and bug 22989.
Exposing it in the default LocalSettings.php as I did in r90105 was not a good solution, really the only way to avoid breakage is to just get the protocol from $wgServer whenever you need the protocol.
Fixed $wgCookieSecure so that it will be enabled automatically if the user sets $wgServer to an https URL in LocalSettings.php. Added documentation for other cookie-related globals.
Grep indicates that $wgProto is not used by any extensions. $wgCookieSecure is used, hence the need for the Setup.php patch.
* One less entry point to worry about
* Completely obsolete by load.php and api.php
* Left $wgDebugRawPage in place, also affects load.php requests (docs already reflect)
* Affects dumpHTML (probably broken anyway, has anyone RL-ified this?), and two abandoned/obsolete extensions
