Last modified: 2014-06-02 07:23:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36493, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34493 - Unable to refer to core images in extension styles
Unable to refer to core images in extension styles
Status: NEW
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.20.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-18 16:49 UTC by Niklas Laxström
Modified: 2014-06-02 07:23 UTC (History)
7 users (show)

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


Attachments

Description Niklas Laxström 2012-02-18 16:49:18 UTC
One cannot use core images in extension stylesheets. skins/... work in non-debug mode where RL leaves the URL untouched, but breaks in debug mode when the CSS is loaded from different base. Relative urls like ../../skins/... don't work.
Comment 1 Rob Lanphier 2012-02-19 16:40:12 UTC
Hi Niklas, does this affect 1.19 as well?  Also, would this apply to Javascript as well?  I wonder if this has anything to do with bug 34469, which now only seems to be a problem in debug mode.
Comment 2 Niklas Laxström 2012-02-20 07:19:23 UTC
Yes it does, but as far as I can tell this is not a regression and only affects CSS.
Comment 3 Krinkle 2012-03-05 06:19:06 UTC
I'm not sure I get it.

Relative paths in CSS should start from their own directory. So why would it not work to traverse to ./skins/common/images but would work to go to ../images/ of the current extension.

Examples please :)
Comment 4 Krinkle 2012-03-05 06:19:36 UTC
In production mode RL rewrites them to originate correctly from load.php, in debug mode the path is untouched so it should be fine as it is.
Comment 5 Niklas Laxström 2012-03-05 07:55:39 UTC
What examples you want? I didn't commit such code because *it just doesn't work*. The path is left untouched and there is no image embedding.
Comment 6 Krinkle 2012-03-05 08:11:03 UTC
An example here on bugzilla would suffice as well.

Basically if the following is placed in ./extensions/Foo/modules/ext.foo.css:

background-image: url(images/foo.png);

In debug mode it would remain unchanged (pointing to ./extensions/Foo/modules/images/foo.png), and in production it would be re-mapped to point to that as well.

I'm assuming that works as expected.

Can you provide a sample that doesn't work as expected?
Comment 7 Krinkle 2012-03-05 08:15:07 UTC
I can imagine if ResourceLoader doesn't allow leaving the localPath given to the module (e.g. wgExtensionAssetsPath). Also, desired external url to the skins directory can be configured (e.g. wmf points it to //bits.wikimedia.org/skins instead of $wgScriptPath/skins; that can complicate things as well.

Do we want to encourage this though? Extensions linking to core resources directly? I can also understand if we would purposely not allow this (just thinking out loud)
Comment 8 Niklas Laxström 2012-03-05 08:32:09 UTC
It makes it hard to stay consistent with core styles and look if we do not allow it. I was trying to use the close button image for my translation editor.

Would changing localBasePath/remoteExtPath/somethingElse allow to make extension module that could use core images?

Simple example would be to use the code below in the file extensions/Translate/resources/ext.translate.quickedit.css

.mw-translate-close {
  background-image: url( '../../../skins/common/images/closewindow19x19.png' );
}
Comment 9 Krinkle 2012-03-05 08:35:44 UTC
Hm.. do you have extension checked out and/or symlinked into ./w/extensions or only outside ./w ? Remember that for embedding the path needs to exist from the perspective of the file system.
Comment 10 Niklas Laxström 2012-03-05 08:40:17 UTC
I have extensions in the standard location at w/extensions.
Comment 11 Mark A. Hershberger 2012-06-22 20:51:22 UTC
I have a skin whose CSS *file* at /wiki/skin/skinName/file.css that refers to something like

   background: url(bg.gif)

This is being rewritten as

   background: url(/wiki/bg.gif)

no matter what I change the path to.

A similar thing at [[MediaWiki:Common.css]] appears to get rewritten correctly.  That is, I can change the path to something like

   background: url(skins/skinName/bg.gif)

and MW will correctly rewrite [[MediaWiki:Common.css]] to point to

  background: url(/wiki/skins/skinName/bg.gif)

Haven't yet tested this with 1.19 and, fwiw, I'm seeing this on Windows so maybe there is something crazy with the file stating and caching.
Comment 12 Krinkle 2012-06-30 04:52:42 UTC
(In reply to comment #11)
> I have a skin whose CSS *file* at /wiki/skin/skinName/file.css that refers to
> something like
> 
>    background: url(bg.gif)
> 
> This is being rewritten as
> 
>    background: url(/wiki/bg.gif)
> 
> no matter what I change the path to.

Which kind of path path where?
It sounds like remoteBasePath was not set in the module definition.

> > A similar thing at [[MediaWiki:Common.css]] appears to get rewritten correctly.
>  That is, I can change the path to something like
> 
>    background: url(skins/skinName/bg.gif)
> 
> and MW will correctly rewrite [[MediaWiki:Common.css]] to point to
> 
>   background: url(/wiki/skins/skinName/bg.gif)

The default base path is external: wgScriptPath / local: $IP. So that works as expected.
Comment 13 Bartosz Dziewoński 2014-06-01 20:34:01 UTC
Eh, everything under skins/common/ should be considered legacy these days…
Comment 14 Niklas Laxström 2014-06-02 07:23:47 UTC
(In reply to Bartosz Dziewoński from comment #13)
> Eh, everything under skins/common/ should be considered legacy these days…

This bug is about re-using core image resources in extensions. It does not matter which path they are in. See bug 48067 for an use case.

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


Navigation
Links