Last modified: 2014-02-14 02:04:30 UTC
------------ REPRODUCTION ------------ * Go to the following link for it.wiktionary.org: http://bits.wikimedia.org/it.wiktionary.org/load.php?debug=true&modules=ext.gadget.Edittools,WmfProjectStatusHelper,collapsibleTables,site|ext.rtlcite,wikihiero|ext.uls.nojs|mediawiki.legacy.commonPrint,shared|mw.PopUpMediaTransform|skins.vector&only=styles&skin=vector&* * Search for "portal". No results will be found * Go to the following link for it.wikipedia.org: http://bits.wikimedia.org/it.wikipedia.org/load.php?debug=true&modules=ext.gadget.Edittools,WmfProjectStatusHelper,collapsibleTables,site|ext.rtlcite,wikihiero|ext.uls.nojs|mediawiki.legacy.commonPrint,shared|mw.PopUpMediaTransform|skins.vector&only=styles&skin=vector&* * Search for "portal". The first result will be: "#mw-panel.collapsible-nav .portal {" ------------- OTHER DETAILS ------------- I believe this behavior changed sometime after 2014-02-09 19:30 UTC (Sunday). I generated css files using variations of those links for all the Italian wikis: it.wikipedia.org; it.wiktionary; it.wikisource.org; it.wikivoyage.org; it.wikiquote.org; it.wikibooks.org; it.wikiversity.org; it.wikinews.org. At the time, it generated approximately 225 KB of css data for each wiki. Now, it only generates 40 kb for all wikis except for it.wikipedia.org. Among other missing elements, there is no data for the portal class as well as many other related classes (p-personal; p-namespaces; p-views; etc) Note that this also affects other language wikis. For example, I've tested en.wiktionary.org and simple.wikibooks.org and both return vastly reduced css data.
Not sure what this would have to do with Wikidata...
Sorry. I left the wrong value in the drop-down by accident
I did some more investigation and discovered that changing "skins.vector" to "skins.vector.styles" will generate a css with the stated "portal" css class. For example, this it.wiktionary.org link now generates a "full" css: http://bits.wikimedia.org/it.wiktionary.org/load.php?debug=true&modules=ext.gadget.Edittools,WmfProjectStatusHelper,collapsibleTables,site|ext.rtlcite,wikihiero|ext.uls.nojs|mediawiki.legacy.commonPrint,shared|mw.PopUpMediaTransform|skins.vector.styles&only=styles&skin=vector&* I'd still be interested to know why "skins.vector" works only for the Wikipedia version, or why it changed recently. Likewise, any information about whether or not the previous behavior ("skins.vector") will be restored. (It had been working since at least 2013-07 until this past Sunday) Thanks.
This bug report does not say anything about the effects of this change or why it should not be this way. Please amend.
These are not expected to have the same code. Wikimedia's cluster uses a phased deployment process. See https://wikitech.wikimedia.org/wiki/Deployments . Right now, Wikipedia has 1.23wmf12 and Wiktionary has 1.23wmf13 (a newer version). You can check Special:Version to see the version at any time. This appears to be caused by some refactoring that removed the skins.vector module. It was replaced with other modules, which seem to be skins.common.interface and skins.vector.styles . See 1d5ec4a6a130cb4e291741a3b32d155ee9932a76 and 840764cc2d8956ea6348cce10da31809807bb12a (among other related ones). The report does not indicate any end-user impact, so I'm closing as WORKSFORME. Please reopen if there are symptoms visible to a wiki user.
Removing only=styles gives you more debug information and trivially reveals the problem. http://bits.wikimedia.org/it.wikipedia.org/load.php?debug=true&modules=ext.gadget.Edittools,WmfProjectStatusHelper,collapsibleTables,site%7Cext.rtlcite,wikihiero%7Cext.uls.nojs%7Cmediawiki.legacy.commonPrint,shared%7Cmw.PopUpMediaTransform%7Cskins.vector&skin=vector&* mw.loader.state({ "ext.gadget.Edittools":"missing", "ext.gadget.WmfProjectStatusHelper":"missing", "ext.gadget.collapsibleTables":"missing", "ext.gadget.site":"missing" }); http://bits.wikimedia.org/it.wiktionary.org/load.php?debug=true&modules=ext.gadget.Edittools,WmfProjectStatusHelper,collapsibleTables,site%7Cext.rtlcite,wikihiero%7Cext.uls.nojs%7Cmediawiki.legacy.commonPrint,shared%7Cmw.PopUpMediaTransform%7Cskins.vector&skin=vector&* mw.loader.state({ "ext.gadget.Edittools":"missing", "ext.gadget.WmfProjectStatusHelper":"missing", "ext.gadget.collapsibleTables":"missing", "ext.gadget.site":"missing", "skins.vector":"missing" // <!-- The problem });
This is indeed not a valid problem, since these urls are generated by the software, and the new version of the software gives the new urls, and the old version the old urls. The question is, where did you (@gnosygnu) get the urls from? Did you manually change it in the url from wikipedia to wiktionary? Or where you getting these in your browser and thus actually seeing a page with missing css (e.g. portal doesn't look right). Regardless of whether the software did it right or not, this is bound to go wrong during the 5 minutes of cache invalidation and longer for third parties when they upgrade with cached html. This is why module changes like was done to "skins.vector" are bad and bound to cause trouble.
The urls were being used by XOWA: http://xowa.sourceforge.net. XOWA is an offline wiki app. After it sets up a wiki, it gets the CSS for that wiki for rendering the article. It uses the URL above to retrieve the wiki's CSS. I understand that this does not strictly affect wiki users. However, how should third-party tools get the official CSS for a given wiki? The above was recommended by another user, and had been working without any issue since 2013-July.
(In reply to gnosygnu from comment #8) > I understand that this does not strictly affect wiki users. However, how > should third-party tools get the official CSS for a given wiki? The above > was recommended by another user, and had been working without any issue > since 2013-July. The exact URL requests and module names are not a public API (I use the term "API" generally). They can change. The most future-proof solution is probably to behave as a browser would. I understand an offline program is not going to visit every separate page once. However, XOWA could visit one page (e.g. the main page), and download all the <link rel="stylesheet"> stylesheets. If that is missing something, you could do another explicit request to pick up additional known modules that may be page-specific (e.g. ext.rtlcite). However, don't expect this latter workaround to be future-proof.
Ok. Your recommended course of action should be fine (caveats noted). My apologies for opening up this issue, but I had assumed that "bits.wikimedia.org" had a public API'ish nature to it, and was alarmed when it suddenly changed. I'm fine with the ticket being resolved. Thanks everyone for the responses.
(In reply to gnosygnu from comment #8) > I understand that this does not strictly affect wiki users. However, how > should third-party tools get the official CSS for a given wiki? A question that [[m:WikiTeam]] has too: if you find a solution please share at https://code.google.com/p/wikiteam/issues/detail?id=82 . (In reply to Matthew Flaschen from comment #9) > could visit one page (e.g. the main page), and download > all the <link rel="stylesheet"> stylesheets. Does wget --page-requisites (also) download those? I think it's supposed to.
(In reply to Nemo from comment #11) > Does wget --page-requisites (also) download those? I think it's supposed to. With some extra options (e.g. for Meta): wget -e robots=off --page-requisites --convert-links --adjust-extension --span-hosts --domains meta.wikimedia.org,bits.wikimedia.org meta.wikimedia.org However, it also downloads some other stuff (e.g. CentralAutoLogin), so it might be better for the program to explicitly download just the stylesheets.
