Talk:ResourceLoader

This page used the LiquidThreads extension to give structured discussions. It has since been converted to wikitext, so the content and history here are only an approximation of what was actually displayed at the time these comments were made.

Top-loaded site scripts

Latest comment: 14 years ago8 comments2 people in discussion

Is ResourceLoader 2 going to fix the issue with scripts loading after a significant delay after the rest of the page loads? Yair rand 19:04, 31 May 2011 (UTC)Reply

I don't intend to be a nag here, but the title for this thread and the contents of your message are somewhat addressing different, albeit overlapping, issues.

I'll answer them seperately.

Loading scripts from the top of the document

As of ResourceLoader 2 a module can be registered with one of various queue names. The default is 'bottom', which means the all-in-one load request will be initiated from the bottom of the page (after the output of the article, but stilll a fair distance away before the document-ready event).

This queue should be used to load scripts that affect the page independant from on-or-after-load scripts. A good example is the stylesheet that applies to HTML generated by PHP. For example Extension:CodeReview and Extension:LiquidThreads output HTML via PHP through Special pages and other means. The styling for this HTML should be loaded before the rest of the page is loaded (otherwise there'd be a moment of unstyled content, which is bad).

For these scenario's the "position" property of the module registry should be set to "top". Which means the module will be loaded from the top of the page and will, just like any ‎<script> tag does in the ‎<head>, block page execution untill it's parsed and executed.

Load delay

There were some issues in RL1 (most are fixed, some are pending) with the order and speed of the modules loaded. These should not be resolved by injecting the modules earlier (ie. "position" => "top") as this will either fail or have an effect that doesn't do what one might think (either way, it's evading the issue at hand).

Scripts that only affect a later state of the page or bind event handlers should not be loaded from the "top" (because these elements do not exist yet at that time, "top" basically means before ‎<body> exists).

