@awight I think this request is covered by something or another in the T370027: [Epic] Parsoid CSS counter reset footnote numbering mechanism should be dropped in favor of plain text pile?

Cross-referencing a few other pipetrick-related bugs, in case someone decides to do some work on pipetrick again:

• T9264: Magic word to give Page Title as if pipe-trick performed on it
• T30730: pipe trick does not work if link contains a target (aka [[mw:foo#bar|]] isn't expanded)
• T160389: Incorrect behavior for pipe trick with underscore

Change #1080320 merged by jenkins-bot:

[mediawiki/core@master] live preview: Do not add edit/view-source link for special pages

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

Change #1080323 merged by jenkins-bot:

[mediawiki/core@master] TemplatesOnThisPage: Do not show non-functional link for special pages

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

I couldn't reproduce this at first – special page transclusion does not result in those links being shown. I eventually figured out that the links are produced by Scribunto's mw.title getContent() method. I think that's the real bug here, and I filed a task about it: T377530: Scribunto mw.title getContent() method can record templatelinks to special pages (but I still approved your patches here, as it seems reasonable to handle this case – maybe recording special page transclusions is made to work one day, or maybe no one ever fixes that Scribunto bug).

Change #1080323 had a related patch set uploaded (by Ammarpad; author: Ammarpad):

[mediawiki/core@master] TemplatesOnThisPage: Do not show non-functional link for special pages

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

I think we also need to duplicate this for the non-live preview version. There's no error in that case, but a non-functional 'view-soure' link is always shown.

Change #1080320 had a related patch set uploaded (by Ammarpad; author: Ammarpad):

[mediawiki/core@master] live preview: Do not add edit/view-source link for special pages

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

Anything left to do here?

the category existence check has already happened on the first server loading of the edit page which is the only load for live preview

The parse API should return ext.gadget.Calculator as one of the modules.

I believe the problem is the module presence (to be eligible for return) is dependent on category existence, but the category existence check has already happened on the first server loading of the edit page which is the only load for live preview. You can request the parsing API to return the categories of the page blindly, but then you really have to parse that info (maybe in MediaWiki-extensions-Gadgets) and dynamically load the module if it qualifies.

In T376647#10215813, @CCiufo-WMF wrote:

Would https://codesearch.wmcloud.org/deployed/?q=cdx-message be comprehensive?

Would https://codesearch.wmcloud.org/deployed/?q=cdx-message be comprehensive?

Thanks for the writeup @Krinkle, I think you've identified an important piece that wasn't directly considered when these messages boxes were ported to use the Codex styles: that historically on the wikis, the color of a message has been used in different ways, often to signal importance/urgency, rather than a semantic connection to a specific type of message (error, warning, success, notice). Maybe that should change, but it would probably need to be done on a case-by-case basis for each message so that a decision can be made depending on the context. Either way, the presence of the icons is clearly unexpected based on the existing designs of many these messages.

In T376647#10211160, @DTorsani-WMF wrote:

The use of an icon in addition to the color of the message allows for a similar level of cognitive load, as long as the icon is accessible, […]

Another example:
https://wikitech.wikimedia.org/w/index.php?title=User:Krinkle/common.js&action=edit

Thanks @DTorsani-WMF, sounds like the icon will be accessible if we choose to keep using it in this way.

The changes proposed in T376641 as a result of T371119 would introduce a very minor adjustment to the 500 value of all colors, which will serve as the status icon colors in light mode, ensuring sufficient contrast on any background that Codex supplies as tokens.

I think one thing we need to look into is whether we need to support status messages without icons. It does feel a bit restrictive to me that an icon is required.

This one is fixed visually - I am seeing the inline Codex styles and block styles.
There is follow up work to not rely on Skin.php to load it - I'm going to resolve this and track that work in T375287.

I just noticed that when viewing source of a page that is edit-protected, the sections are not made collapsible.

Stalling until we have T375287 in place so can identify other pages.

Change #1074471 merged by jenkins-bot:

[mediawiki/core@master] Add Codex message box style module to pages that need it

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

Change #1074471 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Style Codex message boxes on edit pages

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