I've updated the description to remove the requirements that would increase the workload for the WMF. Hopefully this will mean it can be fully implemented.

Never mind, I found that PluggableAuthPopulateGroups is called from the LocalUserCreated hook.

I guess what I'm saying is; Should I just use the UserAuthorization hook? It looks like I should, so feel free to WONTFIX.

I've been trying to find a way to "fix" this without littering Special:ListGroupRights with random "read" rights. I realized that changing the $wgGroupPermissions right to

$wgGroupPermissions["GROUP"]["*"] = false;

seems to do the job.

In T245134#6489963, @Dinoguy1000 wrote:

As more wikis are updating to MW 1.34+, this is impacting more people. See for example https://www.mediawiki.org/wiki/Topic:Vuij4e8ea5ydavbn. Would be nice to see this fixed in a new point release of the extension.

In T245134#6164031, @MGChecker wrote:

Can you try again with the master version of the Arrays extension? This is probably broken because the global default value has been broken for some time in v2.2: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Arrays/+/6a47eac735e7cd9c16b445453f960e6b057845ae

In T268328#6637187, @Krinkle wrote:

Among the additional stuff is a secondary index of https://raw.githubusercontent.com/MWStake/nonwmf-extensions/master/.gitmodules (ref) which is what you propose, but behind one extra anti-abuse step where MWStake has decided to list the repo. Whether to use this or some other mechanism, I think it's worth having something like that in place before feeding straight into Codesearch cloning, tracking and indexing the repo for the next 24 hours.

No, I don't think that is a good enough solution. That's why I was thorough in cleaning out the permissions.

The code could be simpler, but then it wouldn't address the page properties that already exist. Without that, the possibility of ghost user restrictions remains.

Just getting rid of the parameters on the wiki does not make them unavailable to users. We want users to use the group parameter, but we do not want to let them use the user parameter since that will change the behavior in an undesired way.

In T269060#6661223, @Yaron_Koren wrote:

Okay, now I get it. It would be easier to just disable the "users" parameter when handling #approvable_by... I suppose the downside there is that you can't do anything about #approvable_by calls that already exist and already include a "users" param, but that doesn't seem like a big deal. Or is it?

We want users to be able to say

{{#approvable_by: group = approvers}}

or

{{#approvable_by: group = editors}}

but not

{{#approvable_by: user = sam}}

I may have to eat my words. Setting up a test wiki with only

wfLoadExtension( 'ApprovedRevs' );
$wgGroupPermissions['sysop']['approverevisions'] = false;
$egApprovedRevsBlankIfUnapproved = true;
$egApprovedRevsShowNotApprovedMessage = true;

shows behavior more like what I expected. Reviewing all this now.

Note that changing my membership in the group does immediately add or remove the approve links from the history page.

It looks like this is no longer an issue.

In T250406#6596381, @daniel wrote:

It is my understanding that this RFC effectively asks the WMF to release all extensions she maintains on a composer repository (packagist or self-hosted) on a regular bases (along with core releases, presumably). Did I get that right?

Those of us working on this have updated Composer/For_extension_developers and Composer/For_extensions in anticipation of the resolution of this.

Do you have the following in your LocalSettings.php?

$wgVirtualRestConfig['modules']['parsoid']['forwardCookies'] = true;

Currently working on CW, so this may see some attention.

The patch needs to be updated and I need to talk to the people who originally requested this to see if they still want it.

Doesn't need to be done. I'm happy just pointing to the repositories and occasionally moving what the parent repo points to.

@Joergi123 can you confirm that VE works for you after you've made these changes? Can you tell us what specific lines you added or changed? From your description, it sounds like the following:

Hmmm.... after testing this morning, let me clarify that using the LocalSettings.php that MW generates works, but doing something very similar with my own LocalSettings.php does not work and I'm not sure what the difference is.

Note that I see this error as well on a fresh install of 1.35.0. VE worked in the previous RC for 1.35.0 that I tried.

FWIW, the maintainer of the RH package is the same person who maintains the Remi repository -- his name is on the changelog. I think it is reasonable to use the Remi repo for your CentOS instance.

Reedy, it is especially hard to find the official RH versions without a subscription. I got a 30 day free trial today and found this list of supported versions:

RHEL 8 has PHP 7.3.20 available. To use it:

yum module install php:7.3/*

Shouldn't the extension also be re-added to translatewiki.net? It
was there (albeit with only one translatable message) before the
original archival.

yep... thanks.

@TK-999 I'm very interested in the Percona aspect of this. Have you tried my Percona driver ??

Is there an example of this somewhere on mw.o so we can see how it works?

Ah, sorry. I clicked on the abandoned link instead of the new one.

The failures are caused by code style issues and can be fixed with "composer update && composer fix && git commit --amend && git review".

I'm running into this consistently here: http://podz.winkyfrown.com/w/index.php

In T250406#6363841, @dbarratt wrote:

Also, if you "require" an extension with Composer in Drupal, it does not enable that extension. I think the same should happen for MediaWiki.

I'm using Percona XtraDB Cluster 5.7.23-23-57-log which uses the MySQL 5.7 engine. There are a number of SO questions about this difference in MySQL 5.7, many of which say to disable ONLY_FULL_GROUP_BY but this Percona blog post explains how to actually address the problem.

TL;DR: Perfect is the enemy of Good Enough.

One option would be to drop the fields in cleanupUsersWithNoId.php. Another would be to incorporate cleanupUsersWithNoId.php into update.php, but this would mean using a fixed username prefix.

Sorry, this doesn't work. The results in the list are different, but they seem to have no relation to anything.

awesome, trying now.

Note that @Lex has some interest in this and proposed that the MediaWiki-Stakeholders-Group provide this as a service for its members. If we were to offer this (+ some code review) as a service, it might also allow us to review non-public extensions.

Also note that a committee from the board just so happen to be meeting today to discuss these tasks and figure out which one(s) should be our current focus.

@Akuckartz Thanks for noting that. I've fixed that one. Thanks for taking this on!

https://www.mediawiki.org/w/index.php?title=MediaWiki_Stakeholders%27_Group&type=revision&diff=3912499&oldid=3900039&diffmode=source

In T64996#658961, @Umherirrender wrote:

So this looks like bug 25417.

See T27417: ref inside Wikilinks leave UNIQ

In T250406#6146885, @Tgr wrote:

[...]
Throwing an exception is the best that can be done in that situation.

Maybe MWExceptionRenderer could be split into a simple and a complex part, where the simple does not depend on OutputPage etc, and the simple version could be installed for the early part of Setup.php.