# Fri, Jan 8

MarkAHershberger updated the task description for T250406: RFC: Hybrid extension management.
MarkAHershberger added a comment to T250406: RFC: Hybrid extension management.

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.

MarkAHershberger updated the task description for T250406: RFC: Hybrid extension management.

# Thu, Jan 7

Refactor individual local/ldap checking bits into protected methods
Reduce code duplication by creating a protected getAuthManager()

# Wed, Dec 30

MarkAHershberger added a comment to T270918: PluggableAuth: Add hook when users are created.

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

MarkAHershberger updated the task description for T270918: PluggableAuth: Add hook when users are created.

# Tue, Dec 29

MarkAHershberger added a comment to T270918: PluggableAuth: Add hook when users are created.

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

# Dec 15 2020

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.

# Dec 14 2020

MarkAHershberger committed rELDB3a2f221adf23: Populate $id if we can (authored by MarkAHershberger). Populate$id if we can

# Dec 7 2020

MarkAHershberger added a comment to T245134: Arrays extension cannot parse certain numbers.

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.

MarkAHershberger added a comment to T245134: Arrays extension cannot parse certain numbers.

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

# Dec 2 2020

MarkAHershberger added a comment to T268328: Automatically index extensions in Codesearch.

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.

# Dec 1 2020

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.

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}}

# Nov 19 2020

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

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

# Oct 27 2020

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.

# Oct 15 2020

MarkAHershberger renamed T265665: MovePage::moveToInternal() should use Title::getArticleId() not Title::exists() from MovePage::moveToInternal() should use Title::getId() not Title::exists() to MovePage::moveToInternal() should use Title::getArticleId() not Title::exists().

# Oct 5 2020

@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:

# Oct 2 2020

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.

# Sep 11 2020

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:

(The image lists 7.3.20. The changelog shows this was uploaded on July 10th.)

RHEL 8 has PHP 7.3.20 available. To use it:

yum module install php:7.3/*

# Sep 4 2020

MarkAHershberger updated subscribers of T261923: Unarchive mediawiki/extensions/MagicNumberedHeadings.
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.

# Aug 26 2020

MarkAHershberger committed rELCKb307d209426c: update with getLink() (authored by MarkAHershberger).
MarkAHershberger committed rELCK0696327c4c41: update with getLink() (authored by MarkAHershberger).

# Aug 25 2020

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

# Aug 23 2020

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

# Aug 18 2020

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".

# Aug 16 2020

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

# Aug 6 2020

MarkAHershberger added a comment to T250406: RFC: Hybrid extension management.

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

# Jul 20 2020

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.

# Jul 12 2020

MarkAHershberger added a comment to T250406: RFC: Hybrid extension management.

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

# Jul 10 2020

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.

# Jun 23 2020

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

awesome, trying now.

# Jun 18 2020

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!

# Jun 14 2020

Akuckartz awarded T250406: RFC: Hybrid extension management a Like token.

# May 22 2020

MarkAHershberger updated subscribers of T64996: <ref> in template parameter exposes UNIQ string on preview.

So this looks like bug 25417.

MarkAHershberger updated the task description for T250406: RFC: Hybrid extension management.
MarkAHershberger added a comment to T250406: RFC: Hybrid extension management.

[...]
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.