Wikipedia talk:Database reports

Requests: Please list any requests for reports below in a new section. Be as specific as possible, including how often you would like the report run.

• Archive
• Bugs
• Configuration

Soft redirects and set index articles at Wikipedia:Database reports/Forgotten articles

See also: Wikipedia talk:Database reports § Try to replace special pages with database reports?

Currently 4 of the top 5 entries at Wikipedia:Database reports/Forgotten articles are soft redirects to Wiktionary and the rest of the list consists mostly of set index articles (SIAs), including surname articles. Wikipedia:Database reports/Forgotten articles states that it ignores disambiguation (dab) pages and redirects. SIAs are classified as standalone lists but they serve a function similar to dab pages. I would think the reasons some dab pages are stable and rarely updated apply to SIAs. Wiktionary redirects are just a special type of redirect; they are far less common than regular redirects. Is there a reason why SIAs and soft redirects are featured here when similar pages are excluded? This has been raised a few times over the years at Wikipedia talk:Database reports/Forgotten articles but that page doesn't see much traffic. —Myceteae‍🍄‍🟫 (talk) 19:14, 19 March 2026 (UTC)

The issue with soft redirects has been raised again at RfD: Wikipedia:Redirects for discussion/Log/2026 April 7#Speciousness. —Myceteae‍🍄‍🟫 (talk) 18:58, 8 April 2026 (UTC)

Myceteae - New "Most forgotten articles..." reports which address your concern are now released here and here. The first report, like the original "Forgotten articles", doesn't care who did the last edit (bot or human), while the second report looks at last human edits only. Enjoy! the Stefen 𝕋ower 18:35, 10 August 2026 (UTC)

@StefenTower thank you! Glad to see this implemented! Perhaps these could be linked from Wikipedia:Database reports/Forgotten articles to increase visibility and address the recurring request for this update. —Myceteae‍🍄‍🟫 (talk) 18:45, 10 August 2026 (UTC)

My understanding is the page for the original report is fully generated by a bot so any updates to it would likely be wiped out. If there is community agreement, we could change the page to a redirect and have the bot stop overwriting the page. the Stefen 𝕋ower 18:51, 10 August 2026 (UTC)

I'm not sure we should yeet (WP:BLAR) the old report; that should probably have more community input. It would seem simpler to just update the description ("lead") of Wikipedia:Database reports/Forgotten articles to include links to the two newer reports but I don't know what all that entails. It's not necessarily urgent but I think it would be helpful. I assume many editors who visit Wikipedia:Database reports/Forgotten articles aren't regularly scanning the list to see if new reports have been added but I'm not sure. Perhaps @MusikAnimal, who operates @Community Tech bot, can weigh in on updating the lead to Wikipedia:Database reports/Forgotten articles. If this needs more input, perhaps WP:VPR would be the right venue. —Myceteae‍🍄‍🟫 (talk) 19:01, 10 August 2026 (UTC)

I boldly tried adding a banner on Wikipedia:Database reports/Forgotten articles. I figure we'll find out if the bot wipes it! I don't imagine it would block the bot from running. Dreamyshade (talk) 23:42, 10 August 2026 (UTC)

Thanks! Looks like we should know in about a week. The more I think about it, I might support moving Wikipedia:Database reports/Most forgotten articles overall to the old title or blanking and redirecting the old one, but again I do think there should be an opportunity for more community input. —Myceteae‍🍄‍🟫 (talk) 01:45, 11 August 2026 (UTC)

The goal is to move all User:Community Tech bot database reports to either use Template:Database report or to User:HaleBot. Do the two new reports make WP:DUSTY redundant? If so, let's just retire the existing DUSTY task already and change the redirect to one of the new reports. Or, please feel free to change DUSTY to use Template:Database report and keep everything as-is. Just be sure to ping me whenever I should shut off CommTech bot task. Thanks, — MusikAnimal ^talk 17:50, 11 August 2026 (UTC)

Since "Most forgotten articles overall" is the direct reworking of "Forgotten articles", WP:DUSTY should redirect to that. I just boldly changed that. This report chains to the other one ("by human editors") via a "see also".

MusikAnimal - As far as I can see, the bot task can now be shut off. the Stefen 𝕋ower 18:15, 11 August 2026 (UTC)

Retargeting WP:DUSTY makes sense. But then I think we should either Wikipedia:Database reports/Most forgotten articles overall to Wikipedia:Database reports/Forgotten articles or BLAR Wikipedia:Database reports/Forgotten articles and turn off the bot function. BLAR would preserve the edit history in a way that makes it easiest to find (and restore, if anyone objects). Or we should put a link to Wikipedia:Database reports/Forgotten articles from the new report. I don't mean to overcomplicate this. I think Wikipedia:Database reports/Most forgotten articles overall is clearly the replacement but people using the old shortcut should be give some indication of why they've arrived at a different page. —Myceteae‍🍄‍🟫 (talk) 19:37, 11 August 2026 (UTC)

I added a notice to the replacement report. IMHO, that should be enough to re-orient users of the old report. the Stefen 𝕋ower 19:50, 11 August 2026 (UTC)

Looks good to me. Presumably you've programmed the bot so this won't be wiped out when the report updates. —Myceteae‍🍄‍🟫 (talk) 20:31, 11 August 2026 (UTC)

I have shut off the Community Tech bot task. Please feel free to move Wikipedia:Database reports/Most forgotten articles overall and point WP:DUSTY back to the old location at Wikipedia:Database reports/Forgotten articles. That sounds like the best course of action for me. Best, — MusikAnimal ^talk 20:41, 11 August 2026 (UTC)

The report I made is on a different page, and I really don't see a need to move it. The old one should be marked historical, and perhaps removed from the Database Reports listing. the Stefen 𝕋ower 20:55, 11 August 2026 (UTC)

This set up looks good to me, with the old one marked historical and with links to the two new reports. —Myceteae‍🍄‍🟫 (talk) 21:39, 11 August 2026 (UTC)

Redirects with no categorisation

Idea: Put redirects with no categorisation into it's own maintenance category (See WP:RCAT and Wikipedia:Template index/Redirect pages) Jacksonvil (alt) (talk) (contribs) (Main account) 05:20, 29 May 2026 (UTC)

Wikipedia:Database reports/Transclusions of non-existent templates

I'm wondering if it makes sense to limit Wikipedia:Database reports/Transclusions of non-existent templates so that it does NOT include templates that are exclusively used in draft articles? @Jonesey95: thoughts on this? I know you use this report a lot... Zackmann (^{Talk to me}/_{What I been doing}) 20:31, 1 June 2026 (UTC)

I have BOLDly limited the report to not look at drafts with Special:Diff/1357289213. Obviously if anyone disagrees, feel free to revert/discuss here. Zackmann (^{Talk to me}/_{What I been doing}) 20:47, 1 June 2026 (UTC)

Sounds OK to me. I have documented this additional exclusion. If Draft pages are moved to article space, the pages will show up on the report and can be cleaned up then. – Jonesey95 (talk) 02:05, 2 June 2026 (UTC)

I will suggest this

since IP blocks of ipv6 range normally not smaller than /64, what will the database report search for IP blocks smaller than /64 ~2026-33487-88 (talk) 04:52, 22 June 2026 (UTC)

Largest articles not included in WikiProjects

If you've ever wondered which articles haven't yet been added to any WikiProjects, we now have a report for that in the WikiProjects section. Please let me know if you have any questions or find a bug in the results. This report will update on a daily basis. Enjoy! the Stefen 𝕋ower 04:16, 7 August 2026 (UTC)

Try to replace special pages with database reports?

There are a lot of "Special" reports that seem like they could be productively replaced with more useful and frequently-updated reports that use the replica database, and the tops of those pages could link to the database reports. I think several of the special pages could even be entirely deprecated.

Examples:

• Special:UncategorizedPages is infrequently updated and weirdly short. Better: User:StefenTower/All uncategorized articles (by @StefenTower). (Could this be turned into a report linked from this table?)

• Special:DeadendPages is so infrequently updated that it is not helpful. Better: Wikipedia:Database reports/Dead-end pages (by @Jonesey95). (Could this be linked from this table?)
• Special:LonelyPages is too full of interwiki redirects and set index articles. I made narrower reports that are more interesting to me: User:Dreamyshade/LonelyPages.
• Special:AncientPages is too full of interwiki redirects and set index articles. Wikipedia:Database reports/Forgotten articles looks like it should be better, but it's also full of them, as noted above.
• Special:FewestRevisions is too full of interwiki redirects and set index articles.
• Special:ShortPages is too full of interwiki redirects and set index articles.

I found this recent related Phabricator discussion: T310456. Other related discussions within the past couple years: How to get 'Maintenance reports' in 'Special pages' reports fixed, Orphaned pages. Dreamyshade (talk) 07:11, 8 August 2026 (UTC)

I'm actually working on adding "All uncategorized articles" to the Database Reports page, and was going to do so once I work the kinks out. the Stefen 𝕋ower 07:17, 8 August 2026 (UTC)

This one is now released. I'll try to consider other ones in the next few days. the Stefen 𝕋ower 09:16, 8 August 2026 (UTC)

Thank you, great report! (Convenient link for anyone reading this: Wikipedia:Database reports/All uncategorized articles.) I like to use DATE_FORMAT to output the timestamp as a human-readable date, but totally fine either way.

I'm going to go ahead and link Wikipedia:Database reports/Dead-end pages from the table, since I can't think of a reason why not. Dreamyshade (talk) 16:58, 8 August 2026 (UTC)

Since the timestamp was there just to give a feel for the age of the article, I have formatted it as a date without the timing to a second. Thank you for the suggestion. the Stefen 𝕋ower 20:15, 8 August 2026 (UTC)

I only prefer TO_CHAR() because it's easy to remember and impossible to get wrong even without having to doublecheck a reference - it seems like every third query I clean up that uses DATE_FORMAT() gets something subtlely wrong. —Cryptic 20:35, 8 August 2026 (UTC)

I got what you were doing, but we really just needed the date, and it's best performance-wise to do converts on the much shorter determined list (what main_query produces). the Stefen 𝕋ower 20:45, 8 August 2026 (UTC)

Dreamyshade - are there any reports you referred to that are remaining to review or develop? I may return to working on more reports soon but I wanted to ensure your list was satisfied first. the Stefen 𝕋ower 23:46, 6 October 2026 (UTC)

Thank you for asking! I think that offering a somewhat opinionated alternative to Special:ShortPages could be helpful, along the lines of User:Dreamyshade/ShortPages. Special:ShortPages is much better than it used to be, but it's helpful to exclude articles that are typically short and to sort by date.

It could also be helpful to offer a list of longest orphans - I've found User:Dreamyshade/LonelyPages to be a good way to find articles that need some care. I couldn't find a way to get the query to be relatively fast other than narrowing it to a few years at a time, but I'm guessing you could figure out something better. Dreamyshade (talk) 02:38, 24 October 2026 (UTC)

