ayg wrote:

Note that for JS, you can accomplish this easily enough, by using document.write( '<script type="text/javascript" src="..."></script>' ); or similar. For CSS you can't, since imports need to go at the beginning of the document for some crazy reason, and user CSS is appended to the end of site CSS; you have to use JS to import the CSS too. But it's more or less doable now, is the point, by anyone who wants it. So not such a high priority compared to other CentralAuth things we want, IMO.

dotkorg wrote:

For CSS you can't, since imports need to go at the beginning of the
document for some crazy reason, and user CSS is appended to the end of site
CSS; you have to use JS to import the CSS too.

I can actually import an external file or subpage by using @import "... .css&action=raw&ctype=text/css";

But it's more or less doable now, is the point, by anyone who wants it.
So not such a high priority compared to other CentralAuth things we want, IMO.

I agree; it is not a problem if a user wants this on a few wikis, but it would be really useful to users monitoring multiple projects.

ayg wrote:

(In reply to comment #2)

For CSS you can't, since imports need to go at the beginning of the
document for some crazy reason, and user CSS is appended to the end of site
CSS; you have to use JS to import the CSS too.

I can actually import an external file or subpage by using @import "...
.css&action=raw&ctype=text/css";

In IE, maybe. Try it on a standards-compliant browser like Firefox and in my experience it will fail. As the spec says:

"CSS 2.1 user agents must ignore any '@import' rule that occurs inside a block or after any valid statement other than an @charset or an @import rule."
http://www.w3.org/TR/CSS21/syndata.html#at-rules

Your user CSS file is appended to the end of the site CSS file, which in turn will commonly contain at least one valid statement, so last I checked, Firefox correctly ignores any @import in user CSS. CSS3 has the same restriction, in the current draft for this component:

"Any @import rules must follow all @charset rules and precede all other at-rules and rule sets in a style sheet."
http://www.w3.org/TR/2003/WD-css3-syntax-20030813/#at-import

dotkorg wrote:

(In reply to comment #3)

In IE, maybe. Try it on a standards-compliant browser like Firefox and in my
experience it will fail.

It may not work in theory, but it works in practice :)

Please see for example:

• http://fr.wiktionary.org/wiki/Utilisateur:Korg/monobook.css
• http://meta.wikimedia.org/wiki/User:Korg/global.css

The CSS subpage is properly imported when using Firefox 2.0.0.14, Opera 9.27 or IE7.

ayg wrote:

No, I see, you're right. I was misremembering how we do user CSS: it's as its own file, apparently, so it works fine. I guess I had it confused with generated JavaScript, where we do concatenate various things.

Wiki.Melancholie wrote:

Referring to bug 16575#c1: See also 4547.

And see [[meta:User:Pathoschild/Scripts/SynchCrosswiki]] for a workaround service.

charlie wrote:

Isn't this what the [[mediawiki:Extension:GlobalCssJs]] extension is?

Probably worth building into CentralAuth instead of enabling some random extension.

The extension on the wiki appears to use shared user tables, which is not what we use. We use the CentralAuth extension. Some kind of global preference would be required. The extension is therefore not suitable for Wikimedia.

beau wrote:

I have submitted gerrit change #7274 for review.

Can someone with the appropriate access please add 14759 to the "See also" field? Thanks.

(In reply to comment #8)

Probably worth building into CentralAuth instead of enabling some random
extension.

If an extension can be written to work with both CentralAuth and shared user tables, that's a plus rather than adding more bloat to CentralAuth.

The extension on the wiki appears to use shared user tables, which is not
what
we use. We use the CentralAuth extension. Some kind of global preference
would
be required. The extension is therefore not suitable for Wikimedia.

The extension could call a hook which CentralAuth ties into to check whether the user on meta == local user.
I don't know why a user preference would be required, we don't have one to turn on/off userjs/css. If a user wants it disabled, they just blank/delete the page.

The extension would probably need to be re-written to use ResourceLoader, moved to git, etc.

(In reply to comment #9)

I have submitted Gerrit change #7274 for review.

Are you still working on this?

(In reply to comment #12)

(In reply to comment #9)

I have submitted Gerrit change #7274 for review.

Are you still working on this?

I've picked up the patch and will attempt to finish it.

IMO this feature should live in its own extension. The only dependency that this has upon CentralAuth is whether user:a @ xxwiki === user:a @ yywiki. That can easily be a hook which CentralAuth interfaces with. Other comments would be appreciated :)

(In reply to comment #13)

IMO this feature should live in its own extension. The only dependency that
this has upon CentralAuth is whether user:a @ xxwiki === user:a @ yywiki.
That can easily be a hook which CentralAuth interfaces with. Other comments
would be appreciated :)

It's a matter of expectations:

• Would you expect anyone to want to install a GlobalBits script but not install CentralAuth?

• Would you expect when installing CentralAuth that it would include the ability to have global bits?

After framing it this way, I think I see your point. A separate extension probably makes sense. Pick an extension name? :-)

I think this feature is small enough and sufficiently linked to CentralAuth that it doesn't make sense to split out.

The separate extension would be very small, and essentially only call the core ResourceLoader and LB/DB_Multi interface and the CentralAuth interface. So there would be no added value in separating it because it has no re-usable components. And the components it uses that are re-usable are already available for other extensions to depend on in core or CentralAuth.

I think we should either reject this feature, or add it to CentralAuth.

Also note that, like user and site css/js in core (wgAllowUserJs etc.), this is also behind a configuration flag. So any concerns an admin may have are addressed by that.

(In reply to comment #15)

The separate extension would be very small, and essentially only call the
core
ResourceLoader and LB/DB_Multi interface and the CentralAuth interface. So
there would be no added value in separating it because it has no re-usable
components. And the components it uses that are re-usable are already
available
for other extensions to depend on in core or CentralAuth.

Having a small extension that serves a specific purpose isn't a problem IMO.

If your wiki uses a shared user table, or any other non-CA global authentication configuration (LDAP possibly), then it's entirely re-usable. I'm not aware of what in core that offers this feature, nor any other extensions (excluding Skizzerz's extension mentioned above).

I think we should either reject this feature, or add it to CentralAuth.

Rejecting this feature isn't an option ;)

Also note that, like user and site css/js in core (wgAllowUserJs etc.), this
is
also behind a configuration flag. So any concerns an admin may have are
addressed by that.

If split out to another extension, there is no need for a feature flag, you either enable the extension or you don't.

(In reply to comment #15)

I think this feature is small enough and sufficiently linked to CentralAuth
that it doesn't make sense to split out.

Sufficiently linked in what ways?

Change 7274 had a related patch set uploaded by Krinkle:
(bug 13953) Allow global user CSS/JS.

https://gerrit.wikimedia.org/r/7274

I agree with Krinkle, I think this module is small enough that it can live in CentralAuth without a problem. I'd be happy to see it merged into that extension.

(In reply to comment #19)

I agree with Krinkle, I think this module is small enough that it can live in
CentralAuth without a problem. I'd be happy to see it merged into that
extension.

With the caveat that this really should be part of the (mythical) central code repository, which is currently wanted by lots of people, but not on anyone's roadmap. If/when that happens, it should be easy to convert to that system, and I think that should be easy with the design in this patch.

(In reply to comment #19)

I agree with Krinkle, I think this module is small enough that it can live in
CentralAuth without a problem.

It's not a matter of whether it's problematic, per se, it's a matter of whether it's expected behavior. As I laid out in comment 14, I think putting this code into the CentralAuth extension probably defies reasonable user expectations.

(In reply to comment #19)

I agree with Krinkle, I think this module is small enough that it can live in
CentralAuth without a problem. I'd be happy to see it merged into that
extension.

I agree that it can live in CentralAuth with no problems, but I don't believe it's best for it to live there.

On Uncyclopedia we use shared user tables, and we'd also like to have global JS/CSS. Installing CentralAuth just to get that feature makes no sense at all.

Making a separate extension work with CentralAuth is pretty simple, as can been seen at gerrit change #94837.

That said, I'd like to see this deployed by the end of the year so I'd rather not waste time bikeshedding over where the code will live, and I can copy it into a separate extension for non-WMF usage.

(In reply to comment #22)

(In reply to comment #19)

I agree with Krinkle, I think this module is small enough that it can live in
CentralAuth without a problem. I'd be happy to see it merged into that
extension.

I agree that it can live in CentralAuth with no problems, but I don't believe
it's best for it to live there.

Totally agree :)

That said, I'd like to see this deployed by the end of the year so I'd rather
not waste time bikeshedding over where the code will live, and I can copy it
into a separate extension for non-WMF usage.

If it's part of CentralAuth, I'm pretty sure we can get it rolled out. If it a separate extension, I'm not sure. If it was based on the code that's in the current patch, I would pass the security review pretty much right away. The rest of the process may take some work.

(In reply to comment #23)

If it's part of CentralAuth, I'm pretty sure we can get it rolled out. If it
a
separate extension, I'm not sure. If it was based on the code that's in the
current patch, I would pass the security review pretty much right away. The
rest of the process may take some work.

I9329573da7d4f2af60515ef32b3b64bb769e3755 is what it looks like in a separate extension.

Deploying a new extension takes some more time, but I think doing it correctly is more important. This bug has been open for 5+ years, waiting a bit more is fine. Now that the code is written, I just don't want to get it stuck on bikeshedding where the code should live.

@Krinkle: Is deploying it in a separate extension okay for you?

(In reply to comment #16)

(In reply to comment #15)

If your wiki uses a shared user table, or any other non-CA global
authentication configuration (LDAP possibly), then it's entirely re-usable.
I'm
not aware of what in core that offers this feature, nor any other extensions
(excluding Skizzerz's extension mentioned above).

I think we should either reject this feature, or add it to CentralAuth.

Rejecting this feature isn't an option ;)

What I meant is, if this is small enough that it doesn't need an extension (e.g. can be done with LocalSettings), then we'd reject it as a feature in CentralAuth, but just document how to enable it using mediawiki core features in your LocalSettings.

(In reply to comment #17)

(In reply to comment #15)

I think this feature is small enough and sufficiently linked to CentralAuth
that it doesn't make sense to split out.

Sufficiently linked in what ways?

It needs a pointer to the 'central' wiki and a way to resolve that reference in the site matrix. I thought this was CentralAuth feature. Though SiteMatrix is indeed a CentralAuth feature, it looks like wgLocalDatabases and (Multi)-SiteConfiguration are actually core features, so it isn't really linked to CentralAuth in any way other than the ability to verify that the user's account is confirmed on both wikis. That's the only thing the patch had that is CentralAuth specific. If we move this else where, we should still somehow enforce that (perhaps through a hook that CentralAuth can use to communicate with this other extension, when one has both installed).

(In reply to comment #21)

It's not a matter of whether it's problematic, per se, it's a matter of
whether it's expected behavior. As I laid out in comment 14 [..]
into the CentralAuth extension probably defies reasonable user expectations.

(In reply to comment #14)

(In reply to comment #13)
It's a matter of expectations:

1. Would you expect anyone to want to install a GlobalBits script but not

install CentralAuth?

2. Would you expect when installing CentralAuth that it would include the

ability to have global bits?

After framing it this way, I think I see your point. A separate extension
probably makes sense. Pick an extension name? :-)

Though I mind it being in a separate extension, I'm pretty sure the question to both questions is "Yes, but..". 1) Yes, though perhaps not just CentralAuth. As pointed out, there are other ways to set up wiki farms. But each one probably comes with small details that need to be handled specifically to make it work correctly. For example, in the case of CentralAuth we need the global user module to take into account that the user has a local account on both wikis involved. Even if we move this to a separate extension, we still need something in CentralAuth that will tab into this other extension to enforce that.

And given that the amount of code to create global user modules is so small, I figured it wouldn't be worth it. We might as well document that bit code, advocate its use and implement it in CentralAuth as primary example + the CentralAuth specific bits, and then people using other ways to set up wiki farms can copy the same example and implement their bits as well.

Again, I'm fine with it being an extension, but it will still need some local settings tuning, and hooks with CentralAuth.

(In reply to comment #20)

(In reply to comment #19)

I agree with Krinkle, I think this module is small enough that it can live in
CentralAuth without a problem. I'd be happy to see it merged into that
extension.

With the caveat that this really should be part of the (mythical) central
code repository, which is currently wanted by lots of people [..]

What central code repository are you talking about? I suspect you might refer to the concept of a central wiki for one or more of templates, gadgets and lua modules. This does not overlap with global user modules and would be hard or inappropriate to utilise for this purpose I think.

(In reply to comment #23)

If it's part of CentralAuth, I'm pretty sure we can get it rolled out. If it
a separate extension, I'm not sure.

The separate extension already existed, and is now being rewritten. It will be using similar methods, but will require proper extension review nonetheless as it isn't a straight copy from the patch (and couldn't be).

(In reply to comment #24)

@Krinkle: Is deploying it in a separate extension okay for you?

I'm okay with us reviewing, maintaining and deploying this as a separate extension.

Change 7274 abandoned by Legoktm:
Implement global user CSS/JS module

Reason:
Being pursued as a separate extension, most of the code was moved to I9329573da7d4f2af60515ef32b3b64bb769e3755

https://gerrit.wikimedia.org/r/7274

Bug 57891 is tracking enabling the GlobalCssJs extension on Wikimedia wikis.

Change 154432 had a related patch set uploaded by MZMcBride:
Enable GlobalCssJs on all CentralAuth wikis minus loginwiki

https://gerrit.wikimedia.org/r/154432

Change 154432 merged by jenkins-bot:
Enable GlobalCssJs on all CentralAuth wikis minus loginwiki

https://gerrit.wikimedia.org/r/154432