Makes sense to me! However we're not actually telling it to plot like that; it's the Chart.js library that decided this. I will look into seeing if this is fixed in a newer version, but otherwise it probably something we can't fix.

Thanks, I don't know the CI system very well so I'll defer to others. I will say that the most recent build suggests we're using an image that doesn't have PHP 7.2. We will definitely need that! How can we change it?

Thanks for creating this task! I guess we don't truly need it to run the tests in this case, but it's good to require it in composer.json for wherever the application is meant to live (be it Toolforge or your local environment).

Ready for review: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/518816 This only includes surfacing copyvios. ORES to come in a separate patch.

(didn't mean to move this to "needs review")

@Niharika The "Copyvio" indicator on the main Special:NewPagesFeed interface has a link to the copyvios tool. I assume we'll want to do the same for the info flyout?

In T215192#5276136, @MarcoAurelio wrote:

Okay, so with both tools working maybe we can close this task and create another to make the tool support new versions of PHP?

Thank you both for the detailed feedback!

The route has changed to https://xtools.wmflabs.org/authorship/de.wikipedia.org/BMW_8er_(2018) but I made the old one work, too.

What Rchard2scout said. T101631 was resolved and the bug fixed itself. If only all bugs fixed themselves!

XTools' Global Contribs has a new home at https://xtools.wmflabs.org/globalcontribs, and you should now see better performance. There are also options to filter by namespace and date range.

Fixed! Thanks for the report.

Below I have broken down the data from UptimeRobot, in bimonthly increments:

Per our standup, even better:

We discussed several ideas in the estimation meeting, including but probably not limited to:

I've got a rough plan for this that I think will work. However I'm going to side-step this until T225239 and related work is resolved. The implementation will depend on the outcome of that investigation.

An update that the deployment train is apparently blocked due to T226109 (unrelated to our work).

Thank you! :D

@Marostegui @jcrespo Apologies for the ping, but we were hoping to get the OK from DBAs on our proposed query. To summarize:

If there are errors about temporary files, T225966 may be related.

We are now using Webpack Encore, and there is no longer any configuration on where the Node executable lives.

With the 1-year limitation now in place, I have very rarely seen these queries time out. Hopefully someday we can allow for wider date ranges, but for now this is what we have to do.

Fine suggestions! Thanks

I'm pretty sure this is the same issue as T225966: Toolforge: File upload to PHP webservice fails because temp file can't be opened. I restarted the webservice again, so we're good for now. Leaving this open till we have a permanent fix

This just happened again for Global Search, T225587. I question if this has anything to do with uploads, or just the file system in general?

@MaxBioHazard That is not one of the tools we maintain. This task is about tools built and maintained by Community Tech

We had this problem with SVG Translate T217815: [4 hours] opening temp-file failed: No such file or directory, which uploads files too.

In T223828#5267259, @DannyS712 wrote:

@MusikAnimal Can I suggest not disabling it for a bit, so that it can be used to verify that the queue is working as expected (i.e. all pages that had the tag added by 342 should have also shown up in the queue)

I tested this by creating https://test.wikipedia.org/w/index.php?title=Foobar_redirect&redirect=no using a sysop account, then turning it into an article using an account without any additional rights. The article showed up in the queue as expected. This confirms the system is correctly getting the previous edit, which is what was broken. I did not do any tests on really old redirects; those can be hard to find.

Finally figured it out. Careless error, simple fix: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/PageTriage/+/517720

No problem. I'm going to close this as invalid since there doesn't appear to be a bug.

In T225865#5260859, @BeckenhamBear wrote:

to get the true stat, you would have to know that the article title had been changed, and add it onto the query. ... The score does not move with the title change, its effectively lost.

https://gerrit.wikimedia.org/r/517576 is nothing more than a sloppy and unsuccessful attempt to get it in a working state. I've shifted my attention to improve XTools' Latest Global, and I'll have a much faster version of it deployed fairly soon. After that, I can revisit the GUC patch. Anyone should feel free to takeover in the meantime, though :)

@daniel Adding you as a subscriber, should you want to pursue this further. I did not tag this with Core Platform Team (MCR) as I can't confirm it's truly MCR-related, but that is my best guess.

In T225239#5264075, @DannyS712 wrote:

@MusikAnimal but that would require keeping track of all possible templates that can be safely ignored. Image the following:

#REDIRECT [[Foo]]

{{R from misspelling}}

Insert BLP name here is an idiot

The fact that the original redirect to foo was okay does not mean that this new page, which also includes other content, should be automaticall patrolled