In T157670#8627277, @Legoktm wrote:

(I'm assuming that all pages since Oct. 2022 have been updated since and it's not just a bad random sample.)

As I've pointed out previously in this Phab, except for the NULL Sweet 16 and the purge-resistant Super 6.

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.

In T319568#8589717, @komla wrote:

In T319568#8550874, @Wbm1058 wrote:

If anyone figures out how to use a wrapper script, please let me know how you did it. Thanks

Lacking an answer there, I'm waiting for T301901 too.

T301901 has been resolved now. Are you able to proceed now?

Swagger is a suite of tools for API developers from SmartBear Software and a former specification upon which the OpenAPI Specification is based.

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.

Dear komla and nskaggs,

Per the documentation:

$ toolforge-jobs run refreshlinks--k8s --command "php ./php/refreshlinks.php > ./logs/refreshlinks--k8s.log" --image tf-php74 --no-filelog

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?

In T182867#3889857, @Niharika wrote:

The probable reason is that your bot only logs in and doesn't make any edits. The IP(s) don't get recorded in the CheckUser table that way and every log in is treated as being from a "new" IP. Unfortunately I don't have a solution for you except for either turning off the notifications for this feature (you don't have to turn off notifications for everything) or making a few null edits (on different logins) from the bot on a sandbox page. That'd make sure the few rotating IPs get registered in checkuser and are no longer "new".

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.

I see this item is still open, though no comments in three years.

In T157670#6785924, @tstarling wrote:

Here's what page_links_updated looks like on enwiki now. I added page lengths to give an idea of the work involved in parsing them.

MariaDB [enwiki]> select left(page_links_updated,4) as year,count(*),avg(page_len),sum(page_len) from page where page_random between 0.001 and 0.002 group by year;
+------+----------+---------------+---------------+
| year | count(*) | avg(page_len) | sum(page_len) |
+------+----------+---------------+---------------+
| NULL |     2821 |      719.9596 |       2031006 |
| 2010 |        5 |      145.8000 |           729 |
| 2011 |        9 |      116.0000 |          1044 |
| 2012 |       11 |      111.1818 |          1223 |
| 2013 |       16 |       85.2500 |          1364 |
| 2014 |     1139 |     1619.6558 |       1844788 |
| 2015 |     1528 |     1383.2808 |       2113653 |
| 2016 |     1149 |     1116.9634 |       1283391 |
| 2017 |     1846 |     1817.3922 |       3354906 |
| 2018 |     1507 |     2056.5448 |       3099213 |
| 2019 |     6557 |      938.2196 |       6151906 |
| 2020 |    23928 |     2034.6179 |      48684337 |
| 2021 |    12018 |     5909.8995 |      71025172 |
+------+----------+---------------+---------------+
13 rows in set (0.78 sec)

So if we refreshed up to 2020-01-01, including nulls, that would be about 16.6M pages and 18.5 GB of wikitext.

A volunteer to help me migrate my English Wikipedia bot request for approval would be appreciated.

In T157670#3398429, @Jdforrester-WMF wrote:

In T157670#3395486, @Jonesey95 wrote:

It would be great to make some progress on this task. On en.WP, Category:Pages using ISBN magic links is still populating, seven months after the MediaWiki code change that created it. This bug is blocking implementation of things like the Tidy conversion and removal of magic links.

This is not really a task you make progress on, I'm afraid. It's more a "Rain may cause flooding" task, with some issue-amelioration sub-tasks proposed underneath. It certainly won't ever be "done", unless we radically re-think what MediaWiki is and re-write it. Can you link to the tasks you think are blocked by this so we can look for a way around this?

Bot request for approval

Bot request for approval

What's up? I just tried querying the database, which has been working for me for months, and see a query failed error:

Thanks. That does clarify things at a high level; I'm still foggy on the details.

What is the difference between refreshLinks.php (manual) and purgePage.php (manual)?

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.

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}}.

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).

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.

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

In T157670#7785047, @TheDJ wrote:

Just to make sure this is documented for WMF engineers. Apparently there is a community bot running to slowly null edit 2.7mil enwiki pages that had never had their page_links_updated value set yet.

https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1077662724#A_page_is_populating_a_hidden_maintenance_category,_but_the_category_is_empty!

I like

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.

In T254649#6851414, @Beetstra wrote:

Would it be an option to have all wiki pages be custom set by the wiki:
$whereIsSpamBlacklist=Wikipedia:here?

See the closed discussion at Wikipedia talk:Spam blacklist §Requested move 10 February 2021

In T235957#5927586, @Ahecht wrote:

Why does {{REVISIONID}} now return blank when substed? Shouldn't it at least return '-'?

What is the accommodation for cases where the revision ID needs to be inserted into a URL such as in Template:Db-g12 or Template:RMassist/core?

A solution was implemented on English Wikipedia that removes undesirable Side Effect #1 but apparently also removes the desirable side effect(s) as well.

In T239277#6441033, @DannyS712 wrote:

In T239277#6441015, @Xaosflux wrote:

Are there any default (or wmf-specific) groups this will be added to, or will WMF communities need to request this be added to groups as needed?

No groups have it yet. I was envisioning this as a right for enwiki's page mover group, and was planning to start a discussion for that at some point once the train reaches enwiki

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.

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.

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

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

In T45911#530431, @Graham87 wrote:

This bug was discussed in this thread on the technical village pump:
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Bug_in_undeleting_2_pages_with_many_edits

Already done
https://en.wikipedia.org/wiki/User_talk:Anomie#Great_work!

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.

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

In T210739#4874448, @greg wrote:

In T210739#4855182, @Anomie wrote:

Probably downgrade it from UBN, since it seems it mostly stopped happening:

OK, I just got this error again: Internal error

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.

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?

In T200391#4807826, @Reedy wrote:

In T200391#4807816, @Xaosflux wrote:

Can a batch fix of moving them all to Project/Project_talk just be done?

I wonder if we should just re-add the EducationProgram NS in mw-config to the Wikis that had it enabled...

https://en.wikipedia.org/w/api.php?action=query&pageids=38654465&prop=info%7Crevisions&rvprop=content confirms the content type isn't anything that depends on the extension, it's just wikitext

See https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Special_pages_for_the_Education_Program_%E2%80%93_what_happened_to_them?

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.

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?

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

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.

Also https://phabricator.wikimedia.org/T159403

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Wikidata_alert_is_sticky

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.

You don't need to overthink this. Nobody is asking for an extra button.

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*

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.

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/

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

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

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

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.

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.

Is it possible to change the DESCRIPTION at the top of this page?