Last modified: 2011-02-19 14:58:39 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 27328 - using relative paths in CSS imports in MediaWiki:Common.css broken in 1.17
using relative paths in CSS imports in MediaWiki:Common.css broken in 1.17
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.17.x
All All
: Normal major (vote)
: ---
Assigned To: Trevor Parscal
http://en.wikibooks.org/w/index.php?t...
:
Depends on:
Blocks: 27339
  Show dependency treegraph
 
Reported: 2011-02-11 14:47 UTC by aaron.adrignola
Modified: 2011-02-19 14:58 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description aaron.adrignola 2011-02-11 14:47:17 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.
Comment 1 Liangent 2011-02-11 15:00:57 UTC
Site CSS is loaded from load.php instead of index.php.

You have to add "index.php" before the question mark.
Comment 3 Liangent 2011-02-11 16:15:00 UTC
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.
Comment 4 darklama 2011-02-11 16:48:42 UTC
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.
Comment 5 Liangent 2011-02-11 17:17:58 UTC
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.
Comment 6 darklama 2011-02-11 17:43:44 UTC
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.
Comment 7 Liangent 2011-02-11 17:47:38 UTC
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.
Comment 8 Krinkle 2011-02-11 17:56:56 UTC
Adjusting summary so it can be found easier.

The bug is only happening with relative URLs. Imports in general work just fine.
Comment 9 Trevor Parscal 2011-02-11 18:02:54 UTC
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.
Comment 10 darklama 2011-02-11 19:24:53 UTC
(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.
Comment 11 Trevor Parscal 2011-02-11 19:32:05 UTC
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
Comment 12 Trevor Parscal 2011-02-11 22:57:59 UTC
This should be resolved in r82000.
Comment 13 Krinkle 2011-02-11 23:03:17 UTC
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.
Comment 14 Krinkle 2011-02-11 23:03:50 UTC
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.
Comment 15 darklama 2011-02-12 01:38:44 UTC
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");
Comment 16 Liangent 2011-02-12 09:39:03 UTC
There may be conflicts between page names and urls then I guess...
Comment 17 darklama 2011-02-12 13:04:29 UTC
(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.
Comment 18 Liangent 2011-02-12 13:31:40 UTC
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.
Comment 19 darklama 2011-02-13 09:56:55 UTC
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")
Comment 20 Krinkle 2011-02-14 21:55:47 UTC
(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;
Comment 21 Roan Kattouw 2011-02-14 22:47:45 UTC
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.
Comment 22 darklama 2011-02-15 00:38:17 UTC
(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.
Comment 23 Roan Kattouw 2011-02-16 06:31:07 UTC
This bug is fixed now with r82000, r82156 and r82218
Comment 24 darklama 2011-02-16 14:26:18 UTC
(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.
Comment 25 Roan Kattouw 2011-02-18 17:28:13 UTC
(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.
Comment 26 Roan Kattouw 2011-02-19 14:58:39 UTC
(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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links