Page MenuHomePhabricator

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

Details

Reference
bz27328

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:24 PM
bzimport set Reference to bz27328.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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

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

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.

This bug is fixed now with r82000, r82156 and r82218

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.

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