There's currently a 100-point cap on admin score for non-deleted articles, which means that if you've hit that cap, it's possible to by making your articles worse to the point where they get deleted. (Good example for here?) Anyways, maybe that should be fixed.
Talk:XTools
Querying Admin score for user Azadiazadi on Persian Wikipedia, noticed that 3 score fields are not calculated for that user, all of which are for edits to certain pages. I think the issue is due to undefined page name on fawiki. For example, we have "Wikipedia:نظرخواهی_برای_حذف" instead of "Wikipedia:Articles for deletion". Is there a way to have that score calculated based on local page names? Thanks.
Based on the tool's documentation, looks like this is a known issue. It's ok to close this topic if there's no way to resolve the issue. Thanks again.
Hi. We have user group enabled on Persian Wikipedia named "Eliminators" which is also enabled on some other wikis. can we have an icon for users in that group in the "User groups" column? Thanks.
Administrators (at least on en-WP) have access to the number of watchers of a page when it is less than 30. However, it seems this info shows up neither at XTools nor in the ArticleInfo gadget. Would it be possible to get it to appear for the relevant accounts?
@MusikAnimal, just quickly circling back, do you think this would be feasible?
Yes, this we can do :) With phab:T220475 on the horizon, I've been meaning to move more of the logic from the backend to WMF APIs where possible, and this would be one of them.
I'll try to look into it this week.
Also was looking for this. Guess I understand the difficulty in implementing if this pulls all the data from xtools.
The Arabic version of Xtools employs Indo-Arabic/Eastern Arabic numerals (٠١٢٣٤٥٦٧٨٩), while Western users use Arabic numerals (0123456789). We would prefer it if the defaults were Arabic numerals, as they are the most generally used and understood numeral system, or if there was a choice between the two.
The Hindu-Arabic numerals were added per request from 2019: phab:T185908, phab:T213503. Perhaps things are different for Persian versus other languages that use Hindu-Arabic numerals? It sounds like maybe it's a matter of preference?
It looks like the wiki shows Arabic numerals (i.e. ar:Special:Statistics). If that is the case, then XTools should use those, too, I think.
Pinging @Épine in case they have any input.
Exactly.
As it turns out, MediaWiki goes by $wgTranslateNumerals which is turned off for Arabic language wikis on our cluster. So normally, Arabic does have translated numerals, but your community apparently has requested that it doesn't. Kurdish for example does prefer numerals to be translated.
Anyway, I've made the same change in XTools -- language code ar
will show Western Arabic numerals. I should have this deployed later today or tomorrow.
I really appreciate your explanation! I am grateful for your willingness to share your knowledge and troubleshoot this issue.
No problem :) It might be another few days before the next release, FYI. The code is merged though, so I'm going to go ahead and mark this discussion as resolved.
@MusikAnimal Is there any news about the merge?
Sorry, other priorities have gotten in the way. This next deployment is somewhat risky (lots of API changes and such), so I need to wait to deploy until I have time to tend to any subsequent issues. I'm hoping I'll get around to it next week.
@MusikAnimal Thank you very much, sir. I appreciate the explanation and will not be revisiting the matter now that it is apparent. I hope this takes less time.
Hi, Is there a any way to add a parameter to exclude bots from this list:
https://xtools.wmcloud.org/adminstats/es.wikipedia.org/2024-01-01/2024-06-16
Thanks.
For some reason about a week ago when I started getting a lot of lag when opening Wikipedia articles, which caused the Chrome tab to freeze for a few seconds and the inability to move my mouse. After a bit of troubleshooting, I discovered that it was ArticleInfo gadget, and the lag does not occur when I have it disabled. The lag is so bad infact that I spent 10 minutes trying to edit a page (with 960k bytes) and the Chrome window kept going unresponsive. After disabling the tool I was able to edit the page. What could be causing this lag? It never occurred before. Also, a while ago the gadget said that there was an issue with the API so I wonder if it has something to do with that.
Are you still seeing this issue? Roughly a week ago, we were firing a hook (Special:Diff/6421280) and this could possibly cause some lag, but the issue would then be with whatever is listening to the hook, not the XTools gadget itself. We're no longer firing the hook, but we have plans to reinstate it.
Also roughly a week ago, XTools was experiencing significant performance problems due to an issue with the databases (phab:T361945). This was fixed on April 5.
That said, I don't know why the gadget (with or without the above issues) would cause your entire browser to lag like you describe. There is no infinite loop or anything like that, and it has a very small memory footprint.
Yes, I re-enabled the gadget to find the answer to this question for a few days and the lag has come back.
I now retract my statement. I am still sometimes getting the lag with XTools disabled, but it happens far less frequently.
Yes the lag has now stopped.
I am reopening this because the lag has come back. When I open the article for London, the browser locks up, but does not lock up with XTools disabled.
I am not convinced its the XTools gadget, but I may still be able to help you figure out what's going wrong. Could you follow the steps at w:WP:JSERROR and report back with any findings?
Hello,
Could you please raise your upper limit of edits to beyond 600,000? I look at my XTools page several times a day for a variety of different up-to-date data and features and I'm close to reaching the maximum number of edits. It's hard to imagine that this is a resource that wil soon be unavailable to me. There aren't that many editors on the English Wikipedia that have this many edits, would it really be unworkable to be able to break down their edits and admin tasks? Thanks for considering my request.
I see I'm not the only person here with this request. But if you haven't responded in a month, I wonder if any developers are looking at this talk page.
I see every message here :) If I don't reply, it's probably that I don't have a good answer – and that's the case here. XTools has to service a very large amount of traffic, so long-running queries are automatically killed. The 600,000 edit threshold is just arbitrary to avoid running queries that won't finish. If we didn't have this, XTools would constantly go down.
There are couple tasks tracking this, the main one being phab:T318036. I think the rough plan is two have two thresholds – one is the actual limit that can never be exceeded, and that's something really high like 1 million edits. The other is the lower provisional limit that only requires you to login to proceed. I can't say for sure when I'll get this implemented, but probably in early 2024.
In the meantime, I can probably raise the limit from 600K to something just higher so that it will hold you off for a while. You can also use a host of other tools that don't have the same traffic problems as XTools:
Hope this helps!
Well, I hit 600,000 and I wish I had made copies of my last edit count page as now I just have an edit total and no more information. I use to check this page throughout the day to check some admin tasks so this is unfortunate.
MusikAnimal, if you could raise my threshold, well, I'll send you virtual gift baskets! I think an upper limit of 1 million would just rule out about a dozen editors instead of dozens. Thanks for the links! I'll try them out.
@Liz We don't seem to have too many "queries gone wild" at the moment so I've upped the cap to 650,000K edits across the board. Your comment got me thinking… being able to look up your own account without limitation is a genuine use case I think we can accommodate. After all, the problem isn't that XTools can't handle counting that many edits, it's just doing so at scale. It'll take me a bit before I can implement this, but it should be before you make another 50K edits :)
@MusikAnimal I was just thinking that it has been a while since I asked about the edit count threshold. I saw your comment above regarding the possibility of allowing editors to look up their own accounts without limitation, and I was curious as to whether any progress has been made in the past two months in that regard. It would be great to be able to view my account's XTools data again.
Hello, also see
- https://phabricator.wikimedia.org/T361829 wikiscan.org returns 502 Bad Gateway (workaround for XTools limitation)
Help, @MusikAnimal. I guess I hit 650,000 edits because I just have a blank Edit Count page again. It looks like it took me 5 months to rack up those 50,000 edits.
I feel like I was blessed when you raised my limit last time because I check my edit count page for different reason throughout a regular business day. Any way I could get another boost in my upper limit? That should take care of things until the end of the year as I'm going to be taking a break later on in 2024.
There can't be that many of us that have this problem, on the English Wikipedia it's about 53 editors. I've noticed that the Commons has some very high edit accounts but I'm not sure about other projects. But it can't be more than a few hundred people who are running into this problem. Considering how many registered accounts there are, that's a drop in a bucket! Now that realization could go either way, either it's a problem that affects only a few editors and so isn't that important to address or it's a problem that only affects a few so raising the limit of edit counts wouldn't have a lot of impact on the operating system. Which would be the better argument?
I'm working on a longer-term solution. I hope to have it deployed in the next ~48 hours. Apologies for the disruption.
No problem, @MusikAnimal. I appreciate you addressing the issue. It's the kind of problem that doesn't affect a wide swath of editors but it does impact some of our most active ones.
Okay, deployed! I hope this works. A week or two's time should tell us. If it does, I'll likely be able to increase the thresholds until we find the "sweet spot" where we can allow people like you to get the data you need, but not take down all of XTools in the process.
To be clear, it's not you who's taking down XTools – it's everyone collectively looking up accounts like yours. If too many long-running queries happen simultaneously, we can't make any new queries and so XTools is effectively unusable.
I'm going to resolve this thread for now. Please re-open if you have any related issues.
Hello, thanks a lot!
I still get the follow error message:
User has made too many edits! (Maximum 700,000). Showing Simple Counter instead.
I have just increased it to 800K. If all goes well over the next few weeks, I'll keep raising it.
Thank you so much! It's really cool to be able to access the data again.
I'm still getting the simple counter, even when re-logging in. @MusikAnimal, is the solution deployed already? I'm getting the message "This user has made a substantially high number of edits. Showing limited results." with 652K edits.
@Liz It worked for me: xtools:ec/en.wikipedia/Liz and took only 73 seconds too!
Maybe the redirect from Edit Counter to Simple Counter is cached by your browser. Can you try in a different browser or in private mode?
I just put down more information (below) but I'll try out your suggestions.
Okay, instead of using the open XTools tab and refreshing the page, I went to a new my Contributions page and hit "Edit Count" and after a long wait, it opened up to the familiar page.
Many thanks! I guess I don't have to worry again for a while.
Now, it keeps logging me out of the system and gives me no information about my account at all. What's up with this "fix"?
I get "For performance reasons, the requested data is only available to logged-in users." and then when I try to log in, OAuth states "This request has already been completed and cannot be resubmitted. Go back to the application and try to connect your account again, or contact the application author." Would that be you?
I managed to once again go to the New tab>My contributions>Edit count to get the page back. But I should be able to refresh the XTools page and get the most recent totals without all of this rigamorole, right?
Yes, you should. Login sessions not lasting very long is a known issue that effects many tools, see phab:T224382. I'm not sure about the OAuth issues you're experiencing. It sounds like the login wall you get is also cached… and so the token you send to OAuth is same token as before, and that's why you get the "This request has already been completed" error. Which browser do you use? Do you have any special browser extensions that you think could play a role here?
Apologies for the unwanted behaviour. On the bright side, the "fix" of putting up that login wall has had a dramatic effect on our server load. I've already increased the max edit count threshold to a million edits, and I might even raise it higher.
I'm going to be working on the login issues in the coming weeks, so hopefully that much will be resolved in due time.
When I try to refresh the XTools screen, I'm still getting logged out of XTools even though I've used it for years without problems. Then I try to use OAuth and that doesn't work. But for some reason, if I keep persisting, logging in and refreshing a couple of times, I can eventually get to an updated XTools screen, it just takes jumping through a few hoops. But it would be best not to get logged out when trying to refresh XTools. Just thought I'd post an update, @MusikAnimal.
The admin score feature, while fantastic for almost all wikis, has one major glaring exception: Commons. The biggest thing is changing AIV to com:ANV, AFD to com:DR, articles patrolled to files patrolled, and changing all metrics about the article namespace to either file or category. I'm not sure how difficult the change is, but would be greatly appreciated!
Hello,
I found out that the the username returned in JSON response is being parsed and causing the returned value to be different. Here are a few examples:
Actual Username: 2E171
Returned Username: 2e+171
Link: https://xtools.wmcloud.org/api/user/simple_editcount/en.wikipedia/2E171
Actual Username: HickoryOughtShirt?4
Returned Username: "HickoryOughtShirt"
Link: https://xtools.wmcloud.org/api/user/simple_editcount/en.wikipedia/HickoryOughtShirt?4
Actual Username: 1789.e5
Returned Username: 178900000
Link: https://xtools.wmcloud.org/api/user/simple_editcount/en.wikipedia/1789.e5
Actual Username: 0555
Returned Username: 555
Link: https://xtools.wmcloud.org/api/user/simple_editcount/en.wikipedia/0555
Is there a parameter I should include to disable or avoid this behavior?
Thank you.
Acknowledged. Thanks for reporting this! I have a fix mostly ready to go, but a lot of other changes incidentally need to come with it, including API deprecations. I'm announcing the deprecations in XTools 3.19 which I hope to deploy tomorrow, then 3.20 with the fix for above will follow in a few weeks.
Side note: OughtShirt?4 has to be percent-encoded, because the ?
is what starts the query string in URLs. I.e. use https://xtools.wmcloud.org/api/user/simple_editcount/en.wikipedia/HickoryOughtShirt%3F4 to get the correct user.