Now fixed along with T140960.

Instead, the "Open Page Curation" link will disappear altogether following T320922.

I have readded the Regression tag. It turns out that this is in fact a regression after all.

I suspect that the cause for this is the same as the one for T315591. If the cause turns out to be the same for both, then you may create a new task documenting the cause and merge both tasks into there.

I suspect that the cause for this is the same as the one for T316490. If the cause turns out to be the same for both, then you may create a new task documenting the cause and merge both tasks into there.

Mannan Wani (before it was draftified) also did not get added to the queue even though it was undeleted by a non-autopatrolled admin (Jay). The problem occurs regardless of whether the undeleter has autopatrol rights or not.

In T296035#8072781, @Jdforrester-WMF wrote:

In T296035#8072525, @GeoffreyT2000 wrote:

In T296035#8072424, @Jdforrester-WMF wrote:

In T296035#7590148, @GeoffreyT2000 wrote:

I have created https://www.thetestwiki.org/wiki/T296035 and https://en.wikipedia.org/wiki/User:GeoffreyT2000/T296035 on The Test Wiki and the English Wikipedia respectively to test the difference. Before moving, my edit counts were 94 and 41,894 respectively. After moving, my edit counts increased to 95 and 41,896 respectively. Clearly, moving a page used to increase the user's edit count by 1 (and The Test Wiki still uses an older version of MediaWiki), but now (in MediaWiki 1.38) the user's edit count is increased by 2.

So previously there was a bug, and that was fixed, but you want it reverted? Can you explain in more detail why? Your commit's comment justifying the change (claiming that after the fix it will count as two edits, not three) is at odds with your comments here in Phabricator.

There has never been a "bug". The behavior prior to the PageUpdater change has always been to increment the edit count by 1 for each move, with no additional increment for the redirect.

That definitely sounds like a bug to me; two entries in RecentChanges but only one edit increment. Clearly, you think otherwise.

Now, with PageUpdater being used to create the redirect, PageUpdater will also increment the edit count for the redirect. The correct behavior is to treat the null edit and the redirect as the same move, not as separate edits, when updating the edit count. So, the original change actually introduced a bug, not fixed one.

Right, so even though you say there's a bug in incrementing by 2 instead of 1, your changes don't fix it, but instead fix a different one, of incrementing by 3 instead of 2?

In T296035#8072424, @Jdforrester-WMF wrote:

In T296035#7590148, @GeoffreyT2000 wrote:

I have created https://www.thetestwiki.org/wiki/T296035 and https://en.wikipedia.org/wiki/User:GeoffreyT2000/T296035 on The Test Wiki and the English Wikipedia respectively to test the difference. Before moving, my edit counts were 94 and 41,894 respectively. After moving, my edit counts increased to 95 and 41,896 respectively. Clearly, moving a page used to increase the user's edit count by 1 (and The Test Wiki still uses an older version of MediaWiki), but now (in MediaWiki 1.38) the user's edit count is increased by 2.

So previously there was a bug, and that was fixed, but you want it reverted? Can you explain in more detail why? Your commit's comment justifying the change (claiming that after the fix it will count as two edits, not three) is at odds with your comments here in Phabricator.

Let's make this a blocker for MW 1.39. If the change gets merged in master, then I will backport it to 1.38.

This would require modifying LinksDeletionUpdate.php to no longer have $rcIdsForTitle.

Still not fixed after several months.

Oh, I now see why the change was made. It was made to unofficially fix T297754 (at least on Wikimedia wikis), and now the fix has been officially implemented in MediaWiki.

I have removed the "Regression" tag and updated the description to say that it specifically affects Wikimedia wikis.

Could anyone confirm this on a test installation of MediaWiki 1.38 (as yet unreleased) without the "Linter" extension installed? My guess is that https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Linter/+/755817 causes this on wikis with the extension installed.

I have created https://www.thetestwiki.org/wiki/T296035 and https://en.wikipedia.org/wiki/User:GeoffreyT2000/T296035 on The Test Wiki and the English Wikipedia respectively to test the difference. Before moving, my edit counts were 94 and 41,894 respectively. After moving, my edit counts increased to 95 and 41,896 respectively. Clearly, moving a page used to increase the user's edit count by 1 (and The Test Wiki still uses an older version of MediaWiki), but now (in MediaWiki 1.38) the user's edit count is increased by 2.

Wikipedia's 21st birthday is a month from today (January 15, 2022). Is that what you mean by "Wikipedia Birthday 2022"?

In T291967#7485626, @Pchelolo wrote:

Not on Friday unfortunately. No deployments on Fridays.

So then, we would have to wait until Monday, November 8 before we could backport this to 1.38.0-wmf.7.

@Pchelolo Could you cherry-pick (backport) the patch to 1.38.0-wmf.7 as well?

I have added another example reported by NadVolum.

Adding relevant subscribers from T291677 (@Legoktm and @Pchelolo).

The users were blocked before the user pages were created, so the block log entry that would appear on Special:RecentChangesLinked actually does not appear because its rc_cur_id is zero. Special:RecentChangesLinked checks for recent changes where the rc_cur_id matches the page ID of one of the pages in a category.

@mdipietro No, I still could not stop https://quarry.wmcloud.org/query/53420 or https://quarry.wmcloud.org/query/56363.

I have reopened this task because it appears that redirects from moves are again not tagged as new redirects. The first affected move on the English Wikipedia was the move from Bjarne Hansen to Bjarne Hansen (art director) (and the redirect has since became a disambiguation page, but that doesn't matter).

Now, this appears to have reintroduced T184117.

It seems that T291677 has reintroduced the problem identified here.

After T291689 is resolved, one could then instead do the following: