My conscious is a jukebox
So while the one bug for T163527 needed to be fixed, there was still more ways to improve getting project metadata within XTools. For that I've reworked a bunch of things, namely requiring a new parameter for the API path. This resolves our main issue, where before we were using addwiki's newFromPage to parse the HTML of a project page to get the API path. That to me is kind of crazy, and seems prone to error.
@jcrespo Sorry to bug you. I'm guessing I will not be given the necessary rights to FLUSH STATUSon db2048, so I have prepared a series of test queries for you. Please note these queries are not hand-written, but are constructed by the ContribsPager and Revision classes. The only changes I've made are to JOIN with ip_changes and add the BETWEEN clause.
Hmm, well on the surface, when I think "edit count", I think the number of items I see at Special:Contributions and Special:DeletedContributions. That's how I used to do counts (painstakingly) before I knew about edit counters or Anomie's useridentifier script. The same is obviously true with the revision history of a page. There I see page moves, and XTools and others count those as edits, too.
Maybe I'm doing something wrong, but on the latest mediawiki-api and mediawiki-api-core, with MediawikiApi::newFromPage('https://sq.wikinews.org/'); I now get:
Thu, Apr 27
Well, the analytics part we obviously wouldn't be able to do. Perhaps that's important to some, not sure, but I can suggest that would make this otherwise Easy -ish task into a big project. It would be cool to see if the pages survive speedy deletion, as described. Perhaps we could use both system messages and a backend tracking service. This would allow us to get the numbers we want but permit the community to customize the interface.
An update: The old message is now shown to confirmed users, and Template:Newarticletext-unconfirmed is shown to unconfirmed users. These are transcluded in MediaWiki:Newarticletext and conditionally displayed based on user rights, accomplished with user group CSS (MediaWiki:Group-autoconfirmed.css, specifically)
This was declined with T128495 but times have changed, and the API is much faster now. Even so, querying for redirects could slow things down dramatically depending on how many pages you're querying for and how many redirects those pages have. I don't want to make it a default-on option for this reason, even for the main Pageviews app, but at this point a default-off option should be doable.
Fri, Apr 21
Yup, and I pulled that number myself with https://tools.wmflabs.org/musikanimal I have my regrets :( We definitely don't want to do that for XTools, and I think we're mostly at the consensus of using separate Tool Labs accounts (if we opt for Tool Labs). If someone wants to fork and turn off the other tools, it involves literally one single config file, where you put 0 next to the tools you don't want, and a 1 next to the ones you do. I think all the drawbacks we've discussed thus far regarding new contributors can be solved with good documentation.
Sounds like this investigation has begun!
I think we're past the point of unbundling the suite, at least if we except to meet our quarterly goal. We should mind the enormous amount of work that has already been put into this, let's please not take any steps backwards. It would be different if the XTools codebase were a big giant unorganized mess, like my Pageviews apps =P Instead, we're following the conventions provided by Symfony, a very popular framework. Documentation for it is ample, StackOverflow answers, etc. I agree the one big repo may be confusing for a new contributor, but that's assuming they are either unfamiliar with Symfony or we don't have good documentation (which we will work on). Forking and updating a single tool should be straightforward – for most things you want to do there are only a handful of files that would need adjusting. Now, if they want to fork for their own purposes and use only a single tool, then well, yeah, there's a lot of a unnecessary overhead. However XTools has always been seen as a "suite" of apps, one goes with the other, lots of inter-tool links, etc. We at least have config options to turn certain tools off should you want to.
Note T163527 means currently the API and namespace selector will break if you try certain projects like es.wikipedia.org or sq.wikinews.org
I noticed this too, which effects T162754. Currently you can't select a number of projects, including es.wikipedia.org
[WIP] patch at https://gerrit.wikimedia.org/r/#/c/349457/
I definitely don't think the tools should be broken out into different repos. They share a lot of code, and separating it would defy the point of Symfony, which I've come to enjoy. It looks like a big scary repo but that's the nature of a framework. Once you get it down it's easy peasy. We can also work to document how to add new tools, but those familiar with Symfony would probably figure it out as-is.
Relevant commit: https://github.com/x-tools/xtools-rebirth/commit/65577854b2ef7250e60d3e14930dd7816ef9d8af
Namespace API endpoint: http://tools.wmflabs.org/xtools-dev/api/namespaces/fr.wikipedia.org
Actually, for each autoblock we do have the parent block ID. With that we can get the original block message and account, and trim down the Reason column. I'd take it a step further and have a new column "Account". So for the first one in F7674595, it would have "AndrewTheLogoMaker" as the account and "Persistent addition of unsourced content" as the reason. That should free up a lot of real estate. Below the account name might be where you would put the "(unblock)" link, that makes it clear your unblocking the account.
Well, the sorting should be for all blocks or autoblocks, not for the current page you're looking at. But the current table system (whatever it is) does have some sorting thing built-in, for instance see Special:AbuseFilter.
Thu, Apr 20
All the changes to i18n messages were just changing one key name, and then sorting the list.
I see that suppressredirect is also missing. That might have been added to the bot user group with T133981. Presumably they are not showing up in AbuseFilter for other user groups with these rights as well.
This has been fixed in the rewrite.
This has been fixed in the rewrite, which you should expect in the coming months :) I will not close this but in my opinion "Declined" would be appropriate, as we don't want to put much effort into fixing non-critical bugs with legacy XTools.
Boldly closing as I don't think wikiviewstats will be brought back to life. R.I.P. 🛌 ☮
Wed, Apr 19
See T136144#3195131, will write this here too: I think we should be going by viewership and active contributors in prioritizing which wikis to support, not total number of articles. Some of the smaller wikis like Cebuano Wikipedia are using bots that create the vast majority of articles, pulling from a small pool of sources. I think you and Internet Archive will find your efforts have a greater impact in supporting projects with more readers and with a wider variety of sources subject to linkrot.
I must point out that since you created this task just under a year ago, Cebuano Wikipedia has grown to 4.2 million articles, but with only ~150 active editors total! Looks like Lsjbot (bot) is the main contributor, aggregating data from sources like http://www.catalogueoflife.org/, and http://www.geonames.org/. Just try using their Special:Random and you'll see most articles are largely using the same sources. For this reason perhaps IABot wouldn't be as much of use, as compared to a project with a large diversity of sources more subject to linkrot.