Change #1170221 had a related patch set uploaded (by Gerrit maintenance bot; author: Gerrit maintenance bot):

[analytics/refinery@master] Add zgh.wiktionary to pageview allowlist

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

I have verified that the code changes have been reverted (User-related link colors have been removed).
QA was completed for this ticket using Test wiki 1.45.0-wmf.9 (a9e4ca5) and 1.45.0-wmf.10 (06dce30), and localhost 1.45.0-alpha (1ba8f04).
Thank you @Tchanders.

@ABreault-WMF -- I took a look at the diff. It's incredibly hard to parse though, given changes to formatting and wikitext nuance. I don't think it would actually be useful to a customer trying to figure out what changed so they can decide whether or not they are safe to upgrade. Do y'all have actual spec files that we could compare or something? Or are the wikis the only place specs are described?

In T398952#10999202, @Tchanders wrote:

In T398952#10994537, @Niharika wrote:

4 Grey-background link styles are sometimes applied to the new-messages-from-users bubble - on wikis without Notifications (Echo) installed, if you leave a message on a temporary account's talk page, the person behind that temporary account will see the link styling applied to the "a new message" and "last change" links within this bubble when they're on a page history/user contributions page, but (seemingly) not if they're on most other pages. -- "a new message" and "last change" links should have the grey background.

@Niharika Should this say instead that they should not have the grey background? Just asking because this seems to be the one example of a link having a grey background that isn't a user link.

FYI: For me the (static) map now renders in the iOS app.

Change #1167859 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] ZObjectContentHandler::fillParserOutput: Add labels as parser page properties

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

In T398952#10994537, @Niharika wrote:

4 Grey-background link styles are sometimes applied to the new-messages-from-users bubble - on wikis without Notifications (Echo) installed, if you leave a message on a temporary account's talk page, the person behind that temporary account will see the link styling applied to the "a new message" and "last change" links within this bubble when they're on a page history/user contributions page, but (seemingly) not if they're on most other pages. -- "a new message" and "last change" links should have the grey background.

In T398952#10995352, @Tchanders wrote:

@Esanders That makes sense to me.

we should style all contrib links (links to [[Special:Contributions/<tempuser>]] with any label) and user page links in the content area, as this will give us a reasonably low false-positive and false-negative rate.

Noting for @Niharika that this would mean styling links that have the temp user name as text, but link to the user page rather than the contribs page (as happens with @ mentions). Does this sound OK?

In T399197#10995222, @HCoplin-WMF wrote:

@ABreault-WMF -- was v1.x formally deprecated? If so, when was it, and what does the announcement process look like? I see we're on 2.7 now, but I'd like to have something we can point to with the comms about the versioning changes.

@Esanders That makes sense to me.

For non article content links, we should maintain the status quo before this patch which is to apply the mw-tempuserlink class to anything that currently has mw-userlink and is for a temp user.

@ABreault-WMF -- was v1.x formally deprecated? If so, when was it, and what does the announcement process look like? I see we're on 2.7 now, but I'd like to have something we can point to with the comms about the versioning changes.

Possible replication:

Template:Ta

<includeonly>{|
<div>
</includeonly>

Template:Tb

<includeonly>
</div>|}
</includeonly>

Page

{{Ta}}
řaa
<table>
<tr><td>
a
</tr></td>
</table>
{{Tb}}

Letter ř in this case can be replace with any 2 byte utf-8 character.
Error stack trace:

Emm... I think the correct way should be getWikitextForTransclusion instead of $wgNonincludableNamespaces.

In T398952#10994742, @A_smart_kitten wrote:

Question that came to mind: What if a temporary account is pinged by another user in a discussion (e.g. by using @[[User:~2025-3105|~2025-3105]])? Should the temporary account username in the ping have a grey background?
& what if an editor pings them in a way such as Thank [[User:~2025-3105|you]] for the question! [...]? Would/should the word "you" have a grey background in this context?

In T399081#10992274, @Winston_Sung wrote:

I would say WikiLambda ZObject pages are actually JSON pages (not something like Wikibase entity pages) and therefore not something really should be added to $wgNonincludableNamespaces.

https://www.wikifunctions.org/wiki/Z4?action=raw

vs.

https://www.wikidata.org/wiki/Property:P31?action=raw

Question that came to mind: What if a temporary account is pinged by another user in a discussion (e.g. by using @[[User:~2025-3105|~2025-3105]])? Should the temporary account username in the ping have a grey background?

Generally speaking we only want the grey background for temporary account usernames and not on other links, even if they play a supporting role.

Parsoid generally doesn't protect against this because we assume the input is valid UTF-8 and sanitized before it is given to the parser. It appears that perhaps the REST API needs to call UtfNormal\Validator::cleanUp on its input at some point before it is given to Parsoid.

Removing the profile would mean they are willing to accept any breaking changes we may make. The point of content negotiation was
that we were going to give a grace period between major version bumps for clients to upgrade. I'm not sure how well we've adhered to semver though and if the client is still on 1.2.1 then they haven't been following any announcements about version upgrades anyways.

In T399197#10993182, @HCoplin-WMF wrote:

@ABreault-WMF is right. They confirmed they're getting a 406.

@ABreault-WMF is right. They confirmed they're getting a 406. The error code was not reported in the initial response, so I assumed 500 (especially after messing around and being able to make 500s trigger). Does this mean the fix would be to either ask them to remove the spec version, or add support for specifying a spec version?

In T399081#10992274, @Winston_Sung wrote:

I would say WikiLambda ZObject pages are actually JSON pages (not something like Wikibase entity pages) and therefore not something really should be added to $wgNonincludableNamespaces.

https://www.wikifunctions.org/wiki/Z4?action=raw

vs.

https://www.wikidata.org/wiki/Property:P31?action=raw

In T399197#10992314, @daniel wrote:

I am seeing another kind of failure on this endpoint, starting on the 18th, e.g. reqId c69c2570-2213-4e2e-901d-357481cd5ef9:

Error message: PHP Warning: Uninitialized string offset 39

Stack trace:

from /srv/mediawiki/php-1.45.0-wmf.6/vendor/wikimedia/wikipeg/src/PEGParserBase.php(144)

In T399197#10992215, @daniel wrote:

I found an instance on logstash, requestId 6d0f6eda-1e06-4446-ab0a-ebb59b65783a:

The error message is TypeError: normalizer_normalize(): Argument #1 ($string) must be of type string, array given.

...

However, they are all from today - perhaps from someone trying to reproduce this issue, and triggering another issue...

Not sure how relevant this is to the current issue but Parsoid can't generate a semantically equivalent version for that. This should at least be returning a 406

Steps to reproduce the 500 error in the REST framework:

• Configure the following header parameters in Postman:
  • Accept-Charset=utf-8
  • Accept=text/html
  • Content-Type=application/x-www-form-urlencoded
  • Profile=https://www.mediawiki.org/wiki/Specs/HTML/1.2.1

Analysis of the TypeError:

Tagging Content-Transform-Team for the parsoid issue. @cscott any thoughts?