Change #1087431 merged by jenkins-bot:

[mediawiki/extensions/Kartographer@master] Different file name for virtual vs. physical externalLinks.json

https://gerrit.wikimedia.org/r/1087431

Indeed, it’s red for me as well. However, my link turned blue within a minute on beta cluster (without doing any purge or null edit), so whatever the issue is, it seems to depend on multiple things – which isn’t surprising, given it’s a caching issue. It may also be that the bug has been fixed in the meantime (your example is three days old), although I tried to check out rMWf7f41ea950d581f3c78320d8d63f5465d960cb82 (the then-current master at 21:53, 7 November 2024 CET), and the new link still turned blue within a minute.

It was not visible for admins before this report. (I am admin in fiwiki)

Code in setActionTabs says show this only if no protection tab present...

Correct

Non-admins see this link?
Administrators can click "Protect".

In T379218#10307462, @Tacsipacsi wrote:

• On beta cluster, as Tacsipacsi (a reviewer / Sichter):
  • Added a link from Test1 to Test_42, the edit was reviewed, as expected (since the previous version was reviewed);
  • Created Test_42, which unexpectedly remained unreviewed (this is the originally reported bug);
  • Refreshed Test1, and the link turned blue, as expected (i.e. the second bug didn’t come up).

In T379218#10307172, @Zache wrote:

There was one user who reported that after creating page from the red link the link in the original page doesn't change to blue. User said that he tried to purge the page cache and it didn't help. ( not sure if this was a single insident or if there was multiple ones )

The problem described by Ipr1 was that when adding a template to page which is included from another page (in this case creating a help page for a template) page doesn't update by itself without doing a purge anymore. (this can be replicated )

New pages are unreviewed. Blue links stay red.
Huge problem in deWiki. It is probably a big problem in many wikis. Please fix this technical problem.

In T379218#10307172, @Zache wrote:

There was one user who reported that after creating page from the red link the link in the original page doesn't change to blue. User said that he tried to purge the page cache and it didn't help. ( not sure if this was a single insident or if there was multiple ones )

There was one user who reported that after creating page from the red link the link in the original page doesn't change to blue. User said that he tried to purge the page cache and it didn't help. ( not sure if this was a single insident or if there was multiple ones )

In T379218#10307127, @Ipr1 wrote:

With the recent update there are other problems noticed that pages are not updating correctly after changes.

In theory of course we could. In practice rolling back the train on a Monday is very rare (deployments on weekends are even rarer). And it was already called not a blocker at T375661#10301176

With the recent update there are other problems noticed that pages are not updating correctly after changes.
Again, could you rollback the changes?

T379152 is not a problem because FlaggedRevs doesn’t touch tags, but what I noticed is that the hook is called with a fresh WikiPage instance, so data on the ongoing edit (which is used by FlaggedRevs) is lost – this may be the culprit.

Could you rollback to previous version if there is no fix available soon?

Change #1088696 had a related patch set uploaded (by C. Scott Ananian; author: C. Scott Ananian):

[mediawiki/core@master] Provide a way for Messages to add metadata to the output page

https://gerrit.wikimedia.org/r/1088696

Change #1088672 had a related patch set uploaded (by Wargo; author: Wargo):

[mediawiki/extensions/FlaggedRevs@master] Use RevisionRecord provided by onPageMoveComplete

https://gerrit.wikimedia.org/r/1088672

The order of hook -> event processing is not clear (at least for me) in DomainEventDispatcher. Make sure hook is run first, then ChangeTrackingEventIngress process. Second, $event->getTags() can't be modified (as far as I know), so where the modified by hooks array is finally written and can be read at the end of RevisionFromEditComplete hookusers processing?

As @matmarex pointed out in the patch, the fixed with [x] button (as opposed to 1/7th width) is also used in the wikitext editor, so we should fix that as well.

The extension is using the RevisionFromEditComplete hook. With T379152 there is an report about problems with change 5febca16489246a326e3b18471c8101dc3dd9358 (DomainEventDispatcher), this sounds very related to that task. The patch set is also listed as risky on the train task T375661

Change #1088643 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/skins/MinervaNeue@master] Follow-up Iefa1fee9c: Remove bold styling from all non-href links

https://gerrit.wikimedia.org/r/1088643

If anyone is interested in that, I've created a bot to automatically review moved and created pages (this is the bot that Wargo talks about above). It works in real time, based on EventStreams, so as to make an impression that this issue is no longer present. (Review log from plwiki).

In T379218#10304174, @binbot wrote:

For the time the issue will be corrected, I hacked a little scipt that reviews new pages that were edited only by trusted users. Please forward the information to the bot owners in your wiki.
https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:BinBot/huwiki/temp_review.py

For the time the issue will be corrected, I hacked a little scipt that reviews new pages that were edited only by trusted users. Please forward the information to the bot owners in your wiki.
https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:BinBot/huwiki/temp_review.py

New info.
If bot reviews these edits, they are marked as... autoreviewed instead of reviewed by <username>.

Trying to bring this to the attention of someone who is able to help. There is a related pending patch in T379217

Change #1088406 merged by jenkins-bot:

[mediawiki/extensions/Hashtags@master] Add rcsave hook to work around T379152

https://gerrit.wikimedia.org/r/1088406

Change #1088406 had a related patch set uploaded (by Brian Wolff; author: Brian Wolff):

[mediawiki/extensions/Hashtags@master] Add rcsave hook to work around T379152

https://gerrit.wikimedia.org/r/1088406

Yeah, InfoChip seems the way to go. Although I think we should override its background color to be the old shade. Perhaps we can declare a CSS var --background-color-warning-strong and then use that.