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.
Version: 1.20.x
Severity: enhancement
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.
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 :)
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.
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.
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?
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)
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' );
}
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.
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.
(In reply to comment #11)
I have a skin whose CSS *file* at /wiki/skin/skinName/file.css that refers to
something likebackground: 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.
(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.