[00:09:42] [1595fcff86b0b9339cce91bd] 2026-01-30 00:09:31: Fatal exception of type "MediaWiki\Storage\NameTableAccessException" [00:27:59] [1/2] `Failed to access name from slot_roles using id = 1` [00:28:00] [2/2] I think I know how to fix this [00:28:40] is it a miraheze thing or did i fuck something up lol [00:29:10] Should be fixed now [00:29:40] works, thanks! [00:29:42] It happens sometimes when resetting a wiki [00:29:43] [1/2] It's a known issue that happens a lot after a reset [00:29:44] [2/2] https://meta.miraheze.org/wiki/Tech:Fixing_slot_roles_and_content_models [00:29:48] ah [00:30:02] (maybe we should create a task and investigate this at some point) [00:30:07] it can't be impossible to fix [10:09:07] https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Scribunto/+/1228547 Just wondering, what is the usual position of Miraheze when it comes to enabling settings like this one? Does the tech team have to discuss it in some place, it becomes an option in ManageWiki or something else? [10:14:00] I wrote this patch, but I think it would be difficult to enable it on all wikis as it might break modules under certain circumstances, and we can't realistically check all of them [10:15:07] We can add it to ManageWiki, the question is just whether the average wiki admin understands what it's doing and doesn't complain if the modules they imported from wikipedia or somewhere else don't work properly [10:16:00] ahhh, thank you for your work! Makes sense. Welp, guess worst scenario is PR to mw-config to enable it for a wiki 🫠 [10:17:09] yep [10:17:39] I'll keep that in mind for the future, thank you for answer! Have a great day :) [10:18:32] no problem, you too! [10:18:58] Thanks! [14:20:40] Just won $2,500 on KAIWIN.CC with promo code: GIFT 💰💸 @everyone [15:05:31] https://issue-tracker.miraheze.org/T14871 [15:06:14] they're not going to get done any faster just because you're linking them here [15:06:32] when i dont see any tags on tasks i typically link them here [15:06:39] i just found out theres a workboard for resets [15:06:44] so im doing that [18:05:54] [1/2] trying to log in [18:05:55] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1466856970228207705/image.png?ex=697e4482&is=697cf302&hm=1d95be8a81a6c172bea81a90fe8327a207cf7cac0d8f30da56010796ee80ea74& [18:06:15] seems it works fine on the miraheze domain for some reason [18:07:11] @cosmicalpha loading CSS fails on auth.miraheze.org due to violating CSP for custom domains [18:07:19] Of course. [18:11:51] See #announcements , we are in the process of upgrading our login system. [18:11:58] yep yep [18:12:04] thanks for your work :) [18:12:35] Ope, I spoke too soon, this may actually be a tech issue as the deployment should be finished [18:13:01] Deployment is finished [18:13:15] Currently working on a few issues popping up on login and CSS for CDs [18:13:46] Thanks Pix, can confirm I see the same CSS issue but was able to log in to a wiki with a custom domain [18:14:32] I’ll test on the bus [18:14:44] aka when I’m not procrastinating in math class because I entirely forgot adhd meds today [18:24:55] @cosmicalpha some wikis throwing permission errors seems to be reproducible too [18:25:15] I can reproduce on https://overkill.miraheze.org/Special:ManageWiki from a none staff account [18:44:25] i’m having issues logging on [18:59:01] still seeing CSP errors despite chucking on no caching refreshes and debug mode [18:59:28] [1/2] [18:59:28] [2/2] [19:14:18] I wonder if cache somehow as I can confirm some custom domains work. Ones I originally tested did. [19:15:02] its not hitting cf or varnish [19:18:07] Oh... I think I may know what is causing this... [19:18:26] Hard redirect on the miraheze.org domain so even manually forcing it isnt working. [19:18:46] aha [20:05:59] <.labster> Still no styling when trying to login from allthetropes.org [20:06:43] Aware. Happens when we force redirect the miraheze.org domain. Im working on it. [20:08:32] <.labster> That said, login persisting across domains is working better than previously [20:09:36] Haven't been logged out once despite hopping multiple custom domains/new attaches to my wobbly account, so a happy improvement [20:10:40] I presume it would be safe to switch MFA to WebAuthn now? [20:12:31] It should be. Let me know if you have any issues. [20:13:16] Will move over soon [20:14:33] pix about to be a very happy wiki man [20:14:47] after he gets a sweater on [20:15:43] <.labster, replying to abaddriverlol> Great patch, that one config setting would essentially remove the use cases for Extension:Variables in some deployments that I've seen [21:39:25] @cosmicalpha can confirm as working now [21:39:33] Great thanks! [22:57:22] [1/2] Hi, sorry for what may be an offtopic question. My browser sanitiser rejects a custom font I uploaded to a wiki. To my understanding that's an issue between the woff2 file and the browser, not Miraheze-specific. I have seen this webfont in use on other websites so I know it's possible to get it working, but cannot find information on repairing/remaking woff2s. Would someone have gu [22:57:22] [2/2] idance on this? [22:58:12] The error messages are ⁨`Bad cmap subtable`⁩, ⁨`Failed to parse table`⁩, then ⁨`rejected by sanitizer`⁩