Wikipedia:Request a query

Shortcuts

This is a page for requesting one-off database queries for certain criteria. Users who are interested and able to perform SQL queries on the projects can provide results from the Quarry website.

You may also be interested in the following:

The database replicas do not have access to page content, so requests which require checking wikitext cannot be answered with database queries. In particular, there is no way to query for template parameters or anything related to references. However, someone may be able to assist by querying in another way (for example, checking for external links rather than references) or suggest an alternative tool.

Most consecutive citations

In the vein of WP:Citation overkill, can someone write a query to find the most consecutive citations on a a page? 77551enpassant (talk) 19:47, 28 October 2026 (UTC)

Queries can't even detect citations on a page at all. I don't think the underpowered regex engine in search can do this either. You could in theory do it with a database dump, but it'd be really, really slow. (If someone does, WP:RECORDS would probably be interested in the answer too.) —Cryptic 21:13, 28 October 2026 (UTC)
A few years back I did see this calculated from a dump, but tragically I am now unable to find the analysis! (It was in a discussion on twitter and finding old stuff on there is a right pain these days). I don't think the result at that point exceeded any of the worst cases noted in Wikipedia:Citation overkill, however. Andrew Gray (talk) 18:27, 8 November 2026 (UTC)

Pages in Special:NewPagesFeed by how long they have been in the queue

For example, New Village Arts was created on 2023-10-14 but has only been in the NPP queue for a few weeks.

As a first pass, I'd like to have only those articles that have been in the queue for >90 days (which entails being older than 90 days, I guess). Knowing the number of those would be helpful for the RFC at Wikipedia:New pages patrol/2026 backlog discussion/RFC phase#Q5: Draftification permissibility in particular.

quarry:query/99823 does part of what I want, but as explained at User talk:Novem Linguae#Oldest pages in the queue it includes recent page moves. WhatamIdoing (talk) 06:23, 3 November 2026 (UTC)

This is hard. Thinking out loud:
  • Pagetriage doesn't itself keep track of when a page enters the queue. This right here is the real problem. It really really should, not to make datamining easier, but because that's the order that pages should be presented to reviewers in. Arguably it's the only reasonable order.
  • Page moves are logged only at the source title, not at the target title. The recent page move from Paul Galligan to Peter Paul Galligan, for example, shows no log entries at all for the latter. The only reason that the log entry on Paul Galligan shows the target page is because there's a serialized php data structure stuffed into it; it looks like a:3:{s:9:"4::target";s:19:"Peter Paul Galligan";s:10:"5::noredir";s:1:"0";s:17:"associated_rev_id";i:1383543811;}. That's not robustly parseable in sql (at least, not without functions, which we don't have permissions to create), though while you can sort of hack it apart with regex replacements to make it look pretty (and I've actually done that a couple times), it falls apart if some joker tries moving a page to a title like 4::target";s:496;"Ha ha ha";. More importantly, it's not indexed, and there's just too many log entries to deal with, even cutting it down to just the move log and just to entries post-dating the creation time.
  • The other approach that could maybe sort of work is looking for the dummy revision created during a page move, in this case Special:Diff/1383543811. That's at least indexable to the right page, but it's still much more fragile than I'd like. The lazy approach is to search by comment text, something like comment_text LIKE CONCAT('% moved page [[%]] to [[', REPLACE(REPLACE(page_title, '_', ' '), '%', '_'), ']]%'). Which is an awful hack, and just as ugly as it looks when you know sql as when you don't, but would probably work? Especially if I then compared its text to the revision just in front of it, which used to be easy - you couldn't and still can't see the actual page text, but there was a hash of it right in the revision table. Now that looks like it's been moved to content.content_sha1, with slots as a junction table. But I haven't followed its development, or even seen it before today, so I'm not so confident in writing queries against it.
  • Pages can also enter the triage queue if they're changed from a redirect to a nonredirect. There's a tag for that, mw-removed-redirect, so at least we can be confident that's really what happened, but it adds complexity.
  • Pages can also enter the triage queue if someone unreviews them, I think? I don't know what that looks like at the database level, or even if it's separately recorded at all except maybe in a log entry, that may or may not be reasonably searchable.
  • And, anyway, if a page entered the queue four years ago, and sat there and sulked until yesterday, when someone misclicked and reviewed it and then immediately unreviewed it, should it be considered as four years or one day old?
