May 8 2019
I also started seeing the symptoms described by Jonesey95 about a week ago on enwiki and the read/unread results on my watchlist remain essentially random now.
May 25 2018
Jul 30 2017
action=compare also appears to have no equivalent to diffto=prev to get a single diff content. What's the right way to get even a single diff of a page, where you only know a single revision id, without using the now-deprecated APIs? Are we supposed to request the page history first to get the adjacent revision ID?
I've only just become aware of this task. I use action=query&prop=revisions with rvdiffto=prev to get diff content for a number of revisions at once. Sometimes it returns notcached for a diff, but it's a good way of getting bulk diffs without imposing a big resource demand.
Jul 25 2017
Oct 7 2015
Aug 4 2015
Okay then, so I'm guessing it's the GROUP BY / ORDER BY that are taking all the time, right?
Aug 3 2015
Jul 31 2015
Thanks for the logging_userindex suggestion. Using that table, then, what makes this so slow:
I've updated the wiki with some guidelines on how to get python3 working using this. The biggest problem seems to be that uWSGI mountpoints don't work with Python 3, but that's a uWSGI bug.
Jul 29 2015
Yes, I guess that'd also work!
Or, in fact, even just reversing the order in which the --venv and --ini arguments are added to the args list would be good enough. If --ini comes first, then you can specify the plugin in the ini file, and then --venv will work.
On a little more investigation, it seems that --venv does work if --plugin python3 (or --plugin python) is also specified. Putting plugin = python3 in the ini file doesn't change anything. Perhaps adding this to modules/toollabs/files/tool-uwsgi-plain would be a workaround, though not very satisfactory:
Mmmmkay. I've put this in ~/uwsgi.ini: