I added a note about this problem to https://www.mediawiki.org/wiki/Gerrit/Cross-repo_dependencies, as this is something I ran into while working on T326454. I hope I described it correctly.

PEAR Mail 1.5.1 was released a couple days ago, so we can now apply this eight month old bug fix to MediaWiki.

In T337700#8900237, @PleaseStand wrote:

HistoryBlobCurStub objects were added during the 1.5 upgrade for each revision in the cur table (the current revision of each page that existed at the time of the upgrade). When adding such rows to the text table, the upgrade1_5.php script would set old_flags to 'object' (leaving out the 'utf-8' flag) and would not convert the character encoding. (source)

In T337700#8900028, @Ladsgroup wrote:

Thanks for that. it didn't give me any error when I ran it :/ There might be something logically broken there :(

check-vars.php was removed; see T326292.

In T326800#8533792, @daniel wrote:

I think we can use the ./ prefix for paths relative tp cwd (and / for absolute), and otherwise make everything relative to maintenance.

In T99268#8507896, @Tgr wrote:

This is great, but the new warning shown for old-style scripts is likely to mess up any automation and should be reverted IMO (or maybe it should try to detect whether it is writing to an interactive terminal).
Vagrant for example breaks quite spectacularly: T326522: Vagrant mediawiki::maintenance resource broken by new maintenance script output

I think these particular errors were fixed upstream several years ago, likely in https://github.com/pear/pear-core/commit/f50de8c32c56c1927deffac1869fb2b2014dae3f and https://github.com/pear/Mail/commit/b84fceecdfdaabddfb0391a9b50b5e688481f9a6.

The changes in mediawiki/core and operations/mediawiki-config have been merged. There were no other Codesearch results (outside of release notes) for this setting's name.

In T321467#8337824, @hashar wrote:

Maybe preg_split returns false based on certain user input?

In T320929#8323596, @Legoktm wrote:

@Urbanecm please clarify what part of this change do you want SRE to coordinate :)

This wikitext comes from the local message override at https://en.wikisource.org/w/index.php?title=MediaWiki:Pagetitle&action=edit. This code removes the namespace prefix from the HTML titles of pages in the Author (diff), Portal (diff), and Translation (diff) namespaces and corresponding talk namespaces, apparently so it won't appear in search engine (Google) results pages. This may have been done in order to avoid having to set $wgRestrictDisplayTitle to false (the default is true).

In T132104#8149544, @Dzahn wrote:

@Aklapper If the intention of this ticket was that the site is not hosted on Wordpress VIP anymore and instead becomes completely in-house again... no.. since wikimediafoundation.org itself is just another site on Wordpress VIP.

If the part that it is back in WMF DNS and not directly pointing to Wordpress VIP....when then our Apache cluster redirects it to the above counts .. then yes.

This bug appears to have been originally fixed in r11323 (69e2b7946c764901) and reintroduced during refactoring in f7f84dddb33ee4bd.

orphans.php was removed in 2ab5e5885702ca7486313619a88b012ced93ff53.

1.39.0-wmf.23 was deployed, and it appears to have fixed the reported problem on jawiki.

This likely was related to a prior file rename; see move log. In any case, the image_comment_temp table no longer exists; see T188132: Merge image_comment_temp table into the image table and T209591: Drop table image_comment_temp on all wikis.

My patch to MediaWiki appears to have fixed the reported problem on jawikivoyage. It is expected to be deployed to jawiki tomorrow at around 18:00 UTC (see deployment calendar) as part of 1.39.0-wmf.23.

While of course hex dumps would be helpful, I already did notice something:

Apparently, the SecurePoll tables (or at least the securepoll_elections table) didn't get created on blkwiki, and this is causing an error (on votewiki) that prevents editing polls. This needs to be fixed very soon because there is an upcoming board election. See T314006: Can't edit SecurePoll poll on votewiki (DBQueryError): Error 1146: Table 'blkwiki.securepoll_elections' doesn't exist.

In T314006#8112739, @jrbs wrote:

