wiki.techinc.nl/tests/phpunit/includes/ResourceLoader/ModuleTest.php

308 lines
8.3 KiB
PHP
Raw Normal View History

<?php
namespace MediaWiki\Tests\ResourceLoader;
use LogicException;
use MediaWiki\MainConfigNames;
use MediaWiki\ResourceLoader\FileModule;
use MediaWiki\ResourceLoader\Module;
use MediaWiki\ResourceLoader\ResourceLoader;
use ReflectionMethod;
use ResourceLoaderFileModuleTestingSubclass;
use ResourceLoaderTestCase;
use ResourceLoaderTestModule;
/**
* @covers \MediaWiki\ResourceLoader\Module
*/
class ModuleTest extends ResourceLoaderTestCase {
public function testGetVersionHash() {
resourceloader: Skip version hash calculation in debug mode === Why * More speed In debug mode, the server should regenerate the startup manifest on each page view to ensure immediate effect of changes. But, this also means more version recomputation work on the server. For most modules, this was already quite fast on repeat views because of OS-level file caches, and our file-hash caches and LESS compile caches in php-apcu from ResourceLoader. But, this makes it even faster. * Better integration with browser devtools. Breakpoints stay more consistently across browsers when the URL stays the same even after you have changed the file and reloaded the page. For static files, I believe most browsers ignore query parameters. But for package files that come from load.php, this was harder for browsers to guess correctly which old script URL is logically replaced by a different one on the next page view. === How Change Module::getVersionHash to return empty strings in debug mode. I considered approaching this from StartupModule::getModuleRegistrations instead to make the change apply only to the client-side manifest. I decided against this because we have other calls to getVersionHash on the server-side (such as for E-Tag calculation, and formatting cross-wiki URLs) which would then not match the version queries that mw.loader formats in debug mode. Also, those calls would still be incurring some the avoidable costs. === Notes * The two test cases for verifying the graceful fallback in production if version hash computations throw an exception, were moved to a non-debug test case as no longer happen now during the debug (unminified) test cases. * Avoid "PHP Notice: Undefined offset 0" in testMakeModuleResponseStartupError by adding a fallback to empty string so that if the test fails, it fails in a more useful way instead of aborting with this error before the assertion happens. (Since PHPUnit generally stops on the first error.) * In practice, there are still "version" query parameters and E-Tag headers in debug mode. These are not module versions, but URL "combined versions" crafted by getCombinedVersion() in JS and PHP. These return the constant "ztntf" in debug mode, which is the hash of an empty string. We could alter these methods to special-case when all inputs are and join to a still-empty string, or maybe we just leave them be. I've done the latter for now. Bug: T235672 Bug: T85805 Change-Id: I0e63eef4f85b13089a0aa3806a5b6f821d527a92
2021-08-28 02:53:36 +00:00
$context = $this->getResourceLoaderContext( [ 'debug' => 'false' ] );
$baseParams = [
'scripts' => [ 'foo.js', 'bar.js' ],
'dependencies' => [ 'jquery', 'mediawiki' ],
'messages' => [ 'hello', 'world' ],
];
$module = new FileModule( $baseParams );
$module->setName( "" );
$version = json_encode( $module->getVersionHash( $context ) );
// Exactly the same
$module = new FileModule( $baseParams );
$module->setName( "" );
$this->assertEquals(
$version,
json_encode( $module->getVersionHash( $context ) ),
'Instance is insignificant'
);
// Re-order dependencies
$module = new FileModule( [
'dependencies' => [ 'mediawiki', 'jquery' ],
] + $baseParams );
$module->setName( "" );
$this->assertEquals(
$version,
json_encode( $module->getVersionHash( $context ) ),
'Order of dependencies is insignificant'
);
// Re-order messages
$module = new FileModule( [
'messages' => [ 'world', 'hello' ],
] + $baseParams );
$module->setName( "" );
$this->assertEquals(
$version,
json_encode( $module->getVersionHash( $context ) ),
'Order of messages is insignificant'
);
// Re-order scripts
$module = new FileModule( [
'scripts' => [ 'bar.js', 'foo.js' ],
] + $baseParams );
$module->setName( "" );
$this->assertNotEquals(
$version,
json_encode( $module->getVersionHash( $context ) ),
'Order of scripts is significant'
);
// Subclass
$module = new ResourceLoaderFileModuleTestingSubclass( $baseParams );
$module->setName( "" );
$this->assertNotEquals(
$version,
json_encode( $module->getVersionHash( $context ) ),
'Class is significant'
);
}
public function testGetVersionHash_debug() {
$module = new ResourceLoaderTestModule( [ 'script' => 'foo();' ] );
$module->setName( "" );
$context = $this->getResourceLoaderContext( [ 'debug' => 'true' ] );
$this->assertSame( '', $module->getVersionHash( $context ) );
}
public function testGetVersionHash_length() {
resourceloader: Skip version hash calculation in debug mode === Why * More speed In debug mode, the server should regenerate the startup manifest on each page view to ensure immediate effect of changes. But, this also means more version recomputation work on the server. For most modules, this was already quite fast on repeat views because of OS-level file caches, and our file-hash caches and LESS compile caches in php-apcu from ResourceLoader. But, this makes it even faster. * Better integration with browser devtools. Breakpoints stay more consistently across browsers when the URL stays the same even after you have changed the file and reloaded the page. For static files, I believe most browsers ignore query parameters. But for package files that come from load.php, this was harder for browsers to guess correctly which old script URL is logically replaced by a different one on the next page view. === How Change Module::getVersionHash to return empty strings in debug mode. I considered approaching this from StartupModule::getModuleRegistrations instead to make the change apply only to the client-side manifest. I decided against this because we have other calls to getVersionHash on the server-side (such as for E-Tag calculation, and formatting cross-wiki URLs) which would then not match the version queries that mw.loader formats in debug mode. Also, those calls would still be incurring some the avoidable costs. === Notes * The two test cases for verifying the graceful fallback in production if version hash computations throw an exception, were moved to a non-debug test case as no longer happen now during the debug (unminified) test cases. * Avoid "PHP Notice: Undefined offset 0" in testMakeModuleResponseStartupError by adding a fallback to empty string so that if the test fails, it fails in a more useful way instead of aborting with this error before the assertion happens. (Since PHPUnit generally stops on the first error.) * In practice, there are still "version" query parameters and E-Tag headers in debug mode. These are not module versions, but URL "combined versions" crafted by getCombinedVersion() in JS and PHP. These return the constant "ztntf" in debug mode, which is the hash of an empty string. We could alter these methods to special-case when all inputs are and join to a still-empty string, or maybe we just leave them be. I've done the latter for now. Bug: T235672 Bug: T85805 Change-Id: I0e63eef4f85b13089a0aa3806a5b6f821d527a92
2021-08-28 02:53:36 +00:00
$context = $this->getResourceLoaderContext( [ 'debug' => 'false' ] );
$module = new ResourceLoaderTestModule( [
'script' => 'foo();'
] );
$module->setName( "" );
$version = $module->getVersionHash( $context );
$this->assertSame( ResourceLoader::HASH_LENGTH, strlen( $version ), 'Hash length' );
}
public function testGetVersionHash_parentDefinition() {
resourceloader: Skip version hash calculation in debug mode === Why * More speed In debug mode, the server should regenerate the startup manifest on each page view to ensure immediate effect of changes. But, this also means more version recomputation work on the server. For most modules, this was already quite fast on repeat views because of OS-level file caches, and our file-hash caches and LESS compile caches in php-apcu from ResourceLoader. But, this makes it even faster. * Better integration with browser devtools. Breakpoints stay more consistently across browsers when the URL stays the same even after you have changed the file and reloaded the page. For static files, I believe most browsers ignore query parameters. But for package files that come from load.php, this was harder for browsers to guess correctly which old script URL is logically replaced by a different one on the next page view. === How Change Module::getVersionHash to return empty strings in debug mode. I considered approaching this from StartupModule::getModuleRegistrations instead to make the change apply only to the client-side manifest. I decided against this because we have other calls to getVersionHash on the server-side (such as for E-Tag calculation, and formatting cross-wiki URLs) which would then not match the version queries that mw.loader formats in debug mode. Also, those calls would still be incurring some the avoidable costs. === Notes * The two test cases for verifying the graceful fallback in production if version hash computations throw an exception, were moved to a non-debug test case as no longer happen now during the debug (unminified) test cases. * Avoid "PHP Notice: Undefined offset 0" in testMakeModuleResponseStartupError by adding a fallback to empty string so that if the test fails, it fails in a more useful way instead of aborting with this error before the assertion happens. (Since PHPUnit generally stops on the first error.) * In practice, there are still "version" query parameters and E-Tag headers in debug mode. These are not module versions, but URL "combined versions" crafted by getCombinedVersion() in JS and PHP. These return the constant "ztntf" in debug mode, which is the hash of an empty string. We could alter these methods to special-case when all inputs are and join to a still-empty string, or maybe we just leave them be. I've done the latter for now. Bug: T235672 Bug: T85805 Change-Id: I0e63eef4f85b13089a0aa3806a5b6f821d527a92
2021-08-28 02:53:36 +00:00
$context = $this->getResourceLoaderContext( [ 'debug' => 'false' ] );
$module = $this->getMockBuilder( Module::class )
->onlyMethods( [ 'getDefinitionSummary' ] )->getMock();
$module->method( 'getDefinitionSummary' )->willReturn( [ 'a' => 'summary' ] );
$module->setName( "" );
$this->expectException( LogicException::class );
$this->expectExceptionMessage( 'must call parent' );
$module->getVersionHash( $context );
}
/**
* @covers \MediaWiki\ResourceLoader\Module
* @covers \MediaWiki\ResourceLoader\ResourceLoader
*/
public function testGetURLsForDebug() {
$module = new ResourceLoaderTestModule( [
'script' => 'foo();',
'styles' => '.foo { color: blue; }',
] );
$context = $this->getResourceLoaderContext( [ 'debug' => 'true' ] );
$module->setConfig( $context->getResourceLoader()->getConfig() );
$module->setName( "" );
$this->assertEquals(
[
'https://example.org/w/load.php?debug=1&lang=en&modules=&only=scripts'
],
$module->getScriptURLsForDebug( $context ),
'script urls debug=true'
);
$this->assertEquals(
[ 'all' => [
'/w/load.php?debug=1&lang=en&modules=&only=styles'
] ],
$module->getStyleURLsForDebug( $context ),
'style urls debug=true'
);
$context = $this->getResourceLoaderContext( [ 'debug' => '2' ] );
$this->assertEquals(
[
'https://example.org/w/load.php?debug=2&lang=en&modules=&only=scripts'
],
$module->getScriptURLsForDebug( $context ),
'script urls debug=2'
);
$this->assertEquals(
[ 'all' => [
'/w/load.php?debug=2&lang=en&modules=&only=styles'
] ],
$module->getStyleURLsForDebug( $context ),
'style urls debug=2'
);
}
public function testValidateScriptFile() {
$this->overrideConfigValue( MainConfigNames::ResourceLoaderValidateJS, true );
$context = $this->getResourceLoaderContext();
$module = new ResourceLoaderTestModule( [
'mayValidateScript' => true,
'script' => "var a = 'this is';\n {\ninvalid"
] );
$module->setConfig( $context->getResourceLoader()->getConfig() );
$this->assertEquals(
'mw.log.error(' .
'"JavaScript parse error (scripts need to be valid ECMAScript 5): ' .
'Parse error: Unexpected token; token } expected in file \'input\' on line 3"' .
');',
$module->getScript( $context ),
'Replace invalid syntax with error logging'
);
$module = new ResourceLoaderTestModule( [
'script' => "\n'valid';"
] );
$this->assertEquals(
"\n'valid';",
$module->getScript( $context ),
'Leave valid scripts as-is'
);
}
resourceloader: Store relative instead of absolute paths in module_deps Make paths stored in the module_deps table relative to $IP. This ensures that when the MediaWiki install path changes and/or if the location of the extension or skins directory changes, that ResourceLoader's internal model is still accurate. Previously when these paths change, ResourceLoader would exhibit various bugs. 1. Unable to detect changes in the module (if the directory no longer exists). 2. Point #1 is usually preceeded by one last cache invalidation as the content hash of the file path changes (from a valid hash to an empty string). 3. Unnecessary cache invalidation (if both old and new directories exist). This happens when a file is both an entry point (in the 'scripts' or 'styles' array) and also a file dependency. At first they are de-duplicated by array_unique. But after the disk path changes, the next check will result in the old path being fetched from module_deps, and the new path from the live configuration. This causes two changes that result in needless cache invalidation: - The hash list contains one more item (T111481). - The hash list contains both the old and new version of a file. (or even alternate versions, e.g. when a change is backported to the old wmf branch; it also affects wikis on the new branch due to the stale file path still in the database). It seems unusual to move a MediaWiki install, and usually we recommend third parties to run update.php if site administrators do move their wiki. However Wikimedia's deployment system implicitly moves the MediaWiki install continously from e.g. "/srv/mediawiki/php-1.26wmf5" to "/srv/mediawiki/php-1.26wmf6". This caused virtually all ResourceLoader caching layers to get invalidated every week when another wmf-branch is deployed, thus breaking these file paths, which changes the version hash, which then invalidates the cache. Bug: T111481 Change-Id: I173a9820b3067c4a6598a4c8d77e239797d2659c
2015-09-23 01:35:38 +00:00
public static function provideBuildContentScripts() {
return [
[
"mw.foo()",
"mw.foo()\n",
],
[
"mw.foo();",
"mw.foo();\n",
],
[
"mw.foo();\n",
"mw.foo();\n",
],
[
"mw.foo()\n",
"mw.foo()\n",
],
[
"mw.foo()\n// mw.bar();",
"mw.foo()\n// mw.bar();\n",
],
[
"mw.foo()\n// mw.bar()",
"mw.foo()\n// mw.bar()\n",
],
[
"mw.foo()// mw.bar();",
"mw.foo()// mw.bar();\n",
],
];
}
/**
* @dataProvider provideBuildContentScripts
*/
public function testBuildContentScripts( $raw, $build, $message = '' ) {
$context = $this->getResourceLoaderContext();
$module = new ResourceLoaderTestModule( [
'script' => $raw
] );
$module->setName( "" );
$this->assertEquals( $raw, $module->getScript( $context ), 'Raw script' );
$this->assertEquals(
resourceloader: Remove selective build optimisation from getModuleContent() This follows 5ddd7f91c7, which factored out response building from ResourceLoader.php to ResourceLoaderModule::buildContent. As optimisation, I made this method only return the array keys needed for the current response; based $context->getOnly(). The reason for this refactoring was the creation of the 'enableModuleContentVersion' option to getVersionHash(), which would use this method to create a module response, and hash it. During the implementation of that option, I ran into a problem. getVersionHash() is called by the startup module for each registered module, to create the manifest. The context for the StartupModule request itself has "only=scripts". But, we must still compute the version hashes for whole modules, not just their scripts. I worked around that problem in aac831f9fa by creating a mock context in getVersionHash() that stubs out the 'only' parameter. This worked, but made the assumption that the scripts and styles of a module cannot differ based on the 'only' parameter. This assumption was wrong, because the 'only' parameter is part of ResourceLoaderContext and available to all getters to vary on. Fortunately, the 'enableModuleContentVersion' option is off by default and nobody currently using it was differing its output by the 'only' parameter. I intend to make use of the 'enableModuleContentVersion' option in StartupModule to fix T201686. And StartupModule outputs a manifest if the request specifies only=scripts, and outputs a warning otherwise. As such, it cannot compute its version if the 'only' parameter is stubbed out. * Remove the 'only' parameter stubbing. * Remove the selective building from the buildContent() method. This was not very useful because we need to build the whole module regardless when computing the version. As benefit, this means the in-process cache is now shared between the call from getVersionHash and the call from makeModuleResponse. Bug: T201686 Change-Id: I8a17888f95f86ac795bc2de43086225b8a8f4b78
2018-08-30 01:42:24 +00:00
$build,
$module->getModuleContent( $context )[ 'scripts' ],
$message
);
}
resourceloader: Store relative instead of absolute paths in module_deps Make paths stored in the module_deps table relative to $IP. This ensures that when the MediaWiki install path changes and/or if the location of the extension or skins directory changes, that ResourceLoader's internal model is still accurate. Previously when these paths change, ResourceLoader would exhibit various bugs. 1. Unable to detect changes in the module (if the directory no longer exists). 2. Point #1 is usually preceeded by one last cache invalidation as the content hash of the file path changes (from a valid hash to an empty string). 3. Unnecessary cache invalidation (if both old and new directories exist). This happens when a file is both an entry point (in the 'scripts' or 'styles' array) and also a file dependency. At first they are de-duplicated by array_unique. But after the disk path changes, the next check will result in the old path being fetched from module_deps, and the new path from the live configuration. This causes two changes that result in needless cache invalidation: - The hash list contains one more item (T111481). - The hash list contains both the old and new version of a file. (or even alternate versions, e.g. when a change is backported to the old wmf branch; it also affects wikis on the new branch due to the stale file path still in the database). It seems unusual to move a MediaWiki install, and usually we recommend third parties to run update.php if site administrators do move their wiki. However Wikimedia's deployment system implicitly moves the MediaWiki install continously from e.g. "/srv/mediawiki/php-1.26wmf5" to "/srv/mediawiki/php-1.26wmf6". This caused virtually all ResourceLoader caching layers to get invalidated every week when another wmf-branch is deployed, thus breaking these file paths, which changes the version hash, which then invalidates the cache. Bug: T111481 Change-Id: I173a9820b3067c4a6598a4c8d77e239797d2659c
2015-09-23 01:35:38 +00:00
public function testPlaceholderize() {
$getRelativePaths = new ReflectionMethod( Module::class, 'getRelativePaths' );
resourceloader: Store relative instead of absolute paths in module_deps Make paths stored in the module_deps table relative to $IP. This ensures that when the MediaWiki install path changes and/or if the location of the extension or skins directory changes, that ResourceLoader's internal model is still accurate. Previously when these paths change, ResourceLoader would exhibit various bugs. 1. Unable to detect changes in the module (if the directory no longer exists). 2. Point #1 is usually preceeded by one last cache invalidation as the content hash of the file path changes (from a valid hash to an empty string). 3. Unnecessary cache invalidation (if both old and new directories exist). This happens when a file is both an entry point (in the 'scripts' or 'styles' array) and also a file dependency. At first they are de-duplicated by array_unique. But after the disk path changes, the next check will result in the old path being fetched from module_deps, and the new path from the live configuration. This causes two changes that result in needless cache invalidation: - The hash list contains one more item (T111481). - The hash list contains both the old and new version of a file. (or even alternate versions, e.g. when a change is backported to the old wmf branch; it also affects wikis on the new branch due to the stale file path still in the database). It seems unusual to move a MediaWiki install, and usually we recommend third parties to run update.php if site administrators do move their wiki. However Wikimedia's deployment system implicitly moves the MediaWiki install continously from e.g. "/srv/mediawiki/php-1.26wmf5" to "/srv/mediawiki/php-1.26wmf6". This caused virtually all ResourceLoader caching layers to get invalidated every week when another wmf-branch is deployed, thus breaking these file paths, which changes the version hash, which then invalidates the cache. Bug: T111481 Change-Id: I173a9820b3067c4a6598a4c8d77e239797d2659c
2015-09-23 01:35:38 +00:00
$getRelativePaths->setAccessible( true );
$expandRelativePaths = new ReflectionMethod( Module::class, 'expandRelativePaths' );
resourceloader: Store relative instead of absolute paths in module_deps Make paths stored in the module_deps table relative to $IP. This ensures that when the MediaWiki install path changes and/or if the location of the extension or skins directory changes, that ResourceLoader's internal model is still accurate. Previously when these paths change, ResourceLoader would exhibit various bugs. 1. Unable to detect changes in the module (if the directory no longer exists). 2. Point #1 is usually preceeded by one last cache invalidation as the content hash of the file path changes (from a valid hash to an empty string). 3. Unnecessary cache invalidation (if both old and new directories exist). This happens when a file is both an entry point (in the 'scripts' or 'styles' array) and also a file dependency. At first they are de-duplicated by array_unique. But after the disk path changes, the next check will result in the old path being fetched from module_deps, and the new path from the live configuration. This causes two changes that result in needless cache invalidation: - The hash list contains one more item (T111481). - The hash list contains both the old and new version of a file. (or even alternate versions, e.g. when a change is backported to the old wmf branch; it also affects wikis on the new branch due to the stale file path still in the database). It seems unusual to move a MediaWiki install, and usually we recommend third parties to run update.php if site administrators do move their wiki. However Wikimedia's deployment system implicitly moves the MediaWiki install continously from e.g. "/srv/mediawiki/php-1.26wmf5" to "/srv/mediawiki/php-1.26wmf6". This caused virtually all ResourceLoader caching layers to get invalidated every week when another wmf-branch is deployed, thus breaking these file paths, which changes the version hash, which then invalidates the cache. Bug: T111481 Change-Id: I173a9820b3067c4a6598a4c8d77e239797d2659c
2015-09-23 01:35:38 +00:00
$expandRelativePaths->setAccessible( true );
$this->setMwGlobals( [
resourceloader: Store relative instead of absolute paths in module_deps Make paths stored in the module_deps table relative to $IP. This ensures that when the MediaWiki install path changes and/or if the location of the extension or skins directory changes, that ResourceLoader's internal model is still accurate. Previously when these paths change, ResourceLoader would exhibit various bugs. 1. Unable to detect changes in the module (if the directory no longer exists). 2. Point #1 is usually preceeded by one last cache invalidation as the content hash of the file path changes (from a valid hash to an empty string). 3. Unnecessary cache invalidation (if both old and new directories exist). This happens when a file is both an entry point (in the 'scripts' or 'styles' array) and also a file dependency. At first they are de-duplicated by array_unique. But after the disk path changes, the next check will result in the old path being fetched from module_deps, and the new path from the live configuration. This causes two changes that result in needless cache invalidation: - The hash list contains one more item (T111481). - The hash list contains both the old and new version of a file. (or even alternate versions, e.g. when a change is backported to the old wmf branch; it also affects wikis on the new branch due to the stale file path still in the database). It seems unusual to move a MediaWiki install, and usually we recommend third parties to run update.php if site administrators do move their wiki. However Wikimedia's deployment system implicitly moves the MediaWiki install continously from e.g. "/srv/mediawiki/php-1.26wmf5" to "/srv/mediawiki/php-1.26wmf6". This caused virtually all ResourceLoader caching layers to get invalidated every week when another wmf-branch is deployed, thus breaking these file paths, which changes the version hash, which then invalidates the cache. Bug: T111481 Change-Id: I173a9820b3067c4a6598a4c8d77e239797d2659c
2015-09-23 01:35:38 +00:00
'IP' => '/srv/example/mediawiki/core',
] );
$raw = [
resourceloader: Store relative instead of absolute paths in module_deps Make paths stored in the module_deps table relative to $IP. This ensures that when the MediaWiki install path changes and/or if the location of the extension or skins directory changes, that ResourceLoader's internal model is still accurate. Previously when these paths change, ResourceLoader would exhibit various bugs. 1. Unable to detect changes in the module (if the directory no longer exists). 2. Point #1 is usually preceeded by one last cache invalidation as the content hash of the file path changes (from a valid hash to an empty string). 3. Unnecessary cache invalidation (if both old and new directories exist). This happens when a file is both an entry point (in the 'scripts' or 'styles' array) and also a file dependency. At first they are de-duplicated by array_unique. But after the disk path changes, the next check will result in the old path being fetched from module_deps, and the new path from the live configuration. This causes two changes that result in needless cache invalidation: - The hash list contains one more item (T111481). - The hash list contains both the old and new version of a file. (or even alternate versions, e.g. when a change is backported to the old wmf branch; it also affects wikis on the new branch due to the stale file path still in the database). It seems unusual to move a MediaWiki install, and usually we recommend third parties to run update.php if site administrators do move their wiki. However Wikimedia's deployment system implicitly moves the MediaWiki install continously from e.g. "/srv/mediawiki/php-1.26wmf5" to "/srv/mediawiki/php-1.26wmf6". This caused virtually all ResourceLoader caching layers to get invalidated every week when another wmf-branch is deployed, thus breaking these file paths, which changes the version hash, which then invalidates the cache. Bug: T111481 Change-Id: I173a9820b3067c4a6598a4c8d77e239797d2659c
2015-09-23 01:35:38 +00:00
'/srv/example/mediawiki/core/resources/foo.js',
'/srv/example/mediawiki/core/extensions/Example/modules/bar.js',
'/srv/example/mediawiki/skins/Example/baz.css',
'/srv/example/mediawiki/skins/Example/images/quux.png',
];
$canonical = [
resourceloader: Store relative instead of absolute paths in module_deps Make paths stored in the module_deps table relative to $IP. This ensures that when the MediaWiki install path changes and/or if the location of the extension or skins directory changes, that ResourceLoader's internal model is still accurate. Previously when these paths change, ResourceLoader would exhibit various bugs. 1. Unable to detect changes in the module (if the directory no longer exists). 2. Point #1 is usually preceeded by one last cache invalidation as the content hash of the file path changes (from a valid hash to an empty string). 3. Unnecessary cache invalidation (if both old and new directories exist). This happens when a file is both an entry point (in the 'scripts' or 'styles' array) and also a file dependency. At first they are de-duplicated by array_unique. But after the disk path changes, the next check will result in the old path being fetched from module_deps, and the new path from the live configuration. This causes two changes that result in needless cache invalidation: - The hash list contains one more item (T111481). - The hash list contains both the old and new version of a file. (or even alternate versions, e.g. when a change is backported to the old wmf branch; it also affects wikis on the new branch due to the stale file path still in the database). It seems unusual to move a MediaWiki install, and usually we recommend third parties to run update.php if site administrators do move their wiki. However Wikimedia's deployment system implicitly moves the MediaWiki install continously from e.g. "/srv/mediawiki/php-1.26wmf5" to "/srv/mediawiki/php-1.26wmf6". This caused virtually all ResourceLoader caching layers to get invalidated every week when another wmf-branch is deployed, thus breaking these file paths, which changes the version hash, which then invalidates the cache. Bug: T111481 Change-Id: I173a9820b3067c4a6598a4c8d77e239797d2659c
2015-09-23 01:35:38 +00:00
'resources/foo.js',
'extensions/Example/modules/bar.js',
'../skins/Example/baz.css',
'../skins/Example/images/quux.png',
];
resourceloader: Store relative instead of absolute paths in module_deps Make paths stored in the module_deps table relative to $IP. This ensures that when the MediaWiki install path changes and/or if the location of the extension or skins directory changes, that ResourceLoader's internal model is still accurate. Previously when these paths change, ResourceLoader would exhibit various bugs. 1. Unable to detect changes in the module (if the directory no longer exists). 2. Point #1 is usually preceeded by one last cache invalidation as the content hash of the file path changes (from a valid hash to an empty string). 3. Unnecessary cache invalidation (if both old and new directories exist). This happens when a file is both an entry point (in the 'scripts' or 'styles' array) and also a file dependency. At first they are de-duplicated by array_unique. But after the disk path changes, the next check will result in the old path being fetched from module_deps, and the new path from the live configuration. This causes two changes that result in needless cache invalidation: - The hash list contains one more item (T111481). - The hash list contains both the old and new version of a file. (or even alternate versions, e.g. when a change is backported to the old wmf branch; it also affects wikis on the new branch due to the stale file path still in the database). It seems unusual to move a MediaWiki install, and usually we recommend third parties to run update.php if site administrators do move their wiki. However Wikimedia's deployment system implicitly moves the MediaWiki install continously from e.g. "/srv/mediawiki/php-1.26wmf5" to "/srv/mediawiki/php-1.26wmf6". This caused virtually all ResourceLoader caching layers to get invalidated every week when another wmf-branch is deployed, thus breaking these file paths, which changes the version hash, which then invalidates the cache. Bug: T111481 Change-Id: I173a9820b3067c4a6598a4c8d77e239797d2659c
2015-09-23 01:35:38 +00:00
$this->assertEquals(
$canonical,
$getRelativePaths->invoke( null, $raw ),
resourceloader: Store relative instead of absolute paths in module_deps Make paths stored in the module_deps table relative to $IP. This ensures that when the MediaWiki install path changes and/or if the location of the extension or skins directory changes, that ResourceLoader's internal model is still accurate. Previously when these paths change, ResourceLoader would exhibit various bugs. 1. Unable to detect changes in the module (if the directory no longer exists). 2. Point #1 is usually preceeded by one last cache invalidation as the content hash of the file path changes (from a valid hash to an empty string). 3. Unnecessary cache invalidation (if both old and new directories exist). This happens when a file is both an entry point (in the 'scripts' or 'styles' array) and also a file dependency. At first they are de-duplicated by array_unique. But after the disk path changes, the next check will result in the old path being fetched from module_deps, and the new path from the live configuration. This causes two changes that result in needless cache invalidation: - The hash list contains one more item (T111481). - The hash list contains both the old and new version of a file. (or even alternate versions, e.g. when a change is backported to the old wmf branch; it also affects wikis on the new branch due to the stale file path still in the database). It seems unusual to move a MediaWiki install, and usually we recommend third parties to run update.php if site administrators do move their wiki. However Wikimedia's deployment system implicitly moves the MediaWiki install continously from e.g. "/srv/mediawiki/php-1.26wmf5" to "/srv/mediawiki/php-1.26wmf6". This caused virtually all ResourceLoader caching layers to get invalidated every week when another wmf-branch is deployed, thus breaking these file paths, which changes the version hash, which then invalidates the cache. Bug: T111481 Change-Id: I173a9820b3067c4a6598a4c8d77e239797d2659c
2015-09-23 01:35:38 +00:00
'Insert placeholders'
);
$this->assertEquals(
$raw,
$expandRelativePaths->invoke( null, $canonical ),
resourceloader: Store relative instead of absolute paths in module_deps Make paths stored in the module_deps table relative to $IP. This ensures that when the MediaWiki install path changes and/or if the location of the extension or skins directory changes, that ResourceLoader's internal model is still accurate. Previously when these paths change, ResourceLoader would exhibit various bugs. 1. Unable to detect changes in the module (if the directory no longer exists). 2. Point #1 is usually preceeded by one last cache invalidation as the content hash of the file path changes (from a valid hash to an empty string). 3. Unnecessary cache invalidation (if both old and new directories exist). This happens when a file is both an entry point (in the 'scripts' or 'styles' array) and also a file dependency. At first they are de-duplicated by array_unique. But after the disk path changes, the next check will result in the old path being fetched from module_deps, and the new path from the live configuration. This causes two changes that result in needless cache invalidation: - The hash list contains one more item (T111481). - The hash list contains both the old and new version of a file. (or even alternate versions, e.g. when a change is backported to the old wmf branch; it also affects wikis on the new branch due to the stale file path still in the database). It seems unusual to move a MediaWiki install, and usually we recommend third parties to run update.php if site administrators do move their wiki. However Wikimedia's deployment system implicitly moves the MediaWiki install continously from e.g. "/srv/mediawiki/php-1.26wmf5" to "/srv/mediawiki/php-1.26wmf6". This caused virtually all ResourceLoader caching layers to get invalidated every week when another wmf-branch is deployed, thus breaking these file paths, which changes the version hash, which then invalidates the cache. Bug: T111481 Change-Id: I173a9820b3067c4a6598a4c8d77e239797d2659c
2015-09-23 01:35:38 +00:00
'Substitute placeholders'
);
}
public function testGetHeaders() {
$context = $this->getResourceLoaderContext();
$module = new ResourceLoaderTestModule();
$module->setName( "" );
$this->assertSame( [], $module->getHeaders( $context ), 'Default' );
$module = $this->getMockBuilder( ResourceLoaderTestModule::class )
->onlyMethods( [ 'getPreloadLinks' ] )->getMock();
$module->method( 'getPreloadLinks' )->willReturn( [
'https://example.org/script.js' => [ 'as' => 'script' ],
] );
$this->assertSame(
[
'Link: <https://example.org/script.js>;rel=preload;as=script'
],
$module->getHeaders( $context ),
'Preload one resource'
);
$module = $this->getMockBuilder( ResourceLoaderTestModule::class )
->onlyMethods( [ 'getPreloadLinks' ] )->getMock();
$module->method( 'getPreloadLinks' )->willReturn( [
'https://example.org/script.js' => [ 'as' => 'script' ],
'/example.png' => [ 'as' => 'image' ],
] );
$module->setName( "" );
$this->assertSame(
[
'Link: <https://example.org/script.js>;rel=preload;as=script,' .
'</example.png>;rel=preload;as=image'
],
$module->getHeaders( $context ),
'Preload two resources'
);
}
}