The reason that doing so might have side effects is due to dependancies. If a script wrongly puts itself in the "top" position and depends on another module (ie. jquery.ui.dialogs), that means that all of jquery.ui.dialogs (and it's dependancies: jquery.ui.core, jquery.ui.widget, jquery.ui.button etc. which also have dependancies that load) are now all loaded in the top of the page, because that one module needs it.

That would slow down the page noticably.

If scripts execute with a delay, please report it as soon as possible. If you can, check out a copy of the current development trunk (svn checkout http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3 w) via Subversion so that you can see if the current solution and improvements work for you and solve the issues you had. (By doing that we can catch and resolve problems before you need to start thinking about work-arounds, because it's still in development and nothing is in release or deployment yet!) Krinkle 20:26, 31 May 2011 (UTC)Reply

On Wikimedia wikis, all site JS is loaded after a delay since 1.17 was launched. Everything from slight changes in things like tab appearance (w: only displays "Main Page" instead of "Article" a while after the page loads) to major DOM modifications (which is a necessity on some wikis) do not work optimally, causing the page to click/pop/jump into showing the right content after a delay instead of the way it used to be, with essentially zero delay in which the wrong content is displayed. Yair rand 21:54, 31 May 2011 (UTC)Reply

Indeed.

I still notice pages jumping, mostly when I click in the link to a specific section (e.g. of the village pump) and when the page finishes loading the section displayed is not the one I wanted. More info at:

Wikipedia runs the latest almost-stable release of MediaWiki (currrently MediaWiki 1.17)

This was fixed in the live development branch ("trunk", currently aimed at MediaWiki 1.19). I've made and ran tests for this and they look at lot better than it did in 1.17.

If you feel like testing this yourself, please install MediaWiki yourself (from svn trunk that is, not from Download). Krinkle 16:09, 2 June 2011 (UTC)Reply

Like I said in the initial post, whether the page jupms right now in Wikipedia is not entirely relevant because nothing changed there. Wikipedia runs the latest (almost) stable version, not the development version that we are working on (eg. "the next version").

The development version is not stable yet for use on Wikipedia, however to verify that your issue has been resolved, please test it on the development version and not on the live site.

It would be crazy to apply this fix to Wikipedia before we know wether it actually works for all the use-cases. It would be helpful if you could install a copy of the Subversion development and see if the issue is resolved there.

Thanks. Krinkle 14:16, 10 July 2011 (UTC)Reply

Oh, and I really don't understand exactly how top-loading and JS delays are separate issues. If scripts are loaded at the bottom, there will always be a delay, unless I'm mistaken. How could the delay be removed unless the scripts are loaded before the content and the functions are activated immediately or almost immediately after the load of #footer? (And re: your example of the dependencies, I really doubt it's at all common that one would need complex jQuery modules immediately upon loading.) Yair rand 16:56, 1 June 2011 (UTC)Reply

My point exactly, I believe we are in agreement here!

If a script does not need a complex jQuery module tree, it should not be loaded in a way that is blocking page-display.

For example, suppose there's a script that enables one to do complex stuff with categorization in the "Categories: "-box on the bottom of the article through ajax queries and jQuery UI dialog boxes. That entire gadget (including all of the jQuery modules) don't have to be loaded before the article is displayed.

Ideally this gadget would be seperated into two (or more) modules of which one is loaded in the head (the one that adds a button to the tabbar or whatever), and the rest of the script at the bottom. Krinkle 14:21, 10 July 2011 (UTC)Reply

Is there any way to do that, and have one gadget include multiple parts that are loaded at different points, the first part activating immediately and the second loaded later? (Note that in some cases it's necessary for a script to rework the entire content of a page, in which case all that matters is how long it takes between the bodycontent loading and the script starting to work, which will be longer than ideal unless the script was loaded before and nothing happens between #footer loading and $.ready() starting the function, so content-blocking doesn't matter in the slightest.) Yair rand 12:17, 12 July 2011 (UTC)Reply

Is it possible to load resources from a different URL

Latest comment: 13 years ago10 comments5 people in discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Hi,

I'm trying to load all the static resources (js, css and image files) from a separate URL (a CDN actually), and using $wgStylePath has the images working just fine, but all the css and js loaded through the ResourceLoader still comes from the original domain.
Is it possible (now in 1.17.0 or in the future) to make these files load from a different URL?
Thanks,
-Dan 199.247.190.198 00:54, 16 October 2011 (UTC)Reply

Wikipedia does this as well, they load resources through http://bits.wikimedia.org/

To achieve this set $wgLoadScript to where you want requests for load.php to end up.

Note that this means that your CDN needs to have access to your database, MediaWiki and your configuration. Krinkle 19:59, 16 October 2011 (UTC)Reply

Thanks for the answer.

From my testing, setting $wgLoadScript also means the CDN has to be able to execute PHP (load.php), so in other words it has to be a full-on webserver, not just a static file server (as 99% of all CDNs are). The fact that it also needs to access the db and LocalSettings.php means it probably has to be on the same subnet, etc.

I'm starting to wonder about this resourceloader - it goes to a lot of trouble to minify a ton of css and js on every single request, using php to do so, and hitting the main web server (in this case, memory-hungry Apache).

Wouldn't it be better to minify as many of those files as possible beforehand and just serve them as they are (and then they can also come from a static-file-server CDN somewhere else on the internet (ie. entirely different subnet, etc.) ?

Is there any way to achieve this?

Thanks again,

-Dan 199.247.190.198 00:23, 17 October 2011 (UTC)Reply

Well depending on your set up, it obviously is not intended to go through all minification, combination, embedding, localization etc.

Because of various unique combinations in the URL such as the version timestamps that ResourceLoader includes in requests to load.php, these requests are highly cachaeble!

Because of the wide range of scenarios that MediaWiki has to support to be able to scale to a platform like Wikipedia, it needs access to the filesystem and the database. (Consider localization into over 300 languages including right-to-left and non-latin languages, support for user-preferences that allow users to change the skin on a per-user base (and thus changing the modules to be loaded), gadgets (enabling custom scripts), scripts from extensions loaded only under certain conditions)

The way Wikipedia has this set up is by using a reverse-proxy like Squid or Varnish that serve a static cache of all resources and, because of the timestamps, it can cache these requests "for ever". Whenever a module has changes (which won't happen for an average MediaWiki install unless you upgrade MediaWiki, change configuration files or install/uninstall extensions), it will use the new timestamp in the request for that module, thus changing the url to load.php. Then the bits-server will only initiate MediaWiki if there is no static cache for the url.

According to the stats as of August 2011, bits.wikimedia.org/../load.php has a cache hit ratio of 98.2%. For all those requests MediaWiki was not initialized, no database connection etc.

However a simple static-file-server CDN does not suffice. It's not impossible to use a static-file-server CDN, but no implementation for that was made as Wikipedia uses Varnish as a reverse-proxy for cache. You could contact User:Catrope if you're interested in building in support for a static-file-server CDN (e.g. somehow upload static files through FTP or something to that CDN when new ones need to be generated and embed or 301-redirect to those urls directly. Krinkle 17:06, 17 October 2011 (UTC)Reply

Thanks for the great explanation Krinkle, I understand the situation much better now. The timestamp-on-the-resourceLoader-URLs makes a lot of sense for a reverse-proxy cache like Varnish

I had always intended to put Varnish in front of MediaWiki/Apache at some point, so I'll focus my efforts there instead of trying to offload more stuff into a static file-serving CDN.

Thanks again!

-Dan 199.85.228.100 17:16, 17 October 2011 (UTC)Reply

It said 98.2% on the slide Krinkle 21:06, 18 October 2011 (UTC)Reply

You meant 99.8% ;) . Also, all Wikimedia wikis run off four web servers with a total of nine Varnish servers (in two different data centers) in front of them. And those four Apaches barely get any load; their CPU usage is like 10% so in theory ResourceLoader could run off a single Apache. See also our OSCON presentation, and the slide with these numbers. --Catrope 19:14, 18 October 2011 (UTC)Reply

From your description, we could setup anything for load.php to goto the CDN. If the CDN uses our server as the origin (and includes the query params as part of the caching) then the very first request hits our server and what it produces is imminently cachable by the CDN (forever).

So why couldnt we use a CDN (with no Varnish, no access to the DB etc.) with load.php? 204.14.239.208 20:50, 19 February 2013 (UTC)Reply

Nobody is saying you can't use a CDN. If you have a CDN that works the way you just described (automatically pulling uncached urls from your origin web server, including query parameters), then by all means, go for it :) Krinkle (talk) 01:46, 23 February 2013 (UTC)Reply

You're welcome.

If you'd like to know more about Wikipedia's configuration feel free to join #wikimedia-tech ^connect on IRC. Krinkle 21:13, 17 October 2011 (UTC)Reply

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Compression on javascript requests not working

Latest comment: 9 years ago4 comments3 people in discussion

I'm using MW 1.18.1, and all requests going to MW have "Accept-Encoding gzip, deflate".

css requests loaded by the Resource Loader are compressed with "Content-Encoding: gzip", but javascript requests are not.

The following examples are the only two Resource Loader files being compressed:

http://example.org/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cskins.vector&only=styles&skin=vector&*

http://example.org/load.php?debug=false&lang=en&modules=site&only=styles&skin=vector&*

Which are both text/css.

The following examples are not being compressed:

http://example.org/load.php?debug=false&lang=en&modules=startup&only=scripts&skin=vector&*

http://wikioverland.org/load.php?debug=false&lang=en&modules=skins.vector&only=scripts&skin=vector&*

In all there are 7 requests to /load.php? that are not compressed, they are all text/javascript.

I have verified zlib is correctly installed in Apache. I am NOT using $wgDisableOutputCompression

Thanks,

-Dangrec 00:40, 14 February 2012 (UTC)Reply

I am seeing the same thing in MW 1.21 (i found these because Google analytics page speed analysis complained about them). Any suggestions? Thanks a lot. Wikihy com (talk) 12:16, 10 November 2013 (UTC)Reply

Found the solution: edit /etc/php.ini and set zlib.output_compression to "On". Then test with http://www.whatsmyip.org/http-compression-test/ or Google Analytics. Wikihy com (talk) 18:53, 10 November 2013 (UTC)Reply

Thanks a lot. This helped me too. Google complained about 5 load.php statements not being compressed (as far as I can see 4 scripts and 1 style). After setting zlib.output_compression to "On" all is compressed :) Stefahn (talk) 12:27, 23 May 2016 (UTC)Reply

Getting error filemtime() stat failed in resourceloader

Latest comment: 14 years ago2 comments2 people in discussion

Hi, I am gettting this error in log file when i loading mediawiki web app on public domain. Error: filemtime() state failed at resourceloaderfilemodule.php is that serious error because page taking time in response more then 1 minute.can any one tell why it is happening.? I am using mediawiki1.17, IIS7.5 and oracle11g, server 2008 R2

my url is: [clickhere]

Thanks Rahul 14.139.58.34 07:55, 7 April 2012 (UTC)Reply

You should upgrade to MediaWiki 1.19, which has the lastest security fixes and also fixes some of the filemtime errors we've been seeing previously. If the errors still happen after upgrading, please ask again. Catrope (talk) 00:03, 14 April 2012 (UTC)Reply

Suggested feature: What links here?

Latest comment: 8 years ago4 comments3 people in discussion

I'm happy with your exercise and I'm really looking forward to see the delivery. If it is not too late, I have one suggestion:

The address may be enclosed in double brackets.
Reason: the code .load('[[User:Foo/helpful.js]]') generates entries on What links here?
Until now it has been common practice to ask users to add a comment // [[User:Foo/helpful.js]] in order to get knowledge about other users.
That might be helpful to be aware of the number of other people influenced by changes, if the script is developed for common usage. It might be necessary to Talk: to others if behaviour of script changes significantly.
To avoid caching problems after bugfixes, friends were to be informed and asked to clear the cache -- I understood that the RevID will be appended to the URL in the future.
Stripping off enclosing brackets seems to me quite easy. PerfektesChaos 23:24, 10 May 2012 (UTC)Reply

Hi PerfektesChaos,

Thanks for taking the time to write up this feedback. It's most welcome!

To get right to the subject, right now ResourceLoader is not and can not be used to load user scripts. User scripts are a (powerful) invention by the community that has shown great results and makes sharing really easy, however they are currently not natively supported by the MediaWiki software. Scripts are stored on (technically article-like) normal wiki pages, and the method to load the raw wikitext (action=raw) is used to load it without rendering and thus, when the url is inserted into an HTML ‎<script> tag, it is executed as javascript.

To make this easier to do for the community, the developers have added the popular importScript() function to the core software so that it doesn't have be created from scratch on each wiki.

Also Extension:Gadgets was created which makes writing scripts even easier and is ultimately how scripts should be managed. Since Gadgets are built as an extension and connect into the right MediaWiki hooks, all the native features are available for Gadgets. That includes

efficient loading of scripts and styles (combined and compacted into a small package, re-uses this cached package whenever possible, based on:
automatisch cache clearing (cache identified with a unique module name and timestamp of when it was last modified)
(and, soon also:) internationalization / translation (Gadgets 2.0 is on it's way, as part of the RL2 project).
"usage" tracking (through the preferences). See w:Wikipedia:Database_reports/User_preferences#Gadgets for example.
loading other modules as part of your module ('dependencies')
and more..

But what it can't do is create gadgets on a per-user level (only on a per-site level). This is a much requested feature, but currently not possible yet in an efficient and scalable way (requires a few other changes as well). But I expect that this will be implemented as part of Gadgets 3.0.

So to get back at your suggestion. Although you can use mw.loader.load() right now to load a url of choice (including, but not limited to, urls to the current wiki where your user script is stored), that is just loading it as a url (just like importScriptURI does), that is not really a feature of ResourceLoader. And as such, since user scripts technically don't exist as a feature, ResourceLoader can't create an alias for it in the existing system.

Since the environment in which user scripts are written has changed a lot in the past few months/years, I don't think it is a good idea to make any more changes that require (or motivate) a lot of changes (such as changing to format to .load('[[Page name]]'). Instead focus on keeping the environment stable, while developers work on a solution to migrate away from user scripts (the current scripts will continue to work, don't worry)... to a solution that allows the same (and more) functionality in a better way that

does integrate with ResourceLoader
allows creation and modification of gadgets on a user-level
easy sharing with other users (and other wikis)

..in other words: Gadgets 3.0, in which users can create their own fully-featured Gadgets!

So for now I'd recommend to stick with what already users know, use and will work fine:

// [[Namespace:Page name]]
importScript('Namespace:Page name')
/* or */
// [[Namespace:Page name]]
mw.loader.load('https://www.mediawiki.org/w/index.php?title=Namespace:Page_name&action=raw&ctype=text/javascript');

Krinkle (talk) 23:44, 10 May 2012 (UTC)Reply

ResourceLoader 1.46.233.191 (talk) 04:52, 10 January 2018 (UTC)Reply

ResourceLoader ใบอนุญาต CC BY-SA 3.0 1.46.233.191 (talk) 04:53, 10 January 2018 (UTC)Reply

Conditional script inclusion (e.g. < if lt IE 9 > )

Latest comment: 13 years ago3 comments2 people in discussion

My apologies if I failed to see some notes about conditional script inclusion but in a case a browser requires a pre-IE 9 script (add an additional JS script only for that particular situation), how is one to work around this problem with the ResourceLoader.

For example:

<!--[if lt IE 9]><script language="javascript" type="text/javascript" src="excanvas.js"></script><![endif]-->

Register a separated module but it should only be loaded in case the necessary conditions are due to (pre-IE 9).

$wgResourceModules['ext.srf.excanvas'] ...

Which method in the RL/JS could be used to load this module so that the condition [if lt IE 9] is met? MWJames (talk) 10:17, 3 July 2012 (UTC)Reply

This is currently not supported by ResourceLoader. However MediaWiki in general (the OutputPage class that builds the page output) does support it. You may use one of the following two methods:

To load a complete module: Use OutputPage::addScript in combination with Html::inlineScript. For example:

$excanvasLoad = Html::inlineScript(
	ResourceLoader::makeLoaderConditionalScript(
		Xml::encodeJsCall( 'mw.loader.load', array( 'ext.srf.excanvas' ) )
	)
);
$out->addScript( '<!--[if lt IE 9]>' . $excanvasLoad . '<![endif]-->' );
);

To load a single css file (raw, without minification and other ResourceLoader processing): Use OutputPage::addStyle( url, media, condition ) where url points to a file directly. For example:

$out->addStyle( 'modules/IE70Fixes.css', 'screen', 'IE 7' );

Alternatively you coud use mw.loader.using( 'ext.srf.excanvas', function callback() { .. } ); from within your main module code, to load it on-demand when you need it and the browser is IE. Like this

-- modules/ext.James.display.js
var james = {
  init: function () {
    $(document).ready( function () {
      /* do canvas stuff */
    });
  };
};
var p = $.client.profile()
if ( p.name === 'msie' && p.versionNumber < 9 ) {
  mw.loader.using( 'ext.srf.fallback', james.init );
} else {
  james.init();
}

Krinkle (talk) 20:46, 4 July 2012 (UTC)Reply

Thanks, that was very helpful. MWJames (talk) 09:27, 5 July 2012 (UTC)Reply

Loading webfonts via ResourceLoader causes White Screen of Death in IE 6,7,8

Latest comment: 13 years ago1 comment1 person in discussion

Loading my webfonts CSS file - a file which contains only the @font-face statements for the webfonts - via ResourceLoader causes a WSOD (invisible content, links can be clicked but nothing is visible and text cannot be selected) in all versions of IE I can test (6,7,8). Changing it to be loaded via addStyle() (and thus not minified) solves the problem.

I'm experiencing this on http://practicalplants.org

Any ideas why? Is it a known issue? Is there any debugging I can do to see if this is a bug that needs reporting?

Thanks Andru 5.8.188.150 18:10, 7 August 2012 (UTC)Reply

RL fails silently

Latest comment: 13 years ago2 comments2 people in discussion

Hi Timo,

Just to confirm an observation, I had several occasions where when a file that is defined as style resources can not be found at its location the RL fails silently for this resource definition and with all its incorporated definitions. Unfortunately the resource is still somehow registering (I can see the that mw.loader.load still list the resources as valid) but fails to execute its functions specified in the JS even though the only file that is missing is the css file. This same behaviour has been observed with MW 1.19.1 and 1.20alpha (abad0ee). Cheers MWJames (talk) 09:37, 8 August 2012 (UTC)Reply

Hi,

It doesn't fail silently, it just isn't as visible as one might expect. It used to throw fatal exceptions. Since then we changed it to be less visible but still prevent features from breaking. This is done by using the "error" state in the module registry. If a module has any issues whatsoever it will still be registered and stuff won't break, but when it is needed on-demand, it will respond with an error code, so any callbacks queued to run when the module is loaded (e.g. anything having it as a dependency or the first callback from mw.loader.using) will not run. This is so that mw.loader.using('mediawiki.x', function () { mw.x.foo(); }); will not break by either calling an undefined function, or by initializing a module that is missing styles or internationalization messages.

Assuming that code is written sane and clean and does not make assumptions, this will work fine. Because if the entire module and wherever it is a dependency for is not loaded, it means nothing will look broken (there may be features absent, but that should be fine). Sometimes this can cause unexpected problems if modules are intermixed without proper dependency declarations.

So back to where the failures are observable, they can be seen in two places:

Client side: the load.php will output the exception + stack trace in a block comment on top of the script or stylesheet (both in debug mode and in production mode). To check it out its best to use the debugger in your favorite browser (e.g. the Resources tab in the Chrome Developer Tools) to view the individual requests.
Server side: The php error should be logged somewhere depending on your php, apache and mediawiki configuration. Krinkle (talk) 18:34, 9 August 2012 (UTC)Reply

RL and the use of mediaWiki global namespace

Latest comment: 13 years ago2 comments1 person in discussion

Hi Timo,

Again, sorry to bother you but when I went over the JavaScript Globals it states that The only globals should be mediaWiki and jQuery ... all code should be written as an extension to either of these ....

Is their a global namespace register for RL so that with the respect to the mw/mediaWiki namespace it would be possible to register mw.smw and mw.srf (as part of the Semantic MediaWiki or Semantic Result Format extension family) and avoid potential namespace conflicts with the core or other extensions in future.

Of course I could just go like $.fn. ... but it might be nice to expose functions via mw.srf.util = util

Cheers,

mwjames MWJames (talk) 02:10, 30 August 2012 (UTC)Reply

Maybe "mw.libs", which is described as "Empty object that plugins can be installed in" in the source code? Helder 14:03, 30 August 2012 (UTC)

I guess this doesn't really solves the problem as the issues is shifted only downward to mw.libs. Unless I'm missing something, there is a possibility that two different projects occupied the same namespace and using the same function name (virtually unlikely) which can potentially cause trouble.

The question was more directed towards something like Namespace registration as a non binding register for JS module names. MWJames (talk) 16:21, 30 August 2012 (UTC)Reply

RL, media=print and print-only style sheets

Latest comment: 13 years ago6 comments2 people in discussion

Any idea how to use RL in connection with print-only style sheets so that when media=print (I might be mistaken but it seems that a wikipage when it is rendered with &printable=yes does not create media=print tag) is set the print-only style sheet is loaded instead of the "standard" style sheet? MWJames (talk) 10:50, 5 October 2012 (UTC)Reply

The skins.modern module is a great example:

	'skins.modern' => array(
		'styles' => array(
			'modern/main.css' => array( 'media' => 'screen' ),
			'modern/print.css' => array( 'media' => 'print' ),
		),
		'remoteBasePath' => $GLOBALS['wgStylePath'],
		'localBasePath' => $GLOBALS['wgStyleDirectory'],
	),

The $GLOBALS stuff is part of how core modules are defined in resources/Resources.php, you can ignore that. The important part is the 'media' => 'print' part. Catrope (talk) 17:25, 5 October 2012 (UTC)Reply

This is a neat trick. Now the only problem I seem to have is that only when I choose &debug=true (to check on which resources are loaded) that the print CSS does its job but as soon as I choose no debug mode the CSS switches back to the on screen CSS while I'm still in &printable=yes. This behaviour was located on a MW 1.20alpha (1a7da4f) test system. MWJames (talk) 01:02, 6 October 2012 (UTC)Reply

Are the styles loaded by your browser? Do they apply in "print preview" mode in your browser? Catrope (talk) 01:24, 6 October 2012 (UTC)Reply

Styles are loaded by the browser and I can see visual changes when switching between the debug modes (&debug=true) in &printable=yes. When watching firebug I can see that (in &debug=true) styles are loaded from the print resource but as soon I'm not using the debug mode the loaded print related styles start to disappear. (This scenario has been tested without active cache/deleted cache files on the server and browser.) The browser own "print preview" shows to apply the right CSS. MWJames (talk) 03:13, 6 October 2012 (UTC)Reply

Just realized that when using &debug=true it loads both style sheet definitions (screen and print) because even when not using &printable=yes the print CSS overloads the screen CSS on a normal page view (this just happens for &debug=true) which let me think this might be the intended behaviour where &debug=true doesn't care much about the media and just loads all definitions it has found in the resource array. MWJames (talk) 03:29, 6 October 2012 (UTC)Reply

RL, load <noscript> related script

Latest comment: 13 years ago2 comments2 people in discussion

I couldn't find any example of how to adopt the array definition for cases of <noscript> where a separated CSS script should be loaded instead. MWJames (talk) 14:09, 9 October 2012 (UTC)Reply

noscript isn't really supported very well. If you have CSS that must be loaded no matter whether JS works or not, you can use addModuleStyles() instead of addModule(). This only adds the CSS belonging to a module, but adds it as a <link> tag rather than dynamically. The caching behavior is worse this way, but the CSS will always load even if JS doesn't work. MediaWiki uses this to load skin CSS. Catrope (talk) 21:09, 10 October 2012 (UTC)Reply

Cache consumption

Latest comment: 12 years ago6 comments3 people in discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Hi, sorry if this is a wrong place to ask ... in our install of Mediawiki 1.19 (http://wiki.geogebra.org/en/Special:Version ) the ResourceLoader stores some Javascript which contains timestamps: [["site","1352754747",[],"site"],["noscript","1352754747",[],"noscript"],["startup","1352859900",[],"startup"],["user","1352754747",[],"user"],["user.groups","1352754747",[],"user"],["user.options","1352859900",[],"private"],["user.cssprefs","1352859900" ... in the cache (objectcache table in MySQL) with expiration date 2038. I guess such entries are never hit (as they contain timestamps, which are often unique for unregistered users) and since of the long expiration date they fill the cache -- in a couple of weeks it grew to 690MB. What's the best way to circumvent this problem? Zbynek (talk) 03:23, 14 November 2012 (UTC)Reply

Ouch, that's a problem. The cache keys in question probably contain the word 'minify' and an md5 hash, right? If so, it's the JS minifier cache, which caches the result of JS minification, and because the same original code always results in the same minified code, it's cached forever as it can never change.

I'm afraid that for now you'll have to periodically purge the objectcache table of keys with this pattern; I've filed a bug about it, and once it's fixed, there will be a patch that you can apply that addresses this behavior. But it may take up to a few months for this patch to get written, unfortunately. An alternative workaround is to use memcached instead of the DB cache; if you have enough users that you're producing >30MB/day in cache cruft, that might be a good idea anyway. memcached uses a fixed maximum size for its cache, and when the cache fills up, it will start throwing out (evicting) old entries, with the least recently used (LRU) entries getting evicted first. This is what we use on our production wikis (Wikipedia and sister sites) as well.

Thanks for the report, this is a quite nasty issue that we hadn't heard about before. We never experienced it ourselves because we use memcached, which is not affected by this problem as it automatically removes unused entries if the cache grows too large. Catrope (talk) 06:20, 14 November 2012 (UTC)Reply

Thanks for the fast reply! Yes, the keys contain "minify". We will consider switching to memcached, but for now I've just hacked ResourceLoader.php -- instead of

$cache->set( $key, $result);

we now use

$cache->set( $key, $result, time()+86400);

I guess this hack would be a bad thing to do on a large wiki, but it should be OK for our medium sized one (~5k pageviews per day). Zbynek (talk) 12:58, 14 November 2012 (UTC)Reply

That should be fine, it'll expire the minifier cache after a day that way. Even on a large wiki, that would just be a minor annoyance, not a real problem. In fact, we might actually end up with something similar to that as a fix. Catrope (talk) 15:05, 14 November 2012 (UTC)Reply

Hi Catrope,

I was wondering what the bugId number was for this issue. We too have been having this issue (mw 1.18) on our corporate site where the objectcache table grows past a a few GB (at one point it was 28gb). After a while I just go in there and run TRUNCATE TABLE objectcache; to fix it up, however this is not the correct solution.

I recently checked the latest build, 1.20.4 to see if something like the suggested fix was placed in ResourceLoader.php, but did not see it. I was hoping to find the modify for $cache->set( $key, $result ); to something like, $cache->set( $key, $result, time()+86400);.

We love using MW here for our development and support personnel. This bug is our biggest show-stopper and want to upgrade to the latest version, but i want to make sure before I take our site down for maintenance.

Thank you! and keep up the good work Dsuess (talk) 03:06, 27 April 2013 (UTC)Reply

https://bugzilla.wikimedia.org/show_bug.cgi?id=42094 is the bug number.

(Sorry for the late response, I don't monitor this space very well.) Catrope (talk) 10:57, 24 May 2013 (UTC)Reply

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

How to make load.php and the resource loader use versioned resource URLs

Latest comment: 13 years ago1 comment1 person in discussion

My load.php data is cached (by my CDN, BTW) for just 5 minutes - in line with the $wgResourceLoaderMaxage settings for "undersioned" URLs.

How do I make mediawiki use versioned resources? Bodaro (talk) 01:00, 22 February 2013 (UTC)Reply

addMeta line to skin

Latest comment: 13 years ago1 comment1 person in discussion

I seem to be having a lot of trouble with something that is probably simple. I need to add a meta line into the head of only one of the skins, but "$out->addMeta('viewport', 'width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=yes;'."\n");" does not work. It seems to just ignore it in 1.20.2. Is there an easy way to do this without having to deal with extensions and such? Its a mobile skin, and I just need it to scale the site to fit.

Thanks Wikiwhereis (talk) 20:41, 28 February 2013 (UTC)Reply

LESS (CSS preprocessors) supported by RL?

Latest comment: 13 years ago2 comments2 people in discussion

Is it possible to load LESS [1] typed CSS via the RL? Would it be possible for the RL to pre-process LESS (like lessc styles.less styles.css [2]) and sends the resulting CSS to the browser?

bug 40964. Krinkle (talk) 23:00, 26 March 2013 (UTC)Reply

After an edit without my magic word, my script JS disappears

Latest comment: 12 years ago1 comment1 person in discussion

Hi

I'm developing an extension with ResourceLoader. I load the script JS in the render of my magic word.

It works but when I change a page in my Wiki without my magic word, ResourceLoader forget my script JS. I have to purge the page with my magic word to see my script in ResourceLoader.

Have I forgotten something ? The "$wgOut->addModules(" is not in the good function ?

Thanks Karima Rafes (talk) 16:09, 29 July 2013 (UTC)Reply

Javascripts not working on saved copies using HTTrack

Latest comment: 11 years ago2 comments2 people in discussion

I'm testing MW 1.24.1 and using HTTrack to save my site for offline viewing. Javascripts does not seem to work on saved copies.

css works fine as HTTrack will save it as something like loadec88.css but the scripts will be saved as load2b70.php with contents such as

"mobile.editor.api","1419948312",["mobile.stable"]],["mobile.editor.common","1419948312","

Using other webcopiers and even saving actual pages form wikimedia.org reproduces the same result. Is there any way around this? Senghong79 (talk) 07:55, 31 December 2014 (UTC)Reply

Hi, You better use mwoffliner, this is the most advanced solution to make quality offline version of Mediawiki instances. Regards Kelson (talk) 17:12, 1 January 2015 (UTC)Reply

Repainting after page is ready?

Latest comment: 10 years ago1 comment1 person in discussion

RESOLVED

Dupe of Project:Support desk/Flow/2015/05#h-[RESOLVED]_Resource_Loader_adds_CSS_in_style_tag_not_load.php?-2015-05-02T16:15:00.000Z

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

When I add CSS files to RL, the style is applied after the page is ready. This repainting is totally annoying and against all usablity.

I guess it's caused by the <tt>document.write(...)</tt>, position=top doesn't help much either.

What am I doing wrong? Subfader (talk) 17:28, 16 August 2015 (UTC)Reply

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Using LESS with @media and IE8

Latest comment: 10 years ago2 comments2 people in discussion

IE8 doesn't support @media queries. Is there any way to make rendered LESS work with IE8 conditionals (as in include the file again without the @media for IE8, but only IE8)? -— Isarra ༆ 18:48, 21 October 2015 (UTC)Reply

I'm simply accepting the penalty for IE8 users (upgrade, gosh darn it!), and using Respond to load @media rules - by conditionally including Respond itself. FFS ^Talk 20:15, 24 October 2015 (UTC)Reply

is there a way to prefix all css?

Latest comment: 10 years ago1 comment1 person in discussion

the css of wikipedia is messing with other css of the skin and website. i want to limit it to only the rectangle the wiki is inside.

i want to do like:

loader.php?prefix=.wikionly&...

and all the css that it will return will be prefixed Shimondoodkin1 (talk) 11:23, 11 January 2016 (UTC)Reply

BOM characters need stripping

Latest comment: 9 years ago4 comments3 people in discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I've noticed some issues loading resources where source files might have had byte order markers at the start \uFEFF

Not sure how I got them there but I had to use a Notepad++ to strip them for resourceloader to work correctly, might be worth checking for such characters before emebding in resource script object. 203.15.33.179 (talk) 04:21, 31 May 2016 (UTC)Reply

Thanks for your bug report. This is tracked at, https://phabricator.wikimedia.org/T119379 KartikMistry (talk) 15:57, 31 May 2016 (UTC)Reply

Fix upcoming at https://gerrit.wikimedia.org/r/288173. Krinkle (talk) 18:07, 31 May 2016 (UTC)Reply

Landed in master (1.28-alpha) and backported to the MediaWiki 1.27 branch. Krinkle (talk) 16:53, 1 June 2016 (UTC)Reply

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Caching ResourceLoader

Latest comment: 9 years ago3 comments2 people in discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Is a script or stylesheet assembled by ResourceLoader unambiguously defined by its URI, regardless of the user for whom it is served?

In other words, can on safely cache such resources with a caching proxy? Alexander Mashin^talk 08:20, 17 July 2016 (UTC)Reply

Hi Alex, this is not an authoritative answer, but AFAIK the answer is yes, and I certainly do so on my wiki (I use Varnish). The RL module are language dependant, but not exactly user-dependant - user information, such as the config variable wgUserName, are injected into the HTML document itself, which should not be cached for logged-in users.

Wikimedia's own configuration files for Varnish can be found here, if you want to take a look:

https://github.com/wikimedia/operations-puppet/tree/production/modules/varnish/templates/vcl FFS ^Talk 12:07, 17 July 2016 (UTC)Reply

Thank you. Alexander Mashin^talk 15:07, 17 July 2016 (UTC)Reply

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

ResourceLoader loads old/wrong stylesheet

Latest comment: 9 years ago1 comment1 person in discussion

I'm developing an extension and I'm using the resource loader to load my stylesheet and script files. Now that I've developed on multiple branches for a while, I can see that the resource loader responses contain my stylesheet multiple times: Once in its current version and once in an old version or a version that may come from a different branch of my project. How can I purge the cache of the resource loader to remove that second sheet from the response? Sebschlicht (talk) 12:14, 5 March 2017 (UTC)Reply

How to run a function after refreshing the watchlist?

Latest comment: 7 years ago4 comments3 people in discussion

I have a script which makes certain DHTML modifications, but don’t know how to make it called after refreshing—such as pushing [↻ newest changes]—in new Special:Watchlist or RecentChanges.

“$( document ).ready( function () … )” doesn’t help. Also, I found no hooks related to Watchlist in https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw.hook Incnis Mrsi (talk) 19:04, 29 November 2018 (UTC)Reply

I think you can attach your callback to the onclick event of the button in question (now I can't say more, I'm from mobile... apologies). Valerio Bozzolan (talk) 22:50, 29 November 2018 (UTC)Reply

Pushing [↻ newest changes] isn’t the only way how such pages are updated without reloading. Of course, thought about redefining events manually, but it is crude and error-prone. Incnis Mrsi (talk) 05:10, 30 November 2018 (UTC)Reply

I'd also be interested in this. Mainly because I want to get this code which auto-expands grouped-entries, to be triggerable from a new button (which would be useful after clicking the [↻ newest changes] button). (See also phab:T176555 where I filed the above as a suggested feature) –Quiddity (talk) 07:24, 30 November 2018 (UTC)Reply

Caching of load.php

Latest comment: 6 years ago2 comments1 person in discussion

RESOLVED

Solved ... set php in ExpiresByType works. the js does not identify as js since loaded over php.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Thankfully the ini_set("zlib.output_compression","on"); works so i can move on for more optimize. Actually i stuck on caching / stay in browser for the output of RL.

Since the RL delivers over load.php it doensn't uses the ExpiresByType declaration in .htacess. Accordingly to https://www.mediawiki.org/wiki/Project%3ASupport%20desk/Flow/2014/05#h-%5BRESOLVED%5D_Any_way_to_control_the_caching_of_MediaWiki%3ACommon.css%3F-2014-05-13T16%3A27%3A00.000Z $wgResourceLoaderMaxage should be set, but it doesn't make any difference in ~~[https://developers.google.com/speed/pagespeed/insights/ Google Insights]~~ https://webpagetest.org/ . Is there any way to set the leverage browser caching? --Gunnar.offel (talk) 15:08, 7 November 2019 (UTC) IReply

Solved ... set php in ExpiresByType works. the js does not identify as js since loaded over php. --Gunnar.offel (talk) 20:29, 7 November 2019 (UTC)Reply

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Are custom CSS and JavaScript active during a block?

Latest comment: 3 years ago5 comments2 people in discussion

RESOLVED

Never mind, I will try it out myself later. I just asked thinking someone who has already tried it could respond with yes/no.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

For curiousity, do custom CSS and JavaScript run while an account is blocked?

If so, it could cause a user to be unable to turn off their custom code if they want to, since they are unable to edit it. Wiisixtyfour (talk) 15:01, 10 April 2022 (UTC)Reply

Basically, the code can be accessed and executed by any www user around the world.

However, the code is not “running” if an account is not permitted to log in or to edit, since the automatic execution is bound to login.

Turning off is not necessary as long nobody is starting the code, and this needs some kind of explicit transclusion if not per default after login for this account. PerfektesChaos (talk) 17:26, 11 April 2022 (UTC)Reply

Thanks for response.

Basically, the code can be accessed and executed by any www user around the world.

An on-site block can obviously not affect CSS and JS code that is run using other tools such a browser extension, but I was referring to the custom CSS and JS pages that users can have in their user space (e.g. User:Example/common.js), which allows users to enter custom code that runs upon each page load.

However, the code is not “running” if an account is not permitted to log in or to edit, since the automatic execution is bound to login.

An ordinary block does not affect users' ability to log in, it simply disables editing. I presume it also disables the editing of custom CSS and JS pages that the user has in their user space.

But does a block prevent the existing code in user space from being run? Wiisixtyfour (talk) 14:11, 17 April 2022 (UTC)Reply

The code is still there, and if a blocked person is still permitted to log in and will personally execute any JS/CSS they want they are able to do so. There are no means to prevent this, and the code may be copied and executed via en:Greasemonkey or browser JS/config. However, it does no harm to the world around. Who cares?

If there are dangerous things implemented which might e.g. endanger privacy of other people invited to run this code, or manipulate their edits, every sysop is permitted to delete such code immediately without further JS/CSS permissions. PerfektesChaos (talk) 15:04, 17 April 2022 (UTC)Reply

The code is still there, and if a blocked person is still permitted to log in and will personally execute any JS/CSS they want they are able to do so.

Sorry, apparently I didn't word my question well enough. When "User:Example" is logged in, will MediaWiki automatically run "User:Example/common.js" in the browser of "User:Example" while the account "User:Example" is blocked?

I could test it myself, but I have no access to a MediaWiki server at my current location and didn't want to bother setting one up just to test this. Wiisixtyfour (talk) 01:12, 28 April 2022 (UTC)Reply

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.