Page MenuHomePhabricator

Users custom CSS and JS not linked from Special:Preferences
Closed, ResolvedPublic


Author: gangleri


[[User:foo/Monobook.css]] and [[User:foo/Monobook.js]] are part of user
preferences. A new section in [[Special:Preferences]] should include these links
and inform in a few words about their usage.

I did run into this because I reaslised that a wiki does not use
[[MediaWiki:Monobook.js]] of the content language but of the one selected in the
user interface.

This has many implications about viewing a page (or a Mediawiki page). What you
will see with the English interface looking at
is not the same as if you select the Finnish one.

Probably diffs between two pages are not supported at the moment. The new
section could contain links to the relevant diffs comparing the default
[[MediaWiki:Monobook.js]] with the MediaWiki:Monobook.js/<language code> and
also with [[User:foo/Monobook.js]].

Regards Reinhardt [[user:gangleri]]

Version: 1.11.x
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:35 PM
bzimport set Reference to bz2314.
bzimport added a subscriber: Unknown Object (MLST).

gangleri wrote:

I see a handling problem ofering links to the user before he / she has *saved*
the preferenced. The links about skin ".css", ".js" user page and user talk page
should apear *after* saving the preferences / creating an account but probably
not after log in.

See also bug 2359: "New user page - reminder of talk page"

brian wrote:

What's the problem? If the user changes the language in
preferences without saving them, two links should appear -
one for the old language, one for the new language.

Links to the .css/.js in the skin tab added with r38587.

I've reverted r38587, r38589 for now in r38610.

This clutters up the prefs UI with a lot of links which don't currently apply, most of which will never be used. It also isn't clear how it would apply to proposed non-skin-specific pages such as User:X/common.css/.js and User:X/print.css

Fails to check site config if user js/css are enabled; produces useless links if they're not.

(In reply to comment #7)

Fails to check site config if user js/css are enabled; produces useless links
if they're not.

This was fixed.