Page MenuHomePhabricator

Vector-2022.js should no longer load legacy Vector site and user scripts/styles
Open, MediumPublicBUG REPORT

Description

NOTE: Please see T357580 and https://www.mediawiki.org/wiki/Reading/Web/Desktop_Improvements/Features/Loading_Vector_2010_scripts for any actions your community may need to take as part of this change

As part of the splitting of the Vector skins (T291098), here was a product requirement to minimize impact on communities.

To fulfil this the new modern Vector skin:

  • loads both MediaWiki:Vector.(css,js) and MediaWiki:Vector-2022.(css,js)
  • loads both User:<username>/vector.(css,js) and User:<username>/vector-2022.(css,js)

Over time this has become problematic rather than helpful leading to bugs like T357473.

Plan

  • A configuration flag will be added to Vector to disable the site styles/scripts behaviour. Communities can request to disable it, when they are ready. When enabled Vector 2022 will not load either JS or CSS. This is a good opportunity for communities to do some housekeeping, e.g. moving styles to TemplateStyles and scripts to gadgets.
  • A User-notice will be sent out to communities. Users using modern Vector will be instructed to delete/blank their user vector.(js|css) in preparation for the change.
  • We will drop support for new wikis going forward. When wikis switch skins from legacy Vector to Vector 2022 users will need to copy any relevant code from vector.js and vector.css to vector-2022.js and vector-2022.css. Site admins will need to copy important code from MedaWiki:Vector.css/js to MediaWiki:Vector-2022.css/js (February 14th 2024)
  • We will drop support for Wikibooks and Wikivoyage (February 14th 2024)

The remaining projects is based on how many vector.js and vector.css user scripts are active on the projects. Note, the existence of this page doesn't mean it is active or that the user is using Vector 2022 skin, but is the best proxy we have for limiting impact.

https://docs.google.com/spreadsheets/d/14o1gfbLJQZmIfdo4JLUg9dMtXlrG8SciPLsHly3cSe8/edit#gid=56891684

PhaseWeekWho impactedUser noticeDone
09th March 2023Nobody (intention set)T331679
114th February 2024All projects where Vector legacy is the default skin, Wikivoyage, Wikibooks, Japanese WikipediaT357580
24th MarchSee spreadsheetProjects with 0 user scripts and testwiki
318th MarchSee spreadsheet: Projects with <= 50 user scriptsT360384
416th Aprilbgwiki, bmwiki, dawiki, dewiktionary, elwiki, eowiki, eswiktionary, frwikiversity, hiwiki, hrwiki, mlwiki, mswiki, rowiki, skwiki, srwiki, tawikiT362701
57th Maynlwiki,simplewiki,ptwiki,svwiki,kowiki,cswiki,hewiki,cawiki,huwiki,urwiki,idwiki,nowiki,trwiki,viwiki,dawiki: Projects with > 100 user scripts < 500T362701..
621st Mayenwiki,zhwiki,metawiki: Projects with > 500 user scriptsT362701..

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

I would defer to enwiki community on best strategy here. Perhaps you could ask around and see if that advice of moving towards common makes sense

That was a recommendation that I suspect other wikis would agree with, now that we're a decade on (at least) from when common.css/js was enabled for users. Secondly, I was thinking it could be a part of whatever page (phab helper task or wiki page) is set up to handle users who tune in rather than some necessarily technical change.

and maybe it could be automated

Possibly could be. I'd have to get actual consensus for that from the community though and that's potentially forcing breakage on random users they have to undo rather than asking them to opt-in to moving things (the local interface administrators don't have a cohesive opinion on how best to manage common/skin js subpages at scale, and I haven't spent any significant time thinking about or trying to solve the problem even to get all of us thinking about it as the crushing debt it is today).

We can make the "transition" state more obvious with a console log message

"We're not going to load X anymore in Y locations" in console seems like a reasonable thing to do, but I suspect that most people (thanks, everything-that-makes-user-added-javascript-on-Wikipedia) won't know to look there.

( https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/881715 )

Constants::SKIN_NAME_MODERN is a funny name given we have a skin named Modern. (Mostly just funny and possibly confusing a decade down the road.)

'Your gadgets are running in compatibility mode. Please copy contents of [[$legacyScript]] to [[$modernScript]] and blank or delete [[$legacyScript]].'

I think I'd go for truth rather than simplification here and say something like `'You use Vector 2022 but your JavaScript lives in [[$legacyScript]]. Please copy the contents of [[$legacyScript]] to [[$modernScript]] [$modernScript is where I'm advocating for User:Username/common.css] and blank or delete [[$legacyScript]] to ensure continued functioning as we prepare to turn off reliance on the old skin JavaScript. See $page_from_above for more info.)

But this is a reasonable POC for the users who look at console to see why something breaks....

a gadget could be set up to help people prepare for such a change? It's potentially pretty disruptive for people who forgot they added stuff to vector.js and vector.css that they depend on.

Setting up a gadget or run-once kind of script makes a lot of sense but would probably be non-trivial to remove the old contents from wherever to guarantee there are no duplicate imported scripts since we have a transition period regardless.

We should add a config flag regardless to empower enwiki editing community to configure this behaviour and do their own thing without worrying about other projects (that's what my above patch does).

That's your choice too, I think. It's another config element that I don't think you'll want to flip for arbitrary wikis. Perhaps just fleetwide to enable some staged rollout.

As an opinion only, specific users having and using skin-specific JS pages should be more or less an anti-pattern at this point. I'd like to recommend part of the communication be "move any JavaScript you think you'll need regardless of skin to your common.js" subpage and/or "delete the same content from your skin specific pages". That may break the use of some scripts for which we can recommend they place those in the skin-specific pages, but should overall be a more pleasant experience for helping editors who have issues with scripting having to find which scripts are causing issues.

Using common.js/css is generally a good idea, but at the same time it is not possible in every case. It's worth recommending people to use common, yes, but not everything is compatible with all skins. There are even options in RL for gadget definition for this (and gadgets on pl.wiki use this). Some scripts only work well with Vector or selected skins, and can even be created for some specific skin or skins (for example, dark subskin, hidden sidebar script).

I think the change could be done in a less disruptive way. Maybe something like this:

  1. Add an option to load vector-legacy.js/css from the legacy Vector.
  2. Add a message in the JS console about this.
  3. Add a message in the TechNews.
  4. Rollout.
  5. ⏱ And wait for feedback... This will give some time to migrate scripts to either vector-legacy or vector-2022. So separate stuff without distruption.
  6. Remove vector.js/css support from both skins.
  7. Add a message in the TechNews in advance.
  8. Rollout after a week or two.

From talk page on enwiki

Hello, I found a bug. When vector 2022 is selected and there is custom CSS on the Vector 2010 skin it will use this CSS. It will also use the CSS from the Vector 2022 page but it shouldn't. If you select one skin it should not load another's skin CSS.

Change 881716 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Allow wikis to customize whether Vector skins share user scripts and styles

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

[mediawiki/skins/Vector@master] Allow wikis to customize whether Vector skins share user scripts and styles

  • A configuration flag will be added to Vector to disable the site styles/scripts behaviour.

What has been made configurable? User or site scripts/styles?

Change 896148 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/skins/Vector@master] Extend new config flag to site styles

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

Change 896148 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Extend new config flag to site styles

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

T331679 not really, but 26d5d44 did answer my above question. (However, the question I asked in that Gerrit change went unanswered, about which I’m quite disappointed. I didn’t – and don’t – think it justified a −1, but I do think it needs an answer.)

From https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/896148/comments/93cb9ef7_58d658fd:

I think these should be two flags – site styles and scripts are easy to fix (two pages per wiki, which can fixed in a few minutes), with high performance impact (until they’re separated, all users – logged-in and logged-out – need to download the extra styles that don’t apply on their skins), while user styles and scripts potentially need a lot more time to fix, but have a very limited performance impact (basically only those users need to download extra code who regularly switch back-and-forth between the two Vector skins, and thus maintain scripts and/or styles for both).

@Jdlrobson wrote:

I'm sorry I missed this comment somehow. Thanks for flagging it on Phabricator!

That's a fair comment.

I'm not 100% sure on what strategies would make sense here, but I would like to avoid multiple temporary feature flags for a long period of time. I was optimistically hoping that it would be appropriate for some wikis to just do it (since site js|css might be the priority).

i.e.

  1. notify users this was happening
  2. change the flag and do the quick site fix
  3. deal with the small disruption to user style/scripts by responding to the inevitable community portal conversations around broken gadgets.

I think in future if needed we could change the meaning of "sharing styles/scripts" to user scripts e.g. maybe it can be a string or object.

Another thing we could do in future for site styles/scricts is simply ignore Vector.css|js if Vector-2022.css|js equivalents exist, however that might also be somewhat disruptive as potentially people may have written their Vector-2022.css|js with the understanding it was additive. That would look like this:

  1. Move contents of Vector-2022.css|js to Vector.css|js (with checks for skin config variable and using .skin-vector-2022 class) . Delete Vector-2022.css|js
  2. We make a change in Vector to check for title existence for site styles
  3. When the change is live the code is moved back.

Perhaps we could continue this on https://phabricator.wikimedia.org/T301212 in case others have ideas?

Sorry again!

The coupling might make some people fix the user pages as well due to the site ones being urgent, but it may stop others from fixing the site ones due to not being ready to fix the user pages. (I, for myself, am not ready to fix over a hundred user pages just to be able to separate the site styles and scripts.) Fully cleaning up user pages may take decades (I think many such people still have monobook.{css,js} subpages who have never changed their skin settings, so haven’t been using Monobook for over a decade), while the site ones can be done within 1-2 months, even less if global interface editors more aggressively help cleaning up the long tail.

Ignoring vector.{css,js} once vector-2022.{css,js} is created is IMO not only disruptive but also harder to understand (why did the script loaded in vector.js suddenly stop working, although I didn’t change anything in that file?), so I think it’s even worse than the current situation with the coupled settings.

My opinion on whether to do user scripting separately is that we can bite the bullet now or we can bite it later. It will be a much bigger bullet later. The longer you allow the assumption to bake in, the worse it gets, and TBH it's one reason Vector should never have been loaded with Vector 2022. During 'beta', migrating could have been done essentially without any user cost, as with the previous transitions. "Nothing is loaded from your old pages, copy-paste CSS changes to the new CSS page and preferably move any JS customizations to your common.js, but copying to Vector-2022.js will suffice." (My opinion is that JS shouldn't be a skin-specific quality in most cases.) That cat is out of the bag now and waiting isn't going to help.

