Last modified: 2014-05-14 01:56: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.
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).
Adding 1.20 blocker. If possible sooner, but not after 1.20 imho.
(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, but I'm not sure how it works.
Replied there, at comment 3's .
(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.
(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)?
(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.