Last modified: 2014-11-17 10:35:50 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 27535 - Add support for loading wiki pages as scripts/styles in ResourceLoader
Add support for loading wiki pages as scripts/styles in ResourceLoader
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Trevor Parscal
:
Depends on:
Blocks: 27561
  Show dependency treegraph
 
Reported: 2011-02-18 14:12 UTC by Bergi
Modified: 2014-11-17 10:35 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Bergi 2011-02-18 14:12:28 UTC
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 Bug 26291), 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 spezified one or the rest of the script.
Comment 1 Roan Kattouw 2011-02-18 17:30:09 UTC
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 ***
Comment 2 Bergi 2011-02-19 13:25:20 UTC
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.
Comment 3 Krinkle 2011-02-19 15:22:24 UTC
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)
Comment 4 Bergi 2011-02-19 16:09:09 UTC
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.
Comment 5 Krinkle 2011-04-13 15:04:58 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links