? I just ran the query there on toolforge with the where checks on cre.rev_timestamp commented out, and it finished in seven seconds. (261 total hits, if the limit's removed, too. No impact on runtime.) It could probably be improved a little bit - there's an index on revision.rev_page+rev_timestamp, but not on rev_parent_id, for example - but it hardly seems necessary. —Cryptic 02:59, 24 October 2026 (UTC)

I see now that the later queries have a lower minimum size. That does have an impact - runtime with minimum size 7000 and no time restriction took 38 seconds, 8738 total results. I was able to shave off five seconds by finding cre through rev_timestamp. Filtering by creation time shouldn't make any difference anyway; the best index is going to be page_redirect_namespace_len either way. So even if the data's still cached from SDZeroBot's runs on your userpage, at worst it would've run at around the 95 seconds it took there, and that's well within tolerable for a database report. —Cryptic 03:11, 24 October 2026 (UTC)

Oh that's neat, thanks! I adjusted it and see what you mean. I must have gotten that impression from working with a lower minimum size. The list of 261 orphans above 30k bytes seems like plenty for a useful report. Dreamyshade (talk) 03:21, 24 October 2026 (UTC)

Assuming that LonelyPages is settled per the above discussion, I'm not very sure what to do with the ShortPages alternative. Excluding pages not generally recognized as articles seems reasonable, but keeping out particular subjects such as geography or genes has an arbitrary feel to it (they need expansion like anything else). I considered leaving geography pages off the "forgotten" reports, but instead went in the direction of providing ideas/aids for "un-forgetting". Perhaps provide tips for expanding geography or gene stubs to where they can earn the 'Start' rating. the Stefen 𝕋ower 05:47, 24 October 2026 (UTC)

Yes, makes sense to keep filters specific to non-articles for a shared database report (rather than just a personal one). Dreamyshade (talk) 05:54, 24 October 2026 (UTC)

Yeap. If anyone wants a very specialized report, that's what their user pages are for. the Stefen 𝕋ower 06:02, 24 October 2026 (UTC)

For the purpose of superseding Special:LonelyPages:

• A query of articles with 0 inbound links but not tagged as orphans (excluding interwiki redirects and set index articles) with 12,326 results.
• A query of articles tagged as orphans with 2+ inbound links (excluding inbound links from disambiguation pages) with 1990 results.
• Category:All orphaned articles has 53,084 items and can be processed with the usual methods such as PetScan.

For the purpose of superseding Special:AncientPages and Wikipedia:Database reports/Forgotten articles:

• A query of articles not edited in the longest time, limited to articles created before mid-2018, with 1000 results. Earliest last-edited date is 2015-11-05, last is 2017-03-20. Just for fun: here's that list of articles, sorted by pageviews. Mostly tiny places.

For the purpose of superseding Special:FewestRevisions:

• A query of articles with only one revision, ordered by oldest creation date, excluding disambiguation pages, set list articles, surnames, and interwiki redirects. Limited to 1000 results, which span from 2016 to 2023. First 500 sorted by pageviews - not much of note.

The page at Special:ShortPages doesn't seem like it's a burden on the servers, since it runs live, but for the purpose of a more useful list:

• A query of the shortest articles (under 400 bytes), excluding disambiguation pages, set list articles, surnames, interwiki redirects, articles nominated for speedy deletion, and many lists of lists. Mostly non-controversial stubs.

Is there any reason not to turn these into database reports, with reasonable LIMIT statements and daily updates, and list them in the table? I'm sure the SQL could be improved (it's mostly LLM-written), but they seem workable as a first draft. Then I'm wondering if the next step is to workshop a RfC at Wikipedia:Village pump (idea lab). Dreamyshade (talk) 04:21, 10 August 2026 (UTC)

I'm actually close to being finished with a replacement report for "Forgotten articles", actually two reports, one that works like the current one, but eliminating interwiki redirects and set index articles, and removing its unnecessary page_id limitation, and another one with the same changes, but also considers only human edits for determining "forgottenness". I'm currently in test/fix mode but hope to release within 24 hours. the Stefen 𝕋ower 05:18, 10 August 2026 (UTC)

I peeked at your draft report of articles forgotten by human editors, and this is fantastic! Also very helpful for me to see your approach as I learn how to do this better. This is also why I'm excited about redirecting the Special pages to community-managed pages - empowering contributors to invent and iterate on reports is much more inspiring and productive than relying on reports managed by staff who are already committed to other priorities. Dreamyshade (talk) 05:42, 10 August 2026 (UTC)

I agree that with current tools, we can do a lot and also dynamically improve where called for. SD0001 deserves most of the flowers (or for our purposes, barnstars) for making this possible. the Stefen 𝕋ower 06:22, 10 August 2026 (UTC)

The new "Most forgotten articles..." reports are now released here and here. the Stefen 𝕋ower 07:52, 10 August 2026 (UTC)

Using rev_parent_id = 0 as "has no previous revision" isn't always accurate; it'll have both false positives and false negatives. Your FewestRevisions replacement lists Sərkərli, for example, which has 20. —Cryptic 06:12, 10 August 2026 (UTC)

@Cryptic Interesting, thanks! Do you have a sense of what could be a more accurate but relatively efficient way to find articles with only one revision? Dreamyshade (talk) 15:48, 15 August 2026 (UTC)

revision has an index on rev_page, and you already have a known row from page_latest. So you should be able to look for a second revision with something like AND NOT EXISTS (SELECT 1 FROM revision AS r2 WHERE r2.rev_page = page_id AND r2.rev_id != r.rev_id LIMIT 1). It won't be nearly as fast, but it should still fit comfortably in SDZeroBot's 10-minute timeout. —Cryptic 16:09, 15 August 2026 (UTC)

Thanks, updated here! Looks pretty good to me.

