wiki.techinc.nl/includes/ResourceLoader/OOUIFileModule.php

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

117 lines
4 KiB
PHP
Raw Normal View History

<?php
/**
* 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
*/
namespace MediaWiki\ResourceLoader;
/**
* Module which magically loads the right skinScripts and skinStyles for every
* skin, using the specified OOUI theme for each.
*
* @ingroup ResourceLoader
* @internal
*/
class OOUIFileModule extends FileModule {
use OOUIModule;
/** @var array<string,string|FilePath> */
resourceloader: Fix prepending of OOUI theme skinStyles == Background Prior to 1367e356e76e: * Module definition is registered (may have skinStyles). * If the module already has skinStyles, skip this step. Otherwise, skin-provided ResourceModuleSkinStyles are merged into the module def, where '+module' means defaults are kept, and 'module' replaces the defaults. * When the module is constructed for bundling, OOUIFileModule prepends theme-specific resources to skinStyles. For OOUI and MonoBook that meant: * oojs-ui-core.styles has no own skinStyles. * MonoBook/skin.json defines additive (+module) styles, which are set into an otherwise empty skinStyles array. * OOUIFileModule sees skinStyles[monobook] and prepends to it. After 1367e356e76e, it works like this: * Module definition is registered. * The module is constructed, and OOUIFileModule sets skinStyles[monobook] as new key. * Skin-provided ResourceModuleSkinStyles is ignored because by design these are not allowed if the module has skinStyles[monobook] set itself. This refactor changed nothing for most module classes, but did for OOUIFileModule. == Fix We can move the OOUIFileModule logic up to where the new abstraction is, or we can move it down toward run-time methods like getStyleFiles (as SkinModule currently does). I'm choosing the former as otherwise we lose automatic versioning, caching, and inclusion in PHPUnit structure tests for file existence and Less syntax etc. Bug: T290013 Change-Id: Id7c258841d7816e710961a1f7c7f7c99764cf59a
2021-08-31 19:57:04 +00:00
private $themeStyles = [];
public function __construct( array $options = [] ) {
if ( isset( $options['themeScripts'] ) ) {
$skinScripts = $this->getSkinSpecific( $options['themeScripts'], 'scripts' );
$options['skinScripts'] = $this->extendSkinSpecific( $options['skinScripts'] ?? [], $skinScripts );
}
if ( isset( $options['themeStyles'] ) ) {
resourceloader: Fix prepending of OOUI theme skinStyles == Background Prior to 1367e356e76e: * Module definition is registered (may have skinStyles). * If the module already has skinStyles, skip this step. Otherwise, skin-provided ResourceModuleSkinStyles are merged into the module def, where '+module' means defaults are kept, and 'module' replaces the defaults. * When the module is constructed for bundling, OOUIFileModule prepends theme-specific resources to skinStyles. For OOUI and MonoBook that meant: * oojs-ui-core.styles has no own skinStyles. * MonoBook/skin.json defines additive (+module) styles, which are set into an otherwise empty skinStyles array. * OOUIFileModule sees skinStyles[monobook] and prepends to it. After 1367e356e76e, it works like this: * Module definition is registered. * The module is constructed, and OOUIFileModule sets skinStyles[monobook] as new key. * Skin-provided ResourceModuleSkinStyles is ignored because by design these are not allowed if the module has skinStyles[monobook] set itself. This refactor changed nothing for most module classes, but did for OOUIFileModule. == Fix We can move the OOUIFileModule logic up to where the new abstraction is, or we can move it down toward run-time methods like getStyleFiles (as SkinModule currently does). I'm choosing the former as otherwise we lose automatic versioning, caching, and inclusion in PHPUnit structure tests for file existence and Less syntax etc. Bug: T290013 Change-Id: Id7c258841d7816e710961a1f7c7f7c99764cf59a
2021-08-31 19:57:04 +00:00
$this->themeStyles = $this->getSkinSpecific( $options['themeStyles'], 'styles' );
}
parent::__construct( $options );
}
resourceloader: Fix prepending of OOUI theme skinStyles == Background Prior to 1367e356e76e: * Module definition is registered (may have skinStyles). * If the module already has skinStyles, skip this step. Otherwise, skin-provided ResourceModuleSkinStyles are merged into the module def, where '+module' means defaults are kept, and 'module' replaces the defaults. * When the module is constructed for bundling, OOUIFileModule prepends theme-specific resources to skinStyles. For OOUI and MonoBook that meant: * oojs-ui-core.styles has no own skinStyles. * MonoBook/skin.json defines additive (+module) styles, which are set into an otherwise empty skinStyles array. * OOUIFileModule sees skinStyles[monobook] and prepends to it. After 1367e356e76e, it works like this: * Module definition is registered. * The module is constructed, and OOUIFileModule sets skinStyles[monobook] as new key. * Skin-provided ResourceModuleSkinStyles is ignored because by design these are not allowed if the module has skinStyles[monobook] set itself. This refactor changed nothing for most module classes, but did for OOUIFileModule. == Fix We can move the OOUIFileModule logic up to where the new abstraction is, or we can move it down toward run-time methods like getStyleFiles (as SkinModule currently does). I'm choosing the former as otherwise we lose automatic versioning, caching, and inclusion in PHPUnit structure tests for file existence and Less syntax etc. Bug: T290013 Change-Id: Id7c258841d7816e710961a1f7c7f7c99764cf59a
2021-08-31 19:57:04 +00:00
public function setSkinStylesOverride( array $moduleSkinStyles ): void {
parent::setSkinStylesOverride( $moduleSkinStyles );
$this->skinStyles = $this->extendSkinSpecific( $this->skinStyles, $this->themeStyles );
resourceloader: Fix prepending of OOUI theme skinStyles == Background Prior to 1367e356e76e: * Module definition is registered (may have skinStyles). * If the module already has skinStyles, skip this step. Otherwise, skin-provided ResourceModuleSkinStyles are merged into the module def, where '+module' means defaults are kept, and 'module' replaces the defaults. * When the module is constructed for bundling, OOUIFileModule prepends theme-specific resources to skinStyles. For OOUI and MonoBook that meant: * oojs-ui-core.styles has no own skinStyles. * MonoBook/skin.json defines additive (+module) styles, which are set into an otherwise empty skinStyles array. * OOUIFileModule sees skinStyles[monobook] and prepends to it. After 1367e356e76e, it works like this: * Module definition is registered. * The module is constructed, and OOUIFileModule sets skinStyles[monobook] as new key. * Skin-provided ResourceModuleSkinStyles is ignored because by design these are not allowed if the module has skinStyles[monobook] set itself. This refactor changed nothing for most module classes, but did for OOUIFileModule. == Fix We can move the OOUIFileModule logic up to where the new abstraction is, or we can move it down toward run-time methods like getStyleFiles (as SkinModule currently does). I'm choosing the former as otherwise we lose automatic versioning, caching, and inclusion in PHPUnit structure tests for file existence and Less syntax etc. Bug: T290013 Change-Id: Id7c258841d7816e710961a1f7c7f7c99764cf59a
2021-08-31 19:57:04 +00:00
}
/**
* Helper function to generate values for 'skinStyles' and 'skinScripts'.
*
* @param string $module Module to generate skinStyles/skinScripts for:
* 'core', 'widgets', 'toolbars', 'windows'
* @param string $which 'scripts' or 'styles'
* @return array<string,string|FilePath>
*/
private function getSkinSpecific( $module, $which ): array {
$themes = self::getSkinThemeMap();
return array_combine(
array_keys( $themes ),
array_map( function ( $theme ) use ( $module, $which ) {
if ( $which === 'scripts' ) {
return $this->getThemeScriptsPath( $theme, $module );
} else {
return $this->getThemeStylesPath( $theme, $module );
}
}, array_values( $themes ) )
);
}
/**
* Prepend theme-specific resources on behalf of the skin.
*
* The expected order of styles and scripts in the output is:
*
* 1. Theme-specific resources for a given skin.
*
* 2. Module-defined resources for a specific skin,
* falling back to module-defined "default" skin resources.
*
* 3. Skin-defined resources for a specific module, which can either
* append to or replace the "default" (via ResourceModuleSkinStyles in skin.json)
* Note that skins can only define resources for a module if that
* module does not already explicitly provide resources for that skin.
*
* @param array $skinSpecific Module-defined 'skinScripts' or 'skinStyles'.
* @param array $themeSpecific
* @return array Modified $skinSpecific
*/
private function extendSkinSpecific( array $skinSpecific, array $themeSpecific ): array {
// If the module or skin already set skinStyles/skinScripts, prepend ours
foreach ( $skinSpecific as $skin => $files ) {
if ( !is_array( $files ) ) {
$files = [ $files ];
}
if ( isset( $themeSpecific[$skin] ) ) {
$skinSpecific[$skin] = array_merge( [ $themeSpecific[$skin] ], $files );
} elseif ( isset( $themeSpecific['default'] ) ) {
$skinSpecific[$skin] = array_merge( [ $themeSpecific['default'] ], $files );
}
}
// If the module has no skinStyles/skinScripts for a skin, then set ours
foreach ( $themeSpecific as $skin => $file ) {
if ( !isset( $skinSpecific[$skin] ) ) {
resourceloader: Fix prepending of OOUI theme skinStyles == Background Prior to 1367e356e76e: * Module definition is registered (may have skinStyles). * If the module already has skinStyles, skip this step. Otherwise, skin-provided ResourceModuleSkinStyles are merged into the module def, where '+module' means defaults are kept, and 'module' replaces the defaults. * When the module is constructed for bundling, OOUIFileModule prepends theme-specific resources to skinStyles. For OOUI and MonoBook that meant: * oojs-ui-core.styles has no own skinStyles. * MonoBook/skin.json defines additive (+module) styles, which are set into an otherwise empty skinStyles array. * OOUIFileModule sees skinStyles[monobook] and prepends to it. After 1367e356e76e, it works like this: * Module definition is registered. * The module is constructed, and OOUIFileModule sets skinStyles[monobook] as new key. * Skin-provided ResourceModuleSkinStyles is ignored because by design these are not allowed if the module has skinStyles[monobook] set itself. This refactor changed nothing for most module classes, but did for OOUIFileModule. == Fix We can move the OOUIFileModule logic up to where the new abstraction is, or we can move it down toward run-time methods like getStyleFiles (as SkinModule currently does). I'm choosing the former as otherwise we lose automatic versioning, caching, and inclusion in PHPUnit structure tests for file existence and Less syntax etc. Bug: T290013 Change-Id: Id7c258841d7816e710961a1f7c7f7c99764cf59a
2021-08-31 19:57:04 +00:00
$skinSpecific[$skin] = [ $file ];
}
}
return $skinSpecific;
}
}