Can populateContentTables.php be run multiple times without causing harm? It seems like there is no issue, but want to be certain before telling my orchestration system to respond to errors in update.php that look similar to this by trying populateContentTables.php.

@dbarratt how would that work with composer.local.json? If I add extensions to composer.local.json, I believe I can run composer install to get those extensions without impacting the dependencies from composer.json. But then if I bump the version of one of those extension I need to run composer update to get the new version. That’d invalidate composer.lock I believe.

I don't understand. I don't see an error in the revision you linked.

I cannot replicate this on 1.31.1 or 1.32.0. I tried creating a page with just the following content:

I'm fine continuing to use qna or setting up a separate project.

I'm getting the same issue:

This change seems to have made group expiry a requirement rather than optional. Personally I'd like to disable this feature (or at least limit it only to certain users) because I get people applying expiries when they should not. Is there a reason this is no longer optional?

What's the rationale and long term plan for this?

Okay, so I guess that means the prefix "MediaWiki" = MediaWiki core. Removing tag and leaving it tagless for now. @CCicalese_WMF @Darenwelsh not sure how to tag this. I don't think we want to move Meza issues into Phabricator just yet, though I'm not opposed to it if others want that. The code sort of needs to be in GitHub because the CI is tied to Travis. I'm not incredibly familiar with the WMF's Jenkins setup, but we'd need to be able to generate CentOS VMs or Docker containers that we can use to replicate CentOS (as is done on Travis) to move Meza into Gerrit.

@Krenair Concur MediaWiki-General isn't right. Removed it, added MediaWiki-Installer instead. That may not be a perfect fit, but seems closer.

@Aklapper because I created the GitHub issue first (since Meza tracks issues there currently) but people at the WMF Technical Conference asked to create a Phab task instead since that would likely get greater use. I'm not at the conference...just doing their bidding.

Added note about possibly needing --username-prefix="" to docs: https://www.mediawiki.org/wiki/Manual:ImportDump.php

@Nikerabbit what did I do wrong with the commit message?

Submitted patch: https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/459623/

Disregard the above. Removing additional extensions (Arrays, NumerAlpha) removed this issue.

I'm still seeing this error in MW 1.30.0 (830bb58fa2d24eb93d45135c6becd53f6c50d491) using VE tested at the following commits:

Reading through the position statements [1], I think the main points can be summarized into the following four actions the WMF should take. The position statements that support each action are listed as well.

Windows 7
Version 58.0.3029.110 (64-bit)
Vector skin

I'm trying to test another issue and I've done a few edit-and-save cycles and the issue showed up again. I'm not sure at this point what may cause it. Whenever I see the issue on that page from now on I'll edit source on the page and leave an edit summary like "edit with VE issue T166340"

I refreshed this page several times and it continued to happen. But then I just went to it again the problem seems to have gone away.

It seems to me that when creating a bot password I should be required to type my account password before proceeding in the same way I have to prior to changing my account password.

<soapbox>Gerrit needs to be easier to access from behind restrictive firewalls</soapbox>

Like this?

For the last year I've had to modify Parsoid manually to make external images show.

What would be involved in making this fix?

Is this something the new MediaWiki Platform Team would be able to take a look at?

Any progress on this? Anything I can do to help?

Is GraphicsMagick supported? This task indicates that it is not, but this mediawiki.org page indicates it is.