Taking an early look at this, there's some things we're currently missing in Codex that we need to have to be 1:1 equivalent to the old form:

• There's no DateTimeInputWidget equivalent, which is used for the date filters. There also doesn't seem to be a PopupWidget equivalent (besides Tooltip?) where the "calendar" would appear. We might have to roll our own implementation of this.
• There's no TagMultiselectWidget/MultiselectWidget equivalent, which is used for the namespace filters. Having this be a radio group temporarily would be too much clutter, and making it take in only one namespace would be a regression of the work done in T376379.

These are all preliminary looks at what we have; I could be entirely wrong. If any of these exist in some form, or can be implemented from what we have now, please do tell!

Change #1107105 had a related patch set uploaded (by Chlod Alejandro; author: Chlod Alejandro):

[mediawiki/extensions/Nuke@master] Add support for multiple UI renderers

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

Change #1107343 had a related patch set uploaded (by Chlod Alejandro; author: Chlod Alejandro):

[mediawiki/extensions/Nuke@master] Add Codex UI renderer

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

Patch for this is now available as WIP, though this still needs work. I think I've taken this as far as I can, and I think I should probably check in with Moderator Tools first before going further.

The two patches above introduce a SpecialNukeUIRenderer abstract class, SpecialNukeHTMLFormUIRenderer (where all of the current UI code has been moved to), and SpecialNukeCodexUIRenderer (where the new UI lives). The rationale behind doing this method is to ensure that SpecialNuke doesn't balloon to 2,000 lines to support both UI types and to ensure that there's less hard coupling between UI and business logic.

