[01:29:53] [1/3] Would like some feedback on my Module to create documentation from a TemplateData-inspired JSON structure. [01:29:53] [2/3] [01:29:53] [3/3] I used it on a different wikifarm and rn try to iron out minor issues, namely that the `h3` parameter seems to always be considered "true", even when it isn't... Tho, this may be an issue with my IsTrue template... Idk. [01:41:06] [1/2] One thing I would like to change is try and use the syntaxhighlight tag instead of the pre one. [01:41:06] [2/2] But in my testing does it not work. Probably because it puts it on a single line instead of separate ones. I also wonder, if I get it to work, would links still function like with the pre-tag? [01:54:15] Use `frame:extensionTag` for `syntaxhighlight` [01:54:56] I'm curious. [01:55:16] Regarding the steward team, have they been seeking for worthy users? [01:55:27] Because last time I saw the team it's pretty small [01:55:53] (No, I'm not trying to apply. I most likely don't meet the requirements and I'm just curious to see what's on the surface.) [01:56:59] [1/2] Do you mean like `output:extensionTag`? [01:57:00] [2/2] Because I'm not sure how I would use frame with the output. [01:57:34] https://cdn.discordapp.com/attachments/407537962553966603/1459727908724805845/image.png?ex=6964550d&is=6963038d&hm=a7e1201a2c63d9532b8bc58343f0202d742ea754dba883621273ca78666fb17f& [01:57:53] [1/2] Result: [01:57:53] [2/2] https://cdn.discordapp.com/attachments/407537962553966603/1459727987602882680/image.png?ex=69645520&is=696303a0&hm=f925dca837b15611773852b127d3e4a627357cf5638f21ae3dd47f81896fde00& [01:58:24] If you are using mw.html you can use `:node` IIRC [01:58:31] no [01:58:37] i think theyre doing fine tbh with 6 stewards [01:58:38] I do [01:58:56] I thought there were 7 stewards in the team last time?? [01:58:59] I must be misremembering [01:59:07] https://cdn.discordapp.com/attachments/407537962553966603/1459728301793738977/image0.jpg?ex=6964556b&is=696303eb&hm=a13a8b8c37cbe2832f2a56eb5022a2ec2d7dbe9134c00fa0477ec828548c0df2& [01:59:11] I should check out meta more so I can learn a lot more about both the project and stuff. [01:59:14] OH [01:59:24] `div:node(frame:extensionTag(...))` [01:59:54] Considering the projects runs under application-based service, I see what's going on and stuff. [01:59:59] Well, on the surface ofc [02:00:15] seriously though the super blox 64 wiki is still on barebones and i've carried it [02:00:19] and idk css [02:00:24] so uh [02:00:27] im doomed [06:39:28] Good evening Evey [06:39:32] Everyone [06:42:30] is it possible to make cooler looking discussion pages [07:51:32] Heya! [08:10:03] [[64:Main Page]] how does that one work [08:10:04]

[08:10:07] oops [08:10:18] [[mh:64:Egg]] [08:10:19]

