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:

In T137984#2391020, @PleaseStand wrote:

In T137984#2390918, @PleaseStand wrote:

Here is one possible way to count external links:

Step 3:

37133 + 29 = 37162 external links on fywiki, in all namespaces

In T137984#2390918, @PleaseStand wrote:

Here is one possible way to count external links:

In T137984#2390918, @PleaseStand wrote:

Here is one possible way to count external links:

In T137984#2388013, @Nemo_bis wrote:

looking for "http" may exclude protocol-relative links (as well as links to other protocols, although these are rare)

In T137642#2386876, @PleaseStand wrote:

(FlaggedRevs's Special:UnreviewedPages [...] it's already broken because sort keys, as stored in the database, are not well-formed UTF-8 strings that are in NFC and contain only characters allowed by MediaWiki. [...])

In T137642#2386876, @PleaseStand wrote:

the lack of proper handling of duplicate sort keys

In T137642#2374991, @Smalyshev wrote:

Stripping it may be ok for newer , but may present an issue to those running older PHP/HHVM versions. Depends on how exactly the keys are used - what the lifecycle is, I guess.

Already fixed in rMWb6487447463de476.

Per T130692, the cl_collation_ext index was added to Wikimedia databases for use by updateCollation.php. @jcrespo, has the old cl_collation index been removed everywhere, including on the sites that the new index had already been added to? If so, this task can be closed.

In T86096#2322878, @PleaseStand wrote:

This might result in inconsistent normalization when some inputs contain invalid UTF-8 sequences yet do not contain any character having, according to Unicode 6.0, a non-zero canonical combining class or an NFC_QC value of No or Maybe.

In T86096#2322775, @Anomie wrote:

I'd guess it's probably not a blocker since we probably use the intl extension rather than those data tables on the cluster, and the same for the Scribunto bits. So it's probably more of a cleanliness thing.

Florian's change was abandoned and not merged, so reopening.

The patch I uploaded fixes the reported issue by removing the document.write() wrapper around the site notice HTML. However, there is a concern that this would cause the site notice to be indexed and displayed within search engine snippets. I do not know of a way I can confidently avoid this problem.

In T121793#2067431, @Foxtrott wrote:

I did some mockups of the various possibilities to get an idea of what we are talking about.

In T85696#1874397, @aaron wrote:

In T85696#1874387, @jcrespo wrote:

the recount method gets a shared lock on all the categorylinks entries for that category

That is worrying- with InnoDB, while inside a transaction, you do not need to lock the rows- it should get consistent reads automatically.

Without locking, pages getting added and removed from the category while the SELECT gets the new counts will not be counted correctly.

The packagist page https://packagist.org/packages/wikimedia/ip-set has 1.0 and 1.0.1 listed. I am not sure how from where they come from.

In T58041#2045279, @Bawolff wrote:

The best solution is probably to add an index on (cl_collation, cl_to, cl_type, cl_from)

I added the 1.27 PHP compatibility information (diff), though have not yet reviewed the existing information for accuracy. I have not added HHVM information because it is not clear what the minimum supported version of HHVM is; RELEASE-NOTES-1.27 is currently inconsistent on the matter.

In T126495#2019792, @BBlack wrote:

Circling back around to this and looking again: of course it's possible that a better answer here is to refactor recOptimize and recCompress to use loops in place of recursion. In theory, recursive things can always be rewritten as loops that maintain some kind of state-stack variable, e.g. an array stack that grows by one entry for each virtual level of recursion in the loop.

The upside is it could remove the constraint that using this module requires setting a special interpreter/engine config variable in the common case. The primary potential downside is that the code might get more-unreadable (and it's already pretty bad). The other potential fallout is of course the perf impact of that refactor is an unknown, but I'd expect perf improvement, and in the constructor case perf isn't as important as it is in match()

In T84857#1937473, @Cpiral wrote:

Finding 0 now works. For example:
0 prefix:mathie shows the 68 of the 183 pages in that prefix.

Option #1 was implemented in 4479c9f309c0.

In T108811#1877832, @Arkanosis wrote:

@Jules78120 reported an issue with MediaWiki:AnonNotice on the French Wikipedia today, where the notice was added at the bottom left of the page and not at the top.

Could this be related to the use of document.write as well?

See also T54253.