Page MenuHomePhabricator

Add support for loading wiki pages as scripts/styles in ResourceLoader
Closed, DuplicatePublic

Description

Author: a.d.bergi

Description:
Today you only can load modules that are specified by MediaWiki, e.g. jQuery extensions, RL-Gadgets and mediawiki-utilities (legacies), and static uris with the ressource loader.

I already thought about registering user-script-modules, e.g. last lines of http://de.wikipedia.org/wiki/Benutzer:✓/js/deSecure.js. Here other scripts can use the mw.loader.using method, I chose "user.<usernick>.<scriptname>" for the module name analogous to "ext.<extensionname>", "jquery.<modulename>" etc. You already can use the mw.loader.register method to set dependencies, load some system messages per api, specifiy css (or load from api) and design a to-be-executed function, and then mw.loader.implement() them to your module.

But this needs up to 3 file loads (script file with function, dependencies and implementation; messages api; css file) and is used by a call of mw.loader.load(<static url of script file>). Also the dependencies don't work as you use other user scripts, which would cause a request ending up in state:missing when they're not loaded then and preventing the real implentation by that.

A better way would be loading them one-in-all (and not module by module, see T28291), just by one simple module request that specifies project (+project language), user, module name and i18n (message language, by default uselang).
Of course for detecting every modules' messages and dependencies either a auxiliary page (like in the Gadget extension) or a preprocessing of the script page would be needed. I'd propose the latter, this could be done like a /* comment */ at the top of the page where the module creator can specify dependencies, messages and CSS-pages to be embedded in one call of loader.implement. The function would be either a also specified one or the rest of the script.


Version: unspecified
Severity: enhancement

Details

Reference
bz27535

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 11:22 PM
bzimport set Reference to bz27535.
bzimport created this task.Feb 18 2011, 2:12 PM

Bugzilla is configured in a stupid way that makes me put a comment here; it won't let me mark this as a duplicate otherwise.

  • This bug has been marked as a duplicate of bug 25845 ***

a.d.bergi wrote:

I knew that bug already, but it seems to request the provision of a non-uri-load function (aokomoriuta in c9: "It's just to make a helper method").
My proposal is about a feature in load.php to deliver a definable set of user pages together as one module.

Michael Dale had similiar intentions (c5, c8):
"The important part is they have a way to transition [user scripts] into normal named modules"
"support a simple interface or SpecialPage for defining
what page resources ( and associated messages / dependencies for thous
resources ) are globally used on a given wiki, this way their versions numbers
can be included in the start-up module definitions"

I think a separate bug should be filed for this issue.

Changing the scope of the bug a bit.

Right now RL loads wiki pages in two places: Site-scripts (MediaWiki:Common/skinname.js/css) and user-scripts(User:Name/common/skinname.js/css).

We should simply make this into public functionality rather than internally for those two modules:

/* Example */
['ext.Something'] = array(
'scripts' => 'resources/something/something.else.js',
'styles' => 'resources/something/something.else.css',

'wikistyles' => 'MediaWiki:Something-customize.css', <!-- from the wiki
'wikiscripts' => 'MediaWiki:Something-customize.js',
<!-- from the wiki

'dependencies' => 'jquery.ui.dialog',
'messages' => array( 'something-title' , 'something-options' ).
);

That way those would simply be included in the same http request and minified/combined (just like site/user scripts are now)

a.d.bergi wrote:

I think we have to avoid loading CSS per RL, because there are still clients out there with no / too old / disabled javascript.
The only case for allowing this is when the CSS-pieces are needed (only) for and request by some scripts (gadget or user script).
Any modules which contain script-independent CSS (site, user, css-only-gadgets) should be requested by a static link-tag in the documents head.

Marking invalid.

See also:

  • (bug 27561) Register modules client side
  • (bug 25845) Support loading wiki pages through mediaWiki.loader.load()
  • creating/loading a wikimodule on the server side has also implemented (don't know the exact bug id)
  • loading wiki modules via .php is also possible, to do this one has to add [ResourceLoader] to it's gadget definition.
  • Loading one ore more raw wiki pages as js/css resources through load.php (without them being an actual module) is likely to be implemented as part of bug 25845.
Rical added a subscriber: Rical.May 5 2015, 8:27 AM

For 2 months, to help to manage evolutions of complex modules with many sub-modules, I implements a versions manager (in debug phase), and to day I see here in the description "module creator can specify dependencies".

Sorry if I am not exactly in the good place, but I work on a linked implementation.

In my implementation, each module describes in its header a selector of versions and a descriptor of all versions existing. When launched, a main module calls the ControlArgs.modules_builder(p). Each module have its own <module>/18N with any number of translation tables also loaded for all sub-modules.
See the central part of the manager in versions.init_i18n(d) in https://fr.wikisource.org/wiki/Module:ControlArgs
and the main module dependencies descriptor in p.versions in https://fr.wikisource.org/wiki/Module:Author3

He7d3r updated the task description. (Show Details)May 5 2015, 10:15 AM
He7d3r set Security to None.

This task is not about Scribunto modules, but about ResourceLoader modules (i.e. JavaScript/CSS).

Rical removed a subscriber: Rical.Jul 21 2017, 9:39 AM