[01:07:22] There isn't much we can do for HTML cache besides purging it in Varnish I think. [08:52:02] [1/2] Finally seeing OOUI (not Codex!) in Special:UserRights. [08:52:02] [2/2] https://cdn.discordapp.com/attachments/1006789349498699827/1505130696883048538/image.png?ex=6a0981b2&is=6a083032&hm=e68f825f78bbea5304700d7fa48f74fd57f9aab0dbf51c49c836ae4516a6e19b& [10:31:50] is google jail something a recently bought custom domain for miraheze needs to worry about, I know its probably good to get in with google search console at least regardless [10:32:04] I get to ask as a noob because now I'm actually in a position where I'll be attaching a domain to a wiki [10:34:56] [1/2] Definitely. If you use Google Search Console's domain move tool and set up a 301 redirect (done via Phorge) it should be fine. [10:34:56] [2/2] Most wikis don't know about this and their old Miraheze domain still shows up on Google months after the custom domain request and their canonical domain is still nowhere to be found. [10:35:49] I'm mainly scared by reports of people's domains literally not showing up a year outside of that, but if search console resolves it or if it's so obscure its a niche concern I may as well go on with it [10:36:13] if it is a good idea to age up the domain I can sit on it for a while too but if that's not necessary... [10:56:30] I believe in a domain move some authority of the old miraheze.org domain gets carried over. Bing doesn't have the domain move tool and it screwed our wiki really bad until I emailed support twice. Meanwhile the wiki did fine on Google the whole time. [11:03:08] well, will see how it goes [13:02:35] [1/5] Hello, Q): [13:02:35] [2/5] 1) is this used for configuration or its some old config/fork? [13:02:36] [3/5] 2) is local group Users blocked from the IP Information tool [13:02:36] [4/5] (`no-ipinfo`) practically used - i mean, should it be described in User groups page on Meta - group links to here ? [13:02:36] [5/5] 3) in global assistant steward group is abusefilter-modify-global right, but it should be only on meta (noone else global has it and all 3 CVT groups on meta has it locally) [13:04:15] [1/3] 1) It is still used [13:04:15] [2/3] 2) I don't believe ipinfo is deployed anywhere yet [13:04:16] [3/3] 3) that sounds like an error that should be fixed [13:07:48] [1/3] 1) okay, because i think it´s outdated, for example editsitejs for sysop, but it´s not default for new wikis - or i miss something? [13:07:48] [2/3] 2) i found some discussions about ipinfo here, but global groups has that permission so i thought it may be used in theory - but only stewards would be able to assign at this time (and trustandsafety) [13:07:49] [3/3] 3) yes, i think so - not sure how it technically works, if it´s not only for meta and on other wikis cannot filter be set to global - but it should be definitely removed [13:10:59] [1/3] 1) editsitejs wouldn't be configured in the MWE file. It can't be outdated. I don't think you're understanding what it's doing. [13:10:59] [2/3] 2) i don't believe it's used anywhere. We should probably either probably deploy it or remove it. [13:11:00] [3/3] 3) please file a task on [[Phorge]] and we will discuss with Stewards and decide how to proceed. [13:11:00]

[13:12:32] 1) oh sorry, i am stupid, i copied wrong link... i meant this... [13:13:20] 2) yeah, it´s why i am saying it, just check it [13:16:42] Probably can be opened as a ticket on [[Phorge]] too [13:16:42]

[13:17:41] [[phab:T15387]] [13:17:42]

[13:17:57] i am not really good at creating tasks, i hope its good.. [13:17:58] That's only for people setting up ManageWiki for the first time. [13:18:20] so its not related in any way to MIraheze new wikis [13:19:19] No [13:22:32] Lgtm [13:27:29] [[phab:T15388]] [13:27:30]

[14:41:56] [1/2] Are there plan to enable EmailUser anytime soon? [14:41:57] [2/2] [14:42:31] From my understanding it looks like permanent decision to disable it. [14:44:50] question per this: [14:48:30] Also i thought it´s about Mirahaze permissions so how is Fandom seetings related to it? [14:58:42] Why would you like to enable EmailUser? [15:12:38] [1/2] I don't want, but someone is telling me it's "(Temporarily unavailable in wikis, presumably a quirk)" [15:12:38] [2/2] Check diffs above [15:12:51] I just updated user rights by current reality [15:37:59] No [15:38:50] It is not a bug / quirk [15:40:04] I guess we could pull the blockemail right [15:40:10] Given we don't support email [15:40:25] But EmailUser is unlikely to come back any time soon [15:46:50] Yeah, it's my understanding, it's also why i removed it from that list. [15:47:14] Is it used anywhere except for 3 Global groups? [15:47:41] No [15:48:13] I don't think you want let admins block global users? [15:48:22] Nope [15:50:10] Correct, after assessment on what would qualify us as a 'covered entity', it was the tradeoff we made to avoid having to implement the age verification components various online safety laws [15:51:44] The scenario that would let that change is the repeal of those laws or us implementing age verification [16:14:24] Sorry if this is a bother, but what was the conclusion regarding this? Was it page HTML cache not being flushed for logged out users on changes to MediaWiki:Gadgets-definition? I'm \assuming\ this is non-intended behaviour, so should I still make a report on Phorge? [16:24:02] yeah it's html cache not being flushed, but I would call it intended behaviour [16:24:31] since flushing cache upon every update to the gadgets definition is not a wise idea [16:25:48] Dang that's crazy. [16:26:07] Was it just Varnish cache (I'm assuming the cache that got served to logged out users) [16:26:39] Since for some reason the gadget was not loaded (correctly) for logged in users [16:26:48] Either that or it was just me for some reason [16:31:16] that's a question for infra, I'm not sure what all the different layers of caching are after cloudflare caching [16:33:11] It would have been either varnish or cf [16:33:58] Your welcome to make a report on Phorge but I can't guarantee we'll change behaviour [16:34:46] It is intended that JS going through resource loader isn't differentiated on logged in v out [16:35:52] It should be impossible for the output of a load.php call to care about logged in v out [16:36:16] That's fair, it just feels like a bug that should be documented one way or another since it relates to caching [16:36:49] What actually happened [16:37:17] Because if the output of resource loader managed to vary on whether you were logged in, that's a bug with resource loader not our caching config [16:37:24] Or was it just things out of sync [16:37:34] Which might be a bug with gadgets [16:38:34] it wasn't the output of resourceloader, it was that the page html got cached, and the cached html wanted to load the gadget [16:38:51] . [16:39:28] I mean that feels like a bug [16:39:43] So the page html had a call to a gadget in that had changed since [16:40:10] the gadgets definition was updated to only load the gadget inside certain categories [16:40:43] to make that fully propagate you'd have to flush the cache of every single page on the wiki, right? [16:40:49] So logged in v logged out isn't really the issue here [16:40:56] That's a side thing [16:41:25] and what the cached page content of pages outside that category didn't update in varnish? [16:41:32] Or cf? [16:42:04] cf doesn't cache pages anyway so it would have to be in varnish [16:42:28] That feels like a bug to me [16:42:33] But maybe with gadgets [16:43:59] not sure what the performance implications would be if you flushed the cache for everything every time the gadgets definition was updated [16:44:10] Do you need to flush the cache [16:44:20] Or can you just include a revision in the load.php call [16:44:27] I can't think of any other way you'd be able to do it [16:44:41] So it loads the old version of the resources until the page updates [16:45:36] the page stores a list of gadgets that it wants to load, that being `RLPAGEMODULES`, and `RLPAGEMODULES` is embedded directly in the html [16:46:42] so as far as I'm aware the only way to stop unwanted gadget loading would be to make the change to the html itself, which would involve flushing the cache? [16:47:43] Did the gadget change in such a way it no longer worked on the existing page then [16:47:51] [1/2] Question: like there are declined extensions, is there something for variables like $wgRawHtml? Or can it be inserted under Declined extensions? Or create Declined variables section? [16:47:51] [2/2] So we can link it easily when someone requests it. [16:47:53] Or was it the same gadget just being on less pages [16:48:51] same gadget was updated to load on less pages, but the pages it was already loaded on didn't get updated [16:49:10] How did that break the pages then [16:49:15] Or did they just not update [16:49:25] because the gadget code itself was also updated [16:49:51] so e.g. the main page was loading the new version of the gadget, but it shouldn't have loaded the gadget at all [16:50:24] Could be solved with versioning the gadget then? [16:51:32] I guess that would work yeah [16:52:51] I guess that's a feature or bug request to file then [16:53:05] I don't know whether we do