Novem Linguae's query looks like it's pulling from the entire page triage table, not just x days old. Which is good, since I can plug that into toolserver and get an idea of how efficient or not "not reviewed" is (very) and how many pages I'm looking at (a bit under 31000). Cut that down to ones that show a creation date at least 90 days ago, and there's 19033 pages with 468742 revisions among them. That's probably few enough that looking for the this-page-was-just-moved dummy revisions and the not-a-redirect-anymore tags can probably work. The fragility of it all makes me very very unhappy, though, and I haven't even started to write it.
Would it do any good to rant a while about how we know what the real problem with NPP is, and have for going on twenty years now? The backlog sure isn't it, and the software isn't either. —Cryptic 07:58, 3 November 2026 (UTC)
Just in case this is helpful: I came up with quarry:query/105716 a while back as part of some (still unfinished) work to look at prolific article creators. I convinced myself at the time that this was a good query to return moves from somewhere else to mainspace. But maybe it isn't: I freely admit this was lashed together with Copilot helping me, while eyeballing the results to see if they looked plausible. Cheers, SunloungerFrog (talk) 08:58, 3 November 2026 (UTC)
That only works while it's still in recentchanges, which only goes back 30 days. (Also it isn't querying where the page was moved to, just where it was moved from and where it currently is. Which looks right so long as you only test pages that were only moved once.) —Cryptic 09:09, 3 November 2026 (UTC)
On the plus side, it did get me to wondering if anyone had ever gotten around to fixing where log_page points at for moves (it was set to the newly-created redirect's page_id, which was almost entirely useless). Apparently they did in 2014, so 1. I've been killing myself with kludges for it for all this time for no reason, and 2. this suddenly got a whole lot simpler. —Cryptic 09:23, 3 November 2026 (UTC)
Well, I'm glad it was of some tangential benefit! Cheers, SunloungerFrog (talk) 09:27, 3 November 2026 (UTC)
Draft at quarry:query/110878, with very limited sanity checking, and not yet restricted to more than 90 days ago (except if page creation was too). Will check on how bad it looks tomorrow. —Cryptic 09:55, 3 November 2026 (UTC)
At least one element's missing, page undeletion. Gnar Lif3, which the query claims is the oldest queue entry, is (predictably) an example. Not sure offhand if there's a way after the fact to easily distinguish a complete undeletion from an undeletion of history behind an existing page. I'd hope pagetriage wouldn't put the latter back on the queue. —Cryptic 10:10, 3 November 2026 (UTC)
The date on which a page enters the queue is not currently tracked. It's been requested.
Can this be done through a multi-step process? For example, could we run a query to get a short list, then set a bot to check the page history for page moves between namespaces, and post an updated list on wiki?
I looked at items 96–100 (i.e., the last five on the first page when you sort by the 'reviewed_updated' column). They are:
All of them look like what I'm looking for. More recently (~90 days ago), there are:
If we could get a reliable list by queue date, then it would be possible to use it to provide extra points during a backlog drive (e.g., 1 point for a new article, 2 points for articles that have been in the queue for 91–364 days, 3 points for 365+ days). WhatamIdoing (talk) 17:49, 3 November 2026 (UTC)
We're not going to get a reliable list by queue date unless and until that bug is fixed properly.
And sort by last_entered_queue, not review_updated. I don't know what ptrp_review_updated is supposed to do, but it's not what it's documented to. (Or maybe it's documented right, but is just unusably broken.) Mirror (Yi Sang poem) was the "oldest" queue entry on another iteration of this. It has a ptrp_review_updated of 20240621094322, but was unreviewed by Pppery (alt) on 2026-06-24. (Possibly related that its initial review was before its move from Mirror (Yi Sang)?) There's no "added...to the New Pages Feed" log entry for plenty of the other cases, alas, in particular for restores. —Cryptic 18:38, 3 November 2026 (UTC)
Oh, I didn't realize there were so many columns. I could only see:
page title || created || reviewed_updated || last_un
I'm seeing about ~1600 that are over a year old. At exactly 1 year, that includes articles such as:
I don't think we need perfection in this task at the moment. WhatamIdoing (talk) 20:04, 3 November 2026 (UTC)
I used ptrp_review_update at https://quarry.wmcloud.org/query/110326 because it seemed sufficient for my interest in charting approximately how many articles created per day are still unreviewed, including to find the "back" of the queue. I didn't need precision, just a general sense. Dreamyshade (talk) 01:32, 4 November 2026 (UTC)
I don't currently think that it's imprecise. I think it does something else entirely, and we don't know what. Whatever it is, it definitely doesn't include "this page became unreviewed at this time", except perhaps by coincidence. —Cryptic 02:29, 4 November 2026 (UTC)

