The API that it is using works at the time of writing: http://xtools.wmflabs.org/api/namespaces/fr.wikipedia.org

This will not be an issue in the new XTools, which will be released very soon! :) Going to close this as declined because we're no longer supporting the legacy version. Thank you for the report, though!

This perhaps can't or shouldn't be done as described, because there's no guarantee other regex syntax won't be transformed by norm or ccnorm. Let's say we write our filter ccnorm_matches_any(added_lines, "goo+gle", "yahoo+") which would be equivalent to matches_any(added_lines, ccnorm("goo+gle"), ccnorm("yahoo+")) (matches_any does not actually exist either, but that's beside the point). Here we want it to return true if added_lines contains "Go00oogle", "Gooogle", "Yah00ooo", "YahoO", etc (any number of O's, or 0's because ccnorm will turn a 0 into an O). The matches_any function then joins them with a pipe effectively running ccnorm(added_lines) matches "GOO+GLE|YAHOO+". This is great, but what if later someone adds a rule to AntiSpoof to turn +'s into T's? Then you'd unexpectedly end up with ccnorm(added_lines) matches "GOOTGLE|YAHOOT".

In T168527#3367504, @Daniel-Barrows wrote:

@Trizek-WMF I believe the combination of those features would work. I also discovered MassViews which can accept a Page Pile, which you can copy from your raw watchlist. This requires logging into wmflabs, and several steps, so it's not easy for the average user, but it works.

In T165401#3362175, @Samwilson wrote:

It seems to be timing out for users with large numbers of edits.

In T168349#3362544, @Marostegui wrote:

In which hosts did you do the tests?

In T168349#3361928, @zhuyifei1999 wrote:

Maybe DBAs have better ideas, but this is an optimised-to-4-min query:

P5596

In T168335#3361876, @kaldari wrote:

How about we restrict the API to only querying for the past day or week (as it was originally), and let your bot handle the longer time frames (albeit for both patrolling and reviewing).

Yup, the {{sfn}} format is what's throwing it off. Page Cuartion specifically looks for <ref> tags.

I want to also point out this query took 9 seconds to finish on production.

In T168335#3361658, @Platonides wrote:

That AND log_params NOT LIKE '%::auto";i:1%' is everything but efficient. You should be able to replace it with AND log_action = 'patrol' (ie. log_action != 'patrol'), after which you could at least use type_action index.

I ran https://quarry.wmflabs.org/query/19672 on production and it took 25 seconds. That's probably too slow... but we might could add a cron job to pre-compute and cache the stats, say every hour. Consumers of the API will only get the cached result so they are never stuck there waiting. How does that sound?

This is perhaps why the old code only supported stats for the past day and week. My fault that this was overlooked :-/

We're no longer piggybacking off of CheckUser, and the schema for a new table has been approved at T156318. Closing.

In T156318#3355174, @jcrespo wrote:

Looks ok to me, this won't be hopefully a high-rate request point. Can I delete the extra tables?

In T167345#3354015, @Ricordisamoa wrote:

Here's a shitty logo design for $0

xtools.svg2 KB

Download

Declining is the right move. We typically do Twinkle testing on Test Wikipedia, and I doubt any of us are interested in maintaining Twinkle on the Beta wikis.

I'm not sure about recentchanges but going by rev_parent_id = 0 is how XTools and other editor analysis tools do it. I don't think we've ever had a complaint of articles missing from the results.

In T166269#3350027, @Tbayer wrote:

To clarify, this was basically a suggestion to only run the regex over the first line instead of the whole page (as MediaWiki itself does in essence). This may also make things a bit faster.

In T167345#3349653, @kaldari wrote:

Apparently we can get 3 logo designs for $69 at https://worthylogollc.com/.

In T166269#3347007, @Kudpung wrote:

I'm just curious to know what has changed that makes it so difficult to come up with nice clean graphs of a kind - the exact kind we need now - that a volunteer user was able to do so quickly for us at my request almost exactly 6 years ago to the day.

In T166269#3347536, @Tbayer wrote:

In T166269#3346965, @MusikAnimal wrote:

In determining if a user was autoconfirmed at the time of page creation, the script first checks if they were manually granted "confirmed" before the page was created. Then it does the math of checking the registration date and edit count at the time the page was created.

This looks good, except that (unless I'm misreading the script) it seems to omit deleted edits when determining the user's edit count. These are part of the definition of autoconfirmed. I initially made the same mistake myself last week when working on T167471 until Aaron Halfaker pointed this out to me. It should be easy to correct in your code though, by doing a UNION with the archive table.

I wrote a script to get some sample data and have posted the results at https://en.wikipedia.org/wiki/User:MusikAnimal_(WMF)/NPP_analysis

To put in some !votes, I like "XTools" the most, but I'm not married to it, and I believe @Matthewrbowker likes "xTools" and @Samwilson prefers "Xtools". We're on our way to a consensus! =P

Interface is a little off, but we will fix that :) I've been quietly observing updates to the backend code and I'm definitely a fan. +1 from me!

@jcrespo I tried numerous variations of queries (wide range / short timespan, narrow range / long timespan, vice versa, etc., all that returned actual results), and MySQL seemed to choose the most efficient index each time. I tested this by looking at the "rows" column when running EXPLAIN, and doing an EXPLAIN on the same query but forcing the other index.

The usual developer negligence... apologies! The translations for "Query for:" should now be visible, and individual-projects is a new message that I just pushed, so should be on translatewiki soon.

Should be all good now! Thanks for the report :)

In T156318#3297550, @jcrespo wrote:

How do you plan to limit the ranges in both cases to avoid issues?

Commit: https://github.com/MusikAnimal/MusikBot/commit/70eb732f7207dc6dd82dc3e28f95bc12c3014f1e
Example report: https://en.wikipedia.org/w/index.php?title=User:MusikBot/sandbox&oldid=782944994

Here's what I've got so far: https://en.wikipedia.org/w/index.php?title=User:MusikBot/sandbox&oldid=782944994. Total run time: 9 minutes!

In T166350#3295938, @Niharika wrote:

4 story points? We aren't sticking with Fibonacci now? This task, given its current description, will earn a 5 from me.

My thoughts are to first get the list of users who created in any articles in the past 30 days from recentchanges (which will make sure we are only reporting users actively creating articles), then loop through and get the other stats.

@jcrespo (sorry for the double ping) Just wanted to say I got the code working to use ipc_rev_timestamp only for ranges, which I thought was going to be a problem. So all I need at this point is approval on the ip_changes table (not ip_changes2). Many thanks!