My conscious is a jukebox
Where do we stand with this? If we're ever going to change the routing, we should probably do it soon.
We could offer a checkbox "Use subject page instead of talk page", for each category. How does that sound?
One thing I overlooked:
Tue, Sep 18
This has been deployed
Also note https://tools.wmflabs.org/sql-optimizer is a thing, which uses some hacky workarounds. Some queries still can't be explained, though, such as those with UNIONs.
Officially up for code review! https://github.com/wikimedia/grantmetrics/pull/115
Mon, Sep 17
the system would determine the IP address of the event location, and the code would work only from that IP address
Or, would it make more sense to put Event Tools a subproject of Grant-Metrics? (https://phabricator.wikimedia.org/project/subprojects/3009/)
This is amazing! I'm awed by your browser prototypes. You've basically done all the frontend coding! ;)
Thanks! So if I understand correctly, externallinks isn't going anywhere, correct? Am I safe to start using it again on the replicas?
Sun, Sep 16
I'm going to merge with T201659. After that discussion, and seeing this report, I think it makes more sense to show percentages relative to all editors. Will try to get this implemented soon.
Fri, Sep 14
A rough demo is now on https://tools.wmflabs.org/grantmetrics-test. Feel free to give it a try!
No API. Python-urllib should normally be OK but with XTools we saw abuse. I just copied the things we were blocking there.
I blocked Googlebot and the usual other web crawlers to the lighttpd configuration:
The ability to auto-include redirects is a commonly requested feature (T163621, T200256, for example). I built Redirect Views for this purpose, but currently you can only look up one page at a time. Tools like Massviews process thousands of pages. For this we'd need pageviews for the target page + redirects to be precomputed and provided by the API, as doing it programatically would be much too slow and inefficient.
Thu, Sep 13
The overflow: auto CSS rule hides the autocompletion dropdown :(
Wed, Sep 12
One possible issue... it might not be obvious that you have to hit Submit after removing participants, too. For that I propose graying out the item:
I inadvertently deployed this along with T201437 and T200541. The deploy script just pulls from master, so this code went with it. If there are any concerns, let us know and we'll get a fix out ASAP! Gonna leave this in the Product/QA column for now.
Same issue as T203339, I assume. Somehow some of the production cache files went missing. This was fixed by force-clearing the cache again (which in turn regenerates all those files). I could have sworn I checked all the APIs after T203339, hopefully I didn't -- meaning it is a one-off issue and not persistent.
See also T192724, probably could be closed as a duplicate. My suggestion was something that resembles XTools, with a clear +/- diff format:
If you do use Symfony, be sure to use Symfony Flex, too: https://symfony.com/doc/current/setup/flex.html
Tue, Sep 11
my proposal is to compromise by validating that the category title exists in either the category or page table
Got this on enwiki when attempting to delete https://en.wikipedia.org/wiki/File:Dr._Richard_Pierzchajlo,_Head_Shot,_2017.jpg
The UI I'm currently building matches the behaviour of the participants form. When I have something to show (soon!), I'll be sure to put it up on staging and have you all review it.
I wonder if we could bundle this work in with some of the Event Tool work?
For the record, XTools allows users to opt-in to restricted statistics by creating User:<username>/EditCounterOptIn.js on the said wiki, or User:<username>/EditCounterGlobalOptIn.js on Meta to apply to all wikis. This is in addition to a list of wikis that have consensus to always show these stats, which currently only includes English Wikipedia.