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

[mediawiki/extensions/OAuth@master] OAuthManageMyGrants: Remove mediawiki ui button stylesheet

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

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

[mediawiki/extensions/GuidedTour@master] Removes deprecated mediawiki.ui.button in favor of Codex

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

Change 982910 merged by jenkins-bot:

[mediawiki/extensions/OAuth@master] OAuthManageMyGrants: Remove mediawiki ui button stylesheet

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

Change 979432 merged by jenkins-bot:

[mediawiki/extensions/ExternalGuidance@master] Switch from mediawiki ui to Codex markup

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

@Jdlrobson Hi! As revealed here T346469#9411227, the patch in this task breaks the display of Main Pages in several projects. Is there any solution to fix this?
https://ru.wikipedia.org/wiki/Заглавная_страница

As a hotfix, you could create a gadget that loads mediawiki.ui.button on the main page.

However, I believe the real solution for the time being (until T346469 is resolved) is reverting the patch – taking a look at the direct mainspace usages (i.e. without templates considered), there are 1221 results (and not 81), mostly in meta-projects (Meta, mediawiki.org, Wikimania, chapters’ wikis), where the mainspace is not special in this regard and using MediaWiki UI should be perfectly okay. Even on content projects, the majority of usage is on main pages and other portal pages that happen to be in the main namespace.

I've tried to create a style-only styles in Russian Wikipedia that loads mediawiki.ui.button as a dependency but it didn’t work. Not sure why something like this was done without appropriate testing at least on beta cluster, though.

Style-only ResourceLoader modules/gadgets cannot have dependencies, you need to use a general-typed gadget (which causes a flash of unstyled content and doesn’t work without JS, but you have no other choice).

@Iniquity thanks for the ping.

On long term I would advise migrating these to a new button template with its own styles based on the existing mw-ui-button styles. The decision of whether Codex is stable to use (T346469), is separate from deprecating the MediaWiki UI library. If something does come out of the Codex ticket it will be easy to migrate to that and if not these templates will not be broken by the inevitable removal of MediaWiki UI. I don't expect that to happen until at least 1.42 so I would advise planning for both outcomes now.

As a short term fix I would recommend one of three things:

1. We relax the rule to permit usage (for now) on main pages and backport a patch this week (likely Wednesday). I am happy to make an exception for main pages for now.
2. move your Main Page off the article namespace (as Polish Wikipedia does) [1]
3. We create a template on wiki to manage the button template (and thus begin preparing for the long term removal). This would essentially be a template styles version of what you've done in your MediaWiki:Gadget-mw-ui-button-hack.css gadget. (I see you've created https://ru.wikipedia.org/wiki/MediaWiki:Gadget-mw-ui-button-hack.css but that doesn't seem like an ideal solution here as this is slowing down the presentation of all pages by adding a few kb of CSS to all pages for exactly one page on your whole wiki. Perhaps an adapted https://ru.wikipedia.org/w/index.php?title=%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:%D0%9A%D0%BD%D0%BE%D0%BF%D0%BA%D0%B0&action=edit with new classes could be used instead?)

Let me know which you prefer!

taking a look at the direct mainspace usages (i.e. without templates considered), there are 1221 results (and not 81), mostly in meta-projects (Meta, mediawiki.org, Wikimania, chapters’ wikis), where the mainspace is not special in this regard and using MediaWiki UI should be perfectly okay. Even on content projects, the majority of usage is on main pages and other portal pages that happen to be in the main namespace.

@Tacsipacsi this is a misleading number. When you filter out TemplateStyles and subpages (e.g. doc pages) that number drops to 491 [2] and if you inspect those templates using the WhatLinksHere api [e.g. 3] there are only 21 usages inside the main namespace. You are welcome to inspect my methodology (script) [4] if you think I made a mistake in my assessment.

[1] https://pl.wikipedia.org/wiki/Wikipedia:Strona_g%C5%82%C3%B3wna
[2] https://global-search.toolforge.org/?q=mw-ui-button&regex=1&namespaces=10&title=%5B%5E%5C.%5C%2F%5D*
[3] https://en.wikipedia.org/wiki/Special:ApiSandbox#action=query&format=json&prop=linkshere&titles=Template%3AClickable%20button&formatversion=2&lhnamespace=0
[4] https://gist.github.com/jdlrobson/1a00ae06c6d88e48d7280e2639ba802e
[5] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/428856

@Jdlrobson: I know that the hack is suboptimal, at the same time, given that 1) this is a pretty big regression of main page styles, 2) that you didn’t account for while writing your patch or didn’t test for, 3) and that cannot be mitigated by putting the same code into TemplateStyles since there are some unsupported properties in mw-ui-button code; I don’t think this gadget is doing any more harm than the untested deprecation of mw-ui-button already did.

@stjn it's unfortunate this caused a regression and I apologize for that, but it's unrealistic to expect me to test every single page individually. We can only judge impact based on global impact using the existing imperfect tools (global-search) we have :-(. It's especially challenging when the APIs themselves are marked as deprecated and have never been marked as stable. We have to strike a balance between moving MediaWiki forward and disruption. If you have any thoughts around how we could improve on communication/expectation setting/judging impact I'd love to hear them on https://www.mediawiki.org/wiki/Talk:Stable_interface_policy/Frontend. I do think for example that Main page's should be weighted more heavily (but right now we lack the tools to determine how many main pages across all our projects would be impacted by this change).

I do disagree that the gadget does more harm than a missing style on a functional link. You are impacting loading speed for all your users on all pages by loading the whole library just to make one button on one page look nice. I solved this same problem for MediaWiki.org today modifying Template:Clickable_button_2. It makes use of a new module Module:Clickable_button_3 and Template:Clickable_button_2/style.css ) and the styles only get added to the page that use it (and are much slimmer than the previous MediaWiki UI module). I think it could be useful if adapted for Russian Wikipedia and would likely minimize unexpected breakage on the long term.

I am about to begin my winter break and will be signing off Phabricator, so wish you a happy conclusion to 2023 and look forward to collaborating with you in 2024 but you should feel free to ping me on the wikis using my username if you have any questions or concerns about those templates.

Change 985150 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] Skin: Restore autoloading of mediawiki.ui.button styles

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

In T182050#9413647, @Jdlrobson wrote:

taking a look at the direct mainspace usages (i.e. without templates considered), there are 1221 results (and not 81), mostly in meta-projects (Meta, mediawiki.org, Wikimania, chapters’ wikis), where the mainspace is not special in this regard and using MediaWiki UI should be perfectly okay. Even on content projects, the majority of usage is on main pages and other portal pages that happen to be in the main namespace.

@Tacsipacsi this is a misleading number. When you filter out TemplateStyles and subpages (e.g. doc pages) that number drops to 491 [2]

I don’t filter out TemplateStyles and subpages, because I’m speaking about NS_MAIN, not NS_TEMPLATE. And I’m speaking about NS_MAIN because that’s where you disabled the autoloading. Any mainspace usages of those 489 templates should be added to the direct mainspace usages. (Determining/estimating the number of mainspace usages is much more difficult than a simple global search, which is why I decided not to include them, knowingly underestimating the impact.)

and if you inspect those templates using the WhatLinksHere api [e.g. 3] there are only 21 usages inside the main namespace. You are welcome to inspect my methodology (script) [4]

Thanks for sharing the script! So the result of your script should be added to the number of direct usages.

if you think I made a mistake in my assessment.

Yes, you made a mistake: query+linkshere is about links, which we’re not interested in. The correct endpoint is query+transcludedin. (Special:WhatLinksHere shows both, but the API endpoints are separate.)

I fixed the endpoint, and made some tweaks to the output to make it more convenient to post-process:

diff --git a/imported.js b/imported.js
index b73ed09..78f917c 100644
--- a/imported.js
+++ b/imported.js
@@ -9,20 +9,13 @@ let inputStream = fs.createReadStream('mw-ui-button.csv', 'utf8');
 const sleep = (delay) => new Promise((resolve) => setTimeout(resolve, delay))
 
 const makeQuery = ( host, title ) => {
-    const url = `https://${host}.org/w/api.php?action=query&format=json&prop=linkshere&titles=${encodeURIComponent(title)}&formatversion=2&lhnamespace=0`
+    const url = `https://${host}.org/w/api.php?action=query&format=json&prop=transcludedin&titles=${encodeURIComponent(title)}&formatversion=2&tinamespace=0`
     return fetch( url )
         .then((r) => r.json())
         .then((r) => {
-            let lh;
-            try {
-                lh = r.query.pages[0].linkshere;
-            } catch ( e ) {
-                lh = null;
-            }
-            if (lh) {
-                console.log(host, title, lh.length)
-            } else {
-                console.log(host,title,0)
+            const count = r.query.pages[0].transcludedin?.length;
+            if (count) {
+                console.log('%d\t%s\t%s', count, host, title);
             }
         })
 }

and then ran it:

$ node imported.js | cut -f1 | awk '{n += $1}; END{print n}'
518

So the current estimate of the affected pages is 1219+518=1737. (The mainspace search now returned two results less than last time.)

@Jdlrobson thanks for creating that module so quickly, I’ve replaced our admittedly bad gadget with its use on the main page, with some tweaks to make it possible to set multiple classes matching mw-ui- style, see the history in https://ru.wikipedia.org/wiki/Модуль:Clickable_button_2 (probably needs a better name, but not the biggest concern for us for now).

Change 985150 merged by jenkins-bot:

[mediawiki/core@master] Skin: Restore autoloading of mediawiki.ui.button styles

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

@Tacsipacsi thanks for flagging the bug - this is why code review is important! I appreciate you looking at it. I re-ran the script before the holidays.
I also got 518 when I tried the revised script which I have compiled into: https://docs.google.com/spreadsheets/d/19xK_rBTx2dhFQ67TOsXAJGG3O6FwPL09N6D9SMbMGI4/edit#gid=0
I got 1218 on main namespace but 1146 of those were subpages. Many of these are translations as I pointed out before. Looking closely https://meta.wikimedia.org/wiki/Wikimedia_Affiliates_Data_Portal and translations doesn't even use the library (it's improved without it). After the holidays and 5 edits by myself, it seems some of those fixes have propagated to translations as I expected - and that number has reduced to 968.

I'll be having some conversations with the design systems team and web team over the next few weeks about how we want to proceed with this deprecation.
It seems like it might also be useful for us to re-ignite the discussion around communication and impact to improve our shared understanding around communication between consumers and providers.

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

[mediawiki/extensions/Flow@master] Flow should maintain a local version of MediaWiki UI

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

Change 995375 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Remove uses of $wgUseMediaWikiUIEverywhere

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

Change 995376 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Remove $wgUseMediaWikiUIEverywhere

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

Change 995375 merged by jenkins-bot:

[mediawiki/core@master] Remove uses of $wgUseMediaWikiUIEverywhere

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

Change 995376 merged by jenkins-bot:

[mediawiki/core@master] Remove $wgUseMediaWikiUIEverywhere

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

Change 987868 abandoned by Jdlrobson:

[mediawiki/extensions/Flow@master] Flow should maintain a local version of MediaWiki UI

Reason:

Abandoning this as Design Systems Team will now be overseeing this now.

FWIW I think continuing to tie Flow to Codex design tokens is not worth the effort. We should be looking to undeploy this extension and applying pressure by degrading it as much as possible - even if that means it goes out of sync with other parts of the interface. Taking snapshots of the current CSS preserves it as it was. If we continue to support design tokens here we are effectively maintaining it and keeping it up to date with the rest of the codebase IMO and that doesn't seem like a great use of our time.

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

Change 982911 merged by jenkins-bot:

[mediawiki/extensions/GuidedTour@master] Removes deprecated mediawiki.ui.button in favor of Codex

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

Change 1011267 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] mediawiki.ui: Remove 'utilities.less'

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

Change 1011267 merged by jenkins-bot:

[mediawiki/core@master] mediawiki.ui: Remove 'utilities.less'

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

Test wiki on Patch demo by Jdlrobson using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/f5539e0094/w/

Test wiki on Patch demo by Roan Kattouw (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/a1e0f00ea6/w/