[00:01:45] anomie, I'm seeing error: Class undefined: AuthManagerStatsdHandler in /srv/mediawiki/php-1.29.0-wmf.15/includes/libs/ObjectFactory.php on line 71 [00:05:49] MaxSem: the class was in WikimediaEvents... [00:06:04] then Krinkle ^ [00:06:28] I can fix the config, it only affects closed wikis so not tragic [00:07:17] although not sure if we want to get rid of those auth stats, spammers could still used closed wikis to log in (maybe even register?) [00:07:34] It isn't even used in WikimediaEvents [00:07:43] Maybe move to mediawiki-config? [00:08:00] ugh [00:08:10] seems like a terrible place to keep classes [00:08:15] https://github.com/wikimedia/mediawiki-extensions-WikimediaEvents/commit/7b8d602e8e90325e5166910216a9e0306ac91a5e [00:08:21] no tests etc [00:08:31] tgr: what do you mean no tests? [00:08:47] phpunit tests [00:08:51] Maybe move to WikimediaMaintenance as other random equally unrelated git repo? [00:08:57] tgr: mw-config has phpunit tests :) [00:09:32] WikimediaEvents seems fairly related for a Wikimedia-specific event handler [00:10:00] What's in a name. [00:10:45] Unless the code that references the class to set up the subscriber and logging is in the same extension, it really doesn't belong there. The only code that should be referenced in mw-config is mw-config itself and (in rare cases) core itself. [00:15:05] mw-config phpunit requires to pass without mw itself, so core deps will have to be mocked [00:15:51] I'm not sure I understand the logic, config is full of stuff that references code [00:16:11] wfLoadExtension does exactly, even if in a non-straightforward way [00:17:01] 1) disable the auth log on closed wikis, 2) move to WikimediaMaintenance or other Wikimedia-specific enabled-everywhere repo, 3) move to mw-config with refactored tests [00:18:12] 1) works, I'm just not sure if we want it, since those wikis can still be used for authentication, and could be abused by an attacker [00:19:27] anyway, this error is trending [00:22:03] MaxSem: tgr: Let's do #1 as quick -fix and work on considering #2 and #3 in the next hour? [00:22:04] the proper solution IMO is to refactor WikimediaEvents to be able to disable the event handlers which do not make sense for closed wikis with a config flag [00:22:14] yeah, 1) is the quick fix [00:22:26] add wmgUseWikimediaEvents around the caller [00:24:34] https://gerrit.wikimedia.org/r/342778 [00:25:35] tgr: That's not practical for various reasons. Primarily that module registration doesn't support being conditional, even if we can conditionally addModules() they shouldn't be available to the system at all. We'd have to undo extension.json and revert to procedural registration of modules via a hook. I agree that there are valid use cases for an extension [00:25:35] class being referenced in mw-config, for example, configuring an extension-provided subclass for something like FileBackend, Image scalers, job queue, and event handlers (Swift, VIPS, EventBus) in config vars that take class names. However that doesn't change that this class doesn't belong in this extension, really. [00:33:57] Krinkle: in general we are slowly moving towards dependency injection, which means referencing classes (extension or not) from config more often. If you grep for 'class' you can see a couple more examples. [00:34:20] Yeah, that's good. [00:35:13] it's a design pattern I highly encourage for most of our components. Including RL, EventRelayer, BagOStuff, RCFeed and various others in core. [00:35:20] And here as well. [00:35:26] But we'll need to find a different place for this class. [00:36:39] If everything is in core you don't have to worry about loading extensions in the wrong order ;-) [00:37:48] (I'm also a weirdo who runs MediaWiki with no extensions :p) [00:38:04] RainbowSprinkles: Including no skin? I doubt it. [00:38:21] Oh, I reverted that from my local branch [00:38:24] I still have skins in core [00:38:33] putting classes in mw-config is a really bad idea IMO. They are harder to test, you need a SWAT for every code change, changes do not ride the train and can cause more breakage, people grepping mediawiki/extensions might miss it and break it etc [00:38:56] so really an extension is the only reasonable solution [00:39:06] RainbowSprinkles: My sympathies. [00:39:16] It's so much simpler :) [00:39:27] RainbowSprinkles: Use MW 1.1 if you want simple. [00:39:28] given the overhead of deploying extensions, IMO having lots of separate single-purpose WMF-specific extensions is an antipattern [00:39:34] James_F: That's my favorite version! [00:39:44] MediaWiki 1.16: forever young! [00:39:50] RainbowSprinkles: Before I wrote some code into it, hmm? ;) [00:40:05] personally I would merge the three Wikimedia* extensions as well [00:40:10] James_F: BEFORE YOU RUINED EVERYTHING [00:40:16] ;-) [00:40:27] Thass'me. [00:40:39] Honestly, I only run one "extension" which is the Vector skin [00:40:49] All other are superfluous :) [00:41:21] aha, YOU'RE STILL USING SHINY NEW HIPSTER SKINS [00:41:37] Well Vector is just Monobook 2.0 [00:42:49] On the subject of skins...I think we're overdue for killing 1 or 2 more ;-) [00:43:03] * RainbowSprinkles glares at cologneblue especially [00:43:47] Krinkle: registering the RL modules in a hook seems like the least bad solution to me (with creating a new, more explicitly catch-all extension such as WikimediaCustomizations the second least bad) [00:44:09] Oh, and +1 to tgr's idea of combining Wikimedia* extensions [00:44:43] * MatmaRex glares at RainbowSprinkles [00:44:55] * RainbowSprinkles gets into a glaring contest [00:45:50] I prefer Docker. [00:46:22] There's a skin called Docker? [00:46:30] Probably, I don't know :) [00:46:39] But docker is the solution to everything [00:46:45] tgr: Given the whole point of extension.json is that we want to move to static config files (a long way off), doing new things in hooks is still pretty bad as a pattern. :-( [00:46:55] Krinkle: Did you know containers are going to solve world hunger and world peace? [00:47:00] Or so I've heard [00:47:05] RainbowSprinkles: Is that shipping containers? [00:47:08] Actually, that might be true. [00:47:10] Full of food, water and guns? [00:47:26] lol, Reedy wins the internet today [00:47:28] Although I think a more scalable solution would be on-site. [00:47:35] Anyhow... [00:48:11] Reedy: Peace as a Service? [00:48:16] Food as a Service? [00:48:20] RainbowSprinkles: Isn't that a cluster bomb? [00:48:31] Food as a Service -> Postmates? [00:48:48] Amazon is doing that actually. Amazon Button. Press a button and food arrives by drone 12 minutes later. [00:50:11] Depending on where I order from, Postmates can be here pretty quick too [00:52:35] James_F: it is. Trying to pick the smallest evil. [00:52:58] * James_F nods. [01:09:36] redirects are so messed up.. I thought using the Content object instead of WikiPage would save a query, but now I see AbstractContent::getUltimateRedirectTarget just ends up constructing WikiPage objects and calling getRedirectTarget(). [01:09:47] Looking further, it seems we already resolve multiple levels of redirects when saving redirects [01:09:55] the redirect table saves the final target, not just the immediate one [01:11:03] Per WikiPage::insertRedirect and WikIpage::updateRevisionOn [12:35:13] 10MediaWiki-Core-Team, 10Wikimedia-Site-requests, 07WMF-maintenance-script-run: Run sendConfirmAndMigrateEmail.php for all unconfirmed emails on all wikis - https://phabricator.wikimedia.org/T73241#3101592 (10MarcoAurelio) [19:34:48] Refused to execute script from 'http://10.13.37.190/w/load.php?debug=true&lang=en-gb&modules=ext.eventLoggi…artup%7Csite%7Cskins.vector.js%7Cuser.defaults&skin=vector&version=1glsge1' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled. [19:34:51] Well, that's fun [19:36:09] that URL probably put up an HTML error page maybe? [19:41:43] nope [19:42:02] https://phabricator.wikimedia.org/P5062 [20:09:02] RL uses text/plain on error and text/javascript otherwise [20:09:21] so probably a misconfigured web server overrides it?