There is no cleaning out user subpages ultimately regardless, at least on the large wikis without at least some sort of query or set of queries to tell us what people's skins are so we can migrate all the ones on V22 to have the same scripts available as on Vector.

Izno is right. Bite the bullet. Vector.js should apply only to Vector 2010, and Vector-2022.js should apply only to Vector 2022. Common.js should apply to all skins. Just make the change now, before the situation becomes more entrenched.

Common.js should apply to all skins.

Just to clarify this is how it currently behaves and this configuration change doesn't change that.

Just make the change now, before the situation becomes more entrenched.

I'm happy to deploy any configuration changes here provided it has gone through the https://wikitech.wikimedia.org/wiki/Wikimedia_site_requests process :-)

The last 2 linked searches above are mistaken: user pages shouldn't be named Vector.js/css, but vector.js/css (contrarily to the site scripts, which are Titlecased). Just change "Vector" to "vector" in the last 2 links.

And of course, there is a handful of wrongly named user pages, using the erroneous "Vector" case…

Sorry typo. The numbers are correct.

Change 1005569 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[operations/mediawiki-config@master] Remove Japanese Wikipedia from projects sharing user scripts

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

Change 1005569 merged by jenkins-bot:

[operations/mediawiki-config@master] Remove Japanese Wikipedia from projects sharing user scripts

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

Mentioned in SAL (#wikimedia-operations) [2024-02-21T21:27:38Z] <jhuneidi@deploy2002> Started scap: Backport for [[gerrit:1005569|Remove Japanese Wikipedia from projects sharing user scripts (T301212)]], [[gerrit:rMW10055702ccaa|Enable night mode on beta cluster (T357759)]]

Mentioned in SAL (#wikimedia-operations) [2024-02-21T21:29:00Z] <jhuneidi@deploy2002> jdlrobson and jhuneidi: Backport for [[gerrit:1005569|Remove Japanese Wikipedia from projects sharing user scripts (T301212)]], [[gerrit:rMW10055702ccaa|Enable night mode on beta cluster (T357759)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-02-21T21:42:56Z] <jhuneidi@deploy2002> Finished scap: Backport for [[gerrit:1005569|Remove Japanese Wikipedia from projects sharing user scripts (T301212)]], [[gerrit:rMW10055702ccaa|Enable night mode on beta cluster (T357759)]] (duration: 15m 25s)

Jdlrobson updated the task description. (Show Details)

Change 1012425 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[operations/mediawiki-config@master] [phase 4] Projects with < 50 user scripts no longer share skin scripts

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

Change 1012425 merged by jenkins-bot:

[operations/mediawiki-config@master] [phase 4] Projects with < 50 user scripts no longer share skin scripts

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

Mentioned in SAL (#wikimedia-operations) [2024-03-18T20:05:39Z] <urbanecm@deploy2002> Started scap: Backport for [[gerrit:1011454|Throttle: add event (T360357)]], [[gerrit:1012425|[phase 4] Projects with < 50 user scripts no longer share skin scripts (T301212)]]

Mentioned in SAL (#wikimedia-operations) [2024-03-18T20:08:00Z] <urbanecm@deploy2002> rhinosf1 and urbanecm and jdlrobson: Backport for [[gerrit:1011454|Throttle: add event (T360357)]], [[gerrit:1012425|[phase 4] Projects with < 50 user scripts no longer share skin scripts (T301212)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-03-18T20:22:05Z] <urbanecm@deploy2002> Finished scap: Backport for [[gerrit:1011454|Throttle: add event (T360357)]], [[gerrit:1012425|[phase 4] Projects with < 50 user scripts no longer share skin scripts (T301212)]] (duration: 16m 26s)

PhaseWeekWho impactedUser noticeDone
318th MarchSee spreadsheet: Projects with <= 50 user scriptsT360384
42nd AprilSee spreadsheet: Projects with 50-100 user scripts....

T360384 could have been sent out a week earlier… Could you please organize so that the User-notice goes out on the Monday of the week the change is made (e.g. for phase 4, it goes out on April 1, assuming there’s Tech News on Easter Monday)? This would ensure that admins have been informed by the time the change actually happens.

PhaseWeekWho impactedUser noticeDone
514th Aprilnlwiki,simplewiki,ptwiki,svwiki,kowiki,cswiki,hewiki,cawiki,huwiki,urwiki,idwiki,nowiki,trwiki,viwiki,dawiki: Projects with > 100 user scripts < 500....
621st Aprilenwiki,zhwiki,metawiki: Projects with > 500 user scripts....

Are you sure about the dates? These two are Sundays.

The user notice messages now are to allow projects to be reactive. There have already been two messages explaining how communities can be proactive the most recent being T357580.

I will look into the dates.

Yes, it allows them to be reactive – but there is still an important difference between “pardon, we’ll break your wiki in a day because you haven’t been proactive” and “sorry, we’ve broken your wiki six days ago because you haven’t been proactive”: namely whether interface admins can react as soon as you break it, or they have no idea what’s going on for a week. (As far as I remember, the last reminder about this was quite a while ago, so interface admins may have well forgot about it.)

Change #1020292 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[operations/mediawiki-config@master] [phase 4] Vector-2022.js should no longer load legacy Vector site and user scripts/styles

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

Change #1020292 merged by jenkins-bot:

[operations/mediawiki-config@master] [phase 4] Vector-2022.js should no longer load legacy Vector site and user scripts/styles

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

Mentioned in SAL (#wikimedia-operations) [2024-04-16T20:57:52Z] <cjming@deploy1002> Started scap: Backport for [[gerrit:1020292|[phase 4] Vector-2022.js should no longer load legacy Vector site and user scripts/styles (T301212)]]

Mentioned in SAL (#wikimedia-operations) [2024-04-16T21:01:06Z] <cjming@deploy1002> cjming and jdlrobson: Backport for [[gerrit:1020292|[phase 4] Vector-2022.js should no longer load legacy Vector site and user scripts/styles (T301212)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-04-16T21:16:19Z] <cjming@deploy1002> Finished scap: Backport for [[gerrit:1020292|[phase 4] Vector-2022.js should no longer load legacy Vector site and user scripts/styles (T301212)]] (duration: 18m 26s)