[08:10:33] what [08:11:20] explain more on cooler looking [08:12:11] nevermind aobut it [08:26:31] oops [08:27:01] use the 🗑️ react to delete them btw [08:27:08] oh right [08:27:09] i can just do [08:27:10] that [08:27:25] its taking a bit [08:27:33] sleepy bot [08:27:40] @wiki bot hi wake up [08:27:41] maybe it stops listening after like 30s [08:28:58] Sob [12:26:16] yeah, it only waits for a bit [12:27:15] https://github.com/Markus-Rost/discord-wiki-bot/blob/27a99ebc2ca4f8c8af57ee86cebbe7ca5da325a3/util/functions.js#L605 30 sec [12:27:27] <_zombi_> [1/4] does anyone know why things like this are happening? purging the pages doesn’t help [12:27:27] <_zombi_> [2/4] https://cdn.discordapp.com/attachments/407537962553966603/1459886421002424533/IMG_1797.png?ex=6964e8ae&is=6963972e&hm=177b3d1c50196c24b0a0fd518389ca179733b9e40d9e829564e2bbb673dce1bf& [12:27:27] <_zombi_> [3/4] https://cdn.discordapp.com/attachments/407537962553966603/1459886421933555866/IMG_1798.png?ex=6964e8ae&is=6963972e&hm=00320e2c6ce9702010966a3f9ca47ca07c6a9dcc5c23eab99fbca32d8b9a5e24& [12:27:28] <_zombi_> [4/4] https://cdn.discordapp.com/attachments/407537962553966603/1459886422717632584/IMG_1799.png?ex=6964e8ae&is=6963972e&hm=ebc1a85acf6be84c18885a2c913e28e1e0097c9cf24bdc8b3eaa2a938bfd84c0& [12:28:13] does the null edit help? [12:28:41] <_zombi_> the null edit? [12:28:55] https://en.wikipedia.org/wiki/Help:Purge#Null_edit [12:29:26] <_zombi_> ah. yeah i did that, also didn’t fix it [12:29:31] gotcha [12:30:00] the annoying part about this instantcommons bug is that there are no damn logs of why this is not working [12:30:05] @_zombi_can you link the page [12:30:54] <_zombi_> [1/3] it’s multiple pages 😭 i’ll link one [12:30:55] <_zombi_> [2/3] https://concordiancommonwealth.miraheze.org/wiki/2015_So_Peppian_constitutional_crisis [12:30:55] <_zombi_> [3/3] (this is the one with those first two screenshots) [12:31:19] <_zombi_> the image shows here but not in the actual page ? [12:31:24] lets kill instantcommons [12:51:46] <_zombi_> using ?action=purge seems to have worked for some of them [12:52:40] No [12:52:58] It smells of a bastion problem [12:52:59] lets revive instantcommons [12:53:03] Probably just one of them [12:53:19] Or Wikimedia rate limiting [12:53:31] Instant commons has shitty negative caching [12:56:36] @rhinosf1 im more concerned that the quickinstantcommons failures aren't showing up [12:56:45] nothing in logs [12:57:05] Does QIC log failures [12:57:11] We turned off most of its logs [12:57:27] @paladox do we have any logs at the squid level? [12:57:53] We have some logs but i don't think it tells us much [12:58:11] I mean anything is better than nothing [12:58:21] we have access logs [12:58:25] It'll be requests for commons.wikimedia.org/w/api.php [12:58:25] https://github.com/miraheze/mw-config/blob/main/LocalSettings.php#L7397 i think we should log them [12:58:47] i've scrolled through all streams for two wikis now and nothing useful [12:58:50] I have no idea what uses that channel [12:58:51] either that or im blind [12:59:59] it only shows like commons.wikimedia.org (no path) and it is 200 [13:00:21] No 5xx or 4xx for any commons request? [13:00:24] On either bast [13:00:59] 1768136266.382 403 10.0.15.114 TCP_TUNNEL/200 6934 CONNECT commons.wikimedia.org:443 - HIER_DIRECT/ip - (is what it looks like) [13:01:21] anything for `https://upload.wikimedia.org/wikipedia/commons/thumb` or just `upload.wikimedia.org` then ? [13:01:54] It's failing very badly so I think it's the api metadata call that is breaking [13:02:04] mmmmm [13:02:10] What's the 403 in that for [13:02:18] There's a 403 and a 200 [13:02:57] i dunno but the figure above has a higher number so that isn't the status [13:03:53] [1/5] ``` [13:03:53] [2/5] [root@bast161:/var/log/squid]# cat access.log | grep commons.wikimedia.org | grep MISS [13:03:54] [3/5] 1768111462.874 41 10.0.15.150 TCP_MISS/301 258 HEAD http://commons.wikimedia.org/ - HIER_DIRECT/ip - [13:03:54] [4/5] 1768120048.531 41 10.0.18.106 TCP_MISS/301 269 HEAD http://commons.wikimedia.org/w/index.php - HIER_DIRECT/ip - [13:03:54] [5/5] ``` [13:04:47] Request time [13:06:48] Turn some logging channels up then [13:06:57] Maybe turn instant commons logs to debug for like half an hour [13:07:02] They are extremely spammy [13:07:16] aight bet [13:07:16] the first one says `Sunday, 11 January 2026 06:04:22.874` [13:07:52] The first bit is a unix timestamp to the millisecond [13:13:23] urgh i dont have a not working exampe right now [13:19:36] i think i saw something [13:20:24] [1/2] ``` [13:20:24] [2/2] HTTP request to https://commons.wikimedia.org/w/api.php?titles=File%3AMotivator6645769.jpg&iiprop=timestamp%7Cuser%7Ccomment%7Curl%7Csize%7Csha1%7Cmetadata%7Cmime%7Cmediatype%7Cextmetadata&prop=imageinfo&iimetadataversion=2&iiextmetadatamultilang=1&iiurlwidth=120&format=json&action=query&redirects=true&uselang=en failed 429 -``` [13:20:32] @rhinosf1 @paladox ^ [13:20:43] 429 is a rate limit [13:21:00] do we get to ask wikimedia nicely or figure out something else [13:21:26] i'll make a task for reference [13:21:54] rate limit would be easier to hit as it's coming from one ip [13:22:20] but yeh, are you able to ask for a higher rate limit for our ips @rhinosf1 [13:22:32] wish they supported ipv6 [13:23:05] [1/4] wait they do? `host commons.wikimedia.org [13:23:05] [2/4] commons.wikimedia.org is an alias for dyna.wikimedia.org. [13:23:05] [3/4] dyna.wikimedia.org has address 185.15.59.224 [13:23:05] [4/4] dyna.wikimedia.org has IPv6 address 2a02:ec80:300:ed1a::1` [13:24:11] [1/2] > [root@puppet181:/home/paladox]# curl https://commons.wikimedia.org [13:24:12] [2/2] > curl: (35) OpenSSL/3.0.17: error:0A000410:SSL routines::sslv3 alert handshake failure [13:24:13] huh? [13:25:38] we may be able to switch off using the proxy for instantcommons but only when we've verified that requires from mw* work [13:25:42] needs to go through bast first [13:25:54] weird, it has a ipv6 address [13:26:24] i can ping it as well, just can't curl it. [13:26:33] huh [13:26:49] does it work with `-x bastion.fsslc.wtnet:8080` [13:26:55] [1/2] > [root@puppet181:/home/paladox]# host commons.wikimedia.org [13:26:55] [2/2] > Host commons.wikimedia.org not found: 5(REFUSED) [13:27:10] refused, fun [13:28:31] [1/9] > host commons.wikimedia.org 2606:4700:4700::1111 [13:28:31] [2/9] > Using domain server: [13:28:32] [3/9] > Name: 2606:4700:4700::1111 [13:28:32] [4/9] > Address: 2606:4700:4700::1111#53 [13:28:32] [5/9] > Aliases: [13:28:32] [6/9] > [13:28:33] [7/9] > commons.wikimedia.org is an alias for dyna.wikimedia.org. [13:28:33] [8/9] > dyna.wikimedia.org has address 208.80.153.224 [13:28:33] [9/9] > dyna.wikimedia.org has IPv6 address 2620:0:860:ed1a::1 [13:29:24] should I announce this [13:30:34] yeh [13:33:41] ok so it seems to be due to our /etc/resolv.conf [13:33:50] some how our resolver is failing it? but it works for google? [13:51:45] Can you file a task? [13:51:49] On our side [13:51:58] And I'll pic it up in a moment [13:52:05] Mark as a security one [13:52:31] shit [13:52:44] https://issue-tracker.miraheze.org/T14794 [13:53:32] i guess you can make that a subtask of ? [13:53:39] or just yeet entirely [13:54:40] @paladox can we up our caching as an interim measure too [13:54:50] we can increase prefetch [13:54:59] it's at 500 (whereas the default is 1000) [13:56:26] [1/16] should probably raise it in qic as well [13:56:26] [2/16] ``` [13:56:27] [3/16] [ [13:56:27] [4/16] "class" => "MediaWiki\Extension\QuickInstantCommons\Repo", [13:56:27] [5/16] "name" => "wikimediacommons", [13:56:28] [6/16] "directory" => false, [13:56:28] [7/16] "apibase" => "https://commons.wikimedia.org/w/api.php", [13:56:28] [8/16] "hashLevels" => 2, [13:56:29] [9/16] "thumbUrl" => "https://upload.wikimedia.org/wikipedia/commons/thumb", [13:56:29] [10/16] "fetchDescription" => true, [13:56:29] [11/16] "descriptionCacheExpiry" => 43200, [13:56:29] [12/16] "transformVia404" => true, [13:56:30] [13/16] "abbrvThreshold" => 160, [13:56:30] [14/16] "backend" => "wikimediacommons-backend", [13:56:31] [15/16] ], [13:56:31] [16/16] ``` [13:56:55] or we can disable description fetching entirely [13:57:36] Its description fetch that's getting rate limited [13:57:52] So increasing its cache expiry would be an option [13:58:12] It's only 12 hours [13:58:50] the real problem is commons.wikimedia.org failing from our ipv6 only hosts even though it'd work using cloudflare ipv6 dns service. [13:58:55] for some reason googles works [14:00:08] Spreading our traffic across multiple IPs is not the way to reply to being rate limited [14:01:53] updating descriptionCacheExpiry would be such a bother urgh [14:03:03] guess you could say commons wasnt. quickinstant [14:03:23] or rather too instant [14:07:11] @paladox 2602:0294:0000::/48 would be our v6 range wouldn't it if we could resolve them [14:08:10] for bast? [14:08:21] @paladox for any of our servers [14:08:35] All of our IPv6 traffic on cloud* is in one range [14:08:58] oh i guess yes [14:10:11] https://phabricator.wikimedia.org/T414282 [14:10:40] aw i cant see D: [14:10:49] What's your wmf Phab [14:10:56] Pskyechology [14:11:20] cheers <3 [14:11:21] You can now [14:24:53] https://phabricator.wikimedia.org/T81605 [14:27:03] oh god one of those "task has finished school" tasks [14:27:25] i can tell people really love ipv6 [14:32:57] My isp still has no IPV6 support [14:33:22] how's the ipv4 draught in the uk even [14:35:12]