Last modified: 2014-06-08 00:46:15 UTC
Presently, Mediawiki provides the system messages: Mediawiki:Group-sysop.css Mediawiki:Group-sysop.js Mediawiki:Group-checkuser.css Mediawiki:Group-checkuser.js etc. Such that most user classes can have specific CSS and JS associated with them. See also: http://www.mediawiki.org/wiki/Manual:User_group_CSS_and_Javascript As written, the code explicitly excludes the ability to manage content based on membership in the "user" group of logged-in editors. Is there a good reason for this? If there is not a specific reason for prohibiting Mediawiki:Group-user.css Mediawiki:Group-user.js Then I would suggest that they should be added. Such a mechanism would provide a natural way to differentiate some content for logged-in editors vs. readers. For example, many message boxes and error messages can be rather cryptic or unhelpful for readers, and it may make sense to provide readers with a more general explanatory statement while showing editors a different and more specific "how do I fix this" kind of message. Obviously any such differentiation would have to be mindful of the fact that IPs can be editors too, but I think decisions about if/when message differentiation is appropriate is more a community issue than a technical one. So, if there isn't a technical reason that would block this, can we add "user" to the set of classes that can have class-wide CSS and JS pages?
I think this is trivial; we already have Group-autoconfirmed.css.
Pretty simple, code is at https://github.com/wikimedia/mediawiki-core/blob/master/includes/resourceloader/ResourceLoaderUserGroupsModule.php#L62 Will also need i18n messages.
I see a need in MediaWiki:Group-user.css/js since autoconfirmed is not granted from the user's registration in some wikis. I've tried to do some CSS for non-autoconfirmed but logged-in users in MediaWiki.org and was just wondering about that behaviour.
Copying Happy-melon on this bug in case he'd like to weigh in here (he authored r82285).
> Obviously any such differentiation would have to be mindful of the fact that > IPs can be editors too, but I think decisions about if/when message > differentiation is appropriate is more a community issue than a technical > one. My reason for not originally implementing Group-user is basically a personal philosophy, that I do not trust wiki communities (enwiki especially) to *actually* remember the point above. "Logged in verses logged out" is **not** the same as "readers verses editors", and as such, I felt (and still feel) that this feature had *only* misuses, not legitimate uses. If this was made available as the only way of cleanly leveraging one of these distinctions, it would be used as "well this is the best we've got", but it's use would actually be quite detrimental to the wiki's openness.
*** Bug 57486 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > My reason for not originally implementing Group-user is basically a personal > philosophy, that I do not trust wiki communities (enwiki especially) to > *actually* remember the point above. "Logged in verses logged out" is > **not** > the same as "readers verses editors", and as such, I felt (and still feel) > that > this feature had *only* misuses, not legitimate uses. If this was made > available as the only way of cleanly leveraging one of these distinctions, it > would be used as "well this is the best we've got", but it's use would > actually > be quite detrimental to the wiki's openness. Agreed, some people probably will misuse it. That said, I don't think we should limit the software in a way like this. If you have a fishbowl wiki, the distinction between readers and editors *is* whether you're logged in or not.
(In reply to comment #7) > Agreed, some people probably will misuse it. That said, I don't think we > should limit the software in a way like this. Are you saying that because you believe that the potential for legitimate use outweighs the potential for misuse in this instance, or because you think as a general principle we should *never* not implement features because they have the potential to be misused? If so, I don't think that's a very realistic position. The damage to new editor recruitment that creating a UI distinction between logged-in and logged-out would do is creeping and insidious (user makes first tentative step towards editing, is suddenly attacked by a barrage of weird new functionality; conversely reader does not see any of the invitations to edit, so does not make first step). If you have a fishbowl wiki, the > distinction between readers and editors *is* whether you're logged in or not. This has never been an issue that's particularly hard to work around; the main benefit to having it done 'formally' is mainly proper caching via ResourceLoader, and reduction of redundant code load. Both of which are less important on a fishbowl wiki, which will generally be smaller.
I've taken up this task in the Code-in, and should have a working patch very soon.
Change 99434 had a related patch set uploaded by Scimonster: Add group-user-css/js messages. https://gerrit.wikimedia.org/r/99434
One use-case I ran into myself is scripts which use custom preferences (see https://www.mediawiki.org/wiki/API:Options#Changing_options) – these can sometimes only be reasonably ran for registered users.
Change 99434 had a related patch set uploaded by Scimonster: Unblacklist group-user-css/js https://gerrit.wikimedia.org/r/99434
Change 99434 merged by jenkins-bot: Unblacklist group-specific JS/CSS for the user group https://gerrit.wikimedia.org/r/99434
Done by Scimonster as a GCI task. Thanks! I updated the documentation at [[mw:Manual:User group CSS and Javascript]].
