These are running on REL1_31 now...

pear/mail_mime from composer is default from >= 1.31

Is this still a problem? 1.28 is EOL

Is this still a problem?

We should maybe start to version CirrusSearch properly or maybe follow core versions, e.g. CirrusSearch 1.28 requires core 1.28.

Is this still a problem on 1.31?

Closing as resolved, might be a few residual issues, but most of this work should be done now

In T225979#5265026, @Paladox wrote:

This seems like a bug, since you shouldn’t be able to remove a +2 after a change is merged, but it’s expected that you can remove votes after a change is merged.

Anyone know offhand how long this was an issue for?

In T60224#4934961, @Liuxinyu970226 wrote:

Hmm, suitable for migrating to a project or not?

It would be appreciated if this problem could be investigated as well.

After the branch is cut next week seems reasonable

In T225728#5258487, @Ciencia_Al_Poder wrote:

I also have this problem. PHP is executed from an nginx behind a load balancer. HTTPS is terminated on the frontend, and the connection between the frontend, load balancer and MediaWiki is plain HTTP. Because of how the logic is done in MediaWiki, there's no way to get rid of the "use secure connection" link despite all pages being served as HTTPS.

I do note that ProofreadPage doesn't seem to be well translated into yi on translatewiki.net ...

Yay, progress :)

I don't think there's exactly a default (unless I missed something), hence just copying the enwiktionary one

What version of MediaWiki?

I unfortunately don't speak/read/write Yiddish, so can't help too much :(

I've just created that page from the enwikisource version at https://yi.wikisource.org/wiki/%D7%9E%D7%A2%D7%93%D7%99%D7%A2%D7%B0%D7%99%D7%A7%D7%99:Proofreadpage_index_template from https://en.wikisource.org/w/index.php?title=MediaWiki:Proofreadpage_index_template&oldid=9148595

I think it's because https://yi.wikisource.org/wiki/%D7%9E%D7%A2%D7%93%D7%99%D7%A2%D7%B0%D7%99%D7%A7%D7%99:Proofreadpage_index_template doesn't exist...

FWIW, filed upstream at https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/4091

https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/4091

I’m guessing it wasn’t reported upstream?

In T225683#5257607, @matmarex wrote:

The warning is caused by SemanticMediaWiki, see here: T205956#4633005 T205956#4633514

I'm just using the mariadb.org package for Ubuntu 19.04, stock config AFAIK, but possibly not currently what's distributed (as it's an old vm that's been upgraded through many many OS versions)...

Or maybe Language-Team might be interested?

I'm not sure if Lego has any time to work on this based on no activity since November... Can anyone else from CPT pick this up @CCicalese_WMF as the last (known) blocker for PHP 7.3 support?

On my dev wiki with $wgDebugDumpSql

In T225643#5257185, @Reedy wrote:

In T225643#5256591, @jcrespo wrote:

Again, just to be clear, we don't require a feature flag (although it is usually nice to have), just that we wait for the code to be final (for some definition of final, normally "merged to head") to deploy the db changes- which cannot be reverted- we can just apply the opposite changes again.

The question is scheduling then I guess... If we merge to master (as I think it's roughly ready otherwise if we're not adding the feature flag), and can get it deployed before the next branch cut... We're good. I know I'm not a DBA, but I think it's a relatively simple schema change; I'm presuming you might not need to master swap or anything with the number of rows etc

In T225643#5256591, @jcrespo wrote:

Last question, is there a limit on the size or insertion rate of the blob column, either implicit or explicit? Not too worried about it, but wondering if it can be a string of arbitrary size inserted as fast as possible?

Did you disable all extensions to test?

I’m not saying there won’t be another column (though I’d be surprised), but it was more blocked on some other issues with the code, I haven’t reviewed it recently so not sure of the actual state, Brian should have a better idea

In T225643#5253921, @Marostegui wrote:

Can you elaborate a bit more on what you expect to store on those two new columns?

In T225244#5252425, @Lucas_Werkmeister_WMDE wrote:

Travis build succeeded except for the PHP 7.3 version, but that seems to be failing for unrelated reasons.

Thanks for filing this request in advance, however the following isn't very useful: