Though, we can just remove the line entirely too based on https://github.com/wikimedia/mediawiki-extensions-AbuseFilter/blob/REL1_27/AbuseFilter.parser.php#L1692-L1711

Yup, that works. Really, it should be done in extension.json, but we don't have that functionality in REL1_27 - https://github.com/wikimedia/mediawiki/blob/REL1_27/docs/extension.schema.json but things are less broken (as long as composer isn't trying to install antispoof even though it's already installed...

In T202671#4672323, @dmaza wrote:

That is due to AbuseFilter having:

composer.json

{
  "require": {
    "mediawiki/anti-spoof": "dev-master"
  }
}

That should be removed entirely.

@hashar I'm not entirely sure where are you seeing that composer.json file but fwiw the dependency on anti-spoof was removed from AbuseFilter over a year ago https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/383717

Cheers Brad! :)

It's working now.. I wonder if something run by update.php has just cleared it up. Or, via update.php it ran to completion, and when I was trying to run this it was while update.php was running it, so some race condition where the row didn't exist at the start

http://php.net/manual/en/apc.configuration.php list cache_by_default, but http://php.net/manual/en/apcu.configuration.php doesn't. So you'd look to be right

Yeah, I'd agree it's worth backporting fixes from master where we have them. Hopefully prevent a few bug reports down the line

reedy@mwmaint1002:/tmp/uploads$ mwscript importImages.php --wiki=commonswiki --comment-ext=txt --user="Bodhisattwa" /tmp/uploads
Import Images

Seems to exist?

Done

Done

Done

Thanks!

LGTM too

Running mwscript migrateActors.php --wiki=simplewiki --force now

Ok, let's close this task as actually resolved, and file a task for getting the underlying issue resolved

Was it an automatically created redirect when moving a page?

I just changed the content model on the page back to wikitext

Locally

Locally

In T200391#4661981, @MusikAnimal wrote:

Are the plans to remove all related data from the databases? Right now, the MediaWiki API says the Education( talk) namespaces don't exist, but such pages are still in the database. This causes errors for some analytical tools like XTools. We have the page_title, but we can't display it because we don't know what the namespace is.

Worth clearing it up in supported branches too, so hence the patches above

I guess it's because the installer i18n isn't being loaded by update.php (but the installer will load it), so hence it ends up with just the message key being output

For some reason pear/mail just has a suggest for pear/net_smtp. Feels a bit loose to me.

In T109121#4655407, @BPirkle wrote:

I also did not find anywhere that we are using this, and the issue description says it will be removed Q4 2015. Per https://phabricator.wikimedia.org/T173849, it has PHP 7 compatibility issues. Is there any reason we should not go ahead and remove it?

Need to enable 2FA on Phab too if you haven't already :)

In T101058#4650661, @gerritbot wrote:

Change 465288 had a related patch set uploaded (by D3r1ck01; owner: Alangi Derick):
[mediawiki/extensions/Echo@master] Use actual namespaces in Echo

https://gerrit.wikimedia.org/r/465288

@GroupPermissions looks to be missing any useful context, so maybe that should just be removed

My AWB is up to date, and doesn't display this error with my test site.