Last modified: 2014-05-14 01:56:04 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T32358, the corresponding Phabricator task for complete and up-to-date bug report information.
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