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?