[14:20:31] @cosmicalpha fyi https://phabricator.wikimedia.org/T354329 affects ManageWiki [17:54:12] Spoke to @urbanecm and if I understand properly then the default $user = null is probably the most appropriate for ManageWiki @cosmicalpha [18:14:19] If anyone here has time it'd be nice to get some help with some of the remaining configuration tasks (that need a mw-config PR) and also triaging some tasks (I've seen some related to extensions triaged as mediawiki, etc.) [18:20:00] I'll take a look in a bit. [20:15:40] Can take a look right now. [20:16:00] Thanks! I've tagged some of the config ones [20:16:29] I've managed to get us back into single digits for normal priority tasks but there's still a long road ahead! [20:16:35] It'll be a short minute to remember exactly how to do it, but once I do it should be flawless [20:16:58] For the tasks that haven't been done in more than a month I'll probably wait 1-2 weeks for a response and if not sadly close the ones that haven't responded [20:17:09] (so don't do any of the ones that have that mass message yet) [20:17:22] going to handle T11541 [20:26:42] You could probably add that to ManageWiki [20:29:01] https://github.com/miraheze/mw-config/pull/5418 this is how I have it currentlyt [20:30:27] Check your syntax [20:31:13] Fixed ✅ [20:31:57] You don't need WfLoadExtension [20:32:07] And I don't see why that can't be in ManageWiki [20:32:35] @reception123 thought this could work for now? [20:32:45] CA commented the same though [20:32:53] Maybe we should add to ManageWiki [20:33:00] It is in ManageWiki [20:33:05] oh it already is? [20:33:23] where at? [20:33:49] oh... it's already in LS [20:33:51] though I don't see it in MWS [20:33:52] https://github.com/miraheze/mw-config/blob/420acc14a13cd15a4f3c08482e72219c191faa5d/LocalSettings.php#L4992 [20:33:57] It is not in ManageWiki but is in LS [20:34:04] Your thing tries to enable TextExtracts too [20:34:14] You can let them enable text extracts normally [20:34:40] Ah I see it in LS [20:34:44] it's probably too complex to configure through ManageWikiSettings [20:34:59] by complex I mean it allows you to enter any class in there [20:35:10] [1/6] would it be something like: [20:35:11] [2/6] ``` [20:35:11] [3/6] '-softcellwiki' => [ [20:35:11] [4/6] 'div', [20:35:11] [5/6] ], [20:35:12] [6/6] ``` [20:35:12] It can be in MWS using the same type the discord web hooks use for multi text fields [20:35:42] I see an addition but not a subtraction [20:35:50] (already in LS I mean) [20:35:56] Do what @cosmicalpha said [20:36:18] will look [20:36:24] This has quite a bit of use to be in MWS [20:37:10] Let me DM you so I'm not spamming here with questions [20:37:23] Stay in here [20:37:24] That is what this channel is for [20:37:39] ah true [20:37:50] It is not spamming if it is related to tech [20:38:06] To add something to MWS, I'd do ManageWikiSettings.php right? nothing needs an addition in LS I'm assuming [20:38:23] You need to remove the one wiki override in LS and that is all [20:38:41] I will run a script to move to ManageWiki [20:38:42] yeah though someone would need to add those settings to the wiki through managewiki then [20:38:57] Should I notify that wiki that they'll need to change it in ManageWiki? [20:39:03] No I will do it [20:39:03] oh wait the script takes care of it [20:39:16] I'll add that to the task when it's done [20:39:53] this is.....texts as type? [20:40:01] or checkbox [20:41:17] One sec. This might make ManageWiki bloated actually, I need to check something [20:42:09] was going to ask if I had to put this in editing or parser functions [20:43:00] If we add something with this much lines we might want a whole new section for UI purposes. Let me see though there may be a better way [20:43:52] I'm not sure the viability of this, but it's possible we could link to a special page to manage this? [20:44:03] Specifically for this extension's parameters? [20:44:12] Again, not sure how easy that would be to do [20:44:41] From a UI perspective that might be the best option [20:44:43] No that is to much for one config [20:45:23] can't be done like allowed file types setting [20:45:50] That requires listing, here there is no set allowed options, is there? [20:46:10] I don't know the best way to do this, maybe it should just be done in LS for now... [20:46:19] I can check the extension's MW page [20:47:00] Yeah - the `$wgExtractsRemoveClasses` parameter could be any tag, class, or #id [20:47:09] so probably not a drop-select [20:47:50] Yeah so texts is the only way to do it if we do in MWS but that I have concerns about both performance with many new MWS elements and UI with so many possible to add there... [20:48:03] LS might be better in the short-term [20:49:06] I might be able to make MWS support arbitrary values in the tag select (like multi select but custom values being possible) [20:49:52] do you want to try that now, or move ahead with LS and then we can always go back and fix [20:50:25] I don't have time to try it right now. I have to go in like 5 minutes for a couple hours. [20:51:15] This is the current PR for LS: https://github.com/miraheze/mw-config/pull/5419 [20:51:34] If we want to move ahead with MWS I'll scrap this one [20:52:10] '-' does not work I think(?), maybe it does... just override the entire thing if not let me check though [20:52:29] there was a + above [20:52:40] so I just assumed `-` was the opposite [20:53:52] [1/2] > If the "+" operator is used, with any of these, then the merges will follow the following order (earlier entries have precedence on clashing sub keys): [20:53:52] [2/2] Yeah only + works for SiteConfiguration it seems, - would be nice though [20:54:10] Look at the PR again [20:54:12] That should be good now [20:54:15] [1/11] ``` [20:54:15] [2/11] * 1. "+wiki" [20:54:15] [3/11] * 2. "tag" [20:54:16] [4/11] * Only one may match here. And upon match, the merge cascade stops. [20:54:16] [5/11] * 3. "+tag" [20:54:16] [6/11] * These are only considered if there was no "tag" match. [20:54:17] [7/11] * Multiple matches are allowed here, although the array values from [20:54:17] [8/11] * multiple tags that contain the same wiki must not overlap, as it is [20:54:17] [9/11] * undocumented how key conflicts among them would be handled. [20:54:17] [10/11] * 4. "default" [20:54:18] [11/11] ``` [20:54:48] Yeah - I just overrode it all instead of adding or subtracting specific values [20:54:51] I think I did it correctly? [20:55:19] Let me know if I did/didn't [20:55:37] Merged [20:56:07] Thanks! [20:56:10] Np [20:56:35] Closed task in Phab [20:57:12] deployed [21:13:42] now I'll remove manual meta description and I guess will see in the morning if it works [21:19:03] nvm, I have couple of "clean" pages already, div is fetched [21:19:10] thanks <:pupCoffeeMH:766487840694599711>