The $wgWikimediaJenkinsCI hack was moved into a "callback" function
in the hooks file.
Bug: T87955
Change-Id: Ibdb4397231ba9b0301a3b5872867cee5fa3906f3
Set the appropriate TTL when using #time or #timel. Needs I412febf3 and
I3f5a80aa in core to function.
Change-Id: I2e8b8918482b0b3f4adf154af795b6bb53b99497
Add mw.ext.ParserFunctions.expr, allowing #expr to be used without needing
to use frame:callParserFunction.
Change-Id: I64c78fafad7da503b141efb36da64c3e3d8501a5
Jenkins bot unit tests without setting $wgPFEnableStringFunctions = true;
This triggers all the parser tests for string functions to be skipped
Bug: 61410
Change-Id: I69636d656af851beeed6fd5353e4a01c1ca5c608
The PHP modulo operator ('%') casts its operands to ints, causing
floating point values 0 < $right < 1 to raise a divide-by-zero error.
Explicitly casting both operands to float and using fnmod() resolves the
issue. This change also tidies up the check for zero values and adds
tests.
Change-Id: I32c9eca6552e4fec248eb4fa6419faa39c10df3b
* Disable {{#convert}} function by default. This means that this change will not be live by default, so the fixme doesn't block WMF deployment, although it probably should still block the tarball.
* Documentation and type hinting
* Fix minor errors noted by Tim in CR.
* When using HipHop, is_callable() returns false for objects which have only a __call() method instead of the requested one.
* Work around this by removing the ParserFunctions_HookStub hack.
* To retain the behavior that the code of ParserFunctions_body.php is only loaded when needed, turn it into a static class.
* Defer the registering of the ParserClearState hook until a relevant function is called.
* Use autoloader for ConvertParser, and ExprParser which the code was cloned from
* Fix PHP 5.1 compatibility, while there's no requirement for us to keep it, there's also no need to break it unnecessarily, and it's a really trivial fix in this case.
* Tidy whitespace
* Use ConvertDimension::getLocalisedName() for the dimensionmismatch error, as intended
[[Template:Convert]] on enwiki is a behemoth of a construction that just about manages to do this sort of conversion, taking {{convert|5|mi|km}} and outputting "5 miles (8 km)", etc. To port this to another wiki requires copying over three and a half thousand subtemplates. The additional load produced by including numerous copies of this template is measurable on large pages on enwiki, and it eats voraciously into the template limits.
This revision introduces {{#convert: 5 mi | km }}, outputting "8 km" or thereabouts. See http://www.mediawiki.org/wiki/User:Happy-melon/Convert for more details, or look at the examples in the parser tests.
In a very rough profile, comparing 50 calls to {{convert}} verses the same 50 calls to the wrapper template shown at the link above, the parser function implementation reduces page load time by 72%, preprocessor node count by 83%, post-expand include size by 86% and template argument size by 97%. More detailed profiling would probably reveal places where extra caching could improve performance further.
The primary reason for putting it in ParserFunctions instead of its own extension is availability: PFs are already available across the cluster, and it's accepted as an essential extension for any wiki wishing to emulate or mirror WMF content. One less separate extension installed on the cluster is one less extension which has to be matched by reusers.
It's still missing a lot of units, which I ran out of patience to copy from {{convert}}; I thought I'd get some feedback on the infrastructure first.
* 1.11 and below aren't supported anymore, so we don't need to be maintaining back-compat code for it anymore. This is why we branch extensions
* The vast majority of these were using $wgParser. This defeats the purpose of ParserFirstCallInit...allowing you to use parsers other than $wgParser. All these extensions now work in any instance of the Parser, not just $wgParser
* Defer loading the bulk of the code until a parser function is actually called. Necessary due to the recent large increase in code size.
* Fixed the total disregard for parser state and object-oriented data flow in ExtParserFunctions::loadRegex().
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.
Uses DateTime class in PHP 5.2+ to support dates outside the 1970-2038 range. On earlier versions will still fall back to strtotime with the old 32-bit Unix timestamp range limitations.
Patch by rememberthedot -- https://bugzilla.wikimedia.org/attachment.cgi?id=5416
Added a couple quick parser test cases to confirm the new behavior. However I am seeing some annoyances with how input time zones are handled, so we'll want to clean that up at some point. :)
