Talk:XTools

Jump to navigation Jump to search

About this board

This page is a feedback forum for XTools. For reporting bugs, it's preferred that you use Phabricator.

If the issue is urgent and you're unable to use Phabricator, feel free to ping one of the active maintainers.

Edit counter appears to be frozen

6
Summary by MusikAnimal

Back to normal

Yngvadottir (talkcontribs)

24 hours or more ago, I noticed the edit counter flagged a lag of about 2 hours. Since then tehre is no notice, but the count has failed to increase. Sorry, I do not wish to sign away my firstborn child by activating my account on Phabricator. ~~~~

MusikAnimal (talkcontribs)

This is due to phab:T262239 which is outside our control. It will hopefully be resolved in the coming days. Sorry for the inconvenience.

Yngvadottir (talkcontribs)

Thank you! I take it "UBN!" stands for "un-break now!" It would be nice if they would tell us when they were going to do stuff like this. (I gather one doesn't sign here.)

Chicdat (talkcontribs)

Edit counter is still frozen. Says on Wikipedia I have 4,649 edits while I actually have almost 4,700.

Chicdat (talkcontribs)

Updating a bit....


...but not much.

Chicdat (talkcontribs)

Now everything is fine again.

Having issues getting everything started for a private wiki

2
UlfrTheRed (talkcontribs)

Hello!


I've been told that you folks stopped supporting non-WMF wikis from a reasonably reliable source.

Kind of explains why I've been having a mammoth issue getting it up and running on my non-WMF wiki, to be honest.


I was wondering if anyone could direct me to the last version of xtools that supported private wikis or a build that runs on 1.34.2 instead of whatever jiggery-pokery you folks are running these days. I can muddle through commenting out lines that break stuff on my own, but there's not a lot I can do when the script is looking for database fields that simply don't exist for me yet.

And while I'm being a pain I'd like to make a humble suggestion, would it be possible to update the documentation for installation on readthedocs to maybe give a heads up to folks that spinoffs aren't supported (and that mariadb is required)?

MusikAnimal (talkcontribs)

Hey! In the beginning, we aimed to support 3rd party installations, but no one ever expressed interest in XTools, even when we asked wikis about it directly. Eventually the maintenance burden was just too much given no one else cared, so we dropped support, which also opened the door to add WMF-specific features.

I apologize about the poor documentation. XTools is almost entirely maintained by myself these days during my free time, and I struggle to find the time to fix bugs, keep the service up and running reliably, and document every step I take. I will at least put up a disclaimer that non-WMF installations are not explicitly supported.

At any rate, it should be possible to use an older version of XTools. I believe I believe non-WMF support was dropped in version 3.10.0, so I would start with version 3.9.1 https://github.com/x-tools/xtools/releases/tag/3.9.1. You don't need MariaDB necessarily, but you do need MySQL-like. If you are using Postgres or something where MySQL won't translate, I'm afraid XTools will not work for you :( I think you said on IRC it was complaining about a missing meta database; that is only if you are using XTools on a wiki farm. If it's just a single wiki, set app.single_wiki to true. It shouldn't look for a meta database at all if that is set. More at https://xtools.readthedocs.io/en/3.9.1/installation.html#single-wiki

All of that said, I am more than happy to restore non-WMF support if I can get some help. If you're interested, let me know! However it might be complicated to support older versions of MediaWiki. I suppose we could create a branch tied to a specific MW version, and add bug fixes to it as needed.

Hope this helps.

Reply to "Having issues getting everything started for a private wiki"
Orlodrim (talkcontribs)

Hi,

Would it be possible to mark disambiguation pages in the list of articles created by a user (e.g. https://xtools.wmflabs.org/pages/fr.wikipedia.org/Orlodrim)?

A discussion started about that on the French Wikipedia because of our complex assessment rules, which have the consequence that there is a "disambiguation" assessment level but it's only used on a handful of disambiguation pages. On the other hand, all disambiguation pages are tagged with __DISAMBIG__. Thus, it would be useful to display the disambiguation status in addition to the assessment, or maybe as a fallback if there is none.

Reply to "Disambiguation pages"
Red Director (talkcontribs)

Hello. I recently crossed the 400,000 mark. It no longer shows details for me. Can the limit be upped? If not, I understand completely. I can extract my data second-hand through other means.

MusikAnimal (talkcontribs)

I have increased it to 450,000, but if things start timing out a lot it may have to be reduced again. There is a more robust longer-term solution that I hope to get to implementing soon. Until then, the limit may fluctuate depending on the health of the databases.

Red Director (talkcontribs)

No problem. Thanks for the help.

Reply to "400,000 edit limit"
Jonteemil (talkcontribs)
Jonteemil (talkcontribs)
Reply to "Addition of edit"

Article class not displayed properly if the WikiProject tag is 'inactive'

4
Piotrus (talkcontribs)
MusikAnimal (talkcontribs)

The issue appears to be with Template:Inactive WikiProject banner, but I can't help but wonder if this desired behavior. One could argue that if a WikiProject is defunct, so are its assessments. w:Template:WikiProject Culture similarly does not reveal assessments for defunct WikiProjects, nor does it put the page in any categories.

Piotrus (talkcontribs)

I don't think this is desired, assessments are often done by people who are not project members. A project does not have to be active for assessments to still be useful to thers. Assessments are in the end part of an all-wiki imitative, just 'farmed out' to projects for categorization. An inactive wikiprojects should not cripple the global assessment initiative.

MusikAnimal (talkcontribs)

I don't disagree, but regardless there's nothing to fix in XTools. Template:Inactive WikiProject banner does not accept "class" or "importance" parameters. It needs to pass them to the Template:WPBannerMeta parent template in order for the assessment data to be stored in the database. Basically if it doesn't show up at Special:PageAssessments, it won't show up in XTools. However to me it logically makes sense to omit storage of assessments if we're not showing them in the template, which is the case here.

The quick fix would be to simply tag it under a different WikiProject, perhaps the parent WikiProject Sociology. To your point about "the global assessment initiative", I concur it would be nice to have a more generic assessment system without the need for a specific WikiProject. After all, most WikiProjects seem to define classifications in the same way, at least up until GA or FA.

Reply to "Article class not displayed properly if the WikiProject tag is 'inactive'"
Equinox (talkcontribs)

I don't mean the quality, but the choice of pictures to convey the meaning. They should ideally match the wiki terminology. The mop suggests "janitor" rather than "administrator". The choice of physical tools for "bureaucrat" (is it a wrench and screwdriver?) is particularly symbolically jarring for me, because bureaucrats are people who sit at desks, the opposite of people who do physical labour.

RoySmith (talkcontribs)

Using the mop to symbolize administrator is long-steeped in wiki-culture. I've been around for 15 years, and the association predates me. The idea is that an administration is a necessary, but not glamorous, job. If you search for the word "mop" in wikipedia space (at least on enwiki), you'll find many usages. For example, this signpost article.

MusikAnimal (talkcontribs)
Reply to "Icons could be improved"
Psiĥedelisto (talkcontribs)
RoySmith (talkcontribs)

Is it legal to have a username that starts with "User:" (i.e. as part of the actual user name). I see we've got User:User; DROP TABLE 'users'; -- on enwiki (and a few similar), but nothing that actually starts with "User:", so I'm guessing it must not be.

Psiĥedelisto (talkcontribs)

Well, hypothetically, were it, that wouldn't be a reason to reject this request out of hand. All that would need to be done is, check if User:User:Psiĥedelisto exists, and if they do, give precedence to them, adding a warninge.g. Warning: This is the data for User:User:Psiĥedelisto, not User:Psiĥedelisto (Psiĥedelisto). I would say that if User:User: can happen, that's really bad and ought to be disabled, since a lot of scripts/tools strip User: for you!

Reply to "User:"

Time Card API docs don't match reality

2
RoySmith (talkcontribs)

The docs say:

Get the relative distribution of edits made by a user based on hour of day and day of week. The returned values are a percentage of edits made relative to the other hours and days of the week. Hence the maximum value is 100 and this would represent that time and day that the user is most active.

But, the actual JSON output has elements like:


{"day_of_week":2,"hour":10,"value":13,"scale":0}


It's unclear how this maps to what the docs describe.

MusikAnimal (talkcontribs)

Docs are out of date! Thanks for pointing this out, I'll get that fixed. The numbers you see should be the total number of edits made during that hour and day of week.

Reply to "Time Card API docs don't match reality"
Darren-M (talkcontribs)

Is there a way to display the largest articles (i.e. page size) per wiki?

MusikAnimal (talkcontribs)

No, though it would seem such a query would run fast enough for this to be feasible for an on-demand tool like XTools. I don't know that we could show a list across all wikis, however -- that might be too slow. For now you could run a simple Quarry query, take quarry:query/46194 for example (German Wikipedia).

Darren-M (talkcontribs)
MusikAnimal (talkcontribs)

I have created phab:T256549. I'm surprised at how fast the query is! This seems totally doable. Thanks for the suggestion!

Reply to "Article size"