Hi.
The URL for CSS used to be something like this:
//bits.wikimedia.org/skins-1.18/monobook/main.css
Now there's apparently this:
//bits.wikimedia.org/skins-1.20wmf1/monobook/main.css
But this also works:
//bits.wikimedia.org/skins/monobook/main.css
Can someone please explain which should be used? Unexpectedly getting rid of skins-1.18/ is actively breaking the look of certain pages (such as the www portals), but I'm not clear whether I should simply be switching to a new MediaWiki version in the URL or if there's something canonical I can use instead (which would obviously be preferred).
I didn't see anything on the mailing list about this....
MZMcBride
I don't think the problem is specific to the skins directory. Bits has been acting weird all day. To answer your question, I think either URL is fine. It just depends on if you want the CSS updated automatically or manually when new versions are deployed. If anyone knows otherwise, feel free to chime in.
Ryan Kaldari
On 4/16/12 8:08 PM, MZMcBride wrote:
Hi.
The URL for CSS used to be something like this:
//bits.wikimedia.org/skins-1.18/monobook/main.css
Now there's apparently this:
//bits.wikimedia.org/skins-1.20wmf1/monobook/main.css
But this also works:
//bits.wikimedia.org/skins/monobook/main.css
Can someone please explain which should be used? Unexpectedly getting rid of skins-1.18/ is actively breaking the look of certain pages (such as the www portals), but I'm not clear whether I should simply be switching to a new MediaWiki version in the URL or if there's something canonical I can use instead (which would obviously be preferred).
I didn't see anything on the mailing list about this....
MZMcBride
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
1.18 shouldn't be failing anymore since reedy put a symlink in place for it.
Ideally people would code things like that (aka stuff that isn't actually MediaWiki) shouldn't be doing it to be dependant on MW skin folders, eg: build their own css files, Because like this is pointing out, things can change (not just directories, but the actual files as well).
I believe "//bits.wikimedia.org/skins/{monobook/main.css}" is setup to always point to the latest version so that should be alright, but someone else will need to confirm.
K. Peachey wrote:
1.18 shouldn't be failing anymore since reedy put a symlink in place for it.
Ideally people would code things like that (aka stuff that isn't actually MediaWiki) shouldn't be doing it to be dependant on MW skin folders, eg: build their own css files, Because like this is pointing out, things can change (not just directories, but the actual files as well).
Hello,
I would really love having a very basic set of HTML templates with some nice CSS that would let us instantly have the look'n feel of Vector without having to rely on such linking.
We have several website that could uses it:
http://noc.wikimedia.org/ http://noc.wikimedia.org/conf/ http://dumps.wikimedia.org/ and children https://integration.mediawiki.org/ https://svn.wikimedia.org/ Planet could use a refresh: http://en.planet.wikimedia.org/
What I would really love is a theme for the Twitter bootstrap system and have all of that placed in a git repo. We could then have the site above to use a snapshot of the theme and have a similar look'n feel all around.
If there is any volunteer willing to do that, I will definitely use some personal time to review the code / css / puppet config.
Our WordPress skin looks fine to me. But some other apps could use an update:
ViewVC https://svn.wikimedia.org/viewvc Nagios http://nagios.wikimedia.org/ Doxygen output http://svn.wikimedia.org/doc/
Customizing them will be a bit more tedious though.
El 17/04/12 06:13, K. Peachey wrote:
Because like this is pointing out, things can change (not just directories, but the actual files as well).
Yes, they do (and I was bitten by it). For instance, http://bits.wikimedia.org/skins-1.17 is no longer there, and the 1.18 CSS isn't compatible with the old html. So always pointing to the last version isn't necessarily the right thing.
On Mon, Apr 16, 2012 at 9:13 PM, K. Peachey p858snake@gmail.com wrote:
I believe "//bits.wikimedia.org/skins/{monobook/main.css}" is setup to always point to the latest version so that should be alright, but someone else will need to confirm.
In the Magical World of Continuous Deployments, it'll usually point to the second-to-most-recent version -- not the version currently being deployed but the last version that was completely rolled out (technical detail: it indirectly uses the /home/wikipedia/php symlink, which currently points to php-1.19). So right now that's 1.19, even though some wikis are already on 1.20wmf1. Version-specific skin URLs such as skins-1.18 and skins-1.19 WILL BREAK once the version in question is no longer live on any wiki and we're getting ready to deploy the next one. So skins-1.18 is gone now, and once we start the 1.20wmf2 roll-out, skins-1.19 will be removed and skins/ will be updated to point to 1.20wmf1. There are always at most two versions on the cluster at any given time; we can't have more due to APC cache size issues.
Roan
On Apr 17, 2012, at 5:08 AM, MZMcBride wrote:
Hi.
The URL for CSS used to be something like this:
//bits.wikimedia.org/skins-1.18/monobook/main.css
Now there's apparently this:
//bits.wikimedia.org/skins-1.20wmf1/monobook/main.css
But this also works:
//bits.wikimedia.org/skins/monobook/main.css
Can someone please explain which should be used? Unexpectedly getting rid of skins-1.18/ is actively breaking the look of certain pages (such as the www portals), but I'm not clear whether I should simply be switching to a new MediaWiki version in the URL or if there's something canonical I can use instead (which would obviously be preferred).
The MediaWiki skins classes and their resources are bundled in each MediaWiki release, not supposed to be separated like this. And even then, it is best not to load the raw files directly.
One of the advantages of ResourceLoader is that modules have symbolic names and the end-user doesn't need to deal with any version specific file names, file paths or root directory changes.
So loading the 'skins.monobook' module will at any given point in time load that module in a way that it is compatible with the wiki it is loaded from.
So on www.wikipedia.org, instead of:
<link rel="stylesheet" href="//bits.wikimedia.org/skins-1.20wmf1/monobook/main.css?303-4" type="text/css" media="screen, projection" />
Use the same that MediaWiki itself uses (based on sample taken from source code of https://www.mediawiki.org/wiki/MediaWiki?useskin=monobook )
<link rel="stylesheet" href="//bits.wikimedia.org/www.mediawiki.org/load.php?debug=false&lang=en&modules=mediawiki.legacy.commonPrint%2Cshared%7Cskins.monobook&only=styles&skin=monobook&*"/>
That will be more stable than using the raw file from any directory. First, because it has no version in it. Secondly, it also doesn't have any file path specific thing. So if monobook would split the css file into multiple files or rename "main.css" to "screen.css" or whatever, then the above will still work because it uses the ResourceLoader module name "skins.monobook", and MediaWiki itself has the module definition of it that contians what it needs and from where.
This also makes the load module effecient because it is minified (whereas loading main.css directly is just a raw file).
-- Krinkle
wikitech-l@lists.wikimedia.org