User Details
- User Since
- May 17 2015, 1:19 PM (409 w, 2 d)
- Availability
- Available
- LDAP User
- Unknown
- MediaWiki User
- Wbm1058 [ Global Accounts ]
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
Jan 14 2019
OK, I just got this error again: Internal error
Dec 10 2018
While the fact this was first reported early on a Friday has led everyone to suspect something in a Thursday code deployment was responsible for these page-move errors, I note that coincident with that a bot https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/TheSandBot was approved to move over 35,000 pages. It was shortly after this bot was approved and began moving pages en masse that I first encountered this error. Now, it may be a coincidence, as the bot does not have admin privileges and thus does not attempt to move over pages that require deletion to move over them, but it was someone manually trying to do what the bot couldn't, and failing, that threw up the red flags I noticed, and then when I attempted to "fix" their "error" I saw this error.
Dec 9 2018
Is this still a problem? A week ago Friday I saw this error every time I tried to move over a page with history. It didn't seem random, it happened every time. But this condition only lasted for a day or two or three. I can't recall exactly the last time this failed for me, but it's been almost a week now I think since the last time. It seems to have fixed itself. Maybe the problem was some lag in software deployment? Surely someone can figure out why this happened?
Dec 8 2018
Apr 27 2018
All of the .cm-mw- items seem to be for specifying how to color and font-weight something that is not ordinary, normal text, i.e. a section heading, a template, a wikilink, etc.
I'm not following MusikAnimal's comment above.
Feb 24 2018
Dec 19 2017
The fundamental issue here is that start=2016-03-10 is incompatible with offset=20160311235959. You can't start from two different dates! Is start a new parameter; why was it created? It seems like a fork of offset. What are the rules for behavior when both are specified?
Dec 18 2017
OK, so I click the blue link for "500" and it shows me 500 edits, which extend well beyond the date range I selected. Now it does show both "newer 500" and "older 500".
https://en.wikipedia.org/w/index.php?title=Special:Contributions&offset=20160311235959&limit=500&contribs=user&target=Dbachmann&namespace=&tagfilter=&start=2016-03-10&end=2016-03-11
Nov 17 2017
So yeah, this finished far back in the pack in the 2015 Community Wishlist Survey. You could bring it back up for the 2017 survey, which is currently in progress. The chances it will finish in the top ten are slim to none, and we're lucky if the folks working on this stuff can even get ten of these knocked off in a full year. So don't hold your breath.
Jul 14 2017
Jun 2 2016
Apr 4 2016
Thanks for that, matmarex. You said it more succinctly and much better than I did. Right, the Mediawiki software should not consider the /* blah */ to be part of the user's edit summary at all. Rather, it is a Wiki-section-link (using a different syntax than the usual [ [ #blah ] ]) to the single section that the user edited. This should not even be directly under user control. If the user edited more than one section at the same heading-level, then the software should remove the /* blah */ or change it to the next higher level section that includes all sections which were edited. If the user edited just one section (which may or may not include sub-sections) and the /* blah */ is not there, then the software should add it. If the /* blah */ points to the wrong section, then the software should fix it. That's the ideal complete solution, but any partial enhancement that just addressed a subset of all the editing scenarios would be an improvement.
Feb 21 2016
You don't need to overthink this. Nobody is asking for an extra button.
Jan 17 2016
See the related task https://phabricator.wikimedia.org/T122884 which is basically asking for a NEWSECTIONLINK equivalent to the $wgExemptFromUserRobotsControl variable. If such a new "exempt from new-section-linking" variable is implemented, then VisualEditor should also honor that and not offer to set or remove these behavior switches in namespaces where they are disabled.
As I said on the VE feedback page "Bonus points if VisualEditor automatically removes attempts to set INDEX in $wgExemptFromUserRobotsControl namespaces, as I'd like AWB to do as well, if it doesn't already. " In other words, rather than "allow VE users to remove an existing INDEX/NOINDEX in cases where it is ignored", VE should *just do it*
Jan 16 2016
VisualEditor should obey the $wgExemptFromUserRobotsControl variable. In namespaces that this is set to disable, it should not even offer the end-users the opportunity to click any buttons related to indexing. Keep it as simple as possible for the user.
Jan 2 2016
Dec 18 2015
Thanks Ricordisamoa, for linking T67989. Well this is interesting. Maybe this javascript can be leveraged to complete this task?
https://de.wikipedia.org/wiki/Benutzer:Perhelion/sectionSummary
https://de.wikipedia.org/wiki/Benutzer:Perhelion/sectionSummary.js
Just wondering why a patch submitted for a code review has been apparently just sitting there, not reviewed for over a year now. Can someone explain the status of this. Is it normal for patches to wait over a year to be reviewed?
https://gerrit.wikimedia.org/r/#/c/129095/
Dec 5 2015
Another nice to have enhancement related to this. If I edit a section, and change the section title, then change the title accordingly in the edit summary, e.g.:
https://en.wikipedia.org/w/index.php?title=List_of_minor_planets_named_after_places&diff=prev&oldid=693821412
Nov 23 2015
Nov 19 2015
In my ~18 year career as a programmer, I specialized in fixing old and crufty code. Very little of my work was greenfields-type development. I know the shiny-new stuff like Visual Editor is more fun to work on for most, but y'all need to have people on staff who have a talent for wading into cruft and fixing it without breaking things. And hopefully actually enjoy that kind of work. Personally, I think all developers should cut their teeth by demonstrating that they can do this type of task. You learn things by working on other people's code. I'd only let developers work in a greenfield after they demonstrated their abilities in the cruft. Note that here, I've taken over two bots and have them operating successfully without much downtime or drama. /soapbox
Nov 17 2015
The endorsement comment at https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Editing#Generate_automatic_summary_.2F.2A_blah_.2A.2F_when_I_manually_add_a_section_heading_when_editing makes a good point: "Having the wrong section indicated is worse than having no section indicated at all." See this diff: https://en.wikipedia.org/w/index.php?title=User_talk%3AWbm1058&type=revision&diff=691137594&oldid=691061620 I edited my talk page clicking "edit source" at the "Virginia Tech Project Invite" section, then my only addition was the "New section test" section. My exit summary should be →New section test , not →Virginia Tech Project Invite ... this is arguably a BUG, not just an enhancement request. I didn't actually change anything in the Virginia Tech Project Invite section at all!
Actually, on second thought, if text is edited in more than one section at the same level, then it's no longer a "section edit" but a full article edit, and there should be no section link in the edit summary. But if a new section is appended at the end which includes sub-sections of that section, then the edit summary should link to the new section added, not one of its subs.
The simplest enhancement would be to simply look for the equivalent of clicking "New section" on a talk page, and make it work the same way that does. i.e. the diff for the edit just shows additional text being appended to the bottom of the page, *and* the beginning string of that text is recognized as a section header: A series of === followed by text followed by a series of the same number of ===. In the rare case that a section header exceeds the summary limit, just truncate it. I tested on my talk page and found that I could exceed the maximum in the box for entering the section header in the "new section" interface, and indeed it was truncated. Practically speaking, I have never seen a section header so long that it maxed out the summary limit.
https://en.wikipedia.org/w/index.php?title=User_talk:Wbm1058&offset=20151117033000&action=history
Nov 16 2015
Please... after six years sitting here growing cobwebs, please bump this, what seems to be a relatively simple task per Brion, up on the priorities list. If the edit appends text to the end of a page, and begins with a section header (any number of equal signs followed by text followed by the same number of equal signs) then automatically pre-populate the edit summary with that text. Doesn't on the face of it seem like this should be hard to implement.
Sep 24 2015
I've been told that https://en.wikipedia.org/wiki/Template:RMassist no longer is prepopulating the "reason" field; though I haven't looked at it myself, this seems to confirm "you lose whatever you've previously written in the "reason" field" above. Please back off this change until you fix this. Thanks.
May 17 2015
Is it possible to change the DESCRIPTION at the top of this page?