[00:00:10] mmmm, suppose so [00:00:29] Wouldn't be a preformance impact I'd presume [00:01:33] The only disadvantage I could see is that you'd have to check if CentralAuth is installed, as MirahezeMagic cannot depend on CentralAuth as ldapwikiwiki doesn't use CentralAuth [00:01:46] Hm [00:03:09] though atp you could also use the UserCan hook and check the CentralAuth permission there [00:03:48] or whatever the non-deprecated replacement of that is [00:05:00] This is the non deprecated replacement hook lol [00:05:20] (I think) [00:05:59] https://cdn.discordapp.com/attachments/1006789349498699827/1495576226478293203/image.png?ex=69e6bf66&is=69e56de6&hm=b3267ba572b944a123fb9552db8aed8090dc44b059432fc3f7d9add691224215& [00:07:01] Right, that [00:07:13] this codebase is too big for mah small head [00:07:33] I did look at those, I don't think they'd work but I don't trust past me so I'll ;ook again [00:08:09] Right, yeah, the hook is designed to add errors [00:08:11] Not to allow thing [00:08:13] nobody knows the entire codebase lol [00:08:27] pretty sure even OG developers still discover new classes occasionally [00:08:47] hm right [00:09:48] ig the user rights hook you're currently using is probably fine then [00:13:33] So, directly ask CA for the permission check and move the registration [00:14:18] No I'm pretty sure it can also allow things [00:14:29] Based on the code in PermissionManager I don't think so [00:14:29] Pretty sure I checked that before I recommended it before [00:16:01] [1/2] You're looking at this part right [00:16:02] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1495578754939093042/image.png?ex=69e6c1c1&is=69e57041&hm=2315b595d3c08a188e170b1507ddff4979562446da10124636e5c05a8357e223& [00:16:19] yes [00:16:39] $result is modifiable by extensions [00:16:56] So, you'd remove the error from the list? [00:17:27] You'd set it to an empty array and return false I think? [00:17:28] Yeah but I don't think you can override core behaviour this way? [00:18:02] Yeah that seems pretty hacky and like more to reimplement checks [00:18:10] But then UserCan can't do that either? [00:18:21] https://cdn.discordapp.com/attachments/1006789349498699827/1495579341524959493/image.png?ex=69e6c24d&is=69e570cd&hm=4e1b64271a91d135d6aa0748347439df83239f050e73952e263de62718cf04c8& [00:18:27] nope, no hook can [00:18:28] afaics [00:19:24] Just saying there's no reason to use UserCan for this when getUserPermissionsErrors allows you to do the same thing [00:20:07] yep [00:24:51] part of why I prefer UserCan is in case there's any code that runs a check on what perms a user has and then checks that instead of directly asking permissionManager [00:24:55] idk personal pref [00:25:11] I really don't think it's enough of a difference to be worth changing [00:33:23] @abaddriverlol does `use`ing the CA class object need to be done after checking for the ext [00:34:58] https://github.com/miraheze/mw-config/blob/6c5a7d062ed5c024c323193be02095ea7defa7ef/initialise/MirahezeFunctions.php#L783 what am i looking at [00:35:02] You can `use` a class that doesn't exist [00:35:36] As long as you don't reference the class before you check whether the extension actually loaded you're not going to get an error [00:39:21] aha [00:39:24] ` if ( ExtensionRegistry::getInstance()->isLoaded( 'WikibaseClient' ) ) {` [00:39:27] ty mw.org [00:40:22] I'd recommend injecting the extension registry [00:40:56] que [00:41:31] add a property for it to the constructor (via constructor property promotion) and then specify it in the HookHandler definition in extension.json under the "services" array [00:42:13] So pass a registrying instance into the hook class instead of creating a new instance in line [00:42:34] instead of getting one via a static call, yes [00:43:00] Same can be done with Config? [00:43:10] Yeah [00:43:31] (the service is called MainConfig) [00:44:28] I presume SRD is recommending that because it allows for easier testing [00:44:38] How is that accessed, `$self->var`? [00:44:50] And because it's the standard that's being implemented in all new code and also old code [00:44:56] `$this->var` [00:45:38] I mean yeah but like I'm pretty sure the main appeal of dependency injection as a concept is easier testing [00:45:38] [1/9] so [00:45:39] [2/9] ```php [00:45:39] [3/9] public function __construct( [00:45:39] [4/9] private readonly ExtensionRegistry $extensionRegistry [00:45:40] [5/9] ) { [00:45:40] [6/9] }``` [00:45:40] [7/9] ```php [00:45:41] [8/9] if ( $this->extenionRegistry->isLoaded( 'CentralAuth' ) ) { [00:45:41] [9/9] ``` [00:45:41] Oh I just realized you're only referring to injecting ExtensionRegistry [00:45:42] yeah [00:45:57] yes, without the typo in the second snippet [00:46:15] thats not a typo its just one line [00:46:20] might be easier to just bail in the first line of the hook if it's not loaded instead of creating further nesting [00:46:24] [1/6] ```php [00:46:25] [2/6] if ( $this->extenionRegistry->isLoaded( 'CentralAuth' ) ) { [00:46:25] [3/6] $hasGlobalRight = CentralAuthUser::getInstance( $user )->hasGlobalPermission( 'editallcustomprotected' ); [00:46:25] [4/6] } else { [00:46:25] [5/6] $hasGlobalRight = false; [00:46:26] [6/6] }``` [00:46:27] `extenionRegistry`? [00:46:33] .. [00:46:47] right [00:49:11] whats the class for it? to `use` to define the type [00:50:13] `MediaWiki\Config\Config` [01:18:50] i oughta invest in "his ass did not run composer test" memes that can be used against myself the next time i make a patch for anything [01:51:14] okay, after using beta to dignoise such impossible issues as actually using the ExtensionRegistry and CentralAuthUser class and making sure the passed services are in the same order as the constructor, lets seeee [01:51:36] welp, seems to work on a very cursory check [01:51:47] let me make sure its only relying on global rights [01:53:59] mhm [02:23:31] https://github.com/miraheze/MirahezeMagic/pull/650 [02:27:53] @cosmicalpha poke you if you'd like to take a looky as mentor [03:11:08] @cosmicalpha any updates on this? [08:03:04] [1/2] CA isn't very active for the past 3 weeks so it might get postponed as usual for being very low priority. [08:03:04] [2/2] Imo the GDPR compliance aspect is nice (necessary?) but it creates a dialog for every new visitor which adds friction. I'd rather there be nothing between the reader and the wiki page. [08:04:21] Looking at other hosts, runescape.wiki does not have a cookie notice. wiki.gg does but the notice is hidden immdiately when I enter the page, which is a very strange choice for them to make. [08:37:13] Though this is not the first time we respect local regulations more than other hosts. Someone was complaining about not being able to use EmailUser on Meta a while back. [08:59:29] to some extent I've felt we care more about that than is reasonable to do relative to our content and position [08:59:33] but we've managed well enough [21:08:26] Need advice from more experienced WMF Phab users [21:08:57] I made a Parsoid task a while back but since realized it's actually a core MW issue with how Special:Interwiki and InterwikiLookup work [21:09:38] Do you advise making a new task for this with the interwiki project and adding it as a blocker or something else [21:11:04] I guess it's relevant to Miraheze in that you're also using the same virtual domain that's broken on Parsoid [21:11:14] if the issue is detachable enough from your original task then you can make a subtask with the interwiki project yeah [21:11:25] otherwise just add the interwiki project to the same task [21:12:21] Well if I fix the interwiki issue the Parsoid issue gets fixed by itself because it just uses the siteinfo API to fetch the interwiki map [21:13:06] sounds like same task then [21:14:18] i'd say do what skye said [21:14:24] it'll probably get ignored anyway [21:14:35] parsoid team sucks badly [21:15:42] Arlo actually fixed an issue I reported recently but yeah every other Parsoid task I made wasn't as lucky [21:15:57] Well I only made 3 but still [21:33:23] btw we rolled out Parsoid for read views on UT and DR so I guess we're cutting edge now [21:40:10] I rage quit that PortableInfobox section wrapping one and closed it [21:40:16] ignorant as hell [21:40:29] fate of multimediaviewer does not look good [21:40:43] How so [21:41:52] I think there was a separate task where someone's asking "can we just disable section wrapping" so it might get implemented at some point anyways [21:41:54] https://cdn.discordapp.com/attachments/1006789349498699827/1495902355236065471/Screenshot_2026-04-20_at_22.41.50.png?ex=69e7ef22&is=69e69da2&hm=9540eac69bd17a9042114de29f0e93580590f2b08d5c83404c3e16eaea69a30a& [21:42:07] Oh lol [21:42:22] Did they recently add those, I just saw it on RelatedArticles today when I was submitting a patch [21:42:53] Nov '25 I guess it wasn't that recent [21:43:05] first i've seen it lmao [21:43:22] not that I have much occassion to visit that article i guess [21:43:38] I guess that team in particular tried offloading some work to other teams [21:55:17] i always hated the UI of MMV anyway its horrid [22:02:01] Do we have any alternatives actually [23:00:49] Anyone currently thinking of building a MessageWall extension? [23:00:54] similar to Fandom's [23:12:33] Isn't there one already [23:34:07] No? [23:34:22] well not that i know of [23:37:05] Hmm [23:40:45] yeah but socialprofile is just too unstable [23:41:13] Somewhat stable but most of its features no longer function correctly/doesn't function [23:47:10] [1/2] Compared with 6 months ago we have about 100 less SocialProfile installations and 100 more UserProfileV2 installations, so I'd consider that a win. [23:47:10] [2/2] OA thought of making an extension of that nature, and when he does that it will likely work well together with UPV2. [23:52:17] I actually made one but the UI isn't really similar to Fandom's or final at all