when I point my Browser to the install directory I get the following error:
[WHIGxsCoLCwAAEQq@DAAAAGp] /mw-config/index.php InvalidArgumentException
from line 49 of /mnt/web115/a2/12/57862812/htdocs/mediawiki/includes/
libs/objectcache/HashBagOStuff.php: $maxKeys parameter must be above zero
Can you please help me?
I'm wondering if anyone has dealt with the problem of wiki usernames no longer being unique. I'll explain....
In our company, we store usernames in Active Directory and use LDAP for MediaWiki authentication. This has worked reliably for years. Everyone has email addresses ending in "@company.com", and the person with email address "foobar(a)company.com" automatically gets the MediaWiki username "foobar".
Now, our company has started acquiring other companies, and each one has its own internet domain (and they don't all use Active Directory, so we are experimenting with Auth0 for multidomain authentication). Suddenly, we can have users named foobar(a)company.com, foobar(a)anothercompany.com, and foobar(a)thirdcompany.com. If we keep our current solution for creating usernames, all three of these addresses map to the username "foobar", and we have A Bad Situation.
Has anyone else encountered this situation? If so, how did you solve it for MediaWiki? There are several obvious solutions, none of them perfect:
1. Use the entire email address (which is unique) as the MediaWiki username. This affects all existing accounts as well as new accounts. One side-effect is that some people have multiple email addresses (me(a)company.com, me(a)anothercompany.com) and these would be considered different wiki users. That's not a deal-breaker... we can live with it.
2. Somehow map every email address globally to a unique ID, say, with a database table, and use that ID as the MediaWiki username.
3. Force every domain to use Active Directory, insert a unique ID into some Active Directory field, and use it as the MediaWiki username. This is not going to happen. We can't change every company's authentication mechanism.
4. Stop creating usernames automatically, and have users invent their own unique usernames. Not great in a corporate environment. When usernames don't match real names, it's inconvenient to locate the real people behind wiki edits.
Any tips appreciated from anyone who has been there before.
Daniel Barrett asked:
> tl;dr: Is it possible to enforce an order on callback functions
> that are attached to the same hook?
> Unfortunately, MediaWiki 1.28.0 always runs CategoryTree's callback after mine,
> so no matter what I do, CategoryTree wins. (Strangely, in 1.27, my extension always won.)
I don't see any sort of enforced ordering from a quick glance at the code. It does
merge together "old school" ($wgHooks) and "new school" (extension.json) hooks
into a single array, which might account for some of the odd behaviour you are seeing.
I would try to use the same registration method as the version of CategoryTree you
have. In other words, have your extension use the new extension.json if you have a
modern CategoryTree. Otherwise, both can use wgHooks.
Then, in theory, the order they are called in LocalSettings.php should produce a
sane and repeatable order.
Greg Sabino Mullane greg(a)endpoint.com
End Point Corporation
PGP Key: 2529 DF6A B8F7 9407 E944 45B4 BC9B 9067 1496 4AC8