Last modified: 2014-05-14 01:56:04 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 30358 - Make client-side loader load site and user modules
Make client-side loader load site and user modules
Status: NEW
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.20.x
All All
: High enhancement (vote)
: Future release
Assigned To: Nobody - You can work on this!
:
Depends on: 33837
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-13 08:52 UTC by Roan Kattouw
Modified: 2014-05-14 01:56 UTC (History)
7 users (show)

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


Attachments

Description Roan Kattouw 2011-08-13 08:52:04 UTC
The site and user modules are currently loaded with <script> tags that are injected into the HTML from the PHP side. This is apparently done because they need to be loaded with only=scripts (so they're not wrapped in a closure) and need to be loaded last, after anything else. These things are a bit tricky but not impossible to support in the client-side loader, and loading them from the client side will allow us to timestamp the site module (which currently isn't timestamped because anons get it as well), improving caching efficiency by caching it for 30 days instead of 5 minutes. The user module is already timestamped by PHP, which is OK because logged-in users bypass Squid.

We can't combine the site module with any regular modules due to these requirements. We also can't combine the site and user modules in one request because that would cause insane cache fragmentation.
Comment 1 Krinkle 2011-08-28 23:18:23 UTC
We can already make them load separately afaik by putting them in different groups with the group property of the ResourceLoaderModule.

Why is only=script/no-wrapper needed though ?

Loaded 'after anything else' is a bit tricky right now. It assumes that everything before (both top/bottom queue) has loaded before that <script> tag and was synchronous, we already know that isn't the case. Some kind of über dependency ?

I'd say let it only depend on the default core and legacy module(s), and recommend stuff that has other dependencies to be put in gadgets after MediaWiki 1.19 (which will have the 'default' and 'hidden' property and support for dependencies).
Comment 2 Krinkle 2011-08-28 23:19:21 UTC
Adding 1.20 blocker. If possible sooner, but not after 1.20 imho.
Comment 3 Helder 2012-05-21 00:46:05 UTC
(In reply to comment #1)
> MediaWiki 1.19 (which will have the 'default' and 'hidden' property and support
> for dependencies).

Is this "hidden" property documented anywhere? I found it in use on commons[1], but I'm not sure how it works.


[1] [[commons:MediaWiki_talk:Gadgets-definition#Hidden_gadgets.3F]]
Comment 4 Krinkle 2012-05-21 17:20:23 UTC
Replied there, at comment 3's [1].
Comment 5 Krinkle 2012-05-21 17:34:12 UTC
(In reply to comment #0)
> [..] This is apparently done because they
> need to be loaded with only=scripts (so they're not wrapped in a closure) and
> need to be loaded last, after anything else. [..]

I think we can start removing support for implied globals in 1.20 for user-generated content in site/user scripts. We already did that in 1.17 for core, extensions. And Gadgets 2.0 will do it for gadgets.

(In reply to comment #0)
> We can't combine the site module with any regular modules.

This would be redundant if we drop the above 2 requirements. We can still put them in a separate group to avoid cache fragmentation though.
Comment 6 Helder 2012-11-01 20:14:33 UTC
(In reply to comment #5)
> I think we can start removing support for implied globals in 1.20 for

1.21 now. Any progress on this (and Gadgets 2.0)?
Comment 7 Krinkle 2012-11-01 21:38:13 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > I think we can start removing support for implied globals in 1.20 for
> 
> 1.21 now. 
That is bug 33837.

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


Navigation
Links