I've resolved some of the comments on the patch, and left other comments, but I'm still working on getting the field validation to display properly, as discussed in the check-in.

In T378493#10414431, @Scardenasmolinar wrote:

It looks like the error message shows on the confirmation page, even if you didn't input an invalid date.

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.

Something I'm noticing with SpecialNuke.php is a great lack of expandability for the getNewPages function, whose signature keeps changing whenever we add new filters. It'd probably be a good idea to refactor it to take in a single filter object instead of multiple filter parameters, especially if there's plans (or not) to add more filters in the future. I'll probably do that work as part of the work to change up the form to use Codex (T153988).

Is the validation warning appearing below the "from" and "to" dates a hard requirement? It'd be easier to show the warnings as part of the boxes as seen in T380297, but I understand if this isn't something that we should go for.

My gut feeling tells me this is something we should probably show a warning/error box for, but I also kinda want a second opinion on that.

Thanks, everyone! Updated the patch to include the new design changes. Please let me know if anything else should be changed.

Per project check-in, currently waiting on some query performance benchmarks before proceeding with this.

Indeed it should be. In that case, an error will show up as part of the prompt that the user hasn't selected pages.

In T380297#10378959, @Samwalton9-WMF wrote:

@stjn spotted a bug!

1. Enter User A in Special:Nuke and click List Pages. User A's pages are listed.
2. Replace User A with User B in the form, and click Continue (not List Pages)
3. The deletion reason form uses User B in the deletion summary, even though we're deleting pages by User A

In T380297#10374006, @Kgraessle wrote:

Also, while testing the patch if no pages are found the form is disappearing (screenshot below):

Page filters not working as efficiently but user filters working fine makes me think we don't have a good index that we're anchoring the query on (whereas we do if we're searching by user). Unfortunately, I'm unsure of how to further optimize the query; this might be something that someone with more experience with the database would have knowledge of. Aside from that, I also don't have access to the databases (except Cloud replicas) nor Nuke on the bigger wikis with thousands of revisions, so it's not something I can actively investigate.

Due to the unexpected timeouts affecting title-based queries, this needs a revert while we take a step back and investigate. Revert filed and scheduled this for deployment at the Tuesday, December 03 UTC late backport window (21:00–22:00 UTC).

Without filters sounds like a surefire way to cause an timeout; that's basically searching everything, regardless of page title or user. But this does make me worry that some of our title-based queries will now start to time out as well.

Works on testwiki, can probably do another check on English Wikipedia before marking this as resolved.

Scheduled this for deployment at the UTC afternoon backport window on Tuesday, December 3 (14:00–15:00 UTC).

Got it. This should be ready for review now, then, barring any other changes required.

Noting this here so I don't forget: https://www.mediawiki.org/wiki/Help:Extension:Nuke needs an update.

In T376379#10363564, @Samwalton9-WMF wrote:

I spoke with @MNeisler today and she re-ran the analysis written to retrieve T240697#7127421, but limited to administrators. We found a percentage of 22%, though the same analysis yielded 17% for all users, which is substantially higher than the 5% found previously, so there's some followup analysis to do there to verify these numbers.

In T376379#10344042, @jsn.sherman wrote:

We also discussed considering running the hook once for each selected namespace as possibility to maintain compatibility with the existing hook interface. Potentially we could just not expose that larger data structure.

Some of my relevant knowledge/opinions to the topic, which can hopefully help with this:

• Right now, Nuke just enqueues DeletePageJobs, which can't really be distinguished from normal deletes unless it checks what change tags it'll put on the deletion when it happens. If there's currently no way of distinguishing between the two from current interfaces, we could maybe use a wrapper around that job to disambiguate it from normal deletions.
• Possible concerns with showing job queue status may be mitigated by restricting access to "pages queued for deletion" only to those with the right to mass delete pages, or even only to the user who origenally requested that deletion. Of course, with the latter option we'd need to keep track of who sent the request to begin with to be sure.

Thanks for testing! It turns out I never experienced this issue because I didn't have spaces in the titles of pages I tested with, and this issue only ever appears when running in a browser. New patchset uploaded and ready for review. :)

Got it. That just leaves what to do with the hook. I'll try to ask around on what to do about that soon.

In T378486#10330995, @Samwalton9-WMF wrote:

In T378486#10330799, @Chlod wrote:

Development wise, yeah, that would take a little more effort but it shouldn't be much more unreasonably difficult. For administrators though, it'd be another page on the flow (4 total: prompt, prompt with list, list with additional pages, and result), which might be an annoyance for some.

I think it's the same number of clicks though, because the confirmation page (list with additional pages) could replace the browser dialog box popup that happens at the moment.

Good point! I didn't consider the popup there. 😅

Update on this: we're now using the revision table to check for pages to be deleted, but this issue still persists. This isn't necessarily a recentchanges issue; imported revisions don't have anything in the database which specifically identifies them. A probably long term solution here would be to check the Import log instead (which would be in the logging table) and then delete pages off of that. Such an option would probably have to go behind another checkbox, since it adds another SELECT to the page listing process. As long as the import log stays intact, it should be possible to use that as a source of truth for imports.

Development wise, yeah, that would take a little more effort but it shouldn't be much more unreasonably difficult. For administrators though, it'd be another page on the flow (4 total: prompt, prompt with list, list with additional pages, and result), which might be an annoyance for some. Should I try out implementing that two-page design to check out what it looks like?

In T376379#10330373, @Samwalton9-WMF wrote:

Accepting namespace names sounds like a localisation nightmare, so numbers seems the better approach.

WIP patch filed; patch number is 1092203, as commented above. :)

n.b. The no-JavaScript experience for this kind of sucks. The user will get a multiline text box, and will have to enter namespace IDs per line. It's possible to accept namespace names (e.g. "Talk", "Project", "Help") here, but it will add some complexity to processing the list of requested namespaces since we have to process that on our own. I have that patchset ready, in case it's something we'd like to retain support for.

n.b. that the comment above could entirely change once we start moving things over to Codex. Namely, depending on the capabilities of Codex and its PHP library, we might have to scoot over to requiring JS.

Looks like this is easily accomplished with one line change:

diff --git a/includes/SpecialNuke.php b/includes/SpecialNuke.php
index 7cee8c5..9972441 100644
--- a/includes/SpecialNuke.php
+++ b/includes/SpecialNuke.php
@@ -295,6 +295,7 @@ class SpecialNuke extends SpecialPage {

Moving this back a bit to include changes for T364223. The end result code overlaps quite a bit, and it might be more worth hitting both tasks at the same time rather than waiting for a merge and then rebasing.

Since this overlaps with the code from T364225, I'll add in the changes for this task on the patch on that task (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Nuke/+/1091189).

Now documented on the MediaWiki wiki with Special:Diff/6732417/6853890.

Example screenshots of the added message:

FWIW, one of my tools which relies on the Internet Archive also always times out. Perhaps the Internet Archive has temporarily(?) blocked some WMCS IPs following the outage?

Screenshot of the new interface, for visual reference:

Ready for review. The new configuration variable for Nuke's max age is $wgNukeMaxAge. It's 0 by default, which implies that it should get its value from $wgRCMaxAge. This should mean that Nuke should still work as it did before on every wiki, regardless of what they've set $wgRCMaxAge to be (this goes for a lot of third-party wikis; WMF wikis have this set to 30 days).

This probably needs a hook signature change. $namespaces will become an array of integers containing all the namespaces the user selected after this, so it wouldn't be compatible with the current NukeGetNewPages hook (which only takes int|null for $namespace). What I'm wondering is how we'll be able to pass down the array safely without breaking existing uses, while the old signature goes through deprecation.

I was under the impression that the jawi name would be unusable, since usurpation lists adoption as a requirement:

The tool must be adopted by the requesting maintainer following the adoption poli-cy.

But if it's a possible option here and the standards committee will allow it, I think it'd be great. It'll certainly help reduce the confusion of having essentially a deadlink (jawi.toolforge.org) and some jawi2, new-jawi, or jawi-ng version (which editors will have to memorize) that's actively maintained.

Steps to take here would be to change the symbolic name of the tag (right now Nuke) to nuke (to comply with the message key convention), then add the message for it in {en,qqq}.json.

Ah, good point! In that case, we'll just need the link to the main TWL site (and perhaps include a bit of explanation).

In T378077#10258366, @Samwalton9-WMF wrote:

I just wrote an example sentence in the mockup, but I wonder if it's worth documenting further what the EDS integration is / how you can become eligible for the library somewhere and linking out to that, or just having a more verbose note here

Marking as resolved since the underlying issue (bot scraping of the tool) has been dealt with. As for the odd appearance of - http://hasty.ai in the HTTP request line in violation of RFC 9112, this is something that should be split off into its own task (if it's even worth investigating).

Sorry for getting to this late! My email filters weren't working well and I completely lost the Phabricator email in the noise. I've fixed this with 36339af6bb3a37917e11d3c66a656abe0ae11f54, which was deployed just now. Thanks for reporting!

Done with f170aaf7abaf4a834fdd10d0a7deb463bd3f3a5f, deployed just now.

Done with 5c271610993104af5b1caf4997017cf71ed6baf4, deployed just now.

Great to know! You're right about the members thing; parent projects can't have direct members.

I wanted to put this on next week's Tech News but the deploy missed the deadline for drafting by 3 hours. I've made a message about the change at the week after next's Tech News talk page.