Last modified: 2011-02-19 14:58:39 UTC
At en.wikibooks.org we've been using @import lines to bring in CSS in subpages of MediaWiki:Common.css in order to split CSS up by function. This no longer functions with MediaWiki 1.17 and the CSS present in the subpages is not loaded. See the URL for the wiki's implementation, which worked for both the secure and normal servers in 1.16.
Site CSS is loaded from load.php instead of index.php. You have to add "index.php" before the question mark.
Just to be clear: Are you saying apache expands http://en.wikibooks.org and https://secure.wikimedia.org/wikibooks/en/ to http://en.wikibooks.org/w/load.php and https://secure.wikimedia.org/wikibooks/en/w/load.php now instead of to http://en.wikibooks.org/w//w/index.php and https://secure.wikimedia.org/wikibooks/en/w/index.php?
Oh sorry, it's from http://bits.wikimedia.org/en.wikibooks.org/load.php (if you specify http://en.wikibooks.org/w/load.php manually it's also there). I guess you have to use full URL now.
Requiring full URL breaks backwards compatibility with 1.16. I noticed with Firebug that Firefox is looking for http://bits.wikimedia.org/w/index.php?title=Page&action=raw&ctype=text/css for http://en.wikibooks.org, and http://secure.wikimedia.org/w/index.php?title=Page&action=raw&ctype=text/css for http://secure.wikimedia.org/wikibooks/en/ I may be wrong, but wouldn't adding base tag with a value depending on the wiki and whether the secure server is used fix this? For example: <base href="http://en.wikibooks.org/" /> or <base href="http://secure.wikimedia.org/wikibooks/en/" /> in the case of English Wikibooks.
I dunno the config about RL on secure servers. Currently, site css is loaded from http://bits.wikimedia.org/en.wikibooks.org/load.php?..., while you still need to load your other css files from http://en.wikibooks.org/w/index.php?action=raw&... (with SSL it can be https://secure.wikimedia.org/wikibooks/en/w/index.php?action=raw&...), which is the same location as what it was in 1.16. I see no breakage in backwards compatibility. With site JS it can be easily done (by loading wgServer + wgScript + '?...' as CSS) but with site CSS I didn't find an easy way using @import.
The easy solution we were using broke when English Wikibooks was upgraded from 1.16 to 1.17. I do not know what configuration changes are responsible for this breakage either. English Wikiversity also uses relative paths and hasn't yet been upgraded to 1.17. Looking there I see with Firebug that it is still looking for http://en.wikiversity.org/w/ and https://secure.wikimedia.org/wikiversity/en/w respectively. Maybe that can help to diagnose what changes are responsible.
It's because MediaWiki:Common.css is loaded by RL from bits.wikimedia.org while other CSS files have to be loaded from en.wikibooks.org so I guessing specifying absolute URL cannot be avoided.
Adjusting summary so it can be found easier. The bug is only happening with relative URLs. Imports in general work just fine.
The reason this happens if because CSSMin, the library that ResrouceLoader uses to perform a variety of operations on CSS data does not yet support remapping import statements. But it should be very easy to add that since there's already code for remapping url statements.
(In reply to comment #9) > The reason this happens if because CSSMin, the library that ResrouceLoader uses > to perform a variety of operations on CSS data does not yet support remapping > import statements. But it should be very easy to add that since there's already > code for remapping url statements. What version of CSSMin? http://code.google.com/p/cssmin/source/browse/trunk/cssmin.php suggests this may already exist as an undocumented feature that can be enabled by configuring import-base-path.
Not that thing... The one in our codebase that I wrote. http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/libs/CSSMin.php?view=markup
This should be resolved in r82000.
With this fix applied the following: @import url("?title=MediaWiki:Common.css/WikiTable.css&action=raw&ctype=text/css") screen; Which first tried to access: * http://bits.wikimedia.org/w/index.php?title=MediaWiki:Common.css/WikiTable.css&action=raw&ctype=text/css Willl now access: * /windex?title=MediaWiki:Common.css/WikiTable.css&action=raw&ctype=text/css Still a 404 error.
With this fix applied the following: @import url("index.php?title=MediaWiki:Common.css/WikiTable.css&action=raw&ctype=text/css") screen; Which first tried to access: * http://bits.wikimedia.org/w/index.php?title=MediaWiki:Common.css/WikiTable.css&action=raw&ctype=text/css Willl now access: * /windex.php?title=MediaWiki:Common.css/WikiTable.css&action=raw&ctype=text/css Still a 404 error.
r82000 seems to demonstrate a problem with not doing any sanity checks. How about enforcing some consistency with javascript loading instead by assuming when a relative url is passed it always refers to a page name on the wiki? E.g remap: @import url("MediaWiki:Page 1.css"); to: @import url("/w/index.php?title=MediaWiki:Page_1.css&action=raw&ctype=text/css");
There may be conflicts between page names and urls then I guess...
(In reply to comment #16) > There may be conflicts between page names and urls then I guess... I guess you are right. Same problem likely exists with javascript loading too though. Pages beginning with "http://" or "https://" would look like absolute urls and not page/module names.
Page names can also begin with "http://" or "https://". In JavaScript loading there are importScript("MediaWiki:Page.js"); and importScriptURI("http://example.com/script.js"); in legacy JS libs, and in new JS libs loading by page name without constructing URLs manually is not supported (bug 27281). For CSS loading with JavaScript there are importStylesheet("MediaWiki:Page.js"); and importStylesheetURI("http://example.com/style.css"); but it may be unfriendly to people with CSS support but without JavaScript support.
Another option. Invent a new protocol and remap it: url("mw://Page.css") -> url("/w/index.php?title=Page.css&action=raw&ctype=text/css")
(In reply to comment #18) > Page names can also begin with "http://" or "https://". > > In JavaScript loading there are importScript("MediaWiki:Page.js"); and > importScriptURI("http://example.com/script.js"); in legacy JS libs, and in new > JS libs loading by page name without constructing URLs manually is not > supported (bug 27281). > > For CSS loading with JavaScript there are > importStylesheet("MediaWiki:Page.js"); and > importStylesheetURI("http://example.com/style.css"); but it may be unfriendly > to people with CSS support but without JavaScript support. Importing CSS via a shorthand method without JavaScript is indeed not possible, but please note that hit has never been possible. That's not a regression but a feature request. People using relative paths in import with query strings (which is fairly rare), can simply complete the url. ie. @import url("?title=MediaWiki:Common.css/Autocount.css&action=raw&ctype=text/css") screen; --> @import url("/w/index.php?title=MediaWiki:Common.css/Autocount.css&action=raw&ctype=text/css") screen;
Let's keep the bug (fix relative paths) and the feature request (make url(MediaWiki:Foo) or @import MediaWiki:Foo or something similar work) separate here. This bug is for the former, please open a new bug for the latter.
(In reply to comment #21) > Let's keep the bug (fix relative paths) and the feature request (make > url(MediaWiki:Foo) or @import MediaWiki:Foo or something similar work) separate > here. This bug is for the former, please open a new bug for the latter. url("MediaWiki:Foo") is a relative path too, but if a separate bug is wanted I can do that.
This bug is fixed now with r82000, r82156 and r82218
(In reply to comment #23) > This bug is fixed now with r82000, r82156 and r82218 Unfortunately, r82218 breaks it again. All urls beginning with '/' are treated as absolute urls and skipped, which means the original suggestion to use url('/w/index.php?title=MediaWiki:Page.css') doesn't work.
(In reply to comment #24) > (In reply to comment #23) > > This bug is fixed now with r82000, r82156 and r82218 > > Unfortunately, r82218 breaks it again. All urls beginning with '/' are treated > as absolute urls and skipped, which means the original suggestion to use > url('/w/index.php?title=MediaWiki:Page.css') doesn't work. Right, these URLs need to be expanded to http://blah/w/index.php rather than just skipped. I'll fix this soon.
(In reply to comment #25) > Right, these URLs need to be expanded to http://blah/w/index.php rather than > just skipped. I'll fix this soon. Fixed in r82457.
