User Details
- User Since
- May 17 2015, 1:19 PM (485 w, 23 h)
- Availability
- Available
- LDAP User
- Wbm1058
- MediaWiki User
- Wbm1058 [ Global Accounts ]
Jun 12 2024
I put a couple var_dump statements in the code, with the objective of understanding the change from the "legacy error array" format → an array of MessageSpecifier objects
Jun 10 2024
Thanks @Catrope. You have a talent for explaining things at just the right level I need. Now I understand that this authority stuff isn't really where the code changes need to be made for this Phabricator. Admins/page movers have the authority; the issue is what happens after it's been determined that the move is permitted / possible.
Jun 5 2024
I enhanced one of my bots to check for, and report, errors it encounters.
May 28 2024
Thanks. I know that 15 years is like a lifetime in IT. A quarter-century has passed already since I was last paid $ to write code (with one small exception at Wikipedia's Reward Board, ha!). I'm very much comfortable writing procedural code, not so much with object oriented.
May 23 2024
Thanks @Catrope. Indeed I missed the distinction between the boolean and the function. Got it.
May 15 2024
I'm tackling this as my first MediaWiki core coding project, though I haven't formally checked out the code yet. Working on understanding the (somewhat complicated) control flow.
May 10 2024
Thanks. So Quiddity, the advice: "Users must use pl_target_id instead (a foreign key to the linktarget table)." wasn't sufficient to clearly explain to me what I needed to do. I think, to better explain for rusty SQL users like me:
May 6 2024
There are just 16 of these; I call them the "Sweet Sixteen". They've been in the database "forever". Why do you need a script to deal with just 16 items? Why can't someone just manually delete them?
May 4 2024
Apr 22 2024
Sorry to butt in, but, my understanding from the above is that the corrupted table coincidentally happens to be the same table which was just recently "normalized", correct?
Jan 25 2024
Sorry, I have found one more scenario where "Bot1058 is unable to perform a link update using the API" where it was previously able to, before August/September 2023. I'm still not totally up to speed on Phabricator etiquette, so will let y'all who are still subscribed to this decide whether it is appropriate to reopen this Phab, open a new one, or just comment here on this closed Phab without reopening it.
Jan 13 2024
I've finished three 10,000 page runs. They still have the X-Wikimedia-Debug. Yes, the new deployment helped. At least some of the pages are now purged.
Dec 20 2023
OK, I turned X-Wikimedia-Debug back on, and ran a one-off test that attempted to refresh 10,000 links. Hopefully that's given you the data you need to track it down. Let me know if you want me to run more tests.
Dec 4 2023
I've gotten this error twice, when trying to make the same simple edit to a page
Nov 27 2023
I ran a quick bot test on Toolforge Kuberbetes to purge 80 pages. It finished in 14 seconds. Alas, it too failed. My Quarry query of two pages that the bot attempted to purge shows their page_links_updated dates to still be August 20, 2023. That's 25 days before September 14. This bot was endeavoring to keep pages refreshed every 30 days or so, and would have been running really well if it had actually worked it down to just 25. Those pages likely would have been purged around September 15 or 16 if the issue hadn't cropped up, give or take a day or few.
The odds of losing updates due to an error increases when executing long queues
and when large amounts of time pass while tasks are queued. Mitigate this by
trying to eagerly move updates to the JobQueue when possible.
I suspect that changes related to Phabricator T265749 broke my bot's purging. Right about the time when this was marked as closed and resolved (~September 10-11) is when my bot stopped working.
Oct 19 2023
I got a boatload of these "login from a device you haven't recently used" messages on October 14 (and a few before that), but couldn't be bothered to report the problem. I assumed that it was a system problem and not someone actually hacking my password. Glad to see that someone else reported it.
Sep 11 2023
Sorry, it's too much trouble for me to spend an hour trying to figure out how to open a new Phab, so I'm just gonna reuse this one.
Sep 8 2023
OK, I've successfully set up log rotation for a couple of my Toolforge jobs, and have documented how I did it.
Aug 27 2023
I found this helpful documentation:
A Complete Guide to Managing Log Files with Logrotate
Aug 19 2023
Oh, I see (lightbulb turning on):
Aug 18 2023
Aug 16 2023
Well now I see the status is "Open, In Progress, Needs Triage" but I'm at a loss for how to remove "Needs Triage". A member of the Triagers project needs to do that?
I've noted that for a long time the status of this task has been "Open, Needs Triage".
Hmm...
Per the task description which says "If you have already migrated this tool, kindly mark this as resolved." I am marking this as resolved.
Jun 30 2023
ERROR: Please report this issue to the Toolforge admins
This is an unattributed fork of the problem I reported HERE
Jun 15 2023
I'm making more sense of this, figuring out things that should have been explained to us from the start of this phab.
Am I correct in my assumption that Quarry is 100% "supported" by volunteers? Who wrote it?
OK this thread has bugged and annoyed me to sufficiently motivate me to attempt to use Superset. After looking at the user interface Dashboards... Charts... Datasets... for a couple of minutes ..... where do I enter my SQL query?? Oh duh, click on the "SQL" tab... that's one step I don't need to make in Quarry ... I see a more familiar window where I drop my SQL
Jun 11 2023
Jun 1 2023
May 23 2023
Won't you need to keep the Superset machines running and patched with the latest OS / security updates, etc. too?
I'll echo the "why not both" sentiment of Danilo above. Quarry doesn't get a lot of support. Right. Nothing on the developers platform gets a lot of support, so what else it new? Toolforge doesn't get a lot of support. Grid Engine doesn't get a lot of support. Kubernetes doesn't get a lot of support.
Apr 25 2023
Feb 18 2023
Feb 12 2023
Status update. I only started working on GridEngine on October 1 2022 with submitting simple one-off jobs using 'jsub' and never got to the point of having any fully automated jobs running on that platform, as just five days later on October 6 I got your email informing me of this Phabricator. From that point I stopped even running one-offs on GridEngine.
Feb 7 2023
Jan 25 2023
Swagger is a suite of tools for API developers from SmartBear Software and a former specification upon which the OpenAPI Specification is based.
Jan 23 2023
T317967 describes the same or a very similar phenomenon, which, as I said I've observed in legacy Vector from time to time as well.
Well now the Funeral#Visitation link works OK for me too.
Well I see that this section link works properly for me.
But this section link does not.
And neither does this section link which Sj provided in their original report above.
If anyone figures out how to use a wrapper script, please let me know how you did it. Thanks
OK, so now we've just gone from easy to reproduce to damned near impossible to reproduce. Like hunting for a needle in a haystack or finding the winning lottery ticket number.
Open casket is a redirect to [[Funeral#Visitation]].
I just updated to the latest version of Google Chrome and duplicated this on Windows 10.
Nov 26 2022
Dear komla and nskaggs,
Nov 13 2022
Per the documentation:
$ toolforge-jobs run refreshlinks--k8s --command "php ./php/refreshlinks.php > ./logs/refreshlinks--k8s.log" --image tf-php74 --no-filelog
Nov 12 2022
Oh, sorry, thanks. I tried that twice
There is an ongoing ticket for recording logins in CheckUser and that would probably help with this problem. However, that will take some time to get built.
If this task has been finished and closed as resolved, then why isn't --emails EMAILS listed by the Help command?
Nov 10 2022
Nov 6 2022
I see this item is still open, though no comments in three years.
Oct 30 2022
Oct 6 2022
A volunteer to help me migrate my English Wikipedia bot request for approval would be appreciated.
Jun 25 2022
May 30 2022
What's up? I just tried querying the database, which has been working for me for months, and see a query failed error:
May 10 2022
Thanks. That does clarify things at a high level; I'm still foggy on the details.
May 8 2022
May 1 2022
https://quarry.wmcloud.org/query/63057 has been running for four days now. I've run this many, many times and normally it runs in a matter of just seconds or a few minutes at most.
Apr 12 2022
And now I present the Super Six! These six pages have a special power that makes them highly resistant to conventional null-edit purging. All six share in common that they are the same 6 bytes long: {{OW}} i.e. they transclude Template:OW. This template has over 615,000 transclusions on English WIkipedia, which are generally are purge compliant, but for these six. HERE we see an editor work-around for the page's purge resistance. She actually edited the page to make a redirect to the template, in order to force the purge, and then self-reverted back to {{OW}}.
Mar 25 2022
I have a suspect for the cause of "the 16". Noting that the T115081 report was filed on Oct 8 2015, this was just when someone first noticed and reported it. There is a bulge in User, and especially User talk pages to update with page_links_updated = 201505 which is about five months before the bad data was reported. The bulge is caused by a ton of users with names ending ~enwiki so my suspect is the project that implemented Unified login or SUL (single user login).
Mar 24 2022
LOL! I found the Sweet Sixteen! American college basketball fans, the round to determine the Elite Eight kicks off in just a few hours!
In just over ten days I've cleared the NULL members of page_links_updated on enwiki, but for 16 pages that can't be purged, possibly due to random sunspot activity.
Mar 20 2022
Just to be clear on what this is about, here's a link to the manual for refreshLinks.php
https://www.mediawiki.org/wiki/Manual:RefreshLinks.php
Mar 17 2022
Mar 6 2021
Mar 1 2021
Local blacklists and whitelists hmm, maybe a MAGIC WORD is needed to pull the location out of the common or local settings?
LocalSettings.php is not a wiki page and you cannot access it with your web browser. Instead, it is a file in the file system of the server. Its contents are generated during the initial setup of the wiki and the resulting file must be copied on the server manually.
Feb 20 2021
See the closed discussion at Wikipedia talk:Spam blacklist §Requested move 10 February 2021
Dec 24 2020
Nov 23 2020
A solution was implemented on English Wikipedia that removes undesirable Side Effect #1 but apparently also removes the desirable side effect(s) as well.
Sep 13 2020
Feb 28 2020
Thanks, but this link https://en.wikipedia.org/wiki/Template:If_preview is more helpful. My understanding is that the test can only be done using a Lua module; all the template does is invoke the Lua module.
Can I ask what purpose is served by {{REVISIONID}}? With the disabling of this feature, which was the ONLY useful application of this magic word, there is absolutely no practical use for {{REVISIONID}} that I can envision, so you all might just as well remove {{REVISIONID}} from large wikis entirely. No point in documenting something that has no practical use.
May 17 2019
OK, so every time I try to move a page over a redirect the software breaks in with 'The destination page " " already exists. Do you want to delete it to make way for the move? (Check the edit history.)' How dare it do this AGAINST MY EXPECTATIONS! Just move the page and stop running interference.
Feb 12 2019
History-merging pages on enwiki is enough of a pain already (delete and restore are slow, and often time out and need to be repeated) and having to tend to Wikidata on top of that just adds to the trouble.
https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_guide/Fixing_cut-and-paste_moves#Bugs_and_problems
Feb 10 2019
Is this a bug or feature? This is the only evidence that I'm aware of where Special:MergeHistory leaves any log on the target page indicating that another page was merged into it. There is no log entry, nor a no-changes edit that leaves an edit summary indicating a history-merge occurred at this edit. The telltale sign that a merge ooccurred at that edit is the fact that the edit ostensibly increased the page size from zero bytes, when the previous edit did not blank the page. SO to me, this is a useful feature in that it leaves a bit of evidence, albeit cryptic and hard to find, of where another page was histmerged in.
See the description of problems at https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_guide/Fixing_cut-and-paste_moves#Bugs_and_problems
Feb 8 2019
Jan 25 2019
Jan 19 2019
Right, that occured to me moments after I sent my last message. So, in the Tech News, please do advise sysops to add a notice to their wiki's [[MediaWiki:Delete and move confirm]] page.
I restored https://en.wikipedia.org/wiki/MediaWiki:Delete_and_move_confirm which I'd deleted when this went into hibernation. That's probably sufficient; I'm not sure a notice in Tech News is necessary.
Jan 15 2019
Anomie, thanks for "taking ownership" of this. Just noting that when it has failed for me, retrying has never been successful. I just retried another move several times, and it failed each time. I'll stop doing that now as it is probably just pointless spamming of your logs. Hopefully your temporary logging will find the culprit.
Internal error