[11:44:29] So I was asking about my extension yesterday, and it seems like the problem was indeed that I hadn't run the update script. Now I have a different problem, though. My extension apparently has an infinite loop somewhere, because it exhausts the memory limit and gets killed. I don't see any way that it should be infinitely looping, though. https://pastebin.com/tfFWHeYs [11:44:48] I'm literally just checking emails against a blacklist. [11:47:05] And what confuses me here is that a foreach shouldn't even be able to infinitely loop, as far as I know. [11:47:29] That would require somehow populating the array being iterated on mid-loop. [11:47:47] where are you calling isEmailBlacklisted() from? [11:49:05] From the onIsValidEmailAddr hook [11:49:11] Set in the hooks file [11:50:10] https://pastebin.com/vaeuHdJH [12:02:42] Okay, so it's not that hook. It's this: https://pastebin.com/G8sSB0QG [12:02:57] (Ignore the fact that it's commented; I did that to debug and didn't realize I copy-pasted it into pastebin) [12:03:19] This is intended to stop blocked users from changing their information. [12:03:31] But I don't know why it would result in a loop [12:11:05] jfolv: Might be more stricter than what you want, but $wgBlockDisablesLogin will stop blocked users changing their user settings ;) [12:11:31] Hey, that sounds good to me. [12:11:36] Is there any concerns with blocked users being able to change their settings? [12:11:49] Yeah, we want to make sure that they can't hide their email. [12:11:58] Makes them easier to track. [12:13:38] Had problems in the past where people who got blocked would just delete their email from their profile and then make a new account with the same email. [12:30:10] Okay, different problem. MonoBook doesn't seem to load everything properly, and /w/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=monobook returns this error: https://pastebin.com/QrtHvrJt [12:30:51] I deleted the MonoBook skin and replaced it from a fresh tar.gz, but I still get this. [12:34:53] Ohhh I think I see where this is coming from, actually. [12:35:05] Custom extension maintained by a friend of ours. I'll contact them. [13:37:44] jfolv: Hi! this must be me. You can try changing "ResourceLoaderImageModule" to "MediaWiki\\ResourceLoader\\ImageModule" on this file and see if it works https://github.com/ciencia/mediawiki-extensions-TabberTransclude/blob/main/extension.json#L53 [13:37:55] (until I can test it on the new version) [13:43:58] Vulpix: Haha, yep, you caught me. Looks like that does fix it. Guess some of the classes were reorganized. Thanks! [14:19:49] Here's an interesting one: ConfirmEdit causing login to fail with Error: Class "ReCaptcha" not found [14:20:14] The error is somewhat similar [14:20:37] You've probably got a config override you don't need [14:20:50] And/or you haven't upated the extension [14:21:47] Can't be that because ConfirmEdit is bundled with core now. [14:22:02] See the first comment then [14:22:24] You've likely got $wgCaptchaClass = 'ReCaptcha'; that you don't need [14:23:11] Though, I'm not sure the class has been called ReCaptcha for a lot loner... [14:23:13] *longer [14:23:31] Even in 1.35 it was ReCaptchaNoCaptcha [14:23:54] Hm. Must be a relic from old config, then. [14:24:01] But yeah, removing it fixes the problem [14:24:23] Looks like it disappeared for 1.34 [14:25:17] Oh that's fun, my staging site has something different from production in its config. Production uses ReCaptchaNoCaptcha in the captcha class var. [14:25:28] And that's 1.35.8 [14:25:46] Either way, good to know that can probably go [14:30:07] (btw thanks Reedy) [14:41:38] heh