Talk: Global Lua Modules/Colors

Local testing only?

The required PR (#15301) has been merged and is now live. The release status is listed as "stable", so is this module safe to use? DarthKitty (talk) 18:16, June 15, 2018 (UTC)

mw.site.sassParams

It seems like this platform exposed colors globally but not anymore. Here is a simple implementation:

local _M = {}

function _M.setupInterface( info )
	-- Boilerplate
	_M.setupInterface = nil
	local php = mw_interface
	mw_interface = nil

	-- Register this library in the "mw" global
	local sassParams = info.sassParams
	mw = mw or {}
	mw.site = mw.site or {}
	mw.site.sassParams = sassParams

	package.loaded['sassParams'] = sassParams
end

return _M

<?php

namespace SassParams;

use SassUtil;

/**
 * Registers our lua modules to Scribunto
 *
 * @license GPL-2.0-or-later
 * @author FANDOM
 */

class LuaLibrary extends Scribunto_LuaLibraryBase {

	/**
	 * Register the library
	 *
	 * @return array
	 */
	function register() {
		$lib = array();
		$info = array(
			'sassParams' => SassUtil::getSassSettings()
		);

		$this->getEngine()->registerInterface( 'sassParams.lua', $lib, $info );
	}

}

<?php

namespace SassParams;

/**
 * File defining the hook handlers for the Capiunto extension.
 *
 * @license GPL-2.0-or-later
 * @author FANDOM
 */
class LuaSassParamsHooks {

	/**
	 * External Lua library for Scribunto
	 *
	 * @param string $engine
	 * @param array &$extraLibraries
	 * @return bool
	 */
	public static function registerScribuntoLibraries( $engine, array &$extraLibraries ) {
		if ( $engine !== 'lua' ) {
			return true;
		}

		$extraLibraries['sassParams'] = [
			'class' => LuaLibrary::class,
			'deferLoad' => true
		];

		return true;
	}

	/**
	 * External Lua library paths for Scribunto
	 *
	 * @param string $engine
	 * @param array &$extraLibraryPaths
	 * @return bool
	 */
	public static function registerScribuntoExternalLibraryPaths(
		$engine,
		array &$extraLibraryPaths
	) {
		if ( $engine !== 'lua' ) {
			return true;
		}

		$extraLibraryPaths[] = __DIR__ . '/lua';

		return true;
	}

}

I can't see this new codebase so I can't make a PR for it.—Preceding unsigned comment added by MUNEME (talk • contribs) . Please sign your posts with ~~~~!

Since there are two themes on FandomDesktop, I believe exposing colors via the page source is not relevant anymore. Since MediaWiki also does not allow calling CSS variables inline, stylesheets (and sometimes JS) seems like the only available tool for referencing system colors. Nam 15:32, 14 November 2021 (UTC)

Looking at the source, this module actually allowed for mixing new colors. ?uselang produces new article content depending on caching, why can't this module do the same? MUNEME (talk) 13:56, 16 November 2021 (UTC)

Okay, I'm not saying it is technically impossible, but it would require two things which I doubt Fandom will be willing to do any of them.

1. Customizing Scribunto to expose new information — I would like, for example, to be abld to retrive user avatars or user groups via Lua, but it probably wouldn't happen. One of the main principles of the UCP transition was "we want to stay as close to the core MediaWiki as possible so it wouldn't be hard to upgrade again". And colors are now exposed via CSS custom properties, which they weren't back then, so Fandom will have even less motivation to expose them via Lua. I can actually think of a script that will run each time an admin saves changes on Theme Designer and will store the colors on a Lua table available for modules. That would still leaves us with the second problem though.
2. Having two different versions of the page rendering for the two themes. That's far from what Fandom seem to be willing to offer — they don't even provide a URL parameter to switch themes on ocassion. The mobile layout do have a separate rendering, yet there is no direct way to differentiate between the two in page source — unless you use hacks with template types or so. ?uselang is an exceptional case, and I'm not aware of it being used anywhere on Fandom besides page translations here on Dev.

Okay, that was long, sorry :D I believe CSS/JS solutions are more realistic.

Nam

Some wikis probably use the int parser tag. The code above can be set up as a hook extension bypassing the "Scribunto hack" concern. But as you said, it would depend on whether the platform devs want to re-add this feature as a separate extension. MUNEME (talk) 10:25, 17 November 2021 (UTC)

In the meantime, should the sassParams functionality be removed? MUNEME (talk) 10:30, 17 November 2021 (UTC)

I believe so, since the SASS params do not exist anymore. The color manipulation functions can still be useful though. I'm not sure if the module offered manipulations on the SASS values themselves, but that can technically be achieved too by a script that runs upon saving a change on ThemeDesigner and stores the results in a stylesheet.

I am currently working on a stylesheet that exposes the most useful theme variables via some consistent classes, allowing to reference them in the Wikitext.

Nam 11:30, 17 November 2021 (UTC)