Also added my first report to the table: Wikipedia:Database reports/Orphans not tagged as orphans. Dreamyshade (talk) 07:31, 18 August 2026 (UTC)

Special:ShortPages

For Special:Shortpages, see this update. – Jonesey95 (talk) 22:30, 17 August 2026 (UTC)

Looks like it's going to be a "expectshortpage" row in page_props (when it's deployed; it hasn't been yet). —Cryptic 23:15, 17 August 2026 (UTC)

The new magic word has been activated by today's software updates, and the Special:Shortpages report is rapidly becoming useful. As of this time stamp, the top ten listings are actually short pages, and I expect that list of actual short pages to grow as the false positives are processed by the job queue. – Jonesey95 (talk) 00:22, 21 August 2026 (UTC)

Special:Shortpages is ready for use. At this writing, the first 1,200 listings are ready for processing. They are actual very short articles, often just one sentence. – Jonesey95 (talk) 14:15, 23 August 2026 (UTC)

Largest unassessed articles

Now we have a way to see which large articles have been going unassessed for quality. I have created a report for this in the WikiProjects section. Please let me know if you have any questions or find a bug in the results. This report will update on a daily basis. Enjoy! the Stefen 𝕋ower 07:18, 14 August 2026 (UTC)

@StefenTower - thank you for providing this report. It may be a bit early, but I added a link to the report at Wikipedia:Content assessment, See also section. Perhaps that can be placed elsewhere within that page, but for now it's "out there". Cheers, JoeNMLC (talk) 14:28, 14 August 2026 (UTC)

Thank you for spreading the word! the Stefen 𝕋ower 17:19, 14 August 2026 (UTC)

DRAFTNOCAT

Would it be possible for Wikipedia:Database reports/Polluted categories (2) to be updated so that it doesn't list any category that's tagged with the {{Polluted category}} template? In some maintenance categories it isn't important at all to remove drafts, and in most of them it isn't even possible to remove them because the categories are template-transcluded maintenance trackers where removal would entail removing the entire template unnecessarily — but as a result, there are about 15 maintenance categories that are just permanent features of that report from update to update, and five more that kind of bounce on and off the report depending on their current statuseven though they don't actually need to be addressed at all. And that also complicates the process of cleaning up the content categories that do need to be cleaned up, because one has to wade through the "no cleanup necessary" categories to find the "cleanup actually needed" ones.

The report did, in fact, formerly exclude categories that had the polluted category tag on them, but at some point it stopped doing so, and I've asked on a couple of prior occasions for that exclusion to be readded only for my requests to go unaddressed. So could the report be made to exclude categories with the polluted category tag on them, so that it's possible to clear the list down to zero instead of "15-20 permanent speedbumps that don't need to be addressed"? Thanks. Bearcat (talk) 15:23, 20 August 2026 (UTC)

Done. —Cryptic 16:25, 20 August 2026 (UTC)

While I have your attention, would you rather this be grouped together by the draft page? So e.g. you'd currently see only one line for Draft:Bahrain expedition of 1811 containing Category:Conflicts in 1811, Category:Wars involving Oman, Category:Wars involving the First Saudi State, Category:Military history of Bahrain, Category:History of Bahrain, and Category:1811 in Asia; but each of the seven drafts that were in Category:LLM-assisted translations in need of review in the last update would be on separate lines (if that category weren't now excluded because of the polluted tag). —Cryptic 16:41, 20 August 2026 (UTC)

Thanks for the update. To be honest, now that pollution-is-okay categories have been knocked out it doesn't really make that big a difference to the list function if they're grouped by category or by page — although obviously the current structure results in each page being listed several times if it's in several categories, once I've clicked on it once the link turns purple instead of blue, so I already know that I don't need to reclick the purple ones as I scan down the list. And since the list features immediate updatability, my habit has always been that if the list is very long, then after cleaning up about ten to fifteen pages I manually refresh the list, so that any categories that have already been cleaned out go away. (Granted that occasionally a link is purple because I've removed it from categories before and then it got readded to categories again, rather than because I already hit it just a minute ago, but those are also easily ferreted out from the page's failure to drop on a refresh of the list.)
So certainly feel free to update the list that way if you wish, but I wouldn't personally say it needs to be that way — other people's mileage might certainly vary, so by all means go for it if you feel that would make it more user-friendly overall, but at least the way I work with the report it wouldn't make a huge difference either way. Bearcat (talk) 20:57, 20 August 2026 (UTC)

And actually, come to think of it, the fact that the report wasn't dropping the acceptably-polluted maintenance tracking categories until a few hours ago is probably why the report was structured the old way, as it was far, far easier to figure out which categories to skip in a category-sorted list than it would have been to figure out which drafts to skip in a draft-sorted list. Now that the list skips those categories, it actually may be better to have the list sorted by draft instead of by category after all. Bearcat (talk) 21:23, 20 August 2026 (UTC)

OK, done. Easy enough to revert if you change your mind. —Cryptic 22:34, 20 August 2026 (UTC)

Filtered indefinitely semi-protected articles

I've created User:Rusalkii/Candidates for unprotection as a page that's easier to work through to find potentially incorrectly indef semi-protected articles, as an addendum to WP:Database reports/Indefinitely semi-protected articles. May be of interest to watchers here. Rusalkii (talk) 22:25, 26 August 2026 (UTC)

Need feedback on changes to "Most forgotten articles..." reports

Hello all again. Since working on the replacement "Most forgotten articles..." reports (here and here), I've been concerned that there hasn't been much movement in "un-forgetting" articles in the listings by them being constructively edited somehow.

So, I have developed two improvements to encourage un-forgetting:

1. A suggested actions dropdown that will appear in both reports. This will be especially useful for new users to remind them of ways a forgotten article can be improved.
2. A new column "Missing stub tag(s)?" in each report for articles that have been assessed as stubs but don't yet have any stub tags. This appears to be a common issue, and if addressed, un-forgets the article.

Here and here are test reports with these new features. Please give me some feedback if you have any. Thank you! the Stefen 𝕋ower 07:52, 12 September 2026 (UTC)

These are now fully released, with another new column "Content categories" to help an editor see which articles could use additional categories. Still let me know if you have any feedback. Enjoy! the Stefen 𝕋ower 09:05, 14 September 2026 (UTC)

Looks good. ~Kvng (talk) 19:33, 17 September 2026 (UTC)

List issue

For some reason, updates of the draft-polluted category report at Wikipedia:Database reports/Polluted categories (2) this evening have just been listing the draft title as unlinked text instead of as an actual link to the draft, so that I have to hit a category to actually remove the draft from it — which can be a real pain, depending on the actual size of the category. (That is, it's not so bad if the page is in a redlinked category where it's the only entry, but it turns into a needle-in-a-haystack hunt incredibly fast if the page is in a heavily populated bluelinked category with 500 or 600 entries.) This isn't how the report worked previously, and isn't even how it was working this morning, but has been persistent across multiple manual updates of the report over the last ten to fifteen minutes. Could somebody look into this? Thanks. Bearcat (talk) 03:29, 2 October 2026 (UTC)

My report at User:Jonesey95/self-transcluded-templates started doing this today as well, with this diff. It is as if the |wikilinks = 1:10 stopped working all of a sudden. Maybe SD0001 knows if something has changed. – Jonesey95 (talk) 04:10, 2 October 2026 (UTC)

I've changed the polluted categories report to insert the brackets (and "Draft:") at the query level for the time being. —Cryptic 04:22, 2 October 2026 (UTC)

Thanks to SD0001's fix, I undid the SQL change and reran the report, and all seems good now. the Stefen 𝕋ower 07:19, 2 October 2026 (UTC)

Oops, it was due to a buggy commit in mwn, SDZeroBot's underlying framework. The failing tests should have been an indicator, but it was past midnight. I was trying to fix the case where someone entered an invalid namespace number in wikilinks, which earlier broke the bot. Should be fixed now. – SD0001 (talk) 06:21, 2 October 2026 (UTC)

All fixed! Thanks for the quick response. – Jonesey95 (talk) 14:23, 2 October 2026 (UTC)

Seeing article link differences between report builds (revisions)

If you ever wanted to see clearly which linked articles are added and which ones are removed between builds (revisions) of a report, I recently developed the user script ArticleLinkDiffs mainly for this purpose. When reports that list articles contain much more information than just the linked articles, it can be difficult to see what has changed on the usual diff screen. Sometimes it is useful if not critical to examine articles which had issues resolved between report builds. That is all basically why I developed this script.

