2010-10-19 18:25:42 +00:00
|
|
|
<?php
|
|
|
|
|
/**
|
2015-10-28 03:24:40 +00:00
|
|
|
* ResourceLoader module based on local JavaScript/CSS files.
|
2012-04-30 07:16:10 +00:00
|
|
|
*
|
2010-10-19 18:25:42 +00:00
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
|
* http://www.gnu.org/copyleft/gpl.html
|
|
|
|
|
*
|
|
|
|
|
* @file
|
|
|
|
|
* @author Trevor Parscal
|
|
|
|
|
* @author Roan Kattouw
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/**
|
2010-10-20 00:22:25 +00:00
|
|
|
* ResourceLoader module based on local JavaScript/CSS files.
|
2019-06-19 22:44:39 +00:00
|
|
|
*
|
|
|
|
|
* The following public methods can query the database:
|
|
|
|
|
*
|
|
|
|
|
* - getDefinitionSummary / … / ResourceLoaderModule::getFileDependencies.
|
|
|
|
|
* - getVersionHash / getDefinitionSummary / … / ResourceLoaderModule::getFileDependencies.
|
|
|
|
|
* - getStyles / ResourceLoaderModule::saveFileDependencies.
|
2010-10-19 18:25:42 +00:00
|
|
|
*/
|
|
|
|
|
class ResourceLoaderFileModule extends ResourceLoaderModule {
|
2010-10-19 23:02:15 +00:00
|
|
|
|
2014-04-20 21:33:05 +00:00
|
|
|
/** @var string Local base path, see __construct() */
|
2010-10-27 22:22:10 +00:00
|
|
|
protected $localBasePath = '';
|
2014-05-10 08:39:37 +00:00
|
|
|
|
2014-04-20 21:33:05 +00:00
|
|
|
/** @var string Remote base path, see __construct() */
|
2010-10-27 22:22:10 +00:00
|
|
|
protected $remoteBasePath = '';
|
2014-05-10 08:39:37 +00:00
|
|
|
|
2014-10-10 00:07:14 +00:00
|
|
|
/** @var array Saves a list of the templates named by the modules. */
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $templates = [];
|
2014-10-10 00:07:14 +00:00
|
|
|
|
2010-10-20 20:43:30 +00:00
|
|
|
/**
|
2014-04-20 21:33:05 +00:00
|
|
|
* @var array List of paths to JavaScript files to always include
|
2012-02-01 17:05:15 +00:00
|
|
|
* @par Usage:
|
|
|
|
|
* @code
|
2016-08-13 01:10:40 +00:00
|
|
|
* [ [file-path], [file-path], ... ]
|
2012-02-01 17:05:15 +00:00
|
|
|
* @endcode
|
2010-10-20 20:43:30 +00:00
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $scripts = [];
|
2014-05-10 08:39:37 +00:00
|
|
|
|
2010-10-20 20:43:30 +00:00
|
|
|
/**
|
2014-04-20 21:33:05 +00:00
|
|
|
* @var array List of JavaScript files to include when using a specific language
|
2012-02-01 17:05:15 +00:00
|
|
|
* @par Usage:
|
|
|
|
|
* @code
|
2016-08-13 01:10:40 +00:00
|
|
|
* [ [language-code] => [ [file-path], [file-path], ... ], ... ]
|
2012-02-01 17:05:15 +00:00
|
|
|
* @endcode
|
2010-10-20 20:43:30 +00:00
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $languageScripts = [];
|
2014-05-10 08:39:37 +00:00
|
|
|
|
2010-10-20 20:43:30 +00:00
|
|
|
/**
|
2014-04-20 21:33:05 +00:00
|
|
|
* @var array List of JavaScript files to include when using a specific skin
|
2012-02-01 17:05:15 +00:00
|
|
|
* @par Usage:
|
|
|
|
|
* @code
|
2016-08-13 01:10:40 +00:00
|
|
|
* [ [skin-name] => [ [file-path], [file-path], ... ], ... ]
|
2012-02-01 17:05:15 +00:00
|
|
|
* @endcode
|
2010-10-20 20:43:30 +00:00
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $skinScripts = [];
|
2014-05-10 08:39:37 +00:00
|
|
|
|
2010-10-20 20:43:30 +00:00
|
|
|
/**
|
2014-04-20 21:33:05 +00:00
|
|
|
* @var array List of paths to JavaScript files to include in debug mode
|
2012-02-01 17:05:15 +00:00
|
|
|
* @par Usage:
|
|
|
|
|
* @code
|
2016-08-13 01:10:40 +00:00
|
|
|
* [ [skin-name] => [ [file-path], [file-path], ... ], ... ]
|
2012-02-01 17:05:15 +00:00
|
|
|
* @endcode
|
2010-10-20 20:43:30 +00:00
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $debugScripts = [];
|
2014-05-10 08:39:37 +00:00
|
|
|
|
2010-10-20 20:43:30 +00:00
|
|
|
/**
|
2014-04-20 21:33:05 +00:00
|
|
|
* @var array List of paths to CSS files to always include
|
2012-02-01 17:05:15 +00:00
|
|
|
* @par Usage:
|
|
|
|
|
* @code
|
2016-08-13 01:10:40 +00:00
|
|
|
* [ [file-path], [file-path], ... ]
|
2012-02-01 17:05:15 +00:00
|
|
|
* @endcode
|
2010-10-20 20:43:30 +00:00
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $styles = [];
|
2014-05-10 08:39:37 +00:00
|
|
|
|
2010-10-20 20:43:30 +00:00
|
|
|
/**
|
2014-04-20 21:33:05 +00:00
|
|
|
* @var array List of paths to CSS files to include when using specific skins
|
2012-02-01 17:05:15 +00:00
|
|
|
* @par Usage:
|
|
|
|
|
* @code
|
2016-08-13 01:10:40 +00:00
|
|
|
* [ [file-path], [file-path], ... ]
|
2012-02-01 17:05:15 +00:00
|
|
|
* @endcode
|
2010-10-20 20:43:30 +00:00
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $skinStyles = [];
|
2014-05-10 08:39:37 +00:00
|
|
|
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
/**
|
|
|
|
|
* @var array List of packaged files to make available through require()
|
|
|
|
|
* @par Usage:
|
|
|
|
|
* @code
|
|
|
|
|
* [ [file-path], [file-path], ... ]
|
|
|
|
|
* @endcode
|
|
|
|
|
*/
|
|
|
|
|
protected $packageFiles = null;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @var array Expanded versions of $packageFiles, lazy-computed by expandPackageFiles();
|
|
|
|
|
* keyed by context hash
|
|
|
|
|
*/
|
|
|
|
|
private $expandedPackageFiles = [];
|
|
|
|
|
|
2010-10-20 20:43:30 +00:00
|
|
|
/**
|
2014-04-20 21:33:05 +00:00
|
|
|
* @var array List of modules this module depends on
|
2012-02-01 17:05:15 +00:00
|
|
|
* @par Usage:
|
|
|
|
|
* @code
|
2016-08-13 01:10:40 +00:00
|
|
|
* [ [file-path], [file-path], ... ]
|
2012-02-01 17:05:15 +00:00
|
|
|
* @endcode
|
2010-10-20 20:43:30 +00:00
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $dependencies = [];
|
2014-05-10 08:39:37 +00:00
|
|
|
|
2014-04-30 21:06:51 +00:00
|
|
|
/**
|
|
|
|
|
* @var string File name containing the body of the skip function
|
|
|
|
|
*/
|
|
|
|
|
protected $skipFunction = null;
|
|
|
|
|
|
2010-10-20 20:43:30 +00:00
|
|
|
/**
|
2014-04-20 21:33:05 +00:00
|
|
|
* @var array List of message keys used by this module
|
2012-02-01 17:05:15 +00:00
|
|
|
* @par Usage:
|
|
|
|
|
* @code
|
2016-08-13 01:10:40 +00:00
|
|
|
* [ [message-key], [message-key], ... ]
|
2012-02-01 17:05:15 +00:00
|
|
|
* @endcode
|
2010-10-20 20:43:30 +00:00
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $messages = [];
|
2014-05-10 08:39:37 +00:00
|
|
|
|
2014-04-20 21:33:05 +00:00
|
|
|
/** @var string Name of group to load this module in */
|
2010-10-19 22:48:52 +00:00
|
|
|
protected $group;
|
2014-05-10 08:39:37 +00:00
|
|
|
|
2014-04-20 21:33:05 +00:00
|
|
|
/** @var bool Link to raw files in debug mode */
|
2010-10-21 01:03:46 +00:00
|
|
|
protected $debugRaw = true;
|
2014-05-10 08:39:37 +00:00
|
|
|
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $targets = [ 'desktop' ];
|
2012-10-11 22:37:59 +00:00
|
|
|
|
2016-10-18 19:04:40 +00:00
|
|
|
/** @var bool Whether CSSJanus flipping should be skipped for this module */
|
|
|
|
|
protected $noflip = false;
|
|
|
|
|
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
/**
|
2014-04-20 21:33:05 +00:00
|
|
|
* @var bool Whether getStyleURLsForDebug should return raw file paths,
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
* or return load.php urls
|
|
|
|
|
*/
|
|
|
|
|
protected $hasGeneratedStyles = false;
|
|
|
|
|
|
2010-10-27 19:59:10 +00:00
|
|
|
/**
|
2014-04-20 21:33:05 +00:00
|
|
|
* @var array Place where readStyleFile() tracks file dependencies
|
2012-02-01 17:05:15 +00:00
|
|
|
* @par Usage:
|
|
|
|
|
* @code
|
2016-08-13 01:10:40 +00:00
|
|
|
* [ [file-path], [file-path], ... ]
|
2012-02-01 17:05:15 +00:00
|
|
|
* @endcode
|
2010-10-27 19:59:10 +00:00
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $localFileRefs = [];
|
2010-10-19 18:25:42 +00:00
|
|
|
|
2015-09-03 21:30:36 +00:00
|
|
|
/**
|
|
|
|
|
* @var array Place where readStyleFile() tracks file dependencies for non-existent files.
|
|
|
|
|
* Used in tests to detect missing dependencies.
|
|
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $missingLocalFileRefs = [];
|
2015-09-03 21:30:36 +00:00
|
|
|
|
2010-10-19 18:25:42 +00:00
|
|
|
/**
|
2010-10-20 00:22:25 +00:00
|
|
|
* Constructs a new module from an options array.
|
2011-06-17 16:05:05 +00:00
|
|
|
*
|
2013-03-11 17:15:01 +00:00
|
|
|
* @param array $options List of options; if not given or empty, an empty module will be
|
2010-11-05 18:33:50 +00:00
|
|
|
* constructed
|
2018-06-26 21:14:43 +00:00
|
|
|
* @param string|null $localBasePath Base path to prepend to all local paths in $options.
|
|
|
|
|
* Defaults to $IP
|
|
|
|
|
* @param string|null $remoteBasePath Base path to prepend to all remote paths in $options.
|
|
|
|
|
* Defaults to $wgResourceBasePath
|
2011-03-02 20:28:32 +00:00
|
|
|
*
|
2011-06-17 16:05:05 +00:00
|
|
|
* Below is a description for the $options array:
|
2015-03-30 16:51:10 +00:00
|
|
|
* @throws InvalidArgumentException
|
2012-02-01 17:05:15 +00:00
|
|
|
* @par Construction options:
|
2011-03-02 20:28:32 +00:00
|
|
|
* @code
|
2016-08-13 01:10:40 +00:00
|
|
|
* [
|
2012-10-07 23:35:26 +00:00
|
|
|
* // Base path to prepend to all local paths in $options. Defaults to $IP
|
|
|
|
|
* 'localBasePath' => [base path],
|
2014-09-17 23:12:53 +00:00
|
|
|
* // Base path to prepend to all remote paths in $options. Defaults to $wgResourceBasePath
|
2012-10-07 23:35:26 +00:00
|
|
|
* 'remoteBasePath' => [base path],
|
|
|
|
|
* // Equivalent of remoteBasePath, but relative to $wgExtensionAssetsPath
|
|
|
|
|
* 'remoteExtPath' => [base path],
|
2014-06-01 17:25:11 +00:00
|
|
|
* // Equivalent of remoteBasePath, but relative to $wgStylePath
|
|
|
|
|
* 'remoteSkinPath' => [base path],
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
* // Scripts to always include (cannot be set if 'packageFiles' is also set, see below)
|
2012-10-07 23:35:26 +00:00
|
|
|
* 'scripts' => [file path string or array of file path strings],
|
|
|
|
|
* // Scripts to include in specific language contexts
|
2016-09-12 10:06:37 +00:00
|
|
|
* 'languageScripts' => [
|
2012-10-07 23:35:26 +00:00
|
|
|
* [language code] => [file path string or array of file path strings],
|
2016-09-12 10:06:37 +00:00
|
|
|
* ],
|
2012-10-07 23:35:26 +00:00
|
|
|
* // Scripts to include in specific skin contexts
|
2016-09-12 10:06:37 +00:00
|
|
|
* 'skinScripts' => [
|
2012-10-07 23:35:26 +00:00
|
|
|
* [skin name] => [file path string or array of file path strings],
|
2016-09-12 10:06:37 +00:00
|
|
|
* ],
|
2012-10-07 23:35:26 +00:00
|
|
|
* // Scripts to include in debug contexts
|
|
|
|
|
* 'debugScripts' => [file path string or array of file path strings],
|
2019-03-10 19:56:34 +00:00
|
|
|
* // For package modules: files to be made available for internal require() do not
|
|
|
|
|
* // need to have 'type' defined; it will be inferred from the file name extension
|
|
|
|
|
* // if omitted. 'config' can only be used when 'type' is 'data'; the variables are
|
|
|
|
|
* // resolved with Config::get(). The first entry in 'packageFiles' is always the
|
|
|
|
|
* // module entry point. If 'packageFiles' is set, 'scripts' cannot also be set.
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
* 'packageFiles' => [
|
|
|
|
|
* [file path string], // or:
|
resourceloader: Change 'packageFiles' format to be JSON-compatible
The module definition format for 'packageFiles', as initially designed,
mixes sequential and associative arrays. This works in PHP, but not in
JSON. To make the format JSON compatible, use a 'name' key instead of
using the key in the main array.
Leave backwards compatibility in place so that extensions using the old
format can be migrated. This will be removed in the next commit.
Before:
'packageFiles' => [
'script.js',
'script2.js',
'config.json' => [ 'config' => [ 'Foo', 'Bar' ] ],
'data.json' => [ 'callback' => function () { ... } ],
],
After:
'packageFiles' => [
'script.js',
'script2.js',
[ 'name' => 'config.json', 'config' => [ 'Foo', 'Bar' ] ],
[ 'name' => 'data.json', 'callback' => function () { ... } ],
],
This can then be written in extension.json as:
"packageFiles": [
"script.js",
"script2.js",
[ "name": "config.json", "config": [ "Foo", "Bar" ] ],
[ "name": "data.json", "callback: [ "MyExtHooks", "getData" ] ]
]
Change-Id: Ic566a1cd7efd075c380bc50ba0cc2c329a2041d7
2019-02-22 01:26:23 +00:00
|
|
|
* [ 'name' => [file name], 'file' => [file path], 'type' => 'script'|'data' ], // or:
|
|
|
|
|
* [ 'name' => [name], 'content' => [string], 'type' => 'script'|'data' ], // or:
|
|
|
|
|
* [ 'name' => [name], 'callback' => [callable], 'type' => 'script'|'data' ],
|
|
|
|
|
* [ 'name' => [name], 'config' => [ [config var name], ... ], 'type' => 'data' ],
|
|
|
|
|
* [ 'name' => [name], 'config' => [ [JS name] => [PHP name] ], 'type' => 'data' ],
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
* ],
|
2012-10-07 23:35:26 +00:00
|
|
|
* // Modules which must be loaded before this module
|
2012-12-27 18:05:53 +00:00
|
|
|
* 'dependencies' => [module name string or array of module name strings],
|
2016-09-12 10:06:37 +00:00
|
|
|
* 'templates' => [
|
2014-10-10 00:07:14 +00:00
|
|
|
* [template alias with file.ext] => [file path to a template file],
|
2016-09-12 10:06:37 +00:00
|
|
|
* ],
|
2012-10-07 23:35:26 +00:00
|
|
|
* // Styles to always load
|
|
|
|
|
* 'styles' => [file path string or array of file path strings],
|
|
|
|
|
* // Styles to include in specific skin contexts
|
2016-09-12 10:06:37 +00:00
|
|
|
* 'skinStyles' => [
|
2012-10-07 23:35:26 +00:00
|
|
|
* [skin name] => [file path string or array of file path strings],
|
2016-09-12 10:06:37 +00:00
|
|
|
* ],
|
2012-10-07 23:35:26 +00:00
|
|
|
* // Messages to always load
|
|
|
|
|
* 'messages' => [array of message key strings],
|
|
|
|
|
* // Group which this module should be loaded together with
|
|
|
|
|
* 'group' => [group name string],
|
2014-04-30 21:06:51 +00:00
|
|
|
* // Function that, if it returns true, makes the loader skip this module.
|
|
|
|
|
* // The file must contain valid JavaScript for execution in a private function.
|
|
|
|
|
* // The file must not contain the "function () {" and "}" wrapper though.
|
|
|
|
|
* 'skipFunction' => [file path]
|
2016-08-13 01:10:40 +00:00
|
|
|
* ]
|
2011-03-02 20:28:32 +00:00
|
|
|
* @endcode
|
2010-10-19 18:25:42 +00:00
|
|
|
*/
|
2014-06-26 14:29:31 +00:00
|
|
|
public function __construct(
|
2016-02-17 09:09:32 +00:00
|
|
|
$options = [],
|
2014-06-26 14:29:31 +00:00
|
|
|
$localBasePath = null,
|
2013-04-02 20:28:40 +00:00
|
|
|
$remoteBasePath = null
|
|
|
|
|
) {
|
2014-10-10 00:07:14 +00:00
|
|
|
// Flag to decide whether to automagically add the mediawiki.template module
|
|
|
|
|
$hasTemplates = false;
|
2014-06-26 14:29:31 +00:00
|
|
|
// localBasePath and remoteBasePath both have unbelievably long fallback chains
|
|
|
|
|
// and need to be handled separately.
|
|
|
|
|
list( $this->localBasePath, $this->remoteBasePath ) =
|
|
|
|
|
self::extractBasePaths( $options, $localBasePath, $remoteBasePath );
|
2014-06-01 17:25:11 +00:00
|
|
|
|
2014-06-26 14:29:31 +00:00
|
|
|
// Extract, validate and normalise remaining options
|
2010-10-19 20:59:23 +00:00
|
|
|
foreach ( $options as $member => $option ) {
|
|
|
|
|
switch ( $member ) {
|
|
|
|
|
// Lists of file paths
|
2010-10-19 18:25:42 +00:00
|
|
|
case 'scripts':
|
|
|
|
|
case 'debugScripts':
|
|
|
|
|
case 'styles':
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
case 'packageFiles':
|
2013-04-02 20:28:40 +00:00
|
|
|
$this->{$member} = (array)$option;
|
2010-10-19 20:59:23 +00:00
|
|
|
break;
|
2014-10-10 00:07:14 +00:00
|
|
|
case 'templates':
|
|
|
|
|
$hasTemplates = true;
|
|
|
|
|
$this->{$member} = (array)$option;
|
|
|
|
|
break;
|
2010-10-19 20:59:23 +00:00
|
|
|
// Collated lists of file paths
|
|
|
|
|
case 'languageScripts':
|
|
|
|
|
case 'skinScripts':
|
2010-10-19 18:25:42 +00:00
|
|
|
case 'skinStyles':
|
2010-10-21 22:34:26 +00:00
|
|
|
if ( !is_array( $option ) ) {
|
2015-03-30 16:51:10 +00:00
|
|
|
throw new InvalidArgumentException(
|
2011-06-17 16:05:05 +00:00
|
|
|
"Invalid collated file path list error. " .
|
2010-11-05 06:53:14 +00:00
|
|
|
"'$option' given, array expected."
|
2010-10-21 22:34:26 +00:00
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
foreach ( $option as $key => $value ) {
|
|
|
|
|
if ( !is_string( $key ) ) {
|
2015-03-30 16:51:10 +00:00
|
|
|
throw new InvalidArgumentException(
|
2011-06-17 16:05:05 +00:00
|
|
|
"Invalid collated file path list key error. " .
|
2010-11-05 06:53:14 +00:00
|
|
|
"'$key' given, string expected."
|
2010-10-21 22:34:26 +00:00
|
|
|
);
|
|
|
|
|
}
|
2013-04-02 20:28:40 +00:00
|
|
|
$this->{$member}[$key] = (array)$value;
|
2010-10-19 18:25:42 +00:00
|
|
|
}
|
2010-10-21 22:34:26 +00:00
|
|
|
break;
|
2016-07-14 22:09:06 +00:00
|
|
|
case 'deprecated':
|
|
|
|
|
$this->deprecated = $option;
|
|
|
|
|
break;
|
2010-10-19 20:59:23 +00:00
|
|
|
// Lists of strings
|
2010-10-19 18:25:42 +00:00
|
|
|
case 'dependencies':
|
|
|
|
|
case 'messages':
|
2012-10-11 22:37:59 +00:00
|
|
|
case 'targets':
|
2013-10-18 13:34:50 +00:00
|
|
|
// Normalise
|
|
|
|
|
$option = array_values( array_unique( (array)$option ) );
|
|
|
|
|
sort( $option );
|
|
|
|
|
|
|
|
|
|
$this->{$member} = $option;
|
2010-10-19 18:25:42 +00:00
|
|
|
break;
|
2010-10-19 20:59:23 +00:00
|
|
|
// Single strings
|
2015-05-25 14:04:57 +00:00
|
|
|
case 'group':
|
2014-04-30 21:06:51 +00:00
|
|
|
case 'skipFunction':
|
2013-04-02 20:28:40 +00:00
|
|
|
$this->{$member} = (string)$option;
|
2010-10-21 01:03:46 +00:00
|
|
|
break;
|
|
|
|
|
// Single booleans
|
|
|
|
|
case 'debugRaw':
|
2016-10-18 19:04:40 +00:00
|
|
|
case 'noflip':
|
2013-04-02 20:28:40 +00:00
|
|
|
$this->{$member} = (bool)$option;
|
2010-10-19 18:25:42 +00:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
if ( isset( $options['scripts'] ) && isset( $options['packageFiles'] ) ) {
|
|
|
|
|
throw new InvalidArgumentException( "A module may not set both 'scripts' and 'packageFiles'" );
|
|
|
|
|
}
|
2014-10-10 00:07:14 +00:00
|
|
|
if ( $hasTemplates ) {
|
|
|
|
|
$this->dependencies[] = 'mediawiki.template';
|
2014-12-17 20:30:54 +00:00
|
|
|
// Ensure relevant template compiler module gets loaded
|
|
|
|
|
foreach ( $this->templates as $alias => $templatePath ) {
|
|
|
|
|
if ( is_int( $alias ) ) {
|
|
|
|
|
$alias = $templatePath;
|
|
|
|
|
}
|
|
|
|
|
$suffix = explode( '.', $alias );
|
|
|
|
|
$suffix = end( $suffix );
|
|
|
|
|
$compilerModule = 'mediawiki.template.' . $suffix;
|
|
|
|
|
if ( $suffix !== 'html' && !in_array( $compilerModule, $this->dependencies ) ) {
|
|
|
|
|
$this->dependencies[] = $compilerModule;
|
|
|
|
|
}
|
|
|
|
|
}
|
2014-10-10 00:07:14 +00:00
|
|
|
}
|
2014-06-26 14:29:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Extract a pair of local and remote base paths from module definition information.
|
|
|
|
|
* Implementation note: the amount of global state used in this function is staggering.
|
|
|
|
|
*
|
|
|
|
|
* @param array $options Module definition
|
2018-06-26 21:14:43 +00:00
|
|
|
* @param string|null $localBasePath Path to use if not provided in module definition. Defaults
|
2014-06-26 14:29:31 +00:00
|
|
|
* to $IP
|
2018-06-26 21:14:43 +00:00
|
|
|
* @param string|null $remoteBasePath Path to use if not provided in module definition. Defaults
|
2014-09-17 23:12:53 +00:00
|
|
|
* to $wgResourceBasePath
|
2017-01-16 15:42:53 +00:00
|
|
|
* @return array [ localBasePath, remoteBasePath ]
|
2014-06-26 14:29:31 +00:00
|
|
|
*/
|
|
|
|
|
public static function extractBasePaths(
|
2016-02-17 09:09:32 +00:00
|
|
|
$options = [],
|
2014-06-26 14:29:31 +00:00
|
|
|
$localBasePath = null,
|
|
|
|
|
$remoteBasePath = null
|
|
|
|
|
) {
|
2014-09-17 23:12:53 +00:00
|
|
|
global $IP, $wgResourceBasePath;
|
2014-06-26 14:29:31 +00:00
|
|
|
|
|
|
|
|
// The different ways these checks are done, and their ordering, look very silly,
|
|
|
|
|
// but were preserved for backwards-compatibility just in case. Tread lightly.
|
|
|
|
|
|
2014-09-25 01:11:39 +00:00
|
|
|
if ( $localBasePath === null ) {
|
|
|
|
|
$localBasePath = $IP;
|
|
|
|
|
}
|
2014-08-07 10:27:36 +00:00
|
|
|
if ( $remoteBasePath === null ) {
|
2014-09-17 23:12:53 +00:00
|
|
|
$remoteBasePath = $wgResourceBasePath;
|
2014-06-26 14:29:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ( isset( $options['remoteExtPath'] ) ) {
|
|
|
|
|
global $wgExtensionAssetsPath;
|
|
|
|
|
$remoteBasePath = $wgExtensionAssetsPath . '/' . $options['remoteExtPath'];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ( isset( $options['remoteSkinPath'] ) ) {
|
|
|
|
|
global $wgStylePath;
|
|
|
|
|
$remoteBasePath = $wgStylePath . '/' . $options['remoteSkinPath'];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ( array_key_exists( 'localBasePath', $options ) ) {
|
|
|
|
|
$localBasePath = (string)$options['localBasePath'];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ( array_key_exists( 'remoteBasePath', $options ) ) {
|
|
|
|
|
$remoteBasePath = (string)$options['remoteBasePath'];
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-17 09:09:32 +00:00
|
|
|
return [ $localBasePath, $remoteBasePath ];
|
2010-10-19 18:25:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2010-10-20 00:22:25 +00:00
|
|
|
* Gets all scripts for a given context concatenated together.
|
2011-06-17 16:05:05 +00:00
|
|
|
*
|
2013-09-13 04:50:45 +00:00
|
|
|
* @param ResourceLoaderContext $context Context in which to generate script
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
* @return string|array JavaScript code for $context, or package files data structure
|
2010-10-19 18:25:42 +00:00
|
|
|
*/
|
2010-10-19 22:48:52 +00:00
|
|
|
public function getScript( ResourceLoaderContext $context ) {
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
$deprecationScript = $this->getDeprecationInformation();
|
|
|
|
|
if ( $this->packageFiles !== null ) {
|
|
|
|
|
$packageFiles = $this->getPackageFiles( $context );
|
|
|
|
|
if ( $deprecationScript ) {
|
2019-04-06 12:48:39 +00:00
|
|
|
$mainFile =& $packageFiles['files'][$packageFiles['main']];
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
$mainFile['content'] = $deprecationScript . $mainFile['content'];
|
|
|
|
|
}
|
|
|
|
|
return $packageFiles;
|
|
|
|
|
}
|
|
|
|
|
|
2011-05-14 12:15:58 +00:00
|
|
|
$files = $this->getScriptFiles( $context );
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
return $deprecationScript . $this->readScriptFiles( $files );
|
2010-10-19 18:25:42 +00:00
|
|
|
}
|
2011-10-14 08:06:54 +00:00
|
|
|
|
|
|
|
|
/**
|
2013-09-13 04:50:45 +00:00
|
|
|
* @param ResourceLoaderContext $context
|
2011-10-14 08:06:54 +00:00
|
|
|
* @return array
|
|
|
|
|
*/
|
Fix the fixme on r88053: dependency handling was broken in debug mode in certain cases. More specifically, if A is a file module that depends on B, B is a wiki module that depends on C and C is a file module, the loading order is CBA (correct) in production mode but was BCA (wrong) in debug mode. Fixed this by URL-ifying scripts and styles for those modules in debug mode, as I said to on CR. What this means is that the initial debug=true request for a module will now always return arrays of URLs, never the JS or CSS itself. This was already the case for file modules (which returned arrays of URLs to the raw files), but not for other modules (which returned the JS and CSS itself). So for non-file modules, load.php?modules=foo&debug=true now returns some JS that instructs the loader to fetch the module's JS from load.php?modules=foo&debug=true&only=scripts and the CSS from ...&only=styles .
* Removed the magic behavior where ResourceLoaderModule::getScripts() and getStyles() could return an array of URLs where the documentation said they should return a JS/CSS string. Because I didn't restructure the calling code too much, the old magical behavior should still work.
* Instead, move this behavior to getScriptURLsForDebug() and getStyleURLsForDebug(). The default implementation constructs a single URL for a load.php request for the module with debug=true&only=scripts (or styles). The URL building code duplicates some things from OutputPage::makeResourceLoaderLink(), I'll clean that up later. ResourceLoaderFileModule overrides this method to return URLs to the raw files, using code that I removed from getScripts()/getStyles()
* Add ResourceLoaderModule::supportsURLLoading(), which returns true by default but may return false to indicate that a module does not support loading via a URL. This is needed to respect $this->debugRaw in ResourceLoaderFileModule (set to true for jquery and mediawiki), and obviously for the startup module as well, because we get bootstrapping problems otherwise (can't call mw.loader.implement() when the code for mw.loader isn't loaded yet)
2011-09-13 17:13:53 +00:00
|
|
|
public function getScriptURLsForDebug( ResourceLoaderContext $context ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
$urls = [];
|
Fix the fixme on r88053: dependency handling was broken in debug mode in certain cases. More specifically, if A is a file module that depends on B, B is a wiki module that depends on C and C is a file module, the loading order is CBA (correct) in production mode but was BCA (wrong) in debug mode. Fixed this by URL-ifying scripts and styles for those modules in debug mode, as I said to on CR. What this means is that the initial debug=true request for a module will now always return arrays of URLs, never the JS or CSS itself. This was already the case for file modules (which returned arrays of URLs to the raw files), but not for other modules (which returned the JS and CSS itself). So for non-file modules, load.php?modules=foo&debug=true now returns some JS that instructs the loader to fetch the module's JS from load.php?modules=foo&debug=true&only=scripts and the CSS from ...&only=styles .
* Removed the magic behavior where ResourceLoaderModule::getScripts() and getStyles() could return an array of URLs where the documentation said they should return a JS/CSS string. Because I didn't restructure the calling code too much, the old magical behavior should still work.
* Instead, move this behavior to getScriptURLsForDebug() and getStyleURLsForDebug(). The default implementation constructs a single URL for a load.php request for the module with debug=true&only=scripts (or styles). The URL building code duplicates some things from OutputPage::makeResourceLoaderLink(), I'll clean that up later. ResourceLoaderFileModule overrides this method to return URLs to the raw files, using code that I removed from getScripts()/getStyles()
* Add ResourceLoaderModule::supportsURLLoading(), which returns true by default but may return false to indicate that a module does not support loading via a URL. This is needed to respect $this->debugRaw in ResourceLoaderFileModule (set to true for jquery and mediawiki), and obviously for the startup module as well, because we get bootstrapping problems otherwise (can't call mw.loader.implement() when the code for mw.loader isn't loaded yet)
2011-09-13 17:13:53 +00:00
|
|
|
foreach ( $this->getScriptFiles( $context ) as $file ) {
|
2016-02-12 23:33:45 +00:00
|
|
|
$urls[] = OutputPage::transformResourcePath(
|
|
|
|
|
$this->getConfig(),
|
|
|
|
|
$this->getRemotePath( $file )
|
|
|
|
|
);
|
Fix the fixme on r88053: dependency handling was broken in debug mode in certain cases. More specifically, if A is a file module that depends on B, B is a wiki module that depends on C and C is a file module, the loading order is CBA (correct) in production mode but was BCA (wrong) in debug mode. Fixed this by URL-ifying scripts and styles for those modules in debug mode, as I said to on CR. What this means is that the initial debug=true request for a module will now always return arrays of URLs, never the JS or CSS itself. This was already the case for file modules (which returned arrays of URLs to the raw files), but not for other modules (which returned the JS and CSS itself). So for non-file modules, load.php?modules=foo&debug=true now returns some JS that instructs the loader to fetch the module's JS from load.php?modules=foo&debug=true&only=scripts and the CSS from ...&only=styles .
* Removed the magic behavior where ResourceLoaderModule::getScripts() and getStyles() could return an array of URLs where the documentation said they should return a JS/CSS string. Because I didn't restructure the calling code too much, the old magical behavior should still work.
* Instead, move this behavior to getScriptURLsForDebug() and getStyleURLsForDebug(). The default implementation constructs a single URL for a load.php request for the module with debug=true&only=scripts (or styles). The URL building code duplicates some things from OutputPage::makeResourceLoaderLink(), I'll clean that up later. ResourceLoaderFileModule overrides this method to return URLs to the raw files, using code that I removed from getScripts()/getStyles()
* Add ResourceLoaderModule::supportsURLLoading(), which returns true by default but may return false to indicate that a module does not support loading via a URL. This is needed to respect $this->debugRaw in ResourceLoaderFileModule (set to true for jquery and mediawiki), and obviously for the startup module as well, because we get bootstrapping problems otherwise (can't call mw.loader.implement() when the code for mw.loader isn't loaded yet)
2011-09-13 17:13:53 +00:00
|
|
|
}
|
|
|
|
|
return $urls;
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-14 08:06:54 +00:00
|
|
|
/**
|
|
|
|
|
* @return bool
|
|
|
|
|
*/
|
Fix the fixme on r88053: dependency handling was broken in debug mode in certain cases. More specifically, if A is a file module that depends on B, B is a wiki module that depends on C and C is a file module, the loading order is CBA (correct) in production mode but was BCA (wrong) in debug mode. Fixed this by URL-ifying scripts and styles for those modules in debug mode, as I said to on CR. What this means is that the initial debug=true request for a module will now always return arrays of URLs, never the JS or CSS itself. This was already the case for file modules (which returned arrays of URLs to the raw files), but not for other modules (which returned the JS and CSS itself). So for non-file modules, load.php?modules=foo&debug=true now returns some JS that instructs the loader to fetch the module's JS from load.php?modules=foo&debug=true&only=scripts and the CSS from ...&only=styles .
* Removed the magic behavior where ResourceLoaderModule::getScripts() and getStyles() could return an array of URLs where the documentation said they should return a JS/CSS string. Because I didn't restructure the calling code too much, the old magical behavior should still work.
* Instead, move this behavior to getScriptURLsForDebug() and getStyleURLsForDebug(). The default implementation constructs a single URL for a load.php request for the module with debug=true&only=scripts (or styles). The URL building code duplicates some things from OutputPage::makeResourceLoaderLink(), I'll clean that up later. ResourceLoaderFileModule overrides this method to return URLs to the raw files, using code that I removed from getScripts()/getStyles()
* Add ResourceLoaderModule::supportsURLLoading(), which returns true by default but may return false to indicate that a module does not support loading via a URL. This is needed to respect $this->debugRaw in ResourceLoaderFileModule (set to true for jquery and mediawiki), and obviously for the startup module as well, because we get bootstrapping problems otherwise (can't call mw.loader.implement() when the code for mw.loader isn't loaded yet)
2011-09-13 17:13:53 +00:00
|
|
|
public function supportsURLLoading() {
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
// If package files are involved, don't support URL loading, because that breaks
|
|
|
|
|
// scoped require() functions
|
|
|
|
|
return $this->debugRaw && !$this->packageFiles;
|
Fix the fixme on r88053: dependency handling was broken in debug mode in certain cases. More specifically, if A is a file module that depends on B, B is a wiki module that depends on C and C is a file module, the loading order is CBA (correct) in production mode but was BCA (wrong) in debug mode. Fixed this by URL-ifying scripts and styles for those modules in debug mode, as I said to on CR. What this means is that the initial debug=true request for a module will now always return arrays of URLs, never the JS or CSS itself. This was already the case for file modules (which returned arrays of URLs to the raw files), but not for other modules (which returned the JS and CSS itself). So for non-file modules, load.php?modules=foo&debug=true now returns some JS that instructs the loader to fetch the module's JS from load.php?modules=foo&debug=true&only=scripts and the CSS from ...&only=styles .
* Removed the magic behavior where ResourceLoaderModule::getScripts() and getStyles() could return an array of URLs where the documentation said they should return a JS/CSS string. Because I didn't restructure the calling code too much, the old magical behavior should still work.
* Instead, move this behavior to getScriptURLsForDebug() and getStyleURLsForDebug(). The default implementation constructs a single URL for a load.php request for the module with debug=true&only=scripts (or styles). The URL building code duplicates some things from OutputPage::makeResourceLoaderLink(), I'll clean that up later. ResourceLoaderFileModule overrides this method to return URLs to the raw files, using code that I removed from getScripts()/getStyles()
* Add ResourceLoaderModule::supportsURLLoading(), which returns true by default but may return false to indicate that a module does not support loading via a URL. This is needed to respect $this->debugRaw in ResourceLoaderFileModule (set to true for jquery and mediawiki), and obviously for the startup module as well, because we get bootstrapping problems otherwise (can't call mw.loader.implement() when the code for mw.loader isn't loaded yet)
2011-09-13 17:13:53 +00:00
|
|
|
}
|
2010-10-19 18:25:42 +00:00
|
|
|
|
|
|
|
|
/**
|
2014-06-04 19:30:14 +00:00
|
|
|
* Get all styles for a given context.
|
2011-06-17 16:05:05 +00:00
|
|
|
*
|
2014-06-04 19:30:14 +00:00
|
|
|
* @param ResourceLoaderContext $context
|
|
|
|
|
* @return array CSS code for $context as an associative array mapping media type to CSS text.
|
2010-10-19 18:25:42 +00:00
|
|
|
*/
|
|
|
|
|
public function getStyles( ResourceLoaderContext $context ) {
|
2011-05-14 12:15:58 +00:00
|
|
|
$styles = $this->readStyleFiles(
|
|
|
|
|
$this->getStyleFiles( $context ),
|
2014-08-20 13:13:43 +00:00
|
|
|
$this->getFlip( $context ),
|
|
|
|
|
$context
|
2010-12-16 19:31:48 +00:00
|
|
|
);
|
2010-10-19 18:25:42 +00:00
|
|
|
// Collect referenced files
|
2015-09-30 00:15:57 +00:00
|
|
|
$this->saveFileDependencies( $context, $this->localFileRefs );
|
2015-09-17 22:14:46 +00:00
|
|
|
|
2010-10-19 18:25:42 +00:00
|
|
|
return $styles;
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-14 08:06:54 +00:00
|
|
|
/**
|
2013-09-13 04:50:45 +00:00
|
|
|
* @param ResourceLoaderContext $context
|
2011-10-14 08:06:54 +00:00
|
|
|
* @return array
|
|
|
|
|
*/
|
Fix the fixme on r88053: dependency handling was broken in debug mode in certain cases. More specifically, if A is a file module that depends on B, B is a wiki module that depends on C and C is a file module, the loading order is CBA (correct) in production mode but was BCA (wrong) in debug mode. Fixed this by URL-ifying scripts and styles for those modules in debug mode, as I said to on CR. What this means is that the initial debug=true request for a module will now always return arrays of URLs, never the JS or CSS itself. This was already the case for file modules (which returned arrays of URLs to the raw files), but not for other modules (which returned the JS and CSS itself). So for non-file modules, load.php?modules=foo&debug=true now returns some JS that instructs the loader to fetch the module's JS from load.php?modules=foo&debug=true&only=scripts and the CSS from ...&only=styles .
* Removed the magic behavior where ResourceLoaderModule::getScripts() and getStyles() could return an array of URLs where the documentation said they should return a JS/CSS string. Because I didn't restructure the calling code too much, the old magical behavior should still work.
* Instead, move this behavior to getScriptURLsForDebug() and getStyleURLsForDebug(). The default implementation constructs a single URL for a load.php request for the module with debug=true&only=scripts (or styles). The URL building code duplicates some things from OutputPage::makeResourceLoaderLink(), I'll clean that up later. ResourceLoaderFileModule overrides this method to return URLs to the raw files, using code that I removed from getScripts()/getStyles()
* Add ResourceLoaderModule::supportsURLLoading(), which returns true by default but may return false to indicate that a module does not support loading via a URL. This is needed to respect $this->debugRaw in ResourceLoaderFileModule (set to true for jquery and mediawiki), and obviously for the startup module as well, because we get bootstrapping problems otherwise (can't call mw.loader.implement() when the code for mw.loader isn't loaded yet)
2011-09-13 17:13:53 +00:00
|
|
|
public function getStyleURLsForDebug( ResourceLoaderContext $context ) {
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
if ( $this->hasGeneratedStyles ) {
|
|
|
|
|
// Do the default behaviour of returning a url back to load.php
|
|
|
|
|
// but with only=styles.
|
|
|
|
|
return parent::getStyleURLsForDebug( $context );
|
|
|
|
|
}
|
|
|
|
|
// Our module consists entirely of real css files,
|
|
|
|
|
// in debug mode we can load those directly.
|
2016-02-17 09:09:32 +00:00
|
|
|
$urls = [];
|
Fix the fixme on r88053: dependency handling was broken in debug mode in certain cases. More specifically, if A is a file module that depends on B, B is a wiki module that depends on C and C is a file module, the loading order is CBA (correct) in production mode but was BCA (wrong) in debug mode. Fixed this by URL-ifying scripts and styles for those modules in debug mode, as I said to on CR. What this means is that the initial debug=true request for a module will now always return arrays of URLs, never the JS or CSS itself. This was already the case for file modules (which returned arrays of URLs to the raw files), but not for other modules (which returned the JS and CSS itself). So for non-file modules, load.php?modules=foo&debug=true now returns some JS that instructs the loader to fetch the module's JS from load.php?modules=foo&debug=true&only=scripts and the CSS from ...&only=styles .
* Removed the magic behavior where ResourceLoaderModule::getScripts() and getStyles() could return an array of URLs where the documentation said they should return a JS/CSS string. Because I didn't restructure the calling code too much, the old magical behavior should still work.
* Instead, move this behavior to getScriptURLsForDebug() and getStyleURLsForDebug(). The default implementation constructs a single URL for a load.php request for the module with debug=true&only=scripts (or styles). The URL building code duplicates some things from OutputPage::makeResourceLoaderLink(), I'll clean that up later. ResourceLoaderFileModule overrides this method to return URLs to the raw files, using code that I removed from getScripts()/getStyles()
* Add ResourceLoaderModule::supportsURLLoading(), which returns true by default but may return false to indicate that a module does not support loading via a URL. This is needed to respect $this->debugRaw in ResourceLoaderFileModule (set to true for jquery and mediawiki), and obviously for the startup module as well, because we get bootstrapping problems otherwise (can't call mw.loader.implement() when the code for mw.loader isn't loaded yet)
2011-09-13 17:13:53 +00:00
|
|
|
foreach ( $this->getStyleFiles( $context ) as $mediaType => $list ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
$urls[$mediaType] = [];
|
Fix the fixme on r88053: dependency handling was broken in debug mode in certain cases. More specifically, if A is a file module that depends on B, B is a wiki module that depends on C and C is a file module, the loading order is CBA (correct) in production mode but was BCA (wrong) in debug mode. Fixed this by URL-ifying scripts and styles for those modules in debug mode, as I said to on CR. What this means is that the initial debug=true request for a module will now always return arrays of URLs, never the JS or CSS itself. This was already the case for file modules (which returned arrays of URLs to the raw files), but not for other modules (which returned the JS and CSS itself). So for non-file modules, load.php?modules=foo&debug=true now returns some JS that instructs the loader to fetch the module's JS from load.php?modules=foo&debug=true&only=scripts and the CSS from ...&only=styles .
* Removed the magic behavior where ResourceLoaderModule::getScripts() and getStyles() could return an array of URLs where the documentation said they should return a JS/CSS string. Because I didn't restructure the calling code too much, the old magical behavior should still work.
* Instead, move this behavior to getScriptURLsForDebug() and getStyleURLsForDebug(). The default implementation constructs a single URL for a load.php request for the module with debug=true&only=scripts (or styles). The URL building code duplicates some things from OutputPage::makeResourceLoaderLink(), I'll clean that up later. ResourceLoaderFileModule overrides this method to return URLs to the raw files, using code that I removed from getScripts()/getStyles()
* Add ResourceLoaderModule::supportsURLLoading(), which returns true by default but may return false to indicate that a module does not support loading via a URL. This is needed to respect $this->debugRaw in ResourceLoaderFileModule (set to true for jquery and mediawiki), and obviously for the startup module as well, because we get bootstrapping problems otherwise (can't call mw.loader.implement() when the code for mw.loader isn't loaded yet)
2011-09-13 17:13:53 +00:00
|
|
|
foreach ( $list as $file ) {
|
2016-02-12 23:33:45 +00:00
|
|
|
$urls[$mediaType][] = OutputPage::transformResourcePath(
|
|
|
|
|
$this->getConfig(),
|
|
|
|
|
$this->getRemotePath( $file )
|
|
|
|
|
);
|
Fix the fixme on r88053: dependency handling was broken in debug mode in certain cases. More specifically, if A is a file module that depends on B, B is a wiki module that depends on C and C is a file module, the loading order is CBA (correct) in production mode but was BCA (wrong) in debug mode. Fixed this by URL-ifying scripts and styles for those modules in debug mode, as I said to on CR. What this means is that the initial debug=true request for a module will now always return arrays of URLs, never the JS or CSS itself. This was already the case for file modules (which returned arrays of URLs to the raw files), but not for other modules (which returned the JS and CSS itself). So for non-file modules, load.php?modules=foo&debug=true now returns some JS that instructs the loader to fetch the module's JS from load.php?modules=foo&debug=true&only=scripts and the CSS from ...&only=styles .
* Removed the magic behavior where ResourceLoaderModule::getScripts() and getStyles() could return an array of URLs where the documentation said they should return a JS/CSS string. Because I didn't restructure the calling code too much, the old magical behavior should still work.
* Instead, move this behavior to getScriptURLsForDebug() and getStyleURLsForDebug(). The default implementation constructs a single URL for a load.php request for the module with debug=true&only=scripts (or styles). The URL building code duplicates some things from OutputPage::makeResourceLoaderLink(), I'll clean that up later. ResourceLoaderFileModule overrides this method to return URLs to the raw files, using code that I removed from getScripts()/getStyles()
* Add ResourceLoaderModule::supportsURLLoading(), which returns true by default but may return false to indicate that a module does not support loading via a URL. This is needed to respect $this->debugRaw in ResourceLoaderFileModule (set to true for jquery and mediawiki), and obviously for the startup module as well, because we get bootstrapping problems otherwise (can't call mw.loader.implement() when the code for mw.loader isn't loaded yet)
2011-09-13 17:13:53 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return $urls;
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-19 22:48:52 +00:00
|
|
|
/**
|
2010-10-20 00:22:25 +00:00
|
|
|
* Gets list of message keys used by this module.
|
2011-06-17 16:05:05 +00:00
|
|
|
*
|
2014-04-20 21:33:05 +00:00
|
|
|
* @return array List of message keys
|
2010-10-19 22:48:52 +00:00
|
|
|
*/
|
2010-10-19 18:25:42 +00:00
|
|
|
public function getMessages() {
|
|
|
|
|
return $this->messages;
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-19 22:48:52 +00:00
|
|
|
/**
|
2010-10-20 00:22:25 +00:00
|
|
|
* Gets the name of the group this module should be loaded in.
|
2011-06-17 16:05:05 +00:00
|
|
|
*
|
2014-04-20 21:33:05 +00:00
|
|
|
* @return string Group name
|
2010-10-19 22:48:52 +00:00
|
|
|
*/
|
2010-10-19 18:25:42 +00:00
|
|
|
public function getGroup() {
|
|
|
|
|
return $this->group;
|
|
|
|
|
}
|
2011-05-21 17:45:20 +00:00
|
|
|
|
2010-10-19 22:48:52 +00:00
|
|
|
/**
|
2010-10-20 00:22:25 +00:00
|
|
|
* Gets list of names of modules this module depends on.
|
2015-12-09 17:20:41 +00:00
|
|
|
* @param ResourceLoaderContext|null $context
|
2014-04-20 21:33:05 +00:00
|
|
|
* @return array List of module names
|
2010-10-19 22:48:52 +00:00
|
|
|
*/
|
2015-04-08 21:34:08 +00:00
|
|
|
public function getDependencies( ResourceLoaderContext $context = null ) {
|
2010-10-19 18:25:42 +00:00
|
|
|
return $this->dependencies;
|
|
|
|
|
}
|
|
|
|
|
|
2014-04-30 21:06:51 +00:00
|
|
|
/**
|
|
|
|
|
* Get the skip function.
|
2014-12-24 13:49:20 +00:00
|
|
|
* @return null|string
|
|
|
|
|
* @throws MWException
|
2014-04-30 21:06:51 +00:00
|
|
|
*/
|
|
|
|
|
public function getSkipFunction() {
|
|
|
|
|
if ( !$this->skipFunction ) {
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$localPath = $this->getLocalPath( $this->skipFunction );
|
|
|
|
|
if ( !file_exists( $localPath ) ) {
|
|
|
|
|
throw new MWException( __METHOD__ . ": skip function file not found: \"$localPath\"" );
|
|
|
|
|
}
|
2016-05-11 11:53:59 +00:00
|
|
|
$contents = $this->stripBom( file_get_contents( $localPath ) );
|
2014-04-30 21:06:51 +00:00
|
|
|
return $contents;
|
|
|
|
|
}
|
|
|
|
|
|
resourceloader: Enable module content version for data modules
This greatly simplifies logic required to compute module versions.
It also makes it significantly less error-prone.
Since f37cee996e, we support hashes as versions (instead of timestamps).
This means we can build a hash of the content directly, instead of compiling a
large array with all values that may influence the module content somehow.
Benefits:
* Remove all methods and logic related to querying database and disk for
timestamps, revision numbers, definition summaries, cache epochs, and more.
* No longer needlessly invalidate cache as a result of no-op changes to
implementation datails. Due to inclusion of absolute file paths in the
definition summary, cache was always invalidated when moving wikis to newer
MediaWiki branches; even if the module observed no actual changes.
* When changes are reverted within a certain period of time, old caches can now
be re-used. The module would produce the same version hash as before.
Previously when a change was deployed and then reverted, all web clients (even
those that never saw the bad version) would have re-fetch modules because the
version increased.
Updated unit tests to account for the change in version. New default version of
empty test modules is: "mvgTPvXh". For the record, this comes from the base64
encoding of the SHA1 digest of the JSON serialised form of the module content:
> $str = '{"scripts":"","styles":{"css":[]},"messagesBlob":"{}"}';
> echo base64_encode(sha1($str, true));
> FEb3+VuiUm/fOMfod1bjw/te+AQ=
Enabled content versioning for the data modules in MediaWiki core:
* EditToolbarModule
* JqueryMsgModule
* LanguageDataModule
* LanguageNamesModule
* SpecialCharacterDataModule
* UserCSSPrefsModule
* UserDefaultsModule
* UserOptionsModule
The FileModule and base class explicitly disable it for now and keep their
current behaviour of using the definition summary. We may remove it later, but
that requires more performance testing first.
Explicitly disable it in the WikiModule class to avoid breakage when the
default changes.
Ref T98087.
Change-Id: I782df43c50dfcfb7d7592f744e13a3a0430b0dc6
2015-06-02 17:27:23 +00:00
|
|
|
/**
|
|
|
|
|
* Disable module content versioning.
|
|
|
|
|
*
|
|
|
|
|
* This class uses getDefinitionSummary() instead, to avoid filesystem overhead
|
|
|
|
|
* involved with building the full module content inside a startup request.
|
|
|
|
|
*
|
|
|
|
|
* @return bool
|
|
|
|
|
*/
|
|
|
|
|
public function enableModuleContentVersion() {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-19 18:25:42 +00:00
|
|
|
/**
|
2018-06-26 01:52:40 +00:00
|
|
|
* Helper method for getDefinitionSummary.
|
2011-06-17 16:05:05 +00:00
|
|
|
*
|
2010-11-05 18:33:50 +00:00
|
|
|
* @see ResourceLoaderModule::getFileDependencies
|
resourceloader: Replace timestamp system with version hashing
Modules now track their version via getVersionHash() instead of getModifiedTime().
== Background ==
While some resources have observeable timestamps (e.g. files stored on disk),
many other resources do not. E.g. config variables, and module definitions.
For static file modules, one can e.g. revert one of more files in a module to a
previous version and not affect the max timestamp.
Wiki modules include pages only if they exist. The user module supports common.js
and skin.js. By default neither exists. If a user has both, and then the
less-recently modified one is deleted, the max-timestamp remains unchanged.
For client-side caching, batch requests use "Math.max" on the relevant timestamps.
Again, if a module changes but another module is more recent (e.g. out-of-order
deployment, or out-of-order discovery), the change would not result in a cache miss.
More scenarios can be found in the associated Phabricator tasks.
== Version hash ==
Previously we virtually mapped these variables to a timestamp by storing the current
time alongside a hash of the value in ObjectCache. Considering the number of
possible request contexts (wikis * modules * users * skins * languages) this doesn't
work well. It results in needless cache invalidation when the first time observation
is purged due to LRU algorithms. It also has other minor bugs leading to fewer
cache hits.
All modules automatically get the benefits of version hashing with this change.
The old getDefinitionMtime() and getHashMtime() have been replaced with dummies
that return 1. These functions are often called from getModifiedTime() in subclasses.
For backward-compatibility, their respective values (definition summary and hash)
are now included in getVersionHash directly.
As examples, the following modules have been updated to use getVersionHash directly.
Other modules still work fine and can be updated later.
* ResourceLoaderFileModule
* ResourceLoaderEditToolbarModule
* ResourceLoaderStartUpModule
* ResourceLoaderWikiModule
The presence of hashes in place of timestamps increases the startup module size on
a default MediaWiki install from 4.4k to 5.8k (after gzip and minification).
== ETag ==
Since timestamps are no longer tracked, we need a different way to implement caching
for cache proxies (e.g. Varnish) and web browsers. Previously we used the
Last-Modified header (in combination with Cache-Control and Expires).
Instead of Last-Modified (and If-Modified-Since), we use ETag (and If-None-Match).
Entity tags (new in HTTP/1.1) are much stricter than Last-Modified by default.
They instruct browsers to allow usage of partial Range requests. Since our responses
are dynamically generated, we need to use the Weak version of ETag.
While this sounds bad, it's no different than Last-Modified. As reassured by
RFC 2616 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3> the
specified behaviour behind Last-Modified follows the same "Weak" caching logic as
Entity tags. It's just that entity tags are capable of a stricter mode (whereas
Last-Modified is inherently weak).
== File cache ==
If $wgUseFileCache is enabled, ResourceLoader uses ResourceFileCache to cache
load.php responses. While the blind TTL handling (during the allowed expiry period)
is still maxage/timestamp based, tryRespondNotModified() now requires the caller to
know the expected ETag.
For this to work, the FileCache handling had to be moved from the top of
ResoureLoader::respond() to after the expected ETag is computed.
This also allows us to remove the duplicate tryRespondNotModified() handling since
that's is already handled by ResourceLoader::respond() meanwhile.
== Misc ==
* Remove redundant modifiedTime cache in ResourceLoaderFileModule.
* Change bugzilla references to Phabricator.
* Centralised inclusion of wgCacheEpoch using getDefinitionSummary. Previously this
logic was duplicated in each place the modified timestamp was used.
* It's easy to forget calling the parent class in getDefinitionSummary().
Previously this method only tracked 'class' by default. As such, various
extensions hardcoded that one value instead of calling the parent and extending
the array. To better prevent this in the future, getVersionHash() now asserts
that the '_cacheEpoch' property made it through.
* tests: Don't use getDefinitionSummary() as an API.
Fix ResourceLoaderWikiModuleTest to call getPages properly.
* In tests, the default timestamp used to be 1388534400000 (which is the unix time
of 20140101000000; the unit tests' CacheEpoch). The new version hash of these
modules is "XyCC+PSK", which is the base64 encoded prefix of the SHA1 digest of:
'{"_class":"ResourceLoaderTestModule","_cacheEpoch":"20140101000000"}'
* Add sha1.js library for client-side hash generation.
Compared various different implementations for code size (after minfication/gzip),
and speed (when used for short hexidecimal strings).
https://jsperf.com/sha1-implementations
- CryptoJS <https://code.google.com/p/crypto-js/#SHA-1> (min+gzip: 2.5k)
http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/sha1.js
Chrome: 45k, Firefox: 89k, Safari: 92k
- jsSHA <https://github.com/Caligatio/jsSHA>
https://github.com/Caligatio/jsSHA/blob/3c1d4f2e/src/sha1.js (min+gzip: 1.8k)
Chrome: 65k, Firefox: 53k, Safari: 69k
- phpjs-sha1 <https://github.com/kvz/phpjs> (RL min+gzip: 0.8k)
https://github.com/kvz/phpjs/blob/1eaab15d/functions/strings/sha1.js
Chrome: 200k, Firefox: 280k, Safari: 78k
Modern browsers implement the HTML5 Crypto API. However, this API is asynchronous,
only enabled when on HTTPS in Chromium, and is quite low-level. It requires boilerplate
code to actually use with TextEncoder, ArrayBuffer and Uint32Array. Due this being
needed in the module loader, we'd have to load the fallback regardless. Considering
this is not used in a critical path for performance, it's not worth shipping two
implementations for this optimisation.
May also resolve:
* T44094
* T90411
* T94810
Bug: T94074
Change-Id: Ibb292d2416839327d1807a66c78fd96dac0637d0
2015-04-29 22:53:24 +00:00
|
|
|
* @param ResourceLoaderContext $context
|
|
|
|
|
* @return array
|
2010-10-19 18:25:42 +00:00
|
|
|
*/
|
2018-06-26 01:52:40 +00:00
|
|
|
private function getFileHashes( ResourceLoaderContext $context ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
$files = [];
|
2011-06-17 16:05:05 +00:00
|
|
|
|
2010-10-19 23:47:56 +00:00
|
|
|
// Flatten style files into $files
|
|
|
|
|
$styles = self::collateFilePathListByOption( $this->styles, 'media', 'all' );
|
|
|
|
|
foreach ( $styles as $styleFiles ) {
|
|
|
|
|
$files = array_merge( $files, $styleFiles );
|
2010-10-19 18:25:42 +00:00
|
|
|
}
|
2014-02-28 19:23:11 +00:00
|
|
|
|
|
|
|
|
$skinFiles = self::collateFilePathListByOption(
|
|
|
|
|
self::tryForKey( $this->skinStyles, $context->getSkin(), 'default' ),
|
|
|
|
|
'media',
|
|
|
|
|
'all'
|
2010-10-19 18:25:42 +00:00
|
|
|
);
|
|
|
|
|
foreach ( $skinFiles as $styleFiles ) {
|
2010-10-19 23:47:56 +00:00
|
|
|
$files = array_merge( $files, $styleFiles );
|
2010-10-19 18:25:42 +00:00
|
|
|
}
|
2011-06-17 16:05:05 +00:00
|
|
|
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
// Extract file names for package files
|
|
|
|
|
$expandedPackageFiles = $this->expandPackageFiles( $context );
|
|
|
|
|
$packageFiles = $expandedPackageFiles ?
|
|
|
|
|
array_filter( array_map( function ( $fileInfo ) {
|
|
|
|
|
return $fileInfo['filePath'] ?? null;
|
|
|
|
|
}, $expandedPackageFiles['files'] ) ) :
|
|
|
|
|
[];
|
|
|
|
|
|
2010-10-19 18:25:42 +00:00
|
|
|
// Final merge, this should result in a master list of dependent files
|
|
|
|
|
$files = array_merge(
|
2010-10-19 23:47:56 +00:00
|
|
|
$files,
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
$packageFiles,
|
2010-10-19 18:25:42 +00:00
|
|
|
$this->scripts,
|
2014-10-10 00:07:14 +00:00
|
|
|
$this->templates,
|
2016-02-17 09:09:32 +00:00
|
|
|
$context->getDebug() ? $this->debugScripts : [],
|
2014-08-29 17:13:21 +00:00
|
|
|
$this->getLanguageScripts( $context->getLanguage() ),
|
2015-10-19 23:04:23 +00:00
|
|
|
self::tryForKey( $this->skinScripts, $context->getSkin(), 'default' )
|
2010-10-19 18:25:42 +00:00
|
|
|
);
|
2014-04-30 21:06:51 +00:00
|
|
|
if ( $this->skipFunction ) {
|
|
|
|
|
$files[] = $this->skipFunction;
|
|
|
|
|
}
|
2016-02-17 09:09:32 +00:00
|
|
|
$files = array_map( [ $this, 'getLocalPath' ], $files );
|
2010-10-27 22:22:10 +00:00
|
|
|
// File deps need to be treated separately because they're already prefixed
|
2015-09-30 00:15:57 +00:00
|
|
|
$files = array_merge( $files, $this->getFileDependencies( $context ) );
|
2015-03-31 18:01:15 +00:00
|
|
|
// Filter out any duplicates from getFileDependencies() and others.
|
|
|
|
|
// Most commonly introduced by compileLessFile(), which always includes the
|
|
|
|
|
// entry point Less file we already know about.
|
|
|
|
|
$files = array_values( array_unique( $files ) );
|
2011-06-17 16:05:05 +00:00
|
|
|
|
2015-07-09 18:30:53 +00:00
|
|
|
// Don't include keys or file paths here, only the hashes. Including that would needlessly
|
|
|
|
|
// cause global cache invalidation when files move or if e.g. the MediaWiki path changes.
|
|
|
|
|
// Any significant ordering is already detected by the definition summary.
|
2016-02-17 09:09:32 +00:00
|
|
|
return array_map( [ __CLASS__, 'safeFileHash' ], $files );
|
2010-10-19 18:25:42 +00:00
|
|
|
}
|
|
|
|
|
|
2013-10-18 13:34:50 +00:00
|
|
|
/**
|
|
|
|
|
* Get the definition summary for this module.
|
|
|
|
|
*
|
2014-08-14 19:34:55 +00:00
|
|
|
* @param ResourceLoaderContext $context
|
2014-04-20 21:33:05 +00:00
|
|
|
* @return array
|
2013-10-18 13:34:50 +00:00
|
|
|
*/
|
|
|
|
|
public function getDefinitionSummary( ResourceLoaderContext $context ) {
|
2015-03-23 03:56:35 +00:00
|
|
|
$summary = parent::getDefinitionSummary( $context );
|
resourceloader: Replace timestamp system with version hashing
Modules now track their version via getVersionHash() instead of getModifiedTime().
== Background ==
While some resources have observeable timestamps (e.g. files stored on disk),
many other resources do not. E.g. config variables, and module definitions.
For static file modules, one can e.g. revert one of more files in a module to a
previous version and not affect the max timestamp.
Wiki modules include pages only if they exist. The user module supports common.js
and skin.js. By default neither exists. If a user has both, and then the
less-recently modified one is deleted, the max-timestamp remains unchanged.
For client-side caching, batch requests use "Math.max" on the relevant timestamps.
Again, if a module changes but another module is more recent (e.g. out-of-order
deployment, or out-of-order discovery), the change would not result in a cache miss.
More scenarios can be found in the associated Phabricator tasks.
== Version hash ==
Previously we virtually mapped these variables to a timestamp by storing the current
time alongside a hash of the value in ObjectCache. Considering the number of
possible request contexts (wikis * modules * users * skins * languages) this doesn't
work well. It results in needless cache invalidation when the first time observation
is purged due to LRU algorithms. It also has other minor bugs leading to fewer
cache hits.
All modules automatically get the benefits of version hashing with this change.
The old getDefinitionMtime() and getHashMtime() have been replaced with dummies
that return 1. These functions are often called from getModifiedTime() in subclasses.
For backward-compatibility, their respective values (definition summary and hash)
are now included in getVersionHash directly.
As examples, the following modules have been updated to use getVersionHash directly.
Other modules still work fine and can be updated later.
* ResourceLoaderFileModule
* ResourceLoaderEditToolbarModule
* ResourceLoaderStartUpModule
* ResourceLoaderWikiModule
The presence of hashes in place of timestamps increases the startup module size on
a default MediaWiki install from 4.4k to 5.8k (after gzip and minification).
== ETag ==
Since timestamps are no longer tracked, we need a different way to implement caching
for cache proxies (e.g. Varnish) and web browsers. Previously we used the
Last-Modified header (in combination with Cache-Control and Expires).
Instead of Last-Modified (and If-Modified-Since), we use ETag (and If-None-Match).
Entity tags (new in HTTP/1.1) are much stricter than Last-Modified by default.
They instruct browsers to allow usage of partial Range requests. Since our responses
are dynamically generated, we need to use the Weak version of ETag.
While this sounds bad, it's no different than Last-Modified. As reassured by
RFC 2616 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3> the
specified behaviour behind Last-Modified follows the same "Weak" caching logic as
Entity tags. It's just that entity tags are capable of a stricter mode (whereas
Last-Modified is inherently weak).
== File cache ==
If $wgUseFileCache is enabled, ResourceLoader uses ResourceFileCache to cache
load.php responses. While the blind TTL handling (during the allowed expiry period)
is still maxage/timestamp based, tryRespondNotModified() now requires the caller to
know the expected ETag.
For this to work, the FileCache handling had to be moved from the top of
ResoureLoader::respond() to after the expected ETag is computed.
This also allows us to remove the duplicate tryRespondNotModified() handling since
that's is already handled by ResourceLoader::respond() meanwhile.
== Misc ==
* Remove redundant modifiedTime cache in ResourceLoaderFileModule.
* Change bugzilla references to Phabricator.
* Centralised inclusion of wgCacheEpoch using getDefinitionSummary. Previously this
logic was duplicated in each place the modified timestamp was used.
* It's easy to forget calling the parent class in getDefinitionSummary().
Previously this method only tracked 'class' by default. As such, various
extensions hardcoded that one value instead of calling the parent and extending
the array. To better prevent this in the future, getVersionHash() now asserts
that the '_cacheEpoch' property made it through.
* tests: Don't use getDefinitionSummary() as an API.
Fix ResourceLoaderWikiModuleTest to call getPages properly.
* In tests, the default timestamp used to be 1388534400000 (which is the unix time
of 20140101000000; the unit tests' CacheEpoch). The new version hash of these
modules is "XyCC+PSK", which is the base64 encoded prefix of the SHA1 digest of:
'{"_class":"ResourceLoaderTestModule","_cacheEpoch":"20140101000000"}'
* Add sha1.js library for client-side hash generation.
Compared various different implementations for code size (after minfication/gzip),
and speed (when used for short hexidecimal strings).
https://jsperf.com/sha1-implementations
- CryptoJS <https://code.google.com/p/crypto-js/#SHA-1> (min+gzip: 2.5k)
http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/sha1.js
Chrome: 45k, Firefox: 89k, Safari: 92k
- jsSHA <https://github.com/Caligatio/jsSHA>
https://github.com/Caligatio/jsSHA/blob/3c1d4f2e/src/sha1.js (min+gzip: 1.8k)
Chrome: 65k, Firefox: 53k, Safari: 69k
- phpjs-sha1 <https://github.com/kvz/phpjs> (RL min+gzip: 0.8k)
https://github.com/kvz/phpjs/blob/1eaab15d/functions/strings/sha1.js
Chrome: 200k, Firefox: 280k, Safari: 78k
Modern browsers implement the HTML5 Crypto API. However, this API is asynchronous,
only enabled when on HTTPS in Chromium, and is quite low-level. It requires boilerplate
code to actually use with TextEncoder, ArrayBuffer and Uint32Array. Due this being
needed in the module loader, we'd have to load the fallback regardless. Considering
this is not used in a critical path for performance, it's not worth shipping two
implementations for this optimisation.
May also resolve:
* T44094
* T90411
* T94810
Bug: T94074
Change-Id: Ibb292d2416839327d1807a66c78fd96dac0637d0
2015-04-29 22:53:24 +00:00
|
|
|
|
2016-02-17 09:09:32 +00:00
|
|
|
$options = [];
|
|
|
|
|
foreach ( [
|
2015-08-23 12:34:33 +00:00
|
|
|
// The following properties are omitted because they don't affect the module reponse:
|
|
|
|
|
// - localBasePath (Per T104950; Changes when absolute directory name changes. If
|
|
|
|
|
// this affects 'scripts' and other file paths, getFileHashes accounts for that.)
|
|
|
|
|
// - remoteBasePath (Per T104950)
|
|
|
|
|
// - dependencies (provided via startup module)
|
|
|
|
|
// - targets
|
|
|
|
|
// - group (provided via startup module)
|
2013-10-18 13:34:50 +00:00
|
|
|
'scripts',
|
|
|
|
|
'debugScripts',
|
|
|
|
|
'styles',
|
|
|
|
|
'languageScripts',
|
|
|
|
|
'skinScripts',
|
|
|
|
|
'skinStyles',
|
|
|
|
|
'messages',
|
2014-10-10 00:07:14 +00:00
|
|
|
'templates',
|
2014-04-30 21:06:51 +00:00
|
|
|
'skipFunction',
|
2013-10-18 13:34:50 +00:00
|
|
|
'debugRaw',
|
2016-02-17 09:09:32 +00:00
|
|
|
] as $member ) {
|
resourceloader: Replace timestamp system with version hashing
Modules now track their version via getVersionHash() instead of getModifiedTime().
== Background ==
While some resources have observeable timestamps (e.g. files stored on disk),
many other resources do not. E.g. config variables, and module definitions.
For static file modules, one can e.g. revert one of more files in a module to a
previous version and not affect the max timestamp.
Wiki modules include pages only if they exist. The user module supports common.js
and skin.js. By default neither exists. If a user has both, and then the
less-recently modified one is deleted, the max-timestamp remains unchanged.
For client-side caching, batch requests use "Math.max" on the relevant timestamps.
Again, if a module changes but another module is more recent (e.g. out-of-order
deployment, or out-of-order discovery), the change would not result in a cache miss.
More scenarios can be found in the associated Phabricator tasks.
== Version hash ==
Previously we virtually mapped these variables to a timestamp by storing the current
time alongside a hash of the value in ObjectCache. Considering the number of
possible request contexts (wikis * modules * users * skins * languages) this doesn't
work well. It results in needless cache invalidation when the first time observation
is purged due to LRU algorithms. It also has other minor bugs leading to fewer
cache hits.
All modules automatically get the benefits of version hashing with this change.
The old getDefinitionMtime() and getHashMtime() have been replaced with dummies
that return 1. These functions are often called from getModifiedTime() in subclasses.
For backward-compatibility, their respective values (definition summary and hash)
are now included in getVersionHash directly.
As examples, the following modules have been updated to use getVersionHash directly.
Other modules still work fine and can be updated later.
* ResourceLoaderFileModule
* ResourceLoaderEditToolbarModule
* ResourceLoaderStartUpModule
* ResourceLoaderWikiModule
The presence of hashes in place of timestamps increases the startup module size on
a default MediaWiki install from 4.4k to 5.8k (after gzip and minification).
== ETag ==
Since timestamps are no longer tracked, we need a different way to implement caching
for cache proxies (e.g. Varnish) and web browsers. Previously we used the
Last-Modified header (in combination with Cache-Control and Expires).
Instead of Last-Modified (and If-Modified-Since), we use ETag (and If-None-Match).
Entity tags (new in HTTP/1.1) are much stricter than Last-Modified by default.
They instruct browsers to allow usage of partial Range requests. Since our responses
are dynamically generated, we need to use the Weak version of ETag.
While this sounds bad, it's no different than Last-Modified. As reassured by
RFC 2616 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3> the
specified behaviour behind Last-Modified follows the same "Weak" caching logic as
Entity tags. It's just that entity tags are capable of a stricter mode (whereas
Last-Modified is inherently weak).
== File cache ==
If $wgUseFileCache is enabled, ResourceLoader uses ResourceFileCache to cache
load.php responses. While the blind TTL handling (during the allowed expiry period)
is still maxage/timestamp based, tryRespondNotModified() now requires the caller to
know the expected ETag.
For this to work, the FileCache handling had to be moved from the top of
ResoureLoader::respond() to after the expected ETag is computed.
This also allows us to remove the duplicate tryRespondNotModified() handling since
that's is already handled by ResourceLoader::respond() meanwhile.
== Misc ==
* Remove redundant modifiedTime cache in ResourceLoaderFileModule.
* Change bugzilla references to Phabricator.
* Centralised inclusion of wgCacheEpoch using getDefinitionSummary. Previously this
logic was duplicated in each place the modified timestamp was used.
* It's easy to forget calling the parent class in getDefinitionSummary().
Previously this method only tracked 'class' by default. As such, various
extensions hardcoded that one value instead of calling the parent and extending
the array. To better prevent this in the future, getVersionHash() now asserts
that the '_cacheEpoch' property made it through.
* tests: Don't use getDefinitionSummary() as an API.
Fix ResourceLoaderWikiModuleTest to call getPages properly.
* In tests, the default timestamp used to be 1388534400000 (which is the unix time
of 20140101000000; the unit tests' CacheEpoch). The new version hash of these
modules is "XyCC+PSK", which is the base64 encoded prefix of the SHA1 digest of:
'{"_class":"ResourceLoaderTestModule","_cacheEpoch":"20140101000000"}'
* Add sha1.js library for client-side hash generation.
Compared various different implementations for code size (after minfication/gzip),
and speed (when used for short hexidecimal strings).
https://jsperf.com/sha1-implementations
- CryptoJS <https://code.google.com/p/crypto-js/#SHA-1> (min+gzip: 2.5k)
http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/sha1.js
Chrome: 45k, Firefox: 89k, Safari: 92k
- jsSHA <https://github.com/Caligatio/jsSHA>
https://github.com/Caligatio/jsSHA/blob/3c1d4f2e/src/sha1.js (min+gzip: 1.8k)
Chrome: 65k, Firefox: 53k, Safari: 69k
- phpjs-sha1 <https://github.com/kvz/phpjs> (RL min+gzip: 0.8k)
https://github.com/kvz/phpjs/blob/1eaab15d/functions/strings/sha1.js
Chrome: 200k, Firefox: 280k, Safari: 78k
Modern browsers implement the HTML5 Crypto API. However, this API is asynchronous,
only enabled when on HTTPS in Chromium, and is quite low-level. It requires boilerplate
code to actually use with TextEncoder, ArrayBuffer and Uint32Array. Due this being
needed in the module loader, we'd have to load the fallback regardless. Considering
this is not used in a critical path for performance, it's not worth shipping two
implementations for this optimisation.
May also resolve:
* T44094
* T90411
* T94810
Bug: T94074
Change-Id: Ibb292d2416839327d1807a66c78fd96dac0637d0
2015-04-29 22:53:24 +00:00
|
|
|
$options[$member] = $this->{$member};
|
2019-06-12 13:35:59 +00:00
|
|
|
}
|
resourceloader: Replace timestamp system with version hashing
Modules now track their version via getVersionHash() instead of getModifiedTime().
== Background ==
While some resources have observeable timestamps (e.g. files stored on disk),
many other resources do not. E.g. config variables, and module definitions.
For static file modules, one can e.g. revert one of more files in a module to a
previous version and not affect the max timestamp.
Wiki modules include pages only if they exist. The user module supports common.js
and skin.js. By default neither exists. If a user has both, and then the
less-recently modified one is deleted, the max-timestamp remains unchanged.
For client-side caching, batch requests use "Math.max" on the relevant timestamps.
Again, if a module changes but another module is more recent (e.g. out-of-order
deployment, or out-of-order discovery), the change would not result in a cache miss.
More scenarios can be found in the associated Phabricator tasks.
== Version hash ==
Previously we virtually mapped these variables to a timestamp by storing the current
time alongside a hash of the value in ObjectCache. Considering the number of
possible request contexts (wikis * modules * users * skins * languages) this doesn't
work well. It results in needless cache invalidation when the first time observation
is purged due to LRU algorithms. It also has other minor bugs leading to fewer
cache hits.
All modules automatically get the benefits of version hashing with this change.
The old getDefinitionMtime() and getHashMtime() have been replaced with dummies
that return 1. These functions are often called from getModifiedTime() in subclasses.
For backward-compatibility, their respective values (definition summary and hash)
are now included in getVersionHash directly.
As examples, the following modules have been updated to use getVersionHash directly.
Other modules still work fine and can be updated later.
* ResourceLoaderFileModule
* ResourceLoaderEditToolbarModule
* ResourceLoaderStartUpModule
* ResourceLoaderWikiModule
The presence of hashes in place of timestamps increases the startup module size on
a default MediaWiki install from 4.4k to 5.8k (after gzip and minification).
== ETag ==
Since timestamps are no longer tracked, we need a different way to implement caching
for cache proxies (e.g. Varnish) and web browsers. Previously we used the
Last-Modified header (in combination with Cache-Control and Expires).
Instead of Last-Modified (and If-Modified-Since), we use ETag (and If-None-Match).
Entity tags (new in HTTP/1.1) are much stricter than Last-Modified by default.
They instruct browsers to allow usage of partial Range requests. Since our responses
are dynamically generated, we need to use the Weak version of ETag.
While this sounds bad, it's no different than Last-Modified. As reassured by
RFC 2616 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3> the
specified behaviour behind Last-Modified follows the same "Weak" caching logic as
Entity tags. It's just that entity tags are capable of a stricter mode (whereas
Last-Modified is inherently weak).
== File cache ==
If $wgUseFileCache is enabled, ResourceLoader uses ResourceFileCache to cache
load.php responses. While the blind TTL handling (during the allowed expiry period)
is still maxage/timestamp based, tryRespondNotModified() now requires the caller to
know the expected ETag.
For this to work, the FileCache handling had to be moved from the top of
ResoureLoader::respond() to after the expected ETag is computed.
This also allows us to remove the duplicate tryRespondNotModified() handling since
that's is already handled by ResourceLoader::respond() meanwhile.
== Misc ==
* Remove redundant modifiedTime cache in ResourceLoaderFileModule.
* Change bugzilla references to Phabricator.
* Centralised inclusion of wgCacheEpoch using getDefinitionSummary. Previously this
logic was duplicated in each place the modified timestamp was used.
* It's easy to forget calling the parent class in getDefinitionSummary().
Previously this method only tracked 'class' by default. As such, various
extensions hardcoded that one value instead of calling the parent and extending
the array. To better prevent this in the future, getVersionHash() now asserts
that the '_cacheEpoch' property made it through.
* tests: Don't use getDefinitionSummary() as an API.
Fix ResourceLoaderWikiModuleTest to call getPages properly.
* In tests, the default timestamp used to be 1388534400000 (which is the unix time
of 20140101000000; the unit tests' CacheEpoch). The new version hash of these
modules is "XyCC+PSK", which is the base64 encoded prefix of the SHA1 digest of:
'{"_class":"ResourceLoaderTestModule","_cacheEpoch":"20140101000000"}'
* Add sha1.js library for client-side hash generation.
Compared various different implementations for code size (after minfication/gzip),
and speed (when used for short hexidecimal strings).
https://jsperf.com/sha1-implementations
- CryptoJS <https://code.google.com/p/crypto-js/#SHA-1> (min+gzip: 2.5k)
http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/sha1.js
Chrome: 45k, Firefox: 89k, Safari: 92k
- jsSHA <https://github.com/Caligatio/jsSHA>
https://github.com/Caligatio/jsSHA/blob/3c1d4f2e/src/sha1.js (min+gzip: 1.8k)
Chrome: 65k, Firefox: 53k, Safari: 69k
- phpjs-sha1 <https://github.com/kvz/phpjs> (RL min+gzip: 0.8k)
https://github.com/kvz/phpjs/blob/1eaab15d/functions/strings/sha1.js
Chrome: 200k, Firefox: 280k, Safari: 78k
Modern browsers implement the HTML5 Crypto API. However, this API is asynchronous,
only enabled when on HTTPS in Chromium, and is quite low-level. It requires boilerplate
code to actually use with TextEncoder, ArrayBuffer and Uint32Array. Due this being
needed in the module loader, we'd have to load the fallback regardless. Considering
this is not used in a critical path for performance, it's not worth shipping two
implementations for this optimisation.
May also resolve:
* T44094
* T90411
* T94810
Bug: T94074
Change-Id: Ibb292d2416839327d1807a66c78fd96dac0637d0
2015-04-29 22:53:24 +00:00
|
|
|
|
2019-06-12 00:57:17 +00:00
|
|
|
$packageFiles = $this->expandPackageFiles( $context );
|
|
|
|
|
if ( $packageFiles ) {
|
|
|
|
|
// Extract the minimum needed:
|
|
|
|
|
// - The 'main' pointer (included as-is).
|
|
|
|
|
// - The 'files' array, simplied to only which files exist (the keys of
|
|
|
|
|
// this array), and something that represents their non-file content.
|
|
|
|
|
// For packaged files that reflect files directly from disk, the
|
|
|
|
|
// 'getFileHashes' method tracks this already.
|
|
|
|
|
// It is important that the keys of the 'files' array are preserved,
|
|
|
|
|
// as they affect the module output.
|
|
|
|
|
$packageFiles['files'] = array_map( function ( $fileInfo ) {
|
|
|
|
|
return $fileInfo['definitionSummary'] ?? ( $fileInfo['content'] ?? null );
|
|
|
|
|
}, $packageFiles['files'] );
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-17 09:09:32 +00:00
|
|
|
$summary[] = [
|
resourceloader: Replace timestamp system with version hashing
Modules now track their version via getVersionHash() instead of getModifiedTime().
== Background ==
While some resources have observeable timestamps (e.g. files stored on disk),
many other resources do not. E.g. config variables, and module definitions.
For static file modules, one can e.g. revert one of more files in a module to a
previous version and not affect the max timestamp.
Wiki modules include pages only if they exist. The user module supports common.js
and skin.js. By default neither exists. If a user has both, and then the
less-recently modified one is deleted, the max-timestamp remains unchanged.
For client-side caching, batch requests use "Math.max" on the relevant timestamps.
Again, if a module changes but another module is more recent (e.g. out-of-order
deployment, or out-of-order discovery), the change would not result in a cache miss.
More scenarios can be found in the associated Phabricator tasks.
== Version hash ==
Previously we virtually mapped these variables to a timestamp by storing the current
time alongside a hash of the value in ObjectCache. Considering the number of
possible request contexts (wikis * modules * users * skins * languages) this doesn't
work well. It results in needless cache invalidation when the first time observation
is purged due to LRU algorithms. It also has other minor bugs leading to fewer
cache hits.
All modules automatically get the benefits of version hashing with this change.
The old getDefinitionMtime() and getHashMtime() have been replaced with dummies
that return 1. These functions are often called from getModifiedTime() in subclasses.
For backward-compatibility, their respective values (definition summary and hash)
are now included in getVersionHash directly.
As examples, the following modules have been updated to use getVersionHash directly.
Other modules still work fine and can be updated later.
* ResourceLoaderFileModule
* ResourceLoaderEditToolbarModule
* ResourceLoaderStartUpModule
* ResourceLoaderWikiModule
The presence of hashes in place of timestamps increases the startup module size on
a default MediaWiki install from 4.4k to 5.8k (after gzip and minification).
== ETag ==
Since timestamps are no longer tracked, we need a different way to implement caching
for cache proxies (e.g. Varnish) and web browsers. Previously we used the
Last-Modified header (in combination with Cache-Control and Expires).
Instead of Last-Modified (and If-Modified-Since), we use ETag (and If-None-Match).
Entity tags (new in HTTP/1.1) are much stricter than Last-Modified by default.
They instruct browsers to allow usage of partial Range requests. Since our responses
are dynamically generated, we need to use the Weak version of ETag.
While this sounds bad, it's no different than Last-Modified. As reassured by
RFC 2616 <http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3> the
specified behaviour behind Last-Modified follows the same "Weak" caching logic as
Entity tags. It's just that entity tags are capable of a stricter mode (whereas
Last-Modified is inherently weak).
== File cache ==
If $wgUseFileCache is enabled, ResourceLoader uses ResourceFileCache to cache
load.php responses. While the blind TTL handling (during the allowed expiry period)
is still maxage/timestamp based, tryRespondNotModified() now requires the caller to
know the expected ETag.
For this to work, the FileCache handling had to be moved from the top of
ResoureLoader::respond() to after the expected ETag is computed.
This also allows us to remove the duplicate tryRespondNotModified() handling since
that's is already handled by ResourceLoader::respond() meanwhile.
== Misc ==
* Remove redundant modifiedTime cache in ResourceLoaderFileModule.
* Change bugzilla references to Phabricator.
* Centralised inclusion of wgCacheEpoch using getDefinitionSummary. Previously this
logic was duplicated in each place the modified timestamp was used.
* It's easy to forget calling the parent class in getDefinitionSummary().
Previously this method only tracked 'class' by default. As such, various
extensions hardcoded that one value instead of calling the parent and extending
the array. To better prevent this in the future, getVersionHash() now asserts
that the '_cacheEpoch' property made it through.
* tests: Don't use getDefinitionSummary() as an API.
Fix ResourceLoaderWikiModuleTest to call getPages properly.
* In tests, the default timestamp used to be 1388534400000 (which is the unix time
of 20140101000000; the unit tests' CacheEpoch). The new version hash of these
modules is "XyCC+PSK", which is the base64 encoded prefix of the SHA1 digest of:
'{"_class":"ResourceLoaderTestModule","_cacheEpoch":"20140101000000"}'
* Add sha1.js library for client-side hash generation.
Compared various different implementations for code size (after minfication/gzip),
and speed (when used for short hexidecimal strings).
https://jsperf.com/sha1-implementations
- CryptoJS <https://code.google.com/p/crypto-js/#SHA-1> (min+gzip: 2.5k)
http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/sha1.js
Chrome: 45k, Firefox: 89k, Safari: 92k
- jsSHA <https://github.com/Caligatio/jsSHA>
https://github.com/Caligatio/jsSHA/blob/3c1d4f2e/src/sha1.js (min+gzip: 1.8k)
Chrome: 65k, Firefox: 53k, Safari: 69k
- phpjs-sha1 <https://github.com/kvz/phpjs> (RL min+gzip: 0.8k)
https://github.com/kvz/phpjs/blob/1eaab15d/functions/strings/sha1.js
Chrome: 200k, Firefox: 280k, Safari: 78k
Modern browsers implement the HTML5 Crypto API. However, this API is asynchronous,
only enabled when on HTTPS in Chromium, and is quite low-level. It requires boilerplate
code to actually use with TextEncoder, ArrayBuffer and Uint32Array. Due this being
needed in the module loader, we'd have to load the fallback regardless. Considering
this is not used in a critical path for performance, it's not worth shipping two
implementations for this optimisation.
May also resolve:
* T44094
* T90411
* T94810
Bug: T94074
Change-Id: Ibb292d2416839327d1807a66c78fd96dac0637d0
2015-04-29 22:53:24 +00:00
|
|
|
'options' => $options,
|
2019-06-12 00:57:17 +00:00
|
|
|
'packageFiles' => $packageFiles,
|
2015-07-09 18:30:53 +00:00
|
|
|
'fileHashes' => $this->getFileHashes( $context ),
|
2015-11-13 00:04:12 +00:00
|
|
|
'messageBlob' => $this->getMessageBlob( $context ),
|
2016-02-17 09:09:32 +00:00
|
|
|
];
|
2017-07-27 01:53:37 +00:00
|
|
|
|
|
|
|
|
$lessVars = $this->getLessVars( $context );
|
|
|
|
|
if ( $lessVars ) {
|
|
|
|
|
$summary[] = [ 'lessVars' => $lessVars ];
|
|
|
|
|
}
|
|
|
|
|
|
2013-10-18 13:34:50 +00:00
|
|
|
return $summary;
|
|
|
|
|
}
|
|
|
|
|
|
2011-05-21 17:45:20 +00:00
|
|
|
/**
|
2014-06-26 14:29:31 +00:00
|
|
|
* @param string|ResourceLoaderFilePath $path
|
2011-05-21 17:45:20 +00:00
|
|
|
* @return string
|
|
|
|
|
*/
|
2010-10-27 22:22:10 +00:00
|
|
|
protected function getLocalPath( $path ) {
|
2014-06-26 14:29:31 +00:00
|
|
|
if ( $path instanceof ResourceLoaderFilePath ) {
|
|
|
|
|
return $path->getLocalPath();
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-27 22:22:10 +00:00
|
|
|
return "{$this->localBasePath}/$path";
|
|
|
|
|
}
|
2011-05-21 17:45:20 +00:00
|
|
|
|
|
|
|
|
/**
|
2014-06-26 14:29:31 +00:00
|
|
|
* @param string|ResourceLoaderFilePath $path
|
2011-05-21 17:45:20 +00:00
|
|
|
* @return string
|
|
|
|
|
*/
|
2010-10-27 22:22:10 +00:00
|
|
|
protected function getRemotePath( $path ) {
|
2014-06-26 14:29:31 +00:00
|
|
|
if ( $path instanceof ResourceLoaderFilePath ) {
|
|
|
|
|
return $path->getRemotePath();
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-27 22:22:10 +00:00
|
|
|
return "{$this->remoteBasePath}/$path";
|
2010-10-19 20:59:23 +00:00
|
|
|
}
|
|
|
|
|
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
/**
|
|
|
|
|
* Infer the stylesheet language from a stylesheet file path.
|
|
|
|
|
*
|
2013-09-27 09:32:41 +00:00
|
|
|
* @since 1.22
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
* @param string $path
|
2014-04-20 21:33:05 +00:00
|
|
|
* @return string The stylesheet language name
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
*/
|
2013-09-28 07:40:03 +00:00
|
|
|
public function getStyleSheetLang( $path ) {
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
return preg_match( '/\.less$/i', $path ) ? 'less' : 'css';
|
|
|
|
|
}
|
|
|
|
|
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
/**
|
|
|
|
|
* Infer the file type from a package file path.
|
|
|
|
|
* @param string $path
|
|
|
|
|
* @return string 'script' or 'data'
|
|
|
|
|
*/
|
|
|
|
|
public static function getPackageFileType( $path ) {
|
|
|
|
|
if ( preg_match( '/\.json$/i', $path ) ) {
|
|
|
|
|
return 'data';
|
|
|
|
|
}
|
|
|
|
|
return 'script';
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-19 20:59:23 +00:00
|
|
|
/**
|
2010-10-20 00:22:25 +00:00
|
|
|
* Collates file paths by option (where provided).
|
2011-06-17 16:05:05 +00:00
|
|
|
*
|
2013-03-11 17:15:01 +00:00
|
|
|
* @param array $list List of file paths in any combination of index/path
|
2010-11-05 06:53:14 +00:00
|
|
|
* or path/options pairs
|
2014-04-20 21:33:05 +00:00
|
|
|
* @param string $option Option name
|
|
|
|
|
* @param mixed $default Default value if the option isn't set
|
|
|
|
|
* @return array List of file paths, collated by $option
|
2010-10-19 20:59:23 +00:00
|
|
|
*/
|
|
|
|
|
protected static function collateFilePathListByOption( array $list, $option, $default ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
$collatedFiles = [];
|
2013-04-02 20:28:40 +00:00
|
|
|
foreach ( (array)$list as $key => $value ) {
|
2010-10-19 20:59:23 +00:00
|
|
|
if ( is_int( $key ) ) {
|
|
|
|
|
// File name as the value
|
|
|
|
|
if ( !isset( $collatedFiles[$default] ) ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
$collatedFiles[$default] = [];
|
2010-10-19 20:59:23 +00:00
|
|
|
}
|
|
|
|
|
$collatedFiles[$default][] = $value;
|
2011-06-17 16:05:05 +00:00
|
|
|
} elseif ( is_array( $value ) ) {
|
2010-10-19 20:59:23 +00:00
|
|
|
// File name as the key, options array as the value
|
2017-10-06 22:17:58 +00:00
|
|
|
$optionValue = $value[$option] ?? $default;
|
2010-10-20 20:43:30 +00:00
|
|
|
if ( !isset( $collatedFiles[$optionValue] ) ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
$collatedFiles[$optionValue] = [];
|
2010-10-19 20:59:23 +00:00
|
|
|
}
|
2010-10-20 20:43:30 +00:00
|
|
|
$collatedFiles[$optionValue][] = $key;
|
2010-10-19 20:59:23 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return $collatedFiles;
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-19 18:25:42 +00:00
|
|
|
/**
|
2014-06-04 19:30:14 +00:00
|
|
|
* Get a list of element that match a key, optionally using a fallback key.
|
2011-06-17 16:05:05 +00:00
|
|
|
*
|
2013-03-11 17:15:01 +00:00
|
|
|
* @param array $list List of lists to select from
|
|
|
|
|
* @param string $key Key to look for in $map
|
2018-06-26 21:14:43 +00:00
|
|
|
* @param string|null $fallback Key to look for in $list if $key doesn't exist
|
2014-04-20 21:33:05 +00:00
|
|
|
* @return array List of elements from $map which matched $key or $fallback,
|
2014-06-04 19:30:14 +00:00
|
|
|
* or an empty list in case of no match
|
2010-10-19 18:25:42 +00:00
|
|
|
*/
|
2010-10-20 20:56:33 +00:00
|
|
|
protected static function tryForKey( array $list, $key, $fallback = null ) {
|
2010-10-19 22:48:52 +00:00
|
|
|
if ( isset( $list[$key] ) && is_array( $list[$key] ) ) {
|
2010-10-20 20:56:33 +00:00
|
|
|
return $list[$key];
|
2011-06-17 16:05:05 +00:00
|
|
|
} elseif ( is_string( $fallback )
|
|
|
|
|
&& isset( $list[$fallback] )
|
2013-12-01 20:39:00 +00:00
|
|
|
&& is_array( $list[$fallback] )
|
|
|
|
|
) {
|
2010-10-20 20:56:33 +00:00
|
|
|
return $list[$fallback];
|
2010-10-19 22:48:52 +00:00
|
|
|
}
|
2016-02-17 09:09:32 +00:00
|
|
|
return [];
|
2010-10-19 18:25:42 +00:00
|
|
|
}
|
|
|
|
|
|
2011-05-14 12:15:58 +00:00
|
|
|
/**
|
2018-06-26 01:52:40 +00:00
|
|
|
* Get a list of script file paths for this module, in order of proper execution.
|
2011-06-17 16:05:05 +00:00
|
|
|
*
|
2013-09-13 04:50:45 +00:00
|
|
|
* @param ResourceLoaderContext $context
|
2014-04-20 21:33:05 +00:00
|
|
|
* @return array List of file paths
|
2011-05-14 12:15:58 +00:00
|
|
|
*/
|
2018-06-26 01:52:40 +00:00
|
|
|
private function getScriptFiles( ResourceLoaderContext $context ) {
|
2011-05-14 12:15:58 +00:00
|
|
|
$files = array_merge(
|
|
|
|
|
$this->scripts,
|
2014-08-29 17:13:21 +00:00
|
|
|
$this->getLanguageScripts( $context->getLanguage() ),
|
2011-05-14 12:15:58 +00:00
|
|
|
self::tryForKey( $this->skinScripts, $context->getSkin(), 'default' )
|
|
|
|
|
);
|
|
|
|
|
if ( $context->getDebug() ) {
|
|
|
|
|
$files = array_merge( $files, $this->debugScripts );
|
|
|
|
|
}
|
2012-10-21 21:06:00 +00:00
|
|
|
|
2014-06-26 14:29:31 +00:00
|
|
|
return array_unique( $files, SORT_REGULAR );
|
2011-05-14 12:15:58 +00:00
|
|
|
}
|
|
|
|
|
|
2014-08-29 17:13:21 +00:00
|
|
|
/**
|
|
|
|
|
* Get the set of language scripts for the given language,
|
|
|
|
|
* possibly using a fallback language.
|
|
|
|
|
*
|
|
|
|
|
* @param string $lang
|
|
|
|
|
* @return array
|
|
|
|
|
*/
|
|
|
|
|
private function getLanguageScripts( $lang ) {
|
|
|
|
|
$scripts = self::tryForKey( $this->languageScripts, $lang );
|
|
|
|
|
if ( $scripts ) {
|
|
|
|
|
return $scripts;
|
|
|
|
|
}
|
|
|
|
|
$fallbacks = Language::getFallbacksFor( $lang );
|
|
|
|
|
foreach ( $fallbacks as $lang ) {
|
|
|
|
|
$scripts = self::tryForKey( $this->languageScripts, $lang );
|
|
|
|
|
if ( $scripts ) {
|
|
|
|
|
return $scripts;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-17 09:09:32 +00:00
|
|
|
return [];
|
2014-08-29 17:13:21 +00:00
|
|
|
}
|
|
|
|
|
|
2011-05-14 12:15:58 +00:00
|
|
|
/**
|
2014-06-04 19:30:14 +00:00
|
|
|
* Get a list of file paths for all styles in this module, in order of proper inclusion.
|
2011-06-17 16:05:05 +00:00
|
|
|
*
|
2018-06-26 01:52:40 +00:00
|
|
|
* This is considered a private method. Exposed for internal use by WebInstallerOutput.
|
|
|
|
|
*
|
|
|
|
|
* @private
|
2013-09-13 04:50:45 +00:00
|
|
|
* @param ResourceLoaderContext $context
|
2014-04-20 21:33:05 +00:00
|
|
|
* @return array List of file paths
|
2011-05-14 12:15:58 +00:00
|
|
|
*/
|
2014-06-04 19:30:14 +00:00
|
|
|
public function getStyleFiles( ResourceLoaderContext $context ) {
|
2011-05-14 12:15:58 +00:00
|
|
|
return array_merge_recursive(
|
|
|
|
|
self::collateFilePathListByOption( $this->styles, 'media', 'all' ),
|
|
|
|
|
self::collateFilePathListByOption(
|
2014-02-28 19:23:11 +00:00
|
|
|
self::tryForKey( $this->skinStyles, $context->getSkin(), 'default' ),
|
|
|
|
|
'media',
|
|
|
|
|
'all'
|
2011-05-14 12:15:58 +00:00
|
|
|
)
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
2013-09-28 07:40:03 +00:00
|
|
|
/**
|
2014-04-01 14:28:46 +00:00
|
|
|
* Gets a list of file paths for all skin styles in the module used by
|
|
|
|
|
* the skin.
|
|
|
|
|
*
|
|
|
|
|
* @param string $skinName The name of the skin
|
|
|
|
|
* @return array A list of file paths collated by media type
|
|
|
|
|
*/
|
|
|
|
|
protected function getSkinStyleFiles( $skinName ) {
|
|
|
|
|
return self::collateFilePathListByOption(
|
|
|
|
|
self::tryForKey( $this->skinStyles, $skinName ),
|
|
|
|
|
'media',
|
|
|
|
|
'all'
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Gets a list of file paths for all skin style files in the module,
|
|
|
|
|
* for all available skins.
|
|
|
|
|
*
|
|
|
|
|
* @return array A list of file paths collated by media type
|
|
|
|
|
*/
|
|
|
|
|
protected function getAllSkinStyleFiles() {
|
2016-02-17 09:09:32 +00:00
|
|
|
$styleFiles = [];
|
2014-04-01 14:28:46 +00:00
|
|
|
$internalSkinNames = array_keys( Skin::getSkinNames() );
|
|
|
|
|
$internalSkinNames[] = 'default';
|
|
|
|
|
|
|
|
|
|
foreach ( $internalSkinNames as $internalSkinName ) {
|
|
|
|
|
$styleFiles = array_merge_recursive(
|
|
|
|
|
$styleFiles,
|
|
|
|
|
$this->getSkinStyleFiles( $internalSkinName )
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $styleFiles;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Returns all style files and all skin style files used by this module.
|
|
|
|
|
*
|
2013-09-28 07:40:03 +00:00
|
|
|
* @return array
|
|
|
|
|
*/
|
|
|
|
|
public function getAllStyleFiles() {
|
2014-04-01 14:28:46 +00:00
|
|
|
$collatedStyleFiles = array_merge_recursive(
|
|
|
|
|
self::collateFilePathListByOption( $this->styles, 'media', 'all' ),
|
|
|
|
|
$this->getAllSkinStyleFiles()
|
|
|
|
|
);
|
|
|
|
|
|
2016-02-17 09:09:32 +00:00
|
|
|
$result = [];
|
2014-04-01 14:28:46 +00:00
|
|
|
|
|
|
|
|
foreach ( $collatedStyleFiles as $media => $styleFiles ) {
|
|
|
|
|
foreach ( $styleFiles as $styleFile ) {
|
|
|
|
|
$result[] = $this->getLocalPath( $styleFile );
|
2013-09-28 07:40:03 +00:00
|
|
|
}
|
|
|
|
|
}
|
2014-04-01 14:28:46 +00:00
|
|
|
|
|
|
|
|
return $result;
|
2013-09-28 07:40:03 +00:00
|
|
|
}
|
|
|
|
|
|
2010-10-19 18:25:42 +00:00
|
|
|
/**
|
2018-06-26 01:52:40 +00:00
|
|
|
* Get the contents of a list of JavaScript files. Helper for getScript().
|
2011-06-17 16:05:05 +00:00
|
|
|
*
|
2013-03-11 17:15:01 +00:00
|
|
|
* @param array $scripts List of file paths to scripts to read, remap and concetenate
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
* @return string Concatenated JavaScript data from $scripts
|
2018-06-26 01:52:40 +00:00
|
|
|
* @throws MWException
|
2010-10-19 18:25:42 +00:00
|
|
|
*/
|
2018-06-26 01:52:40 +00:00
|
|
|
private function readScriptFiles( array $scripts ) {
|
2010-10-19 22:48:52 +00:00
|
|
|
if ( empty( $scripts ) ) {
|
2010-10-19 18:25:42 +00:00
|
|
|
return '';
|
|
|
|
|
}
|
2010-11-05 06:53:14 +00:00
|
|
|
$js = '';
|
2014-06-26 14:29:31 +00:00
|
|
|
foreach ( array_unique( $scripts, SORT_REGULAR ) as $fileName ) {
|
2010-11-05 06:53:14 +00:00
|
|
|
$localPath = $this->getLocalPath( $fileName );
|
2011-08-13 21:25:02 +00:00
|
|
|
if ( !file_exists( $localPath ) ) {
|
2013-02-03 18:30:03 +00:00
|
|
|
throw new MWException( __METHOD__ . ": script file not found: \"$localPath\"" );
|
2010-11-05 06:53:14 +00:00
|
|
|
}
|
2016-05-11 11:53:59 +00:00
|
|
|
$contents = $this->stripBom( file_get_contents( $localPath ) );
|
2010-11-05 06:53:14 +00:00
|
|
|
$js .= $contents . "\n";
|
|
|
|
|
}
|
|
|
|
|
return $js;
|
2010-10-19 18:25:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2018-06-26 01:52:40 +00:00
|
|
|
* Get the contents of a list of CSS files.
|
|
|
|
|
*
|
2019-02-16 23:30:46 +00:00
|
|
|
* @internal This is considered a private method. Exposed for internal use by WebInstallerOutput.
|
2018-06-26 01:52:40 +00:00
|
|
|
* @param array $styles Map of media type to file paths to read, remap, and concatenate
|
2013-09-13 04:50:45 +00:00
|
|
|
* @param bool $flip
|
2019-02-16 23:30:46 +00:00
|
|
|
* @param ResourceLoaderContext $context
|
2014-04-20 21:33:05 +00:00
|
|
|
* @return array List of concatenated and remapped CSS data from $styles,
|
2010-11-05 06:53:14 +00:00
|
|
|
* keyed by media type
|
2018-06-26 01:52:40 +00:00
|
|
|
* @throws MWException
|
2010-10-19 18:25:42 +00:00
|
|
|
*/
|
2019-02-16 23:30:46 +00:00
|
|
|
public function readStyleFiles( array $styles, $flip, $context ) {
|
|
|
|
|
if ( !$styles ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
return [];
|
2010-10-19 18:25:42 +00:00
|
|
|
}
|
|
|
|
|
foreach ( $styles as $media => $files ) {
|
2014-06-26 14:29:31 +00:00
|
|
|
$uniqueFiles = array_unique( $files, SORT_REGULAR );
|
2016-02-17 09:09:32 +00:00
|
|
|
$styleFiles = [];
|
2014-01-30 18:39:51 +00:00
|
|
|
foreach ( $uniqueFiles as $file ) {
|
2014-08-20 13:13:43 +00:00
|
|
|
$styleFiles[] = $this->readStyleFile( $file, $flip, $context );
|
2014-01-30 18:39:51 +00:00
|
|
|
}
|
|
|
|
|
$styles[$media] = implode( "\n", $styleFiles );
|
2010-10-19 18:25:42 +00:00
|
|
|
}
|
|
|
|
|
return $styles;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2010-10-20 00:22:25 +00:00
|
|
|
* Reads a style file.
|
2011-06-17 16:05:05 +00:00
|
|
|
*
|
2010-10-19 22:48:52 +00:00
|
|
|
* This method can be used as a callback for array_map()
|
2011-06-17 16:05:05 +00:00
|
|
|
*
|
2013-03-11 17:15:01 +00:00
|
|
|
* @param string $path File path of style file to read
|
2013-09-13 04:50:45 +00:00
|
|
|
* @param bool $flip
|
2015-09-25 17:57:35 +00:00
|
|
|
* @param ResourceLoaderContext $context
|
2011-05-21 17:45:20 +00:00
|
|
|
*
|
2014-04-20 21:33:05 +00:00
|
|
|
* @return string CSS data in script file
|
2014-07-24 17:43:25 +00:00
|
|
|
* @throws MWException If the file doesn't exist
|
2010-10-19 18:25:42 +00:00
|
|
|
*/
|
2015-09-25 17:57:35 +00:00
|
|
|
protected function readStyleFile( $path, $flip, $context ) {
|
2010-11-05 06:53:14 +00:00
|
|
|
$localPath = $this->getLocalPath( $path );
|
2014-06-26 14:29:31 +00:00
|
|
|
$remotePath = $this->getRemotePath( $path );
|
2011-08-13 21:25:02 +00:00
|
|
|
if ( !file_exists( $localPath ) ) {
|
2013-02-03 18:30:03 +00:00
|
|
|
$msg = __METHOD__ . ": style file not found: \"$localPath\"";
|
2012-10-15 20:32:20 +00:00
|
|
|
wfDebugLog( 'resourceloader', $msg );
|
2012-10-15 17:12:10 +00:00
|
|
|
throw new MWException( $msg );
|
2010-11-05 06:53:14 +00:00
|
|
|
}
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
|
2014-06-26 14:29:31 +00:00
|
|
|
if ( $this->getStyleSheetLang( $localPath ) === 'less' ) {
|
2015-09-25 17:57:35 +00:00
|
|
|
$style = $this->compileLessFile( $localPath, $context );
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
$this->hasGeneratedStyles = true;
|
|
|
|
|
} else {
|
2016-05-11 11:53:59 +00:00
|
|
|
$style = $this->stripBom( file_get_contents( $localPath ) );
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
}
|
|
|
|
|
|
2010-12-16 19:31:48 +00:00
|
|
|
if ( $flip ) {
|
|
|
|
|
$style = CSSJanus::transform( $style, true, false );
|
|
|
|
|
}
|
2014-06-26 14:29:31 +00:00
|
|
|
$localDir = dirname( $localPath );
|
|
|
|
|
$remoteDir = dirname( $remotePath );
|
2010-10-27 19:59:10 +00:00
|
|
|
// Get and register local file references
|
2016-03-03 00:16:13 +00:00
|
|
|
$localFileRefs = CSSMin::getLocalFileReferences( $style, $localDir );
|
2015-09-03 21:30:36 +00:00
|
|
|
foreach ( $localFileRefs as $file ) {
|
|
|
|
|
if ( file_exists( $file ) ) {
|
|
|
|
|
$this->localFileRefs[] = $file;
|
|
|
|
|
} else {
|
|
|
|
|
$this->missingLocalFileRefs[] = $file;
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-03-02 23:55:28 +00:00
|
|
|
// Don't cache this call. remap() ensures data URIs embeds are up to date,
|
|
|
|
|
// and urls contain correct content hashes in their query string. (T128668)
|
|
|
|
|
return CSSMin::remap( $style, $localDir, $remoteDir, true );
|
2010-10-19 18:25:42 +00:00
|
|
|
}
|
2011-10-14 08:06:54 +00:00
|
|
|
|
2011-03-25 11:15:40 +00:00
|
|
|
/**
|
|
|
|
|
* Get whether CSS for this module should be flipped
|
2013-09-13 04:50:45 +00:00
|
|
|
* @param ResourceLoaderContext $context
|
2011-03-25 11:15:40 +00:00
|
|
|
* @return bool
|
|
|
|
|
*/
|
|
|
|
|
public function getFlip( $context ) {
|
2016-10-18 19:04:40 +00:00
|
|
|
return $context->getDirection() === 'rtl' && !$this->noflip;
|
2011-03-25 11:15:40 +00:00
|
|
|
}
|
2012-10-11 22:37:59 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Get target(s) for the module, eg ['desktop'] or ['desktop', 'mobile']
|
|
|
|
|
*
|
2014-04-20 21:33:05 +00:00
|
|
|
* @return array Array of strings
|
2012-10-11 22:37:59 +00:00
|
|
|
*/
|
|
|
|
|
public function getTargets() {
|
|
|
|
|
return $this->targets;
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-10 19:00:44 +00:00
|
|
|
/**
|
|
|
|
|
* Get the module's load type.
|
|
|
|
|
*
|
|
|
|
|
* @since 1.28
|
|
|
|
|
* @return string
|
|
|
|
|
*/
|
|
|
|
|
public function getType() {
|
|
|
|
|
$canBeStylesOnly = !(
|
|
|
|
|
// All options except 'styles', 'skinStyles' and 'debugRaw'
|
|
|
|
|
$this->scripts
|
|
|
|
|
|| $this->debugScripts
|
|
|
|
|
|| $this->templates
|
|
|
|
|
|| $this->languageScripts
|
|
|
|
|
|| $this->skinScripts
|
|
|
|
|
|| $this->dependencies
|
|
|
|
|
|| $this->messages
|
|
|
|
|
|| $this->skipFunction
|
|
|
|
|
);
|
|
|
|
|
return $canBeStylesOnly ? self::LOAD_STYLES : self::LOAD_GENERAL;
|
|
|
|
|
}
|
|
|
|
|
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
/**
|
|
|
|
|
* Compile a LESS file into CSS.
|
|
|
|
|
*
|
2014-08-20 18:26:46 +00:00
|
|
|
* Keeps track of all used files and adds them to localFileRefs.
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
*
|
2013-09-27 09:32:41 +00:00
|
|
|
* @since 1.22
|
2015-10-07 04:55:42 +00:00
|
|
|
* @since 1.27 Added $context paramter.
|
2015-09-10 22:22:13 +00:00
|
|
|
* @throws Exception If less.php encounters a parse error
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
* @param string $fileName File path of LESS source
|
2015-09-25 17:57:35 +00:00
|
|
|
* @param ResourceLoaderContext $context Context in which to generate script
|
2014-04-20 21:33:05 +00:00
|
|
|
* @return string CSS source
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
*/
|
2015-09-25 17:57:35 +00:00
|
|
|
protected function compileLessFile( $fileName, ResourceLoaderContext $context ) {
|
2015-09-23 07:47:40 +00:00
|
|
|
static $cache;
|
|
|
|
|
|
|
|
|
|
if ( !$cache ) {
|
2015-10-31 18:42:48 +00:00
|
|
|
$cache = ObjectCache::getLocalServerInstance( CACHE_ANYTHING );
|
2015-09-23 07:47:40 +00:00
|
|
|
}
|
|
|
|
|
|
2018-08-09 15:09:56 +00:00
|
|
|
$vars = $this->getLessVars( $context );
|
2018-04-10 22:35:49 +00:00
|
|
|
// Construct a cache key from the LESS file name, and a hash digest
|
2015-09-23 07:47:40 +00:00
|
|
|
// of the LESS variables used for compilation.
|
2015-09-25 17:57:35 +00:00
|
|
|
ksort( $vars );
|
|
|
|
|
$varsHash = hash( 'md4', serialize( $vars ) );
|
2015-10-19 17:00:50 +00:00
|
|
|
$cacheKey = $cache->makeGlobalKey( 'LESS', $fileName, $varsHash );
|
2015-09-23 07:47:40 +00:00
|
|
|
$cachedCompile = $cache->get( $cacheKey );
|
|
|
|
|
|
|
|
|
|
// If we got a cached value, we have to validate it by getting a
|
|
|
|
|
// checksum of all the files that were loaded by the parser and
|
|
|
|
|
// ensuring it matches the cached entry's.
|
|
|
|
|
if ( isset( $cachedCompile['hash'] ) ) {
|
|
|
|
|
$contentHash = FileContentsHasher::getFileContentsHash( $cachedCompile['files'] );
|
|
|
|
|
if ( $contentHash === $cachedCompile['hash'] ) {
|
2015-09-30 21:01:01 +00:00
|
|
|
$this->localFileRefs = array_merge( $this->localFileRefs, $cachedCompile['files'] );
|
2015-09-23 07:47:40 +00:00
|
|
|
return $cachedCompile['css'];
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-01-08 22:09:36 +00:00
|
|
|
$compiler = $context->getResourceLoader()->getLessCompiler( $vars );
|
2015-09-23 07:47:40 +00:00
|
|
|
$css = $compiler->parseFile( $fileName )->getCss();
|
|
|
|
|
$files = $compiler->AllParsedFiles();
|
|
|
|
|
$this->localFileRefs = array_merge( $this->localFileRefs, $files );
|
|
|
|
|
|
2017-07-01 00:31:56 +00:00
|
|
|
// Cache for 24 hours (86400 seconds).
|
2016-02-17 09:09:32 +00:00
|
|
|
$cache->set( $cacheKey, [
|
2015-09-23 07:47:40 +00:00
|
|
|
'css' => $css,
|
|
|
|
|
'files' => $files,
|
|
|
|
|
'hash' => FileContentsHasher::getFileContentsHash( $files ),
|
2017-07-01 00:31:56 +00:00
|
|
|
], 3600 * 24 );
|
2015-09-23 07:47:40 +00:00
|
|
|
|
|
|
|
|
return $css;
|
Support LESS stylesheets in ResourceLoader
This patch adds support for the LESS stylesheet language to ResourceLoader.
LESS is a stylesheet language that compiles into CSS. The patch includes
lessphp, a LESS compiler implemented in PHP. The rationale for choosing LESS is
explained in a MediaWiki RFC which accompanies this patch, available at
<https://www.mediawiki.org/wiki/Requests_for_comment/LESS>.
LESS support is provided for ResourceLoader file modules. It is triggered by
the presence of the '.less' extension in stylesheet filenames. LESS files are
compiled by lessc, and the resultant CSS is subjected to the standard set of
transformations (CSSJanus & CSSMin). The immediate result of LESS compilation
is encoded as an array, which includes the list of LESS files that were
compiled and their mtimes. This array is cached. Cache invalidation is
performed by comparing the cached mtimes with the mtimes of the files on disk.
If the compiler itself throws an exception, ResourceLoader constructs a
compilation result which consists of the error message encoded as a CSS
comment. Failed compilation results are cached too, but with an expiration time
of five minutes. The expiration time is required because the full list of
referenced files is not known.
Three configuration variables configure the global environment for LESS
modules: $wgResourceLoaderLESSVars, $wgResourceLoaderLESSFunctions, and
$wgResourceLoaderLESSImportPaths. $wgResourceLoaderLESSVars maps variable names
to CSS values, specified as strings. Variables declared in this array are
available in all LESS files. $wgResourceLoaderLESSFunctions is similar, except
it maps custom function names to PHP callables. These functions can be called
from within LESS to transform values. Read more about custom functions at
<http://leafo.net/lessphp/docs/#custom_functions>. Finally,
$wgResourceLoaderLESSImportPaths specifies file system paths in addition to the
current module's path where the LESS compiler should look up files referenced
in @import statements.
The issue of handling of /* @embed */ and /* @noflip */ annotations is left
unresolved. Earlier versions of this patch included an @embed analog
implemented as a LESS custom function, but there was enough ambiguity about
whether the strategy it took was optimal to merit discussing it in a separate,
follow-up patch.
Bug: 40964
Change-Id: Id052a04dd2f76a1f4aef39fbd454bd67f5fd282f
2013-08-11 16:40:20 +00:00
|
|
|
}
|
2014-08-20 13:13:43 +00:00
|
|
|
|
2014-10-10 00:07:14 +00:00
|
|
|
/**
|
|
|
|
|
* Takes named templates by the module and returns an array mapping.
|
2017-07-01 00:31:56 +00:00
|
|
|
* @return array Templates mapping template alias to content
|
2014-12-24 13:49:20 +00:00
|
|
|
* @throws MWException
|
2014-10-10 00:07:14 +00:00
|
|
|
*/
|
|
|
|
|
public function getTemplates() {
|
2016-02-17 09:09:32 +00:00
|
|
|
$templates = [];
|
2014-10-10 00:07:14 +00:00
|
|
|
|
|
|
|
|
foreach ( $this->templates as $alias => $templatePath ) {
|
|
|
|
|
// Alias is optional
|
|
|
|
|
if ( is_int( $alias ) ) {
|
|
|
|
|
$alias = $templatePath;
|
|
|
|
|
}
|
|
|
|
|
$localPath = $this->getLocalPath( $templatePath );
|
|
|
|
|
if ( file_exists( $localPath ) ) {
|
|
|
|
|
$content = file_get_contents( $localPath );
|
2016-05-11 11:53:59 +00:00
|
|
|
$templates[$alias] = $this->stripBom( $content );
|
2014-10-10 00:07:14 +00:00
|
|
|
} else {
|
|
|
|
|
$msg = __METHOD__ . ": template file not found: \"$localPath\"";
|
|
|
|
|
wfDebugLog( 'resourceloader', $msg );
|
|
|
|
|
throw new MWException( $msg );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return $templates;
|
|
|
|
|
}
|
2016-05-11 11:53:59 +00:00
|
|
|
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
/**
|
2019-06-12 00:57:17 +00:00
|
|
|
* Internal helper for use by getPackageFiles(), getFileHashes() and getDefinitionSummary().
|
|
|
|
|
*
|
|
|
|
|
* This expands the 'packageFiles' definition into something that's (almost) the right format
|
|
|
|
|
* for getPackageFiles() to return. It expands shorthands, resolves config vars, and handles
|
|
|
|
|
* summarising any non-file data for getVersionHash(). For file-based data, getFileHashes()
|
|
|
|
|
* handles it instead, which also ends up in getDefinitionSummary().
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
*
|
2019-06-12 00:57:17 +00:00
|
|
|
* What it does not do is reading the actual contents of any specified files, nor invoking
|
|
|
|
|
* the computation callbacks. Those things are done by getPackageFiles() instead to improve
|
|
|
|
|
* backend performance by only doing this work when the module response is needed, and not
|
|
|
|
|
* when merely computing the version hash for StartupModule, or when checking
|
|
|
|
|
* If-None-Match headers for a HTTP 304 response.
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
*
|
|
|
|
|
* @param ResourceLoaderContext $context
|
|
|
|
|
* @return array|null
|
2019-06-12 00:57:17 +00:00
|
|
|
* @throws MWException If the 'packageFiles' definition is invalid.
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
*/
|
|
|
|
|
private function expandPackageFiles( ResourceLoaderContext $context ) {
|
|
|
|
|
$hash = $context->getHash();
|
|
|
|
|
if ( isset( $this->expandedPackageFiles[$hash] ) ) {
|
|
|
|
|
return $this->expandedPackageFiles[$hash];
|
|
|
|
|
}
|
|
|
|
|
if ( $this->packageFiles === null ) {
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
$expandedFiles = [];
|
|
|
|
|
$mainFile = null;
|
|
|
|
|
|
|
|
|
|
foreach ( $this->packageFiles as $alias => $fileInfo ) {
|
resourceloader: Change 'packageFiles' format to be JSON-compatible
The module definition format for 'packageFiles', as initially designed,
mixes sequential and associative arrays. This works in PHP, but not in
JSON. To make the format JSON compatible, use a 'name' key instead of
using the key in the main array.
Leave backwards compatibility in place so that extensions using the old
format can be migrated. This will be removed in the next commit.
Before:
'packageFiles' => [
'script.js',
'script2.js',
'config.json' => [ 'config' => [ 'Foo', 'Bar' ] ],
'data.json' => [ 'callback' => function () { ... } ],
],
After:
'packageFiles' => [
'script.js',
'script2.js',
[ 'name' => 'config.json', 'config' => [ 'Foo', 'Bar' ] ],
[ 'name' => 'data.json', 'callback' => function () { ... } ],
],
This can then be written in extension.json as:
"packageFiles": [
"script.js",
"script2.js",
[ "name": "config.json", "config": [ "Foo", "Bar" ] ],
[ "name": "data.json", "callback: [ "MyExtHooks", "getData" ] ]
]
Change-Id: Ic566a1cd7efd075c380bc50ba0cc2c329a2041d7
2019-02-22 01:26:23 +00:00
|
|
|
if ( is_string( $fileInfo ) ) {
|
|
|
|
|
$fileInfo = [ 'name' => $fileInfo, 'file' => $fileInfo ];
|
|
|
|
|
} elseif ( !isset( $fileInfo['name'] ) ) {
|
2019-02-22 01:31:22 +00:00
|
|
|
$msg = __METHOD__ . ": invalid package file definition for module " .
|
|
|
|
|
"\"{$this->getName()}\": 'name' key is required when value is not a string";
|
|
|
|
|
wfDebugLog( 'resourceloader', $msg );
|
|
|
|
|
throw new MWException( $msg );
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Infer type from alias if needed
|
resourceloader: Change 'packageFiles' format to be JSON-compatible
The module definition format for 'packageFiles', as initially designed,
mixes sequential and associative arrays. This works in PHP, but not in
JSON. To make the format JSON compatible, use a 'name' key instead of
using the key in the main array.
Leave backwards compatibility in place so that extensions using the old
format can be migrated. This will be removed in the next commit.
Before:
'packageFiles' => [
'script.js',
'script2.js',
'config.json' => [ 'config' => [ 'Foo', 'Bar' ] ],
'data.json' => [ 'callback' => function () { ... } ],
],
After:
'packageFiles' => [
'script.js',
'script2.js',
[ 'name' => 'config.json', 'config' => [ 'Foo', 'Bar' ] ],
[ 'name' => 'data.json', 'callback' => function () { ... } ],
],
This can then be written in extension.json as:
"packageFiles": [
"script.js",
"script2.js",
[ "name": "config.json", "config": [ "Foo", "Bar" ] ],
[ "name": "data.json", "callback: [ "MyExtHooks", "getData" ] ]
]
Change-Id: Ic566a1cd7efd075c380bc50ba0cc2c329a2041d7
2019-02-22 01:26:23 +00:00
|
|
|
$type = $fileInfo['type'] ?? self::getPackageFileType( $fileInfo['name'] );
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
$expanded = [ 'type' => $type ];
|
|
|
|
|
if ( !empty( $fileInfo['main'] ) ) {
|
resourceloader: Change 'packageFiles' format to be JSON-compatible
The module definition format for 'packageFiles', as initially designed,
mixes sequential and associative arrays. This works in PHP, but not in
JSON. To make the format JSON compatible, use a 'name' key instead of
using the key in the main array.
Leave backwards compatibility in place so that extensions using the old
format can be migrated. This will be removed in the next commit.
Before:
'packageFiles' => [
'script.js',
'script2.js',
'config.json' => [ 'config' => [ 'Foo', 'Bar' ] ],
'data.json' => [ 'callback' => function () { ... } ],
],
After:
'packageFiles' => [
'script.js',
'script2.js',
[ 'name' => 'config.json', 'config' => [ 'Foo', 'Bar' ] ],
[ 'name' => 'data.json', 'callback' => function () { ... } ],
],
This can then be written in extension.json as:
"packageFiles": [
"script.js",
"script2.js",
[ "name": "config.json", "config": [ "Foo", "Bar" ] ],
[ "name": "data.json", "callback: [ "MyExtHooks", "getData" ] ]
]
Change-Id: Ic566a1cd7efd075c380bc50ba0cc2c329a2041d7
2019-02-22 01:26:23 +00:00
|
|
|
$mainFile = $fileInfo['name'];
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
if ( $type !== 'script' ) {
|
|
|
|
|
$msg = __METHOD__ . ": invalid package file definition for module " .
|
|
|
|
|
"\"{$this->getName()}\": main file \"$mainFile\" must be of type \"script\", not \"$type\"";
|
|
|
|
|
wfDebugLog( 'resourceloader', $msg );
|
|
|
|
|
throw new MWException( $msg );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-12 00:57:17 +00:00
|
|
|
// Perform expansions (except 'file' and 'callback'), creating one of these keys:
|
|
|
|
|
// - 'content': literal value.
|
|
|
|
|
// - 'filePath': content to be read from a file.
|
|
|
|
|
// - 'callback': content computed by a callable.
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
if ( isset( $fileInfo['content'] ) ) {
|
|
|
|
|
$expanded['content'] = $fileInfo['content'];
|
|
|
|
|
} elseif ( isset( $fileInfo['file'] ) ) {
|
|
|
|
|
$expanded['filePath'] = $fileInfo['file'];
|
|
|
|
|
} elseif ( isset( $fileInfo['callback'] ) ) {
|
2019-06-12 00:57:17 +00:00
|
|
|
if ( !is_callable( $fileInfo['callback'] ) ) {
|
resourceloader: Change 'packageFiles' format to be JSON-compatible
The module definition format for 'packageFiles', as initially designed,
mixes sequential and associative arrays. This works in PHP, but not in
JSON. To make the format JSON compatible, use a 'name' key instead of
using the key in the main array.
Leave backwards compatibility in place so that extensions using the old
format can be migrated. This will be removed in the next commit.
Before:
'packageFiles' => [
'script.js',
'script2.js',
'config.json' => [ 'config' => [ 'Foo', 'Bar' ] ],
'data.json' => [ 'callback' => function () { ... } ],
],
After:
'packageFiles' => [
'script.js',
'script2.js',
[ 'name' => 'config.json', 'config' => [ 'Foo', 'Bar' ] ],
[ 'name' => 'data.json', 'callback' => function () { ... } ],
],
This can then be written in extension.json as:
"packageFiles": [
"script.js",
"script2.js",
[ "name": "config.json", "config": [ "Foo", "Bar" ] ],
[ "name": "data.json", "callback: [ "MyExtHooks", "getData" ] ]
]
Change-Id: Ic566a1cd7efd075c380bc50ba0cc2c329a2041d7
2019-02-22 01:26:23 +00:00
|
|
|
$msg = __METHOD__ . ": invalid callback for package file \"{$fileInfo['name']}\"" .
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
" in module \"{$this->getName()}\"";
|
|
|
|
|
wfDebugLog( 'resourceloader', $msg );
|
|
|
|
|
throw new MWException( $msg );
|
|
|
|
|
}
|
2019-06-12 00:57:17 +00:00
|
|
|
if ( isset( $fileInfo['versionCallback'] ) ) {
|
|
|
|
|
if ( !is_callable( $fileInfo['versionCallback'] ) ) {
|
|
|
|
|
throw new MWException( __METHOD__ . ": invalid versionCallback for file" .
|
|
|
|
|
" \"{$fileInfo['name']}\" in module \"{$this->getName()}\"" );
|
|
|
|
|
}
|
|
|
|
|
$expanded['definitionSummary'] = ( $fileInfo['versionCallback'] )( $context );
|
|
|
|
|
// Don't invoke 'callback' here as it may be expensive (T223260).
|
|
|
|
|
$expanded['callback'] = $fileInfo['callback'];
|
|
|
|
|
} else {
|
|
|
|
|
$expanded['content'] = ( $fileInfo['callback'] )( $context );
|
|
|
|
|
}
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
} elseif ( isset( $fileInfo['config'] ) ) {
|
|
|
|
|
if ( $type !== 'data' ) {
|
resourceloader: Change 'packageFiles' format to be JSON-compatible
The module definition format for 'packageFiles', as initially designed,
mixes sequential and associative arrays. This works in PHP, but not in
JSON. To make the format JSON compatible, use a 'name' key instead of
using the key in the main array.
Leave backwards compatibility in place so that extensions using the old
format can be migrated. This will be removed in the next commit.
Before:
'packageFiles' => [
'script.js',
'script2.js',
'config.json' => [ 'config' => [ 'Foo', 'Bar' ] ],
'data.json' => [ 'callback' => function () { ... } ],
],
After:
'packageFiles' => [
'script.js',
'script2.js',
[ 'name' => 'config.json', 'config' => [ 'Foo', 'Bar' ] ],
[ 'name' => 'data.json', 'callback' => function () { ... } ],
],
This can then be written in extension.json as:
"packageFiles": [
"script.js",
"script2.js",
[ "name": "config.json", "config": [ "Foo", "Bar" ] ],
[ "name": "data.json", "callback: [ "MyExtHooks", "getData" ] ]
]
Change-Id: Ic566a1cd7efd075c380bc50ba0cc2c329a2041d7
2019-02-22 01:26:23 +00:00
|
|
|
$msg = __METHOD__ . ": invalid use of \"config\" for package file \"{$fileInfo['name']}\" " .
|
|
|
|
|
"in module \"{$this->getName()}\": type must be \"data\" but is \"$type\"";
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
wfDebugLog( 'resourceloader', $msg );
|
|
|
|
|
throw new MWException( $msg );
|
|
|
|
|
}
|
|
|
|
|
$expandedConfig = [];
|
|
|
|
|
foreach ( $fileInfo['config'] as $key => $var ) {
|
|
|
|
|
$expandedConfig[ is_numeric( $key ) ? $var : $key ] = $this->getConfig()->get( $var );
|
|
|
|
|
}
|
|
|
|
|
$expanded['content'] = $expandedConfig;
|
|
|
|
|
} elseif ( !empty( $fileInfo['main'] ) ) {
|
resourceloader: Change 'packageFiles' format to be JSON-compatible
The module definition format for 'packageFiles', as initially designed,
mixes sequential and associative arrays. This works in PHP, but not in
JSON. To make the format JSON compatible, use a 'name' key instead of
using the key in the main array.
Leave backwards compatibility in place so that extensions using the old
format can be migrated. This will be removed in the next commit.
Before:
'packageFiles' => [
'script.js',
'script2.js',
'config.json' => [ 'config' => [ 'Foo', 'Bar' ] ],
'data.json' => [ 'callback' => function () { ... } ],
],
After:
'packageFiles' => [
'script.js',
'script2.js',
[ 'name' => 'config.json', 'config' => [ 'Foo', 'Bar' ] ],
[ 'name' => 'data.json', 'callback' => function () { ... } ],
],
This can then be written in extension.json as:
"packageFiles": [
"script.js",
"script2.js",
[ "name": "config.json", "config": [ "Foo", "Bar" ] ],
[ "name": "data.json", "callback: [ "MyExtHooks", "getData" ] ]
]
Change-Id: Ic566a1cd7efd075c380bc50ba0cc2c329a2041d7
2019-02-22 01:26:23 +00:00
|
|
|
// [ 'name' => 'foo.js', 'main' => true ] is shorthand
|
|
|
|
|
$expanded['filePath'] = $fileInfo['name'];
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
} else {
|
resourceloader: Change 'packageFiles' format to be JSON-compatible
The module definition format for 'packageFiles', as initially designed,
mixes sequential and associative arrays. This works in PHP, but not in
JSON. To make the format JSON compatible, use a 'name' key instead of
using the key in the main array.
Leave backwards compatibility in place so that extensions using the old
format can be migrated. This will be removed in the next commit.
Before:
'packageFiles' => [
'script.js',
'script2.js',
'config.json' => [ 'config' => [ 'Foo', 'Bar' ] ],
'data.json' => [ 'callback' => function () { ... } ],
],
After:
'packageFiles' => [
'script.js',
'script2.js',
[ 'name' => 'config.json', 'config' => [ 'Foo', 'Bar' ] ],
[ 'name' => 'data.json', 'callback' => function () { ... } ],
],
This can then be written in extension.json as:
"packageFiles": [
"script.js",
"script2.js",
[ "name": "config.json", "config": [ "Foo", "Bar" ] ],
[ "name": "data.json", "callback: [ "MyExtHooks", "getData" ] ]
]
Change-Id: Ic566a1cd7efd075c380bc50ba0cc2c329a2041d7
2019-02-22 01:26:23 +00:00
|
|
|
$msg = __METHOD__ . ": invalid package file definition for \"{$fileInfo['name']}\" " .
|
|
|
|
|
"in module \"{$this->getName()}\": one of \"file\", \"content\", \"callback\" or \"config\" " .
|
|
|
|
|
"must be set";
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
wfDebugLog( 'resourceloader', $msg );
|
|
|
|
|
throw new MWException( $msg );
|
|
|
|
|
}
|
|
|
|
|
|
resourceloader: Change 'packageFiles' format to be JSON-compatible
The module definition format for 'packageFiles', as initially designed,
mixes sequential and associative arrays. This works in PHP, but not in
JSON. To make the format JSON compatible, use a 'name' key instead of
using the key in the main array.
Leave backwards compatibility in place so that extensions using the old
format can be migrated. This will be removed in the next commit.
Before:
'packageFiles' => [
'script.js',
'script2.js',
'config.json' => [ 'config' => [ 'Foo', 'Bar' ] ],
'data.json' => [ 'callback' => function () { ... } ],
],
After:
'packageFiles' => [
'script.js',
'script2.js',
[ 'name' => 'config.json', 'config' => [ 'Foo', 'Bar' ] ],
[ 'name' => 'data.json', 'callback' => function () { ... } ],
],
This can then be written in extension.json as:
"packageFiles": [
"script.js",
"script2.js",
[ "name": "config.json", "config": [ "Foo", "Bar" ] ],
[ "name": "data.json", "callback: [ "MyExtHooks", "getData" ] ]
]
Change-Id: Ic566a1cd7efd075c380bc50ba0cc2c329a2041d7
2019-02-22 01:26:23 +00:00
|
|
|
$expandedFiles[$fileInfo['name']] = $expanded;
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ( $expandedFiles && $mainFile === null ) {
|
|
|
|
|
// The first package file that is a script is the main file
|
|
|
|
|
foreach ( $expandedFiles as $path => &$file ) {
|
|
|
|
|
if ( $file['type'] === 'script' ) {
|
|
|
|
|
$mainFile = $path;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$result = [
|
|
|
|
|
'main' => $mainFile,
|
|
|
|
|
'files' => $expandedFiles
|
|
|
|
|
];
|
|
|
|
|
|
|
|
|
|
$this->expandedPackageFiles[$hash] = $result;
|
|
|
|
|
return $result;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Resolves the package files defintion and generates the content of each package file.
|
|
|
|
|
* @param ResourceLoaderContext $context
|
|
|
|
|
* @return array Package files data structure, see ResourceLoaderModule::getScript()
|
|
|
|
|
*/
|
|
|
|
|
public function getPackageFiles( ResourceLoaderContext $context ) {
|
|
|
|
|
if ( $this->packageFiles === null ) {
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
$expandedPackageFiles = $this->expandPackageFiles( $context );
|
|
|
|
|
|
|
|
|
|
// Expand file contents
|
|
|
|
|
foreach ( $expandedPackageFiles['files'] as &$fileInfo ) {
|
2019-06-12 00:57:17 +00:00
|
|
|
// Turn any 'filePath' or 'callback' key into actual 'content',
|
|
|
|
|
// and remove the key after that.
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
if ( isset( $fileInfo['filePath'] ) ) {
|
|
|
|
|
$localPath = $this->getLocalPath( $fileInfo['filePath'] );
|
|
|
|
|
if ( !file_exists( $localPath ) ) {
|
|
|
|
|
$msg = __METHOD__ . ": package file not found: \"$localPath\"" .
|
|
|
|
|
" in module \"{$this->getName()}\"";
|
|
|
|
|
wfDebugLog( 'resourceloader', $msg );
|
|
|
|
|
throw new MWException( $msg );
|
|
|
|
|
}
|
|
|
|
|
$content = $this->stripBom( file_get_contents( $localPath ) );
|
|
|
|
|
if ( $fileInfo['type'] === 'data' ) {
|
|
|
|
|
$content = json_decode( $content );
|
|
|
|
|
}
|
|
|
|
|
$fileInfo['content'] = $content;
|
|
|
|
|
unset( $fileInfo['filePath'] );
|
2019-06-12 00:57:17 +00:00
|
|
|
} elseif ( isset( $fileInfo['callback'] ) ) {
|
|
|
|
|
$fileInfo['content'] = ( $fileInfo['callback'] )( $context );
|
|
|
|
|
unset( $fileInfo['callback'] );
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
}
|
2019-06-12 00:57:17 +00:00
|
|
|
|
|
|
|
|
// Not needed for client response, exists for getDefinitionSummary().
|
|
|
|
|
unset( $fileInfo['definitionSummary'] );
|
ResourceLoader: Add support for packageFiles
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
2018-11-03 00:53:17 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $expandedPackageFiles;
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-11 11:53:59 +00:00
|
|
|
/**
|
|
|
|
|
* Takes an input string and removes the UTF-8 BOM character if present
|
|
|
|
|
*
|
|
|
|
|
* We need to remove these after reading a file, because we concatenate our files and
|
|
|
|
|
* the BOM character is not valid in the middle of a string.
|
|
|
|
|
* We already assume UTF-8 everywhere, so this should be safe.
|
|
|
|
|
*
|
2017-07-01 00:31:56 +00:00
|
|
|
* @param string $input
|
|
|
|
|
* @return string Input minus the intial BOM char
|
2016-05-11 11:53:59 +00:00
|
|
|
*/
|
|
|
|
|
protected function stripBom( $input ) {
|
|
|
|
|
if ( substr_compare( "\xef\xbb\xbf", $input, 0, 3 ) === 0 ) {
|
|
|
|
|
return substr( $input, 3 );
|
|
|
|
|
}
|
|
|
|
|
return $input;
|
|
|
|
|
}
|
2010-10-19 18:25:42 +00:00
|
|
|
}
|