Potential change to ACE suffrage

The current ACE suffrage requirements call for 150 all-time mainspace edits before November 1 of the applicable year. SecurePoll cannot compute mainspace edit count. To get around this limitation, we run a script to generate a voter roll, which has caused headaches in the past. SecurePoll can calculate total edits, and I'm curious how the electorate would change if we removed the requirement that all 150 edits be made in mainspace. Therefore, would it be possible to get a list and/or count of editors who:

  1. Have registered an account before 1 October
  2. Have made 150 total edits, but not 150 mainspace edits, before 1 November
  3. Have made 10 live edits in the year before 1 November
  4. Not be blocked sitewide, a bot, or WP:VANISHed

Ideally, it would be possible to run separate queries for this year, 2025, and 2024. Thanks in advance :) Best, HouseBlaster (talk • edits • he/they) 03:40, 9 November 2026 (UTC)

(Isn't this the same as running a script to generate the voter roll, but six times?)
Do you need it to do exactly what SecurePoll does and/or what the previous scripts did? Edit count can mean, hm, at least five things: currently-live edits before the cutoff, all edits (live or deleted) before the cutoff, both of those two without the cutoff (ie as of election time), or whatever user_editcount currently says. user_editcount includes both live and deleted edits, plus edits where the editor field has been revdeleted or oversighted (which the other four methods won't see), but it doesn't include the dummy edits you can see in pages' histories when moving or protecting a page, and it can get out of sync for other reasons; plus, only the current value can be retrieved, not that for previous years. If I had to guess, I suspect the previous script used live edits before the cutoff, and strongly suspect SecurePoll just uses user_editcount and so won't be able to do the November cutoff.
Also, I hope you don't expect me to figure out if someone was sitewide-blocked or vanished, or if an edited page was in mainspace or not or deleted or not, as of the historic elections. Current status will have to do. —Cryptic 04:17, 9 November 2026 (UTC)

I had included a bit about how I didn't expect keeping track of at-the-time blocks/vanishes/etc., but I deleted that because I thought it would go without saying. Current status will be more than sufficient.

The current script is at User:Cyberpower678/ListGen.php. That page doesn't have line number (boo) but it appears that user_editcount is used. I'm sure you can crib most of the code from there. Thank you, as always, for taking this on! Best, HouseBlaster (talk • edits • he/they) 04:40, 9 November 2026 (UTC)
It requires both user_editcount and 150 live edits; deleted edits aren't looked at. Can't tell everything it does for sure, since it depends on command-line parameters. Some surprises in there; it checks that blocks don't expire before the end of the election, which I wouldn't have thought to do, and excludes users with "renamed" or "vanished" anywhere in their name case-insensitive, which I'm surprised doesn't have false positives. Doesn't seem to exclude temporary accounts, either. —Cryptic 05:22, 9 November 2026 (UTC)
I'm not sure why I didn't think of this solution beforehand, but what if I ask Cyberpower to run his script a couple times with different values for $qualifyingNamespaces and the timestamps? HouseBlaster (talk • edits • he/they) 05:25, 9 November 2026 (UTC)
I just figured that he wasn't interested in doing it anymore, since he's not on the election committee this year. I did consider just running it myself. But I'm going to see if I get it to run in One Big Query anyway, so it can be forked on Quarry. —Cryptic 05:42, 9 November 2026 (UTC)
quarry:query/111130, quarry:query/111131, quarry:query/111132. About an 8-9% increase for all three. —Cryptic 06:29, 9 November 2026 (UTC)
And SecurePoll looks at live edits only, and not user_editcount. Unlike either my queries or Cyberpower's script, it can see edits where the editor has been revdeleted or oversighted, though I can't imagine a reason ever to do that without blocking.
Also seems to grab all edits up to the minimum number in the ranges specified, instead of just the 150th (or 1000th, or 150,000th), which seems wasteful, but whatever. —Cryptic 06:52, 9 November 2026 (UTC)
You are a star. Thank you so much :) HouseBlaster (talk • edits • he/they) 07:01, 9 November 2026 (UTC)
(The changes to turn this into actual lists are trivial, if you want to keep the mainspace requirement. —Cryptic 07:05, 9 November 2026 (UTC))

One page, but only from a specific category?

I'm trying to make a fork of quarry:query/111158, which was created by @Blackfootferret, but the catch is that it doesn't focus on all categories. Instead, it tries to find categories that are in Category main article does not match category title that only have one page. Is this possible, or am I being really ambitious? I'm new to Quarry, as you can tell... :P - OpalYosutebito 『talk』 『articles I want to eat』 02:27, 11 November 2026 (UTC)

Direct subcategories only, or the entire tree? —Cryptic 02:46, 11 November 2026 (UTC)
Direct subcats, like Category:0-6-2T locomotives. I hope that clears things up! :D - OpalYosutebito 『talk』 『articles I want to eat』 02:48, 11 November 2026 (UTC)
quarry:query/111219 has all of them (not just the first 50). —Cryptic 03:02, 11 November 2026 (UTC)
Thanks! I'm currently learning SQL. It's late at night for me, though :\ - OpalYosutebito 『talk』 『articles I want to eat』 03:03, 11 November 2026 (UTC)
Glad to see someone is using my query (I'm using it for the category space to remove single entry categories). Boots the Blackfoot Ferret 16:45, 11 November 2026 (UTC)
Heck yeah! CFDS, here we come! :DD - OpalYosutebito 『talk』 『articles I want to eat』 16:47, 11 November 2026 (UTC)
FWIW, your query will break if it happens to look at large categories before small ones. Category size is cached and indexed in the category table; a simple SELECT cat_title FROM category WHERE cat_pages = 1 should give you the same results, and finish instantly (though it would take a while for Quarry to display all the results, there's about 287000 of them). The cache does sometimes get out of sync, but you can at least use it as a first pass so you only manually count categories with, say, cat_pages <= 5. —Cryptic 17:14, 11 November 2026 (UTC)
Thank you for this information! I'll tinker with the query. Boots the Blackfoot Ferret 17:17, 11 November 2026 (UTC)

Displaying a summed count for the counts of all three Frisian Wikipedias together

(There is a section on this topic in Wikimedia_Forum/Archives, but I don't see an index on that page to determine the link from.) What I asked was: Hi, how do I get the total count of the fyː, frrː, and stqː wikipedias? (That is, how do I get a total count for the three Frisian sister languages together?)

I already acknowledge that I probably should go somewhere else, but that I can't make heads of tails of that wiki. Still, one of the replies contained the advice to seek an answer HERE. Hence, the same question here: While we are working our way towards 100 thousand entries in the three Frisian languages combined: How will we know when we reach that mile stone? Mysha (talk) 13:48, 11 November 2026 (UTC)

A total count of what? Pages? Articles? —Cryptic 15:05, 11 November 2026 (UTC)
Anyway, if it's either of those, both are at quarry:query/111239. There are instructions to rerun the query at Wikipedia:Request a query/Archive 1#Newly created Presbyterian articles; they should still be valid, except for the query number. —Cryptic 16:08, 11 November 2026 (UTC)