using relative paths in CSS imports in MediaWiki:Common.css broken in 1.17
Closed, ResolvedPublic

Description

Author: aaron.adrignola

Description:
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.


Version: 1.17.x
Severity: major
URL: http://en.wikibooks.org/w/index.php?title=MediaWiki:Common.css&oldid=2029128

bzimport set Reference to bz27328.
bzimport created this task.Via LegacyFeb 11 2011, 2:47 PM
liangent added a comment.Via ConduitFeb 11 2011, 3:00 PM

Site CSS is loaded from load.php instead of index.php.

You have to add "index.php" before the question mark.

liangent added a comment.Via ConduitFeb 11 2011, 4:15 PM

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.

bzimport added a comment.Via ConduitFeb 11 2011, 4:48 PM

darklama wrote:

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.

liangent added a comment.Via ConduitFeb 11 2011, 5:17 PM

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.

bzimport added a comment.Via ConduitFeb 11 2011, 5:43 PM

darklama wrote:

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.

liangent added a comment.Via ConduitFeb 11 2011, 5:47 PM

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.

Krinkle added a comment.Via ConduitFeb 11 2011, 5:56 PM

Adjusting summary so it can be found easier.

The bug is only happening with relative URLs. Imports in general work just fine.

TrevorParscal added a comment.Via ConduitFeb 11 2011, 6:02 PM

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.

bzimport added a comment.Via ConduitFeb 11 2011, 7:24 PM

darklama wrote:

(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.

TrevorParscal added a comment.Via ConduitFeb 11 2011, 10:57 PM

This should be resolved in r82000.

Krinkle added a comment.Via ConduitFeb 11 2011, 11:03 PM

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:

Willl now access:

  • /windex?title=MediaWiki:Common.css/WikiTable.css&action=raw&ctype=text/css

Still a 404 error.

Krinkle added a comment.Via ConduitFeb 11 2011, 11:03 PM

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.

bzimport added a comment.Via ConduitFeb 12 2011, 1:38 AM

darklama wrote:

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");

liangent added a comment.Via ConduitFeb 12 2011, 9:39 AM

There may be conflicts between page names and urls then I guess...

bzimport added a comment.Via ConduitFeb 12 2011, 1:04 PM

darklama wrote:

(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.

liangent added a comment.Via ConduitFeb 12 2011, 1:31 PM

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.

bzimport added a comment.Via ConduitFeb 13 2011, 9:56 AM

darklama wrote:

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")

Krinkle added a comment.Via ConduitFeb 14 2011, 9:55 PM

(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;

Catrope added a comment.Via ConduitFeb 14 2011, 10:47 PM

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.

bzimport added a comment.Via ConduitFeb 15 2011, 12:38 AM

darklama wrote:

(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.

Catrope added a comment.Via ConduitFeb 16 2011, 6:31 AM

This bug is fixed now with r82000, r82156 and r82218

bzimport added a comment.Via ConduitFeb 16 2011, 2:26 PM

darklama wrote:

(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.

Catrope added a comment.Via ConduitFeb 18 2011, 5:28 PM

(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.

Catrope added a comment.Via ConduitFeb 19 2011, 2:58 PM

(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.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.