[00:19:57] [1/3] What are the rendering differences? They seem identical to me. [00:19:58] [2/3] https://cdn.discordapp.com/attachments/1006789349498699827/1547763595092295680/image.png?ex=6aa49aad&is=6aa3492d&hm=58942a80edb589b911e2b73b85dd609b2ba88f2720b313d37190d6e678df1b99& [00:19:58] [3/3] https://cdn.discordapp.com/attachments/1006789349498699827/1547763595390230608/image.png?ex=6aa49aad&is=6aa3492d&hm=263a15b861664bc0f0c48787a9bb5747d791589be638642cdee3e0ab2bf226b8& [00:32:31] One renders off-center to me? [00:35:43] The one on the left among with several others hides part of the model outside - and pivots from an off-center point. [02:17:53] just remembed https://github.com/miraheze/CreateWiki/pull/605 exists and is now the oldest open pr on CW [02:18:04] this makes me sad and feel like a clown :Clownge: [02:24:44] A lot of that was my fault for not merging earlier. It was almost completely correct and good enough to merge them fell so far out of date that a bunch of conflicts happened and CI wasn't working. [02:28:20] who knows, maybe ill get to void's feedback this weekend (zero promises), CI i still got no idea and dont rly wanna touch [02:28:21] who knows [03:13:54] [1/2] Finding available tech atm [03:13:55] [2/2] I can't login to my wiki (snxyzmetawiki), every time pressing login it shows I have disabled cookie [03:14:23] did you purge cache and cookeis entirely [03:19:37] See if it works in an incognito window. If it does then try to clear cache and cookies as pix said and try again. [05:13:05] So clearing MH cookies works, but I wonder why it happens on my mobile phone [08:24:21] 99% of the login error isn't "disabled cookie" as shown. It's something screwed up between their login and our Central Auth [08:56:36] Try a different browser maybe? [12:24:05] I don't have any other browser atm, but well it resolved itself [13:59:26] is there a way to set the HAWelcome user as a bot [13:59:35] its not registered on my wiki so i cant change its user groups directly [14:00:30] Link to contribs for it [14:02:22] the account? [14:02:25] [16:00:29] Seems like an issue with the default camera position, which is odd because when I visit https://maille.wiki/File:Coyote_maille.glb again the camera is properly centered... [16:06:03] https://cdn.discordapp.com/attachments/1006789349498699827/1548001674423963708/image.png?ex=6aa57867&is=6aa426e7&hm=3bc759c0e5baf54f91b16b2b64645c618bb03e9e6490d12e4edfbef0059239b8& [16:06:18] https://cdn.discordapp.com/attachments/1006789349498699827/1548001734419288224/image.png?ex=6aa57875&is=6aa426f5&hm=3192d0ec7efbbe1376bc9f4ecfb3a85588f96b55741963c8e0adb67e91e67051& [16:11:58] I assume if it has a global account you can just forcibly create a local account? [16:12:45] how [16:13:11] Special:CreateLocalAccount [16:13:12] I think bureaucrats have it [16:13:56] https://cdn.discordapp.com/attachments/1006789349498699827/1548003666995191918/image.png?ex=6aa57a42&is=6aa428c2&hm=81b27d51178c3fc454300ac373474244802433c2798efd7fb2fea03ce9601b6a& [16:14:37] nvm they are not given locally [16:14:47] I guess wait for someone who can [16:15:26] actually idk if it's even a central account [16:15:49] Is it `HAWelcomebot` that's the system user [16:16:42] didn't realise User::newSystemUser didn't make it global [16:29:27] [1/2] I can reproduce it again. Not sure why it was intermittent. [16:29:28] [2/2] This likely has to do with how the viewer determines the bounds of the object. I'll see if there's a fix later today. [17:28:12] [1/2] Cool. 🙂 [17:28:12] [2/2] I could try to recenter objects, but since they work on the original website, I thought I’d check here. 🙂 [17:32:18] no its just `HAWelcome` [17:34:19] ok then it clearl ydoesn't [17:36:58] It's possible to manually specify camera position but in this case it would be better to fix the positioning problem in JS. [17:43:07] No, I mean, at least some of the files looks off-centre in blender. I raised this because several of the files I couldn’t find the off-centre error. [19:42:44] @posix_memalign okay I figured out how to fix the interwiki issue without changing parsoid. Pretty simple. Though having it conflict with interwiki I think is bad practice regardless but still fine I guess. [19:46:05] https://github.com/miraheze/mw-config/pull/6530 [19:52:49] yeah that fixed it [20:05:01] Didn't think of that lol. I guess I was thinking about Lua where setting something to nil is a no-op. [20:18:54] [1/2] @cosmicalpha [20:18:54] [2/2] Still an issue on meta though: https://meta.miraheze.org/wiki/User:PetraMagna/sandbox?useparsoid=1 [20:19:05] Purge the page? [20:19:14] Nevermind it's good now. [20:19:21] I purged a few times but it stayed the same [20:19:31] And then when I open the link again it works [20:19:41] Maybe parsoid's cache is handled separately [20:19:42] I had to purge SR/RW and it immediately started working after that. [20:20:47] I tested on meta on mwtask181 by proxying before deploying just to confirm it worked there first. [20:21:35] Btw should we run `ManageWiki:ResetWikiCaches` on all wikis since I'm still seeing File ns pages in the sitemap? [20:27:10] Don't think that would fix it? It could I guess though. [20:27:56] It was due to cached config not being updated after LocalSettings has changed. [20:28:50] Does that update LocalSettings also? [20:29:05] I guess it would if it changed the mtime of the ManageWiki cache files. [20:29:58] I think it's purely a local cache issue, since new changes to mw-config will not be propagated until the wiki changes something on ManageWiki or until some other thing resets the cache file. [20:30:25] Wait no I think LocalSettings might be fine. [20:30:41] Lemme check the sitemap PR. [20:30:56] If you need to feel free to try it but use --all-wikis, not mwscript all, do mwscript metawiki for the script with --all-wikis. [20:31:47] Ah I see. It only edited ManageWikiNamespaces.php but not LocalSettings.php. [20:32:46] That should still reset it though. https://github.com/miraheze/mw-config/blob/ae29e1e6bc527766b1e17805decb904aaa3f683d/initialise/MirahezeFunctions.php#L526 [20:33:09] So without a LocalSettings default it falls back to MediaWiki's default. Only when ManageWiki gets changed will the cache be updated. [20:33:43] That is odd because I merged the commit a long time ago and still had to do https://discord.com/channels/407504499280707585/808001911868489748/1545348466052694117 to get rid of File NS pages from the sitemap. [20:34:28] And on https://stellasora.miraheze.org/wiki/Special:ManageWiki/namespaces/6 File NS is not in `$wgSitemapNamespaces` but the sitemap from a few days ago still shows File NS pages. [20:35:30] Query what it thinks with shell, and check in the config files to see..Id like to figure out what happened as that shouldn't happen. [20:35:51] Also check mtimes. [20:36:20] So on `/srv/mediawiki/cache/strinovawiki.php` I do see `$wgSitemapNamespaces` set to ManageWiki's default. On `/srv/mediawiki/cache/stellasorawiki.php` I don't see `$wgSitemapNamespaces` at all. [20:36:53] what about in the config- version? [20:37:13] [1/5] In shell, `strinovawiki` shows ManageWiki defaults, and `stellasorawiki` shows [20:37:13] [2/5] ``` [20:37:14] [3/5] > $wgSitemapNamespaces [20:37:14] [4/5] = false [20:37:14] [5/5] ``` [20:38:00] Same symptoms as the non-config version in https://discord.com/channels/407504499280707585/1006789349498699827/1548069710413959313 [20:40:11] Was it changed in ManageWiki on the wiki? [20:40:45] The MediaWiki default is false. If it was never changed in ManageWiki it would be false. [20:42:39] The default was changed in a PR: https://github.com/miraheze/mw-config/pull/6405 [20:43:18] No changes were made to ManageWiki after the deploy. [20:43:23] That doesn't change the default. That only changes ManageWikis default. If it was never changed in ManageWiki that will never apply. [20:43:35] Unless it is also added to LocalSettings.php [20:43:56] Yeah that's basically what I hypothesized in https://discord.com/channels/407504499280707585/1006789349498699827/1548068906680193186 [20:44:22] But a ManageWiki cache purge would have the same effect I think. [20:44:50] Since it re-populates the cache files in `/srv/mediawiki/cache` with ManageWiki defaults. [20:45:19] It shouldn't. If that actually works that is actually the bug. Default values shouldn't be added to the cache unnecessarily. If the default differs from core, the default should be added to LocalSettings.php. [20:46:28] Hmm lemme test this. [20:46:38] I mean you can run resetwikicaches if you want just don't use it with forewchwikiindblist of the farm will crash. [20:47:14] That's why it has a --all-wikis option. [20:47:48] [1/12] Ok. It might have been a bug because after I run https://discord.com/channels/407504499280707585/808001911868489748/1548072269035733075 I see [20:47:48] [2/12] ```php [20:47:48] [3/12] 'wgSitemapNamespaces' => [ [20:47:49] [4/12] 0, [20:47:49] [5/12] 2, [20:47:49] [6/12] 4, [20:47:49] [7/12] 10, [20:47:50] [8/12] 12, [20:47:50] [9/12] 828, [20:47:51] [10/12] ], [20:47:51] [11/12] ``` [20:47:52] [12/12] in `/srv/mediawiki/cache/stellasorawiki.php`, which is just ManageWiki's default. [20:48:15] Yeah that really shouldn't happen. Not a huge issue though but default mismatch should really be in LS. [20:49:14] I can just submit another PR I guess [20:49:22] Better to fix this properly than to purge everyone's cache [20:49:44] Agree. [20:50:34] Anyway now I have something else to look into lol. Thanks for that info though. I should do some permanent fix to fully fix it from happening again. [20:51:34] Can't imagine what your todo list (mental or physical) looks like lol