In T114208#1710868, @demon wrote:

[...] the linked patch above to prevent this from happening again.

In T64371#680404, @scfc wrote:

Couldn't we abuse our Gerrit -> Bugzilla tool for that? If a changeset A is uploaded and it contains something looking like a SHA1/Gerrit Change-Id in the commit message referring to changeset B, add a comment to B that links to A.

Since rMWc63fde6797c2b6ba, this error would instead appear in the log as an DBUnexpectedError exception: "DB connection was already closed or the connection dropped." Though the question remains: In this case, how is mConn becoming a non-object, and why is the DatabaseMysqli object used afterward?

The memory leak from bitwise string operations (not hash_init) was fixed upstream, and the fix was deployed by Wikimedia a while ago (see T78727, T86813).

MediaWiki 1.21 is now an "Obsolete release" according to https://www.mediawiki.org/wiki/Version_lifecycle, so should this request be declined now?

In T39417#409059, @duplicatebug wrote:

Some ghost entries are left in template links, see bug 36195 for maintenance script to be run for that case.

See also T29849.

In T107289#1496075, @Legoktm wrote:

This is automatically done by Xml::encodeJsCall -> Xml::encodeJsVar -> FormatJson::encode( ..., ..., FormatJson::UTF8_OK ). I don't know if there is a specific reason for it...

Script needs to be rerun after T107632 is fixed.

In T106388#1469515, @Legoktm wrote:

AbuseFilter is already updating the text table AFAIS.

The patch was merged quite a while ago (as rMW559afbf6d3a92123), so is this bug now fixed?

The patch was merged, so was this issue fixed?

Some context:

The query runs to completion if I change "USE commonswiki;" to "USE commonswiki_p;" (http://quarry.wmflabs.org/query/4189). So is this a problem with Quarry?

The recent changes seem to have broken even Phabricator's Subversion viewer:

In T97929#1378946, @Krenair wrote:

Is that signed now? Unclear what the status of this request is.

Script appears to have run on s3, as evident on mediawikiwiki (before, after).

In T100908#1323513, @He7d3r wrote:

I can reproduce it by executing this in the console:

mw.loader.using( 'mediawiki.api.options' )
.done( function () {
    ( new mw.Api() )
    .saveOptions( {"nickname":"[[User:foobar|foobar]]","searchNs829":"1"} )
    .always( function ( a, b ) {
        console.log( 'error?', JSON.stringify( b.error ) );
    } );
} );

I think this is a bug in Preprocessor_DOM::expand() and Preprocessor_Hash::expand(). When the output type is Parser::OT_HTML (so $this->parser->ot['html'] is true), the PPFrame::RECOVER_COMMENTS flag has no effect.

I think I know what's causing the gmp_init() failures and will upload a fix for that bug.

In T97929#1262531, @chasemp wrote:

Sign here: <name - country> https://phabricator.wikimedia.org/L2

Today, the script did run on dewiki (in s5); see the query results linked from T98110.

This was proposed somewhere else already, but I couldn't find a report [...]

DBABagOStuff was removed in rMW736820f8f2dc6bcf (1.23.0).

Change was merged.

see T74003

The above change is in 1.25wmf24, which has been deployed to all Wikipedias. There may still be some performance issues, though the script should now be able to run to completion.

In T92357#1182547, @Gilles wrote:

It's deployed and it's all GETs. I have the feeling that this was already accounted for elsewhere in the code :) Oh, well...

It looks like mediawiki.org uses a similar hack (<p></p>). I'm working on a core patch to allow setting the anonnotice to the empty string.

I haven't seen it on en.m.wikipedia.org, though recently I have on en.m.wiktionary.org when logged out (since $wgDismissableSiteNoticeForAnons was enabled).

I don't see how it would be possible to fix the CategoryTree problem (mentioned above in T55130#1102370 and reported by another user as T92767) while still using CSS multi-column layout (as opposed to, e.g. multiple divs styled as table cells) for this. How would you tell the browser to keep the entire tree view in a single column and not rebalance the columns, yet not put everything into a single column and not constrain the column height either? (At least without some ugly hack like copying the remaining links in the column into a separate "overlay" element I don't think so.)

When any category is expanded through the drop-down mark, the list of categories is redistributed to list columns and the category name with the expand/roll-up mark is moved.

When I uncheck the -webkit-column-break-inside: avoid; on .mw-category-group in Chromium's Developer Tools and resize the window to a width below 768px and back again, the page does display in three columns.