Since I wanted to avoid blocking changes (given that there's no one to review until the new year is here), everything has been split into multiple patches. This should also help with review by making each patch focused on the specific change described in its subject line. Currently, there's shared dependent patches for this task with T378493 (1104659). I wanted to avoid merge conflict hell, hence breaking everything apart into multiple patches, and placing shared changes before the main ones. There's some merging that has to be done with this patch if the one in T378493 gets merged first, though the changes are minimal enough not to be extremely painful. In addition, there's a new NukeContext that's part of the dependent patches. More on the rationale for that is in T378493#10424541 and the commit message for that patch. Quoting the latter here for reference:

For every new filter added to Nuke, the method signature for each step in the form grows larger. To alleviate this, this change introduces a context system which will be used to centralize already-sanitized request parameters and helper functions. This means adding more filters or swapping out parts of the interface shouldn't cause a significant refactor every time that requires changing signatures or duplication of sanitization/validation steps.

Everything not marked as WIP is ready for review. I'm not moving this ticket to Engineering review until I've hammered out the issue with the latest/topmost patch (see below), but everything else should be ready.

Now on to the rougher parts:

For some reason, tests are not picking up on wikimedia/codex being added to composer.json. I've already set load_composer_autoloader in extension.json to true, which should ensure that it's loaded, but both Phan and PHPUnit are unable to find anything under \Wikimedia\Codex. Tests are currently failing on Jenkins as a result. I've spent a while tracking down the issue, but since it's working locally, I'm having difficulties. Maybe someone else with a better idea of CI can point me in the right direction? EDIT (2025-01-09T02:38:20.916Z): Caused by T379662.

There's currently a lot of duplication between the ...CodexUIRenderer and ...HTMLFormUIRenderer classes. I've decided to copy over code instead of making them inherit from a single place since we're on track to move to a table view (T381660) and swap out parts of the UI anyway, which means the inheritances built up there would have to be diluted down the line. What wasn't copied over is tests; currently tests are shared between the HTMLForm version and the Codex version. This is because they both still use the same parameter evaluation/validation, and the changing UI shouldn't massively change everything for now (at least until we get new messages in).

On the subject of messages, the link for the nuke-delete-more message was hard-inserted into the message instead of having the link generated programatically. Since the "Delete more pages" button can't work with a link on just the text and I couldn't find a way to make Message strip out wikitext, I had to replace it with a similarly-named nuke-deletemore message which doesn't include the link. This unfortunately means more work for translators, since the new message won't be automatically copied over. If this weren't done, the button would contain escaped HTML text inside, which looks broken.

Date filters remain unimplemented pending T378493 getting merged. I can start to work on that on this patch too, but then there would be the same set of changes on this patch and in the one for adding date filters.

I'll leave the Codex PHP-related comments in T377494. There's a few, but currently luckily nothing that prevented conversion of the entire form. A notable one was that the current layout does not have a fieldset box, nor a maximum width. So the form currently doesn't have a box around it, and the inputs get really long on wide screens (on Legacy Vector, at least). Will follow up more on that in the aforementioned task. It seems like this is a design choice that's somewhat intentional, since Special:Block also lost its fieldset borders when it got converted to Codex. Maybe we should revisit whether the box here should still be included?

When testing locally, there's two ways to enable the new UI:

• Set $wgNukeUIType to "codex" (changes default for all users)
• Supply the ?ui=codex parameter in the URL (subsequent requests will also use the new UI).

If there's any issue with the approach I took for this, either in code, UI, or VCS organization, please do tell me! See you all in the new year! 🎉

And also blocked on T379662. But the first of the two patches can proceed as normal.

Noting here that we've decided to make Codex an optional dependency, allowing the Codex interface to be used only when Codex can be found, since we're still waiting on the Codex PHP deployment on mediawiki/vendor. That leaves us with just the missing MultiselectWidget component for the namespace selection blocking us, and (if possible) the suggestions for the "target" box (which likely need JavaScript).

Change #1107105 merged by jenkins-bot:

[mediawiki/extensions/Nuke@master] Add support for multiple UI renderers

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

In T153988#10603930, @Chlod wrote:

I think I've more or less gotten the message just now (unfortunately pretty late) on how to approach the lack of MultiselectLookup in Codex PHP, which is essentially just using Vue to render that component. This gives it the dynamic interactions that we need via JavaScript. In a sense, we're doing the "hydration" of the "namespaces" field on our own. I've updated the patch to do exactly this, and uploaded another patch to separate out unrelated JavaScript setup work to support the new code.

This should fully unblock the patch, and the Codex interface should have practically the same functionality as the HTMLForm one. Again, it still won't work in production until Codex gets added into mediawiki/vendor, but at least it'll be mergeable. Now boldly moving this to Moderator Tools' engineering review column.

Thanks @Chlod, this looks reasonable to me!

@CCiufo-WMF I just want to verify: is this a good approach for us to take? Adding you to the patch so you can take a gander.

Hey @Chlod, I have been trying to test this locally, but can't seem to find how to switch to the Codex UI. I have added $wgNukeUIType = 'codex'; to LocalSettings.php and have added the nukeUI=codex URL parameter. Is there something else I should be doing?

In T153988#10629888, @Scardenasmolinar wrote:

Hey @Chlod, I have been trying to test this locally, but can't seem to find how to switch to the Codex UI. I have added $wgNukeUIType = 'codex'; to LocalSettings.php and have added the nukeUI=codex URL parameter. Is there something else I should be doing?

I am now able to view the Codex UI. I will be reviewing your patch shortly.

In T153988#10610246, @jsn.sherman wrote:

In T153988#10603930, @Chlod wrote:

I think I've more or less gotten the message just now (unfortunately pretty late) on how to approach the lack of MultiselectLookup in Codex PHP, which is essentially just using Vue to render that component. This gives it the dynamic interactions that we need via JavaScript. In a sense, we're doing the "hydration" of the "namespaces" field on our own. I've updated the patch to do exactly this, and uploaded another patch to separate out unrelated JavaScript setup work to support the new code.

This should fully unblock the patch, and the Codex interface should have practically the same functionality as the HTMLForm one. Again, it still won't work in production until Codex gets added into mediawiki/vendor, but at least it'll be mergeable. Now boldly moving this to Moderator Tools' engineering review column.

Thanks @Chlod, this looks reasonable to me!

@CCiufo-WMF I just want to verify: is this a good approach for us to take? Adding you to the patch so you can take a gander.

I've removed myself from the gerrit patch but we can plan for an engineer from Design-System-Team to review. Getting Codex PHP into vendor is going to be a bit trickier than we originally expected and will require some more dedicated sprint effort from the team. We kick off a sprint on Monday and can provide an update about more exact timing then.

I appreciate your patience on this ticket @Chlod! I have found a few things with the Codex UI that should be addressed:

There is a non-breaking space here that shouldn't be there.

When you query to include talk pages and redirects, the checkboxes are not checked when the page loads with the completed list. I also do not see indentation and italization on the talk pages and redirects when they should be.

You can add a date in the To date field that is before the From date field.

Finally, there is a NamespaceLookup class. Will there be a UserLookup class? In the original form, the user/IP form has autocompletion. Would we implement a Vue lookup, or will there be one in Codex natively?

Thanks for the review, @Scardenasmolinar! Will have this fixed up soon; just have to get through a pretty busy week for me.

Moving to our backlog while we wait for T379662 to advance.

In T153988#10631461, @Scardenasmolinar wrote:

I appreciate your patience on this ticket @Chlod! I have found a few things with the Codex UI that should be addressed:

There is a non-breaking space here that shouldn't be there.

This isn't occurring on my instance for some reason. I remember this was fixed by changes to Codex PHP; have you updated the library to the latest version?

When you query to include talk pages and redirects, the checkboxes are not checked when the page loads with the completed list. I also do not see indentation and italization on the talk pages and redirects when they should be.

Fixed, though the latter seems like it was a consequence of those two options not being honored at all.

You can add a date in the To date field that is before the From date field.

This also didn't throw any errors back in the HTMLForm-based form. Should validation be added for both forms?

Finally, there is a NamespaceLookup class. Will there be a UserLookup class? In the original form, the user/IP form has autocompletion. Would we implement a Vue lookup, or will there be one in Codex natively?

Codex appears to provide a TypeaheadSearch component which fits the bill here, but there's two caveats: (1) I can't find a way to disable the search icon at the start of the form, and (2) it wraps itself in a form element, which interferes with Nuke's form. This is the same issue we were encountering with T381660.

With T379662 resolved, I've rebased the patch against the current master. I've also added a TargetLookup class for searching usernames, using the Lookup component. It seems I also accidentally put in some of the table changes code in this patch when I was resolving merge conflicts; I've removed those pieces of code and will reintroduce them into the patch for T381660 when this patch gets merged. I'm avoiding making further changes to that patch (table conversion) because of how many moving parts this current patch changes. I'll rebase and rework that patch when this one is done.

There appears to be Codex PHP updates since the last time this patch was touched, so please be sure to reinstall Composer dependencies. I also still haven't added a validation warning when "To date" is before "From date". Please do tell if this is something I should add.

Also, should the form window be bordered/width-limited? Right now it expands to the full width of the window and it look somewhat odd on my screen (1920x1080).

Just a question to clarify which patch is ready for review:
Is it this one? https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Nuke/+/1107343/10

Yup, that's the one, though we're on Patchset 32 now so it would be https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Nuke/+/1107343/32

Thank you for all of your hard work on this @Chlod! As I was playing around on my local environment, I noticed a couple of things:

1. The error message that appears at the bottom of the form does not have the class you added in the PHP (I mention it in the Gerrit patch), and thus it appears very close to the form buttons. Also, the icon seems to be misaligned with the error text.
2. I have my wgNukeMaxAge and wgRCMaxAge set to 180 and 90 days, respectively. Whenever I navigate to Special:Nuke, a From date appears to be preloaded. If I click on List Pages with that date, I get the error shown below.

You can see both of these comments in the screenshot below.

@Scardenasmolinar The icon shrinking ("icon misalignment") is a current Codex issue tackled at T398529: Message: icons can get cut off depending on message text length

In T153988#11067053, @Volker_E wrote:

@Scardenasmolinar The icon shrinking ("icon misalignment") is a current Codex issue tackled at T398529: Message: icons can get cut off depending on message text length

Thanks for the additional context!

In T153988#11067040, @Scardenasmolinar wrote:

Thank you for all of your hard work on this @Chlod! As I was playing around on my local environment, I noticed a couple of things:

1. The error message that appears at the bottom of the form does not have the class you added in the PHP (I mention it in the Gerrit patch), and thus it appears very close to the form buttons. Also, the icon seems to be misaligned with the error text.

The related code for this is somewhere else in the file, and it seems I forgot to add the proper class to validation messages. This has been fixed; the issue with the icons, as mentioned by Volker, is something that's out of my control.

2. I have my wgNukeMaxAge and wgRCMaxAge set to 180 and 90 days, respectively. Whenever I navigate to Special:Nuke, a From date appears to be preloaded. If I click on List Pages with that date, I get the error shown below.

You can see both of these comments in the screenshot below.

This one's odd, as I can't seem to replicate this in my instance. My suspicion with this is the usual culprit of dates and times: timezones. Your browser didn't stop you from submitting the form, and <input type="date"> will always work on the browser's local timezone. So your browser receives and understands 02/06/2025, but the current server is already on 02/07/2025. But the only way I would see this happening is if the date had already crossed over to 02/07/2025, and the page had been loaded since before that time in the server's local timezone (assuming that the "From date" was never touched from its default value, which is always going to be the earliest date that the server supports).

For this reason, I've actually wanted this field to be empty by default, as we can imply to use the earliest possible date. But having the date be set by default was a requirement in T378493: Support filtering by page creation date in Nuke.

Test wiki created on Patch demo by KGraessle-WMF using patch(es) linked to this task:
https://2baba5d3fa.catalyst.wmcloud.org/w/

Change #1107343 merged by jenkins-bot:

[mediawiki/extensions/Nuke@master] Add Codex UI renderer

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

Change #1180141 had a related patch set uploaded (by Chlod Alejandro; author: Chlod Alejandro):

[mediawiki/extensions/Nuke@master] Restore inadvertently removed messages

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

It seems like I had inadvertently removed the nuke-delete-more message which shows up at the bottom of the Nuke results page. The patch I just posted restores the message, and also reverts the commit by the Translation updater bot which removed those messages. Ideally, this should be reviewed whenever possible so we can cherry pick this into wmf/1.45.0-wmf.15 before it hits larger wikis and ends up breaking the workflow (since it completely removes the backlink to Special:Nuke on the results page).

Change #1180141 merged by jenkins-bot:

[mediawiki/extensions/Nuke@master] Restore inadvertently removed messages

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

Change #1180159 had a related patch set uploaded (by Chlod Alejandro; author: Chlod Alejandro):

[mediawiki/extensions/Nuke@wmf/1.45.0-wmf.15] Restore inadvertently removed messages

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

Change #1180159 merged by jenkins-bot:

[mediawiki/extensions/Nuke@wmf/1.45.0-wmf.15] Restore inadvertently removed messages

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

Mentioned in SAL (#wikimedia-operations) [2025-08-19T20:16:21Z] <zabe@deploy1003> Started scap sync-world: Backport for [[gerrit:1180159|Restore inadvertently removed messages (T153988)]]

Mentioned in SAL (#wikimedia-operations) [2025-08-19T20:39:45Z] <zabe@deploy1003> chlod, zabe: Backport for [[gerrit:1180159|Restore inadvertently removed messages (T153988)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2025-08-19T20:52:52Z] <zabe@deploy1003> Finished scap sync-world: Backport for [[gerrit:1180159|Restore inadvertently removed messages (T153988)]] (duration: 36m 31s)

@Samwalton9-WMF We have QAed this, and everything looks good. However, this is hidden behind a feature flag. How do we proceed? Do we change the default to Codex so we can further test it with users, or do we just remove the feature flag and the HTMLRenderer?

I'm tentatively wondering if we should remove the HTMLForm renderer considering Codex PHP is now in mediawiki/vendor and could be used in MW core. HTMLForm has the concept of display formats which actually does already include a somewhat usable "codex" option (though there hasn't been much progress on it recently it seems?) which ideally should be what we use in the long term, as many forms within the MediaWiki ecosystem already use HTMLForm and it makes no sense switching away from it just for Codex.

In T153988#11103439, @Scardenasmolinar wrote:

@Samwalton9-WMF We have QAed this, and everything looks good. However, this is hidden behind a feature flag. How do we proceed? Do we change the default to Codex so we can further test it with users, or do we just remove the feature flag and the HTMLRenderer?

Can I test this somewhere now? If it looks/behaves basically the same I think we could probably just switch over, but it's been a while since I saw the codex version :)

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

https://2baba5d3fa.catalyst.wmcloud.org/w/

In T153988#11107061, @Samwalton9-WMF wrote:

In T153988#11103439, @Scardenasmolinar wrote:

@Samwalton9-WMF We have QAed this, and everything looks good. However, this is hidden behind a feature flag. How do we proceed? Do we change the default to Codex so we can further test it with users, or do we just remove the feature flag and the HTMLRenderer?

Can I test this somewhere now? If it looks/behaves basically the same I think we could probably just switch over, but it's been a while since I saw the codex version :)

?nukeUI=codex is the URL parameter to test.

I've just checked this out on en.wiki and all looks good. I've posted about this in the Nuke Discord thread, if there are no concerns we can make this the default in a week or two.

@Soda pointed out that on wider displays the form boxes stretch to fill the entire view:

Is this something that design folks have an opinion on?

Second - the old version auto-focused the username field, whereas the Codex version doesn't. That seems like a useful thing to bring through, since users opening the page almost always want to filter on a user.

In T153988#11168001, @Samwalton9-WMF wrote:

@Soda pointed out that on wider displays the form boxes stretch to fill the entire view:

whereas previously they had an upper width limit:

Is this something that design folks have an opinion on?

I'm of the opinion that there should be a maximum width, and that a field box should contain the entire form, but this doesn't seem to be common in Codex forms (using Special:Block as a reference).

Second - the old version auto-focused the username field, whereas the Codex version doesn't. That seems like a useful thing to bring through, since users opening the page almost always want to filter on a user.

Can add this in on a subsequent patch. I'll attach it to this task.

The up and down buttons on the numeric fields are:

1. Really far away from the numeric value (not as easily found as they should be).
2. Very small and difficult to accurately click (probably almost impossible to click on a tablet or phone).

In contrast, the up/down buttons for numeric fields in OO.UI are easy to find and use. (Note the current OO.UI interface for nuke is not using those.)

In addition, the calendar date selector is undersized and the font size in the widget is excessively small. This is also much more usable in the current nuke interface.

In T153988#11169129, @DanielQ wrote:

The up and down buttons on the numeric fields are:

1. Really far away from the numeric value (not as easily found as they should be).
2. Very small and difficult to accurately click (probably almost impossible to click on a tablet or phone).

In contrast, the up/down buttons for numeric fields in OO.UI are easy to find and use. (Note the current OO.UI interface for nuke is not using those.)

It seems this is the same for Codex in Vue. So perhaps intentional, but I'm not sure. Changing that design isn't under the scope of this task, but it may be something worth bringing up to the Codex Steering Committee.

In addition, the calendar date selector is undersized and the font size in the widget is excessively small. This is also much more usable in the current nuke interface.

The calendar date selector is completely up to your browser and can't be styled. As I've been told, this is an intentional design decision: T377494#10415954.

In T153988#11168207, @Chlod wrote:

Can add this in on a subsequent patch. I'll attach it to this task.

Well, it seems like Lookup doesn't actually have the focus method of its underlying TextInput exposed. We can't have autofocus on that field for now, as it requires a focus() to be called upon component mount. T404328: Lookup: expose focus() method filed.

In T153988#11168207, @Chlod wrote:

In T153988#11168001, @Samwalton9-WMF wrote:

@Soda pointed out that on wider displays the form boxes stretch to fill the entire view:

whereas previously they had an upper width limit:

Is this something that design folks have an opinion on?

I'm of the opinion that there should be a maximum width, and that a field box should contain the entire form, but this doesn't seem to be common in Codex forms (using Special:Block as a reference).

Second - the old version auto-focused the username field, whereas the Codex version doesn't. That seems like a useful thing to bring through, since users opening the page almost always want to filter on a user.

Can add this in on a subsequent patch. I'll attach it to this task.

Thanks for your work on this @Chlod! We'll keep an eye out for another patch to review.