[00:06:14] https://cdn.discordapp.com/attachments/1006789349498699827/1414763793996845128/o.mp4?ex=68c0c0f5&is=68bf6f75&hm=7891792549418cfa94c70bd63a429ef6a405bc5afbb738924bc42dedb829d099& [00:07:10] Its probably cache issues between mediawiki servers. [00:07:39] I will look once I start the sql stuff for the rest of the wikis [00:08:40] I see. It's not a huge deal if this is broken for a few hours while servers figure out their caching. [00:09:20] If you make any ManageWiki change it could trigger a recache that might fix it. [00:12:02] [1/2] Not a bureaucrat on this wiki, unfortunately. It's not causing anything to break except my previews (so far), so I'm not too worried. [00:12:02] [2/2] The wiki where I can freely toggle extensions starts with "S", so it's not on 1.44 yet. [00:13:07] All wikis will be within the next 15-20 minutes [00:20:09] luckily im putting these upgrade commands in screen sessions... as my shell keeps disconnecting right now lol [00:43:25] We need to give CA some money to get a better internet service. [01:06:07] [1/2] @cosmicalpha Original exception: [78fcdccf140f33504927e8da] 2025-09-09 01:05:49: Fatal exception of type "Wikimedia\Rdbms\DBQueryError" [01:06:07] [2/2] https://strinova.org/wiki/Main_Page [01:08:05] And it's back up. Probably a temporary issue. [01:08:31] I ran sql early on that wiki, some wikis will give db query errors until it completes. [01:08:58] I didn't think there was some incompatible SQL but turns out there is. [01:10:06] I sampled a few wikis and they seem to be all fine. Probably a very rare occurrence. [02:30:55] [1/2] Looks like `notcategory` counts toward `maxCategoryCount` in DPL4. Previously it did not in DPL3. [02:30:55] [2/2] Do `category` and `notcategory` have the same performance overhead? It seems to depend on how DPL performs the filtering. If `notcategory` is handled by checking the category on each page, having lots of them seems fine. If `notcategory` fetches all members of a category, it would be as expensive as `category`. [02:32:24] [1/5] TBH the maximum of 4 categories never made sense to me since the same DPL call can be broken into multiple calls to query the same number of categories. [02:32:24] [2/5] Asking because I'm seeing this [02:32:24] [3/5] ``` [02:32:25] [4/5] Extension:DynamicPageList4 (DPL4), version 4.0.0-alpha.5: Error: Too many categories! Maximum: 4. Help: increase

$wgDplSettings['maxCategoryCount']/code to specify more categories or set $wgDplSettings['allowUnlimitedCategories'] = true;/code for no limitation. (Set the variable in the wiki's LocalSettings.php/code configuration file.)
[02:32:25] 	  [5/5] ```
[02:35:39] 	  This was an intentional change because yes they have the same overhead and it was always intended to do the same it was bug that it did not count.
[02:37:13] 	  They both use like queries.
[02:45:50] 	  Is there a chance this config can be raised globally to something like 10? 4 seems overly restrictive. If not, I'll just ask the local bureaucrat to request a `mw-config` change.
[03:13:46] 	  I dont see why we couldnt.
[03:26:26] 	  I hope nothing blows up overnight... but sql stuff is still running.
[03:30:21] 	  Its only to b wikis right now.
[03:32:32] 	  @cosmicalpha a method I tried to try and segment it a bit was to run one script on public wikis and one on private wikis, since both database lists exists
[03:33:45] 	  then there would be more. I segmented by closed, inactive, and active, so splitting that would rego to closed and inactive again also and there would be a lot more that way.
[03:34:00] 	  I have a custom database list im running on it.
[03:34:06] 	  oh that’s nice
[03:34:48] 	  I also segmented it by that too last time (except by active) but it honestly flew over my head that it would run it again on closed and inactive wikis
[03:35:27] 	  I added permanent closed and inactive database lists in the hook also now
[03:35:54] 	  and support for them in mwscript
[04:12:26] 	  1.43 is no more! (I have removed all the stuff for it now, switched everything fully to MediaWiki 1.44)
[05:25:50] 	  rip 1.43
[08:01:50] 	  I'll probably have to update my CSS, or maybe not.
[12:49:17] 	  There seems to be an extension that redefines the non-namespaced class alias for Html... ScratchBlocks worked fine on exttestwikibeta, but it's broken in production as it still uses \Html
[12:49:20] 	  That's quite annoying for testing
[13:12:39] 	  oh what the
[13:26:22] 	  chameleon is the only one I can find defining Html, but it's not enabled on exttest 
[13:33:23] 	  Mermaid is using \Html too...
[15:36:19] 	  Just wanted to put this on the record if we ever need to test extensions in prod for next update, just lmk and I can always enable on PTW, I have no issue breaking things for testing
[15:43:29] 	  Thanks, though the specific issue in this case was that one extension fixed a problem multiple others had, so the problems weren't found. The same thing would have happened on prod and can theoretically only be avoided by enabling only one or a few extensions at a time
[17:02:08] 	  Does the patch system in mediawiki-repos () work / did anybody ever test it? We have 4 patches deployed right now for 1.44 compatibility, but it would probably have been better to add them via the repo instead of manually doing so via git
[18:19:29] 	  No
[18:19:40] 	  The patch to make it work is pending
[21:29:53] 	  i wonder if we can have managewiki purge load.php cache on extension update
[21:31:04] 	  the silly purge all cache button in cloudflare :3
[21:33:39] 	  we should press it on april 1st
[21:53:19] 	  I mean assuming Cloudflare allows you to purge something like /load.php?* Then sure
[21:53:32] 	  Otherwise it would be impossible to know the exact URL that needs putting?
[21:54:03] 	  You can build a derivative context and get the startup modules and the skin but
[22:02:57] 	  you can purge prefixes
[22:04:18] 	  But you cant purge query strings by prefix
[22:04:28] 	  https://developers.cloudflare.com/cache/how-to/purge-cache/purge_by_prefix/#limitations
[22:22:52] 	  hey, I'm following the discussion here about the Bucket extension we're developing - https://issue-tracker.miraheze.org/T14235
[22:25:06] 	  [1/2] @posix_memalign I personally would not view LIKE/RLIKE support as a solution to supporting repeated fields without mysql JSON types - the current bucket implementation is able to use a multi-valued index () so that queries like `WHERE  MEMBER OF(repeated_field)` can be done with
[22:25:06] 	  [2/2]  an indexed lookup rather than a full table scan
[22:25:36] 	  if you do the same sort of thing with LIKE/RLIKE then it's going to necessitate a full table scan, which would start to be very un-performant for large tables
[22:41:31] 	 originalauthority: "Example: If you purge foo.com/bar, any asset that starts with foo.com/bar will be purged, for example, foo.com/bar/baz, foo.com/bar?good=bad, etc. and purging foo.com/bar?good=bad itself will not work."
[22:45:52] 	  Oh I'm blind as a fuckin bat HAHA
[22:46:04] 	 mfw estrogen made me less blind