It depends how quickly SecurePoll can be installed on the new wiki (if that's necessary?), but perhaps there might be a way to have votewiki ignore blkwiki?

API query that shows the issue: https://ja.wikipedia.org/w/api.php?action=query&meta=siteinfo&formatversion=2&siprop=namespaces%7Cnamespacealiases

In T309753#8090373, @Zabe wrote:

In T309753#8089644, @jrbs wrote:

Other than Zabe's patch above, I believe this is now merged on production.

@Zabe, would you prefer we wait until this is merged as well before running these scripts? We are on a bit of a time pressure to get this piece of the election setup completed but nothing too major.

PleaseStand has taken care of getting the patch deployed, so there are no concerns from me.

In T106994#6773827, @Seb35 wrote:

I saw this bug, and my first analysis is that depending on the language (and particularly the number of bytes for the translation of the namespace "User") the 64 UTF-8 characters are sometimes splitted and the last character becomes invalid (e.g. 2 first bytes instead of 4 bytes).

After the 1.39.0-wmf.16 branch cut happened, @tstarling deployed a change to the AbuseFilter extension (see T212129). The change does not seem to have been merged on the new deployment branch though, only on master and wmf/1.39.0-wmf.15. Will it be necessary to merge this change into the new deployment branch, since apparently it is needed for a configuration change that was made in InitialiseSettings.php?

In T289798#7313559, @Legoktm wrote:

Oh, @PleaseStand, how would you prefer to be credited in the report and CVE? Username, real name, both?

In T289798#7312668, @Legoktm wrote:

Thanks for the fantastic report @PleaseStand, I'll start looking into this now. Just to clarify, have you already reached out to the Mailman security team about this? If not that's fine, I'll do that once I figure out what's going wrong...

CollationFa was removed in 5a21de8abb7f03e72a07d8578babc1835dff4a64, because it is no longer necessary.

Marking this resolved because I can't think of any other customizations that would have to be fixed.

In T141286#2691639, @PleaseStand wrote:

I believe I meant you should change .com-google-gerrit-client-diff-DiffTable_BinderImpl_GenCss_style-table to .com-google-gerrit-client-diff-DiffTable_BinderImpl_GenCss_style-table .CodeMirror. I did test this using Firefox Developer Tools, though not by editing GerritSite.css. (I do not have Gerrit installed locally.)

In T141286#2507172, @Paladox wrote:

@PleaseStand hi but we do

.com-google-gerrit-client-diff-DiffTable_BinderImpl_GenCss_style-difftable .CodeMirror pre span {
white-space: pre-wrap !important;
}

with

.CodeMirror

Would you show me what css to use please from the above.

In T127355#2662119, @Aklapper wrote:

This has happened in the meantime, comparing https://www.mediawiki.org/w/index.php?title=Compatibility&oldid=2014764#PHP to https://www.mediawiki.org/w/index.php?title=Compatibility&oldid=2219846#PHP

The procedure to regenerate the captcha image set is documented at https://wikitech.wikimedia.org/wiki/Generating_CAPTCHAs

In T140864#2515298, @Nikerabbit wrote:

No issue for me on master / HHVM 3.4.13.

This was fixed in rMW8a5595f4bd4b904b.

In T141286#2500516, @Paladox wrote:

Hi ive uploaded two commits which should fix your issue, are you still having the same problem?

In T62677#2472387, @brion wrote:

Ok as far as I know there's no blockers, this patch just got lost in review. :( [...]

There should be no way this backtrace could have been generated unless the value of the constant INF is not greater than 0, and that should not happen.

In T137642#2410904, @Joe wrote:

@PleaseStand I think we can simply backport the patch to our current version of HHVM, by the way, in order to make the behaviour consistent. We won't need to remove the null byte then, AIUI.

In T137642#2398339, @PleaseStand wrote:

Or rather, trimming the null byte off in IcuCollation should address the major problem with CategoryViewer's pagination on frwiki.

In T137642#2398339, @PleaseStand wrote:

[...] The script would be to ensure that the duplicate sort key case is handled consistently throughout a site.

In T137642#2398325, @PleaseStand wrote:

[...] more reason to create a script that will quickly fix the issue.

In T137642#2398172, @tstarling wrote:

Could you not just do the update with some replication-safe equivalent of

UPDATE categorylinks SET cl_sortkey=LEFT(cl_sortkey, LENGTH(cl_sortkey)-1) WHERE cl_sortkey LIKE '%\0'

In T137984#2390918, @PleaseStand wrote:

Here is one possible way to count external links: