Earlier this week I asked @Urbanecm to handle this, since deleting this group will require updating community process documentation and communication with the stewards and other users who often assign global group membership.

In T409508#11352208, @Agabi10 wrote:

The composer.json file of the main branch says the library requires PHP >= 8.1.0, so wouldn't named params with whatever default value the current components have be a better option than the array-style component construction? Those should work with Phan out of the box.

Sorry about this -- the reason this broke is because we changed the way we hide the close button from using v-if to using CSS. The previous way (v-if) didn't affect you because you override the header with a custom one so we don't render our own close button regardless. The new way (CSS) did affect you, because your close button in your custom header uses the same CSS class as our built-in one.

Hmm now that I'm thinking about it a little more... do we run mergeMessageFileList for each wmf.N branch separately? If we run it only once and reuse the result across both branches, that would be a problem if an extension was missing in one branch but present in the other.

In T411516#11424578, @bd808 wrote:

I have recently been talking with @Catrope and @thcipriani about the underlying problem here and would like their feedback on my problem description and proposed solution. Obviously input from others is welcome as well.

Another bug: the sticky header isn't wide enough to cover the entire width of the screen, so very occasionally some things on the page can appear beside it when you scroll. This happens for example on pages with a large number of references:

Eric showed me this feature today and I found a bug: when I view https://en.wikipedia.beta.wmcloud.org/wiki/Paris?useskin=minerva&useformat=mobile&stickyHeaders=1&useparsoid=1 in Chrome with mobile device emulation (I used the "Pixel 7" dimensions, 412x915px) and I scroll from the "Etymology" to the "History" section, there's an oscillation bug where the ext-readerExperiments-stickyHeaders on the "Etymology" heading is rapidly removed and re-added and removed again. This doesn't happen for any of the other section transitions on this page, and it also doesn't happen on the non-Parsoid version of the page for some reason.

Right now this is not expected to work, because using Codex components in wikitext directly like this is not supported, and we don't currently have a way to automatically load the InfoChip styles when there is wikitext on the page that uses an InfoChip this way. The reason it sometimes works and sometimes doesn't is that sometimes there's an InfoChip in use somewhere else in the UI, so the InfoChip styles were loaded for that feature.

I see the same purple as Jon does, in both light and dark mode, in Chrome. But I don't know where that color is coming from, I can't find a :target-text rule anywhere (and the inspector does not make it easy to find these). Perhaps the solution here is to explicitly customize the color of the :target-text (and maybe set it differently in light vs dark mode), but that should be done in the skins (MinervaNeue and Vector 2022), not (primarily) in Codex, so untagging Codex.

Everything works great, thanks!

I'd be OK with changing the background-color-*--hover and --active tokens to use transparency instead. I don't think we'd need to create new tokens, unless the switch to transparency would really break a different usage of these tokens.

Specifically, this is about this method, plus this code in the execute() method.

The current notifications are:

This would also be a good opportunity to fix T406584. Creating an HTMLFormField subclass for this should allow us to decouple the name(s) of the query string parameter(s) from the name of the form field, which would let us get away from all the buttons having the same name attribute and instead give each of them a different name.

In T409743#11368811, @A_smart_kitten wrote:

Thank you all :)
To confirm, is there anything now preventing this task from being resolved & made public?

Thanks for this report! This has since been cleaned up by T407057: Run MoveRecoveryCodesFromTOTP.php, which combined all user's old-style (TOTP-associated) and new-style recovery codes. As a result, some users now have 11 or 20 recovery codes instead of 10, depending on when they first visited the new Special:AccountSecurity page. The combined set of recovery codes is now consistently displayed in all places where recovery codes are displayed, and is the full set of recovery codes that will work to log in to your account.

Related to T408759: we are now displaying recovery codes again, but not in a way that everyone expects.

In light of there now being 10 recovery codes, we'll have to reevaluate whether it still makes sense to implement this feature as originally designed. This is closely linked with T408025, so I've posted a comment at T408025#11368971 asking @EMill-WMF to opine on what we should do when a user's recovery codes are running low.

Some more context: the old 2FA code sent a notification when a user had 2 or fewer recovery codes remaining, encouraging them to regenerate their recovery codes. (But there was no way to do that directly, so the text of the notification instead encouraged them to disable then re-enable 2FA.) In the refactor to make recovery codes a separate method, this behavior was lost (the code still exists, but it's never used). At first we thought this would be unnecessary, because each user only had 1 recovery code and we were planning to show them their new code after they logged in with their old code (T406281), but now that we've changed the number of recovery codes back to 10 this is a bit murkier.

This issue is tracked as T394468: Font size of Codex buttons and messages is too big compared to normal text in legacy Vector, which depends on T394685: Font modes: Use the small mode in Vector legacy. I've asked if the latter can be picked up soon.

An example of the kind of bug this causes:

The patch is now deployed.

Quick patch to fix the immediate problem:

An additional complication: MediaWiki no longer writes rows with pr_cascade=1 unless pr_type='edit', and hasn't done so since September 2008. However, the page affected by this bug hasn't had its protection settings changed since March 2008, so it still has a legacy protection row with pr_type='move', pr_cascade=1. The number of affected pages is probably pretty small: I looked at a few large wikis and saw only this one on enwikibooks, 30 on enwiki, 0 on dewiki, 0 on commonswiki and 1 on metawiki.

It looks like the core behavior of cascading protection is broken, and only cascades the protection for one action. Most pages are protected against two actions (edit and move), and in this case only the move protection is being cascaded, and the edit protection is erroneously not being cascaded. This regression appears to be caused by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1193936 , which splits the protection query into two queries, and makes the incorrect assumption that each page will only have one corresponding row in the page_restrictions table (but most pages have two, one for an edit restriction and one for a move restriction). I'll work on a patch to fix this now.

I was not able to reproduce this protection failure locally, or at https://en.wikibooks.beta.wmcloud.org/w/index.php?title=Main_Page/Sisters&action=edit , even though the setup is the same: the Main Page is cascade-protected, the subpage is transcluded, and FlaggedRevs is configured the same. The FlaggedRevs getUserPermissionsErrors hook also doesn't contain any code that would override a permission decision from "not allowed" to "allowed", only the other way around. So something else is going on here, and I don't know what that is yet. I'll keep investigating.

When I go to https://en.wikibooks.org/wiki/Main_Page/Recipe?action=protect , I do see the cascading protection there, so the system does know about it.

In my own work I also encountered a use case for Vue SSR: the Special:AccountSecurity page in MediaWiki-extensions-OATHAuth is currently built with Codex-PHP, and I'm adding some progressive enhancements using Codex-Vue. This would have been a lot easier and involved less code if we had Vue SSR.

Newer prototype work that was done in 2025:

• T385321: Build a minimal prototype for Vue server-side rendering (SSR) of special pages in MediaWiki
• T385336: Prototype common UI patterns with Vue SSR