[00:46:22] see for my opinion on allowing users to enable parsoid [04:25:37] I seeeeeee [13:25:27] [1/3] @kostajh Hi! When testing ConfirmEdit's hCaptcha integration on the 1.46 branch, we encountered an infinite captcha loop documented in https://issue-tracker.miraheze.org/T15679. It seems to be caused by assuming that a `sitekey` field exists in the response, even though in [hCaptcha's documentation](https://docs.hcaptcha.com/#verify-the-user-response-server-side), `sitekey` is [13:25:27] [2/3] only sent as a part of the request and isn't in the response. Do you have any ideas why the sitekey check was added in the first place? [13:25:27] [3/3] This seems unnecessary to me because even if the user tries to reuse a token from a different site, hCaptcha's verification will fail because the sitekey does not match. Since hCaptcha's server will reject the request anyway, there is no reason to check the sitekey again when the hCaptcha's response comes back. [14:01:45] can we add a column for the phorge import workboard for "needs data dump"? would help to be able to see at a glance which import requests are immediately actionable [14:07:03] what do we think of adding this setting to managewiki https://www.mediawiki.org/wiki/Manual:$wgFixDoubleRedirects (per a phorge request) [14:20:58] possibly as a restricted setting ^ [14:31:07] Can we set requires private wiki or something [14:31:10] Given the warning [14:31:15] hm [14:31:26] I don't massively see the benefit as double redirects don't cost a lot [14:31:36] may not suffice for the wiki asking too [14:31:37] lemme see [14:31:44] And it will allow page move vandalism to propagate easily [14:31:50] Link to task [14:31:52] Pls [14:32:02] https://issue-tracker.miraheze.org/T15796 and https://issue-tracker.miraheze.org/T15849 [14:32:57] My answer to T15849 would probably be no [14:33:10] I don't think we can adequately control the risk [14:33:38] We can enable it on individual wikis if they agree to moving move away from everyone [14:33:42] To reduce that risk [14:34:00] We can't add to ManageWiki with requires move not in * or user though [16:19:18] @thewwrnerdguy https://issue-tracker.miraheze.org/T15626 is this still going to need to review all installed extension rights [16:24:22] yes [16:24:36] but I don't know how many extensions would be creating a new right in 1.46 [16:25:52] exttest wiki has most of them enabled so [16:26:19] that's a start [16:26:29] ok yeah we could just enable a load on one wiki and then check off extensions [16:26:39] maybe we could just do that on wwrtest3 again [16:26:43] headachewikibeta [16:26:53] want me to just go and click all the buttons [16:27:00] chewikibeta is my favourite star wars characters [16:27:45] ill avoid any that have any sort of restrictions or conflicts with other extensions to not cause confusion on what's been tested yet [16:27:47] I think it would be better to put an extension toggle in place first [16:27:52] ? [16:30:38] would also require knowing groups that extensions already give [16:31:14] does beta still support 1.45 [16:31:27] Should do [16:31:29] With some pain [16:31:41] Or we make a temp testing wiki on prod [16:32:10] You could get enough information from diffing extension.json between 1.45 & 1.46 [16:32:29] [[mh:sweethopesandprayers]] [16:32:29]

[16:32:41] oh right i broke that didn't I [16:32:44] maybe [16:32:45] idc [16:33:11] (that was a wiki to test CW being not broken) [16:33:27] yea but doing that for like 300 exts is [16:33:55] Painful [16:34:01] But also automatable [16:34:06] morerandomstuffwikibeta [16:34:13] better be [16:34:22] If someone wants to be nerd sniped, it is probably near as quick to write a script to automate it [16:34:31] o [16:34:51] but yeah extension.json probably better way to look [16:35:09] since non-core groups would be in there automatically [16:35:21] hm [16:35:34] who wants to write the script [16:35:45] Not me, I'm too lazy [16:35:53] if Python would be fine I'll do it [16:35:53] puts finger on nose [16:36:04] It should [16:37:17] in py we trust [16:37:31] what would be the best way to make the script then? I suppose I could write it in vim on mwtask181 but is there an easy way to do it in python-functions [16:38:36] Just write it in vim and we'll make it official later [16:39:12] 'official' [17:28:13] [1/2] there's basically no error handling but this is done [17:28:13] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1538600280029921593/p.py?ex=6a8344ac&is=6a81f32c&hm=ff9c45e1de63f5841c8f07705b1cb62c63c2d1fd66fa7bbcd21fe0587a4815b6& [17:28:57] to be used like `./ext_diff.py 1.45 1.46` [17:32:00] (on test151) [17:54:42] @posix_memalign can you pull the list of wikis using Data Transfer? I want to look around to see if there's any real heavy usage so we can consider booting it (https://issue-tracker.miraheze.org/T15602) [19:33:33] https://cdn.discordapp.com/attachments/1006789349498699827/1538631821074497636/image.jpg?ex=6a83620c&is=6a82108c&hm=12e720a705ce93b230afa06b885187fd3830c27755b98bedc37d420a6fa1b16b& [19:34:40] @Discord Moderators [19:36:31] 👀 [20:06:30] Hello all; I am trying to make a system message insert a {{subst:...}}; is there a way to make the subst not work on the systemmessagepage, but on the page where it's inserted? [20:06:31]

[20:10:33] ``? [20:16:44] I actually tested this before responding to your ticket, I tried {{safesubst:XYZ}} and that seems to have worked [20:16:45]

[20:17:20] @thewwrnerdguy speaking of you closed the ticket as resolved, would it usually be invalid since it would have been an SR request? [20:17:32] [1/2] I was drafting this but left the house before submitting [20:17:32] [2/2] > This is now done and the extension is enabled on maillewiki. Note I am closing as 'invalid' as the customary place for requesting restricted extensions in ManageWiki is [[SR/RC]], not Phorge, but it's not enough of a deal to warrent redirecting. Please let us know if you run into any issues, and happy editing. [20:48:08] well think about it this way: if it had been on SR/P you'd have marked it as done [20:48:49] if it's something actionable and you've taken the action then it's resolved [20:56:59] eh, sure [21:08:11] that's how I consider it yeah [21:47:10] [1/3] Thanks; now I am trying to understand another thing. [21:47:10] [2/3] Everything works fine, but subst substs a template that’s just supposed to be included… [21:47:11] [3/3] https://maille.wiki/MediaWiki:Autocreatecategorypages-stub [21:48:15] This code is supposed to add categories - in some categories dynamically, in others statically. [21:49:16] The part {{sortbyweave}} get’s prematurely substed, but I don’t see why. [21:49:18]

[21:51:15] I would not count on ACCP to be very smart with it's parser insertions ngl [21:53:54] Yeah, but it’s supposed to produce {{sortbyweave|{{subst:#sub:C}}}} not {{subst:sortbyweave|…}} [22:04:20] if you're doing any complicated subst: shenanigans I'd highly recommend writing it in Lua [22:08:23] no attached file, presumably ask them if they have a dump for us? https://issue-tracker.miraheze.org/T15856 [22:17:35] subst is a gift from the gods [22:17:47] although i suspect i'm not using it to its full potential [22:21:36] Some bughunting, And I believe it's now in working order. 🙂 [22:31:50] the entire performance of the battle cats wiki's structured data still relies on subst