Last modified: 2013-01-22 02:26:27 UTC
We deployed GettingStarted to test.wikipedia.org using the process at http://wikitech.wikimedia.org/view/How_to_deploy_code#Case_1d:_new_extension , and enabled it on test.wikipedia.org. However, ResourceLoader did not (and still doesn't, as of now) serve the correct messages to JS. Both http://test.wikipedia.org/w/load.php?debug=false&lang=en&modules=ext.gettingstarted.accountcreation&skin=vector&version=20121218T214605Z&* and http://test.wikipedia.org/w/load.php?debug=true&lang=en&modules=ext.gettingstarted.accountcreation&skin=vector&version=20121218T214605Z&* (debug false and true) serve the placeholder messages: {"gettingstarted-welcomesiteuser":"<gettingstarted-welcomesiteuser>","gettingstarted-backtoarticle":"<gettingstarted-backtoarticle>"} When we enabled English Wikipedia and synced there, it worked fine (again, regardless of debug). I'm filing it here since it is not a straight bug in ResourceLoader, but config-dependent.
Different results here, close as WORKSFORME? With debug=true: mw.loader.implement("ext.gettingstarted.accountcreation", ["//test.wikipedia.org/w/static-1.21wmf6/extensions/GettingStarted/resources/ext.gettingstarted.accountcreation.js"], {}, {"gettingstarted-welcomesiteuser":"Welcome to $1, $2!","gettingstarted-backtoarticle":"No thanks, back to article"}); With debug=false: mw.loader.implement("ext.gettingstarted.accountcreation",function(){(function($,mw){$(function(){var title=mw.msg('gettingstarted-welcomesiteuser',mw.config.get('wgSiteName'),mw.config.get('wgUserName'));document.title=title;$('#firstHeading span').text(title);var $returnTo=$('#mw-returnto');var returnToUrl=$('a',$returnTo).attr('href');$returnTo.remove();var $returnToAgora=$('<a />',{id:'back-to-referrer',href:returnToUrl,'class':'blue mw-ui-button',text:'← '+mw.msg('gettingstarted-backtoarticle')});$('#onboarding-header p').append($returnToAgora);var state={};var url=mw.util.wikiGetlink('Special:GettingStarted');if(history.replaceState){history.replaceState(state,title,url);}});})(jQuery,mediaWiki);;},{},{"gettingstarted-welcomesiteuser":"Welcome to $1, $2!","gettingstarted-backtoarticle":"No thanks, back to article"}); /* cache key: testwiki:resourceloader:filter:minify-js:7:0540b98b5c698de4af3e5f932a9d5e57 */
It's interesting that it works now, but that still indicates a problem with cache eviction. It worked on English Wikipedia immediately after we enabled it, but still didn't work on test then (even though test was enabled first). The fact that it worked hours later on test.wiki may give us useful information, but there's still a bug. The point of test.wiki is to test before deploying to a real wiki.
Steven Walling comments that our Extension:PostEdit deploy had a similar problem with missing messages on test.w.o during and after deployment. If I repeat the request above: curl --dump-header - 'http://test.wikipedia.org/w/load.php?debug=false&lang=en&modules=ext.gettingstarted.accountcreation&skin=vector&version=20121213T214605Z&*' I still get the incorrect code. The headers are: HTTP/1.0 200 OK Date: Thu, 13 Dec 2012 23:40:59 GMT Server: Apache X-Content-Type-Options: nosniff Cache-Control: private, s-maxage=0, max-age=0, must-revalidate Last-Modified: Thu, 13 Dec 2012 21:46:05 GMT Expires: Sat, 12 Jan 2013 23:40:59 GMT Vary: Accept-Encoding Content-Length: 946 Content-Type: text/javascript; charset=utf-8 Age: 80701 X-Cache: HIT from cp1012.eqiad.wmnet X-Cache-Lookup: HIT from cp1012.eqiad.wmnet:3128 X-Cache: MISS from cp1002.eqiad.wmnet X-Cache-Lookup: MISS from cp1002.eqiad.wmnet:80 Connection: close The i18n.php, CSS, and JS files on fenari are dated 2012-12-13 21:08, so I don't understand why RL requests made 30 minutes later don't find the i18n strings from the PHP. This is a real bug... somewhere.
Did you rebuild i18n cache ? (using scap and/or the dedicated scripts). We don't read i18n files directly on the cluster, they are cached. ResourceLoader, wfMsg etc. they all interface with the cache. Not the raw files. And we disabled automatic cache refreshing. Instead we build them for all extensions at once periodically, this is not ResourceLoader related afaik.
We did first tried http://wikitech.wikimedia.org/view/How_to_deploy_code#Alternative_to_scap But after that, we did a full scap, with test.wiki enabled, and the strings were still out of date. The original symptom was that these placeholder JS strings actually showed up in the interface However, the same messages worked using transclusion (https://test.wikipedia.org/wiki/User:Superm401/Sandbox).
To my knowledge, this problem has not recurred.
