Page MenuHomePhabricator

Red link for talk pages is no longer rendered correctly in Vector
Open, In Progress, Needs TriagePublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

What happens?:

<li id="pt-mytalk" class="new mw-list-item"><a href="/wiki/User_talk:Stjn_(bot)" title="Your talk page (page does not exist) [Alt+n]" accesskey="n"><span>Talk</span></a></li>

What should have happened instead?:
.new CSS class should be on the link itself and not on the list item. Don’t know how recent it is but it is definitely a regression from something specifically for talk page links:

image.png (828×51 px, 5 KB)

Details

Event Timeline

Exact same thing happening in new Vector, too (also .new on <li> instead of <a>):

image.png (362×419 px, 16 KB)

stjn renamed this task from Red link for talk pages is no longer rendered correctly in Vector 2010 to Red link for talk pages is no longer rendered correctly in Vector.Jun 29 2026, 7:42 PM
stjn updated the task description. (Show Details)

Actually, not just Vector(s), same thing happening for https://en.wikipedia.org/wiki/Main_Page?useskin=monobook
If there’s a skin-agnostic skin issues tag, maybe needs a change to that. I guess that makes tracking down the issue simpler, though.

Change #1306415 had a related patch set uploaded (by Neriah; author: Neriah):

[mediawiki/core@master] Render missing user talk page links as redlinks

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

neriah changed the task status from Open to In Progress.Jun 29 2026, 9:04 PM
neriah claimed this task.
neriah subscribed.
Jdlrobson-WMF subscribed.

Could we do a git bisect and work out when exactly this broke (either accidentally or intentionally)?

My Gerrit-jitsu isn’t good enough for figuring out when it broke, but it is good enough to figure out that this code had looked like basically this since 2005 and initially worked the same for both links, both user and user talk:
https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+blame/ffe4025ef6e1ccdfe00dbbe2a6ccdca003f183d0/includes/SkinTemplate.php

$personal_urls['userpage'] = array(
    'text' => $this->username,
    'href' => &$this->userpageUrlDetails['href'],
    'class' => $this->userpageUrlDetails['exists']?false:'new',
    'active' => ( $this->userpageUrlDetails['href'] == $pageurl )
);
$usertalkUrlDetails = $this->makeTalkUrlDetails($this->userpage);
$personal_urls['mytalk'] = array(
    'text' => wfMsg('mytalk'),
    'href' => &$usertalkUrlDetails['href'],
    'class' => $usertalkUrlDetails['exists']?false:'new',
    'active' => ( $usertalkUrlDetails['href'] == $pageurl )
);

So whatever broke in the handling of both links (and it was broken, otherwise you wouldn’t have had to reset the link colour of red links to blue in Vector 2022, right?) has probably zero thought about it, and is much more likely to be an oversight either during rewrite of the skin system or somewhere else. Assigning .new to the list item instead of the link doesn’t scream intentional.

For instance,