At the top of diff pages, ArticleLinkDiffs will show added/removed article links in the lexical order of their title. The script also displays a count of the instances of them involved in the addition/removal (if more than 1), and even shows piping changes (especially useful if you're viewing article diff pages).

If you need something like this, please check it out. The script's page shows you how to install it. Enjoy! the Stefen 𝕋ower 01:11, 8 October 2026 (UTC)

PHP

With the temporary disabling of Toolforge due to the PHP vulnerability fix, both Wikipedia:Database reports/Polluted categories (for USERNOCAT cleanup) and Wikipedia:Database reports/Polluted categories (2) (for DRAFTNOCAT cleanup) have been unable to update since Tuesday. Is there any non-Toolforge workaround that can be applied temporarily to get them updated promptly, or am I stuck just twiddling my thumbs and then having to clean up thousands of draft and sandbox pages in one shot when Toolforge is finally back online? Bearcat (talk) 12:47, 22 October 2026 (UTC)

SDZeroBot has started running again, so the second of these should update. Direct connections to toolforge are still down, so it can't be prodded to immediately re-run; it's set to update every two days. That could be decreased to one if toolforge stays inaccessible (it's the |interval= parameter).

/Polluted categories is run by HaleBot, which hasn't edited since the start of the phpocalyse. Eyeballing the query, I don't think it's likely to run fast enough to fit within SDZeroBot's timeout - it enforces a ten-minute maximum runtime. Quarry and shell access are still down too, so best I can do for now is to try sticking it into a sandbox and waiting for SDZeroBot to get around to noticing it and seeing what happens. That might take a day or more. —Cryptic 15:54, 22 October 2026 (UTC)

Worked. User:Cryptic/sandbox3 will rerun daily. —Cryptic 16:53, 22 October 2026 (UTC)

Much thanks. I'm working on the draft report right now (due to the backlog it was larger than I was hoping it would be, but thankfully not as large as I'd feared), and I'll tackle the user report a bit later today. Thanks again! Bearcat (talk) 17:50, 22 October 2026 (UTC)

HaleBot's running again now, and the update-this-report links for SDZeroBot's queries are working too. I'm going to leave that sandbox in place for a couple more runs to see how well it generally performs before usurping.

If I can keep it performant, would things be easier if it grouped lines together by the page the cats are on, the way /Polluted categories (2) does? —Cryptic 23:29, 22 October 2026 (UTC)

It probably would, in fact, since pages are generally in multiple categories, thus extending the list to much longer than it really needs to be, and meaning I have to hit a lot of categories that I've actually already cleared — with the added bonus that the jobs queue doesn't actually clear the search results immediately, so it can be up to five minutes before a category I've already cleared will actually show as empty instead of displaying the same page I've already removed the category from. (And I can't entirely rely on "link is purple instead of blue", either — because user sandbox pages that have been previously removed from categories much, much longer than five minutes ago can also be put back into categories for a repeat engagement, I still have to double check purple links that I don't specifically remember "yeah, I just hit that two minutes ago", even if I did and it just slipped my mind.)
The only thing that does give me a bit of concern is that occasionally there are categories that are meant for userpages, where the problem is that a mainspace article has been incorrectly filed in them — "AfC submissions by date/[Month Year]", "translators [langxcode]-[langxcode]" (the mainspace categories for articles about notable translators use the languages' word names, not their langx codes), Category:Wikipedians, etc. — so it might be a bit tricky in some cases to actually identify categories that are the reverse of the usual issue. So I'll leave it to you to decide whether a workable solution can be found for that — maybe a separate spinoff report, or multiple sections of the existing one, which could be populated by a template sort of like {{polluted category}} that would be added when such a category comes up? or a simpler way? — or whether it would be too much trouble to deal with. Bearcat (talk) 16:20, 23 October 2026 (UTC)

When the reverse problem happens, it's going to look like a whole bunch of different user pages each with a count of 1 and linking that one category. I think the best thing to do in such cases is to fix the mainspace page and then rerun the query - this query's been unusually stubborn; almost every change I've tried makes it want to look through all 21 million user talk pages first instead of category pages, and that puts it outside of SDZeroBot's time limit.

Petscan is back up, so it'll be easy to find the odd mainspace page even if the category is huge - by default, Petscan only shows mainspace pages, so you can just go to https://petscan.wmcloud.org/, put the category name in the "Categories" box, and click "Do it!". Right now, for example, doing that with Category:Gqom albums currently shows only the two mainspace pages Highly Flavoured and Summer Life and not User:Hot boymp3/sandbox. Target namespaces can be set in the page properties tab if you don't want mainspace. —Cryptic 18:04, 23 October 2026 (UTC)

Fair enough.

I should also note that the last time I triggered an update on your temporary ad hoc report it was populated at least 50 per cent by sandbox pages "filed" only in CS1 maintenance tracking categories that are transcluded by CS1 templates, and thus non-visible and non-removable. Since these are template-transcluded tracking categories, and not mainspace content categories meant for user browsing, they aren't the category cleanup project's concern and should not be tracked — because I can't remove them without mucking around with CS1 templates in ways that surpass the depth of my understanding of them, they shouldn't be on the report if they can't be cleaned off of it. In fact, they should also be excluded from the regular report as well — but whenever I've tagged them as "polluted category" to get them off the report, that's been reverted on the grounds that CS1 categories aren't supposed to contain draft or user pages — except, as I noted, even if that's true it isn't my job to get those pages out of those categories, so they just sit there as permanent speed bumps that have to be worked around. So they should really be excluded from the USERNOCAT report entirely, because they're just not my responsibility to worry about. Bearcat (talk) 01:04, 25 October 2026 (UTC)

I was wondering why they weren't tagged, and that explanation is nutty. Was the theory that pages in User: and Draft: aren't supposed to have references, or that the references on them are required to be perfect? I've put it directly in the query, since this isn't the sort of structural change that was breaking things before.

Related, I see that over half the uses of {{polluted category}} are on cats that contain either only mainspace pages or only non-mainspace pages, and that have been that way for some time. Fair number of categories with only a single current exception, too. It's probably overdue to be gone over. Quarry's still down, so there's a list at User:Cryptic/sandbox4 if you want to take a look. —Cryptic 02:04, 25 October 2026 (UTC)

The uses of {{polluted category}} are primarily maintenance tracking categories that get transcluded by templates, and are thus entirely unremovable if and when a draft or user page does show up in them for whatever reason, and thus could theoretically have a dozen new pages in them tomorrow that aren't already in them today. So it's not really a question of whether any of those categories currently have draft or user pages in them or not — its usage is based on whether it would be the cleanup brigade's job to worry about that category if a draft or user page did start showing up in it tomorrow, not necessarily whether the category currently has any such pages in it today or not, so it's not a template that actually gets any monitoring for future removal at all.

It's a permanent "always skip in perpetuity regardless of current conditions" marker, not a temporary "skip for now based on current conditions, and then unskip later" toggle — so the only real grounds for removing that tag from a category would be if it (or its broader class) had been coded as a permanent exclusion from the report at the query level, rather than "doesn't currently have any non-mainspace content in as of today". So, since you're the one with access to the actual query programming, you can feel free to remove that template from any category in that list that would already be knocked out by the query programming anyway, and/or can be grouped together as a new exclusion rule — but its core intention is permanent rather than temporary, because they're categories that we never want to see on the report regardless.

In theory, the explanation given behind reverting me on tagging the CS1 categories was that the template itself is supposedly coded to exclude draft and user pages from the tracking categories, so that any appearance of a draft or user page in the categories means that there's some kind of error in the template coding on said page that's causing its automatic exclusion function to fail — but it's not the categorization cleanup crew's job to fix CS1 template coding errors, and nobody else more associated with CS1 templates (and thus more equipped to figure out what was wrong and how to fix it) was stepping up to actually fix the dozen or more CS1 categories that were permanently stuck on the list either, so it would still fall under "not the DNC/UNC cleanup brigade's job to ever worry about this category at all". If the CS1 project wants their own separate report to track such errors so they can clean them up themselves, I won't stand in their way — but it's just not an issue that would be my job to invest time in fixing, so it would have to be tracked separately from standard DNC/UNC cleanup. Bearcat (talk) 11:34, 25 October 2026 (UTC)