# User Details

User Since
Sep 25 2014, 3:45 PM (365 w, 2 d)
Availability
Available
LDAP User
MarkAHershberger
MediaWiki User

# Aug 12 2021

Trying to upgrade a wiki to 1.35 and seeing it consistently in AbuseFilter:

...afl_patrolled_by in table abuse_filter_log already modified by patch …/extensions/AbuseFilter/db_patches/patch-afl_change_deleted_patrolled.sql.
LogicException from line 406 of .../includes/cache/MessageCache.php: Process cache for 'en' should be set by now.
#1 .../includes/cache/MessageCache.php(1034): MessageCache->getMsgFromNamespace('Abusefilter-blo...', 'en')
#2 .../includes/cache/MessageCache.php(1005): MessageCache->getMessageForLang(Object(LanguageEn), 'abusefilter-blo...', true, Array)
#3 .../includes/cache/MessageCache.php(947): MessageCache->getMessageFromFallbackChain(Object(LanguageEn), 'abusefilter-blo...', true)
#4 .../includes/language/Message.php(1304): MessageCache->get('abusefilter-blo...', true, Object(LanguageEn))
#5 .../includes/language/Message.php(862): Message->fetchMessage()
#6 .../includes/language/Message.php(954): Message->toString('text')
#7 …/extensions/AbuseFilter/includes/AbuseFilterHooks.php(658): Message->text()
#8 .../includes/installer/DatabaseUpdater.php(554): AbuseFilterHooks::createAbuseFilterUser(Object(MysqlUpdater))
#11 .../maintenance/doMaintenance.php(107): UpdateMediaWiki->execute()
#12 .../maintenance/update.php(253): require_once('....')
#13 {main}

# Jul 5 2021

@MarkAHershberger What do you think. Does it match your expectation this way?

I think this change deviates from the LDAP standard.

# Jun 24 2021

I believe @Osnard did some work on Confluence that would be helpful here.

# Jun 21 2021

btw, I'm thinking the E_NOTICE on the Special:Version page has something to do with SMW Glossary and Lingo's interaction. But I haven't tested this yet.

# Jun 16 2021

Just saw this in some new transaction handling I added for the SMW extension. The logic I added looks similar to @Tgr's example from Flow.

# Jun 10 2021

MarkAHershberger updated the task description for T284754: ContextMenu endpoint missing in Jenkins.

Switch your test from MediaWikiUnitTestCase to MediaWikiIntegrationTestCase

... and move it out of the unit subdirectory.

# Mar 25 2021

MarkAHershberger committed rELDR51b24daa0a1a: Clean up dotfiles (authored by MarkAHershberger).
Clean up dotfiles

# Mar 24 2021

MarkAHershberger committed rELDR0097b00fef27: Clean up dotfiles (authored by MarkAHershberger).
Clean up dotfiles

# Mar 1 2021

Thanks for calling out the problem with Ubuntu 20.04, @tstarling. We just had someone come into the MediaWiki-Stakeholders-Group channel talking about this issue for 1.35 this morning, so this is a nice bit of serendipity.

# Feb 23 2021

Just ran into this again. This is not a percona problem, but an incompatibility with mysql 5.7.

# Feb 8 2021

Kghbln awarded T158026: Make responsive image maps possible in ImageMap extension a Like token.

# Jan 8 2021

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.

# Jan 7 2021

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

# Dec 30 2020

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.

# Dec 29 2020

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.