This is an artifact created by npm in certain modules. These modules
may contain PHP e.g. grunt-phpdocumentor
Change-Id: Ie46bceb5acbe6141d1e0dc4d3397d04f41d01485
This introduces https://github.com/wmde/Assert as a dependency,
as discussed in the RFC T91071.
This change uses assertions to check some parameters in some places,
to showcase the main intended use case for assertions in MediaWiki.
Bug: T91071
Change-Id: I93ac39b7c146f10532e37b51d973b59b9c424b2f
This drops support for the custom utf8 normal PHP extension in favor
of the intl extension.
Bug: T90825
Change-Id: Ifbaeb2ef684217cf6187ccc4fb4d303f89608300
This patch adds a metric data service object to the IContextSource interface,
with full support for StatsD meters, gauges, counters and timing metrics, via
the liuggio/statsd-php-client, which this patch also introduces.
Usage example:
$stats = $context->getStats();
$stats->increment( 'resourceloader.cache.hits' );
$stats->timing( 'resourceloader.cache.rtt', $rtt );
The metrics are flushed to a StatsD server, which may be specified via the
'StatsdServer' configuration key. If no such configuration key exists, the
metrics are discarded.
The StatsD client supplants MediaWiki's StatCounter class. wfIncrStats()
will continue to work, but it will delegate to the StatsD data object.
Change-Id: Ie10db1c154d225971398e189737de7c560bf0f90
lint uses jakub-onderka/php-parallel-lint to check the syntax of the provided
PHP files or directories.
phpcs uses the MediaWiki codesniffer standard to check the provided files or
directories.
test runs both lint and phpcs together. phpunit is not included at this time
because our phpunit tests require a database to be set up and are very very
slow.
Example usage:
composer lint . # Lint all files
composer phpcs includes/FooBar.php # Check code style of one file
composer test extensions/FooBar # Lint and check an extension
Change-Id: I3c7ac7a02668776de6400ac268f37e7e6b35a3c6
Using * will use the latest compatible version, which could potentially
introduce breaking changes. ~4.5 is equivalent to >=4.5,<5.0
Change-Id: I65bf0998cc028707f607ce7adaf45e27b1e6bca1
According to <https://spdx.org/licenses/>, "GPL-2.0" means "GNU General
Public License v2.0 only", not "GNU General Public License v2.0 or later",
which has the identifier "GPL-2.0+".
Also made the same change in the documentation for $wgExtensionCredits.
Change-Id: If25c15d03a71d7c50c9c85a04c2a589a3d978ad0
Per front-end standards group and architecture cabal
See corresponding change for vendor repo: change Id86b118c
Change-Id: I281acc49c1959bc01d0c1580089fe6896992ba19
Require Composer merge plugin to allow easier local Composer dependency
management without composer.json edit conflicts. The configuration
provided will merge Composer configuration directives found in
a `composer.local.json` config file into those specified by MediaWiki's
composer.json file at Composer runtime.
Bug: T67188
Change-Id: I66a19d0154191e536aab37a5e183e4505bf3e9be
Introduces wfLoadExtension()/wfLoadSkin() which should be used in
LocalSettings.php rather than require-ing a PHP entry point.
Extensions and skins would add "extension.json" or "skin.json" files
in their root, which contains all the information typically
present in PHP entry point files (classes to autoload, special pages,
API modules, etc.) A full schema can be found at
docs/extension.schema.json, and a script to validate these to the
schema is provided. An additional script is provided to convert
typical PHP entry point files into their JSON equivalents.
The basic flow of loading an extension goes like:
* Get the ExtensionRegistry singleton instance
* ExtensionRegistry takes a filename, reads the file or tries
to get the parsed JSON from APC if possible.
* The JSON is run through a Processor instance,
which registers things with the appropriate
global settings.
* The output of the processor is cached in APC if possible.
* The extension/skin is marked as loaded in the
ExtensionRegistry and a callback function is executed
if one was specified.
For ideal performance, a batch loading method is also provided:
* The absolute path name to the JSON file is queued
in the ExtensionRegistry instance.
* When loadFromQueue() is called, it constructs a hash
unique to the members of the current queue, and sees
if the queue has been cached in APC. If not, it processes
each file individually, and combines the result of each
Processor into one giant array, which is cached in APC.
* The giant array then sets various global settings,
defines constants, and calls callbacks.
To invalidate the cached processed info, by default the mtime
of each JSON file is checked. However that can be slow if you
have a large number of extensions, so you can set $wgExtensionInfoMTime
to the mtime of one file, and `touch` it whenever you update
your extensions.
Change-Id: I7074b65d07c5c7d4e3f1fb0755d74a0b07ed4596
Quoting Tim from 240fd31cfa6b in mediawiki/vendor (prepend-autoloader):
Composer's autoloader is slow, taking about 63µs per class, whereas
MediaWiki's is fast, taking about 7µs per class. This adds up to an
overhead of about 13% of CPU time on short requests such as API calls.
On those same short requests, MediaWiki's autoloader finds most of the
classes. So it makes sense to run it first, before the two Composer
autoloaders. So change the config so that composer passes
$prepend=false to spl_autoload_register().
optimize-autoloader is also just a good idea in general.
Change-Id: I383c72a85eda415da92e8a9253e83b4ed591768b
Adds leafo/lessphp 0.5.0 as a dependency, and removes the current
copy of lessphp.
Depends on 7b2af65827 in mediawiki/vendor.
Bug: T1337
Change-Id: Ib5ab4c872d5236258df97d49f4ba72a20758a2e9
The new cdb library is pulled in via composer. Since the
library uses namespaces, a backwards-compatability layer
is provided for the old class names:
* CdbReader
* CdbWriter
* CdbException
The PHP/DBA-specific classes should never have been used directly.
Depends on I98302bdf1 in mediawiki/vendor
Change-Id: I39549ac8540b262cf91f7d1830d36327afb3033d
