[13:32:48] Does anybody know if MW 1.39 supports PHP 8.2. I am in a Debian situation and do not want to fiddle with PHP apart from what ships with the distro. [13:39:19] It should do [13:40:04] Shouldn't be any major show stoppers... Bugs definitely accepted [13:47:47] Thanks for the info. This is great news. Well, I am still on Debian 11 with the 1.39 wikis, so I do not have first-hand experience. The main thing is that the wikis will not go down all of a sudden on PHP 8.2 once I update to Debian 12. [13:48:11] I noticed that we don't document this on https://www.mediawiki.org/wiki/Compatibility#PHP a couple of days ago, then forgot about it [13:48:20] I have filed a bug to at least correct that documentation [13:48:44] I believe (being the one that wrote them), we've said in the point releases (especially!) that we support PHP 8.2, after some appropriate backports [13:49:00] 1.39.0 I'd not expect to work fully (probably, maybe), 1.39.6 I'd be more confident [13:49:46] To be honest. I want to wait until January 2025 when I upgrade the server because this will enable me to get 1.43 right away. [13:50:20] Thank you for filing the bug. [13:51:13] I guess 1.39.0 is of no concern for anybody any longer. Good to know that 1.39.6 has a high confidence factor. [13:52:05] Well, this is why we do point releases :) [13:52:12] Stuff that should be minor changes, but bring in bug and security fixes [13:52:54] Hmm, probably I should give it a shot soon for a server only running about 5 wikis of minor importance. This will help seeing what is ahead and help providing feedback about 8.2 support. [13:53:03] I've been trying to proactively backport PHP 8.x changes to support branches [13:53:17] We eventually gave up on 1.35 for that, as the difference in the code was getting too great [13:54:07] I think I am not the only one who was surprised that Debian 12 came with php 8.2, which could potentially cause the situation. [13:54:46] If you really get stuck, https://deb.sury.org/ are basically pre-releases by the person who does most of the debian PHP packaging [13:54:50] So if you need another version... [13:56:12] Reedy, I believe the whole third-party wiki world admires your work here since it is in a similar situation with Debian and its versions of MW. At least I do. [13:56:54] We do have a bit of control over the MW version in Debian too, as two of the packagers there are primarily here too [13:57:09] Which probably is also a good confirmation of my "it should mostly work" [13:58:22] I'd rather not fiddle with changing the version that ships with the distro. Did that once, and after the first update, the package manager installed all php versions in between. I was able to set it to one of the many versions I ended up on that said server, and things continued to work. I felt doing the wrong thing for the right reason. This [13:58:22] explains my reluctance. [13:58:44] All of this: cool! [19:11:04] how do i get regexfunction to work on all the wikis instead of just locally ? its only working locally on wikis and not globally? [19:24:28] Are you talking about https://www.mediawiki.org/wiki/Extension:RegexFunctions ? [19:24:42] yes [19:29:44] What do you even mean by that? Its a parser function. What would it mean for it to work globally? [19:30:14] i thought the extension was suppose to work like a global lock instead of just a local block [19:30:19] block [19:30:28] What? [19:30:39] It's an extension for regex pattern matching [19:33:44] https://usercontent.irccloud-cdn.com/file/vTJXV5tz/FireShot%20Capture%20020%20-%20User%20group%20rights%20-%20Stranger%20Things%20-%20strangerthings.filmpedia.fah-dc3-ds.com.png [19:34:26] That's not the RegexFunctions extension doing that. [19:34:33] regexblock is not the same as regexfunctions [19:34:40] https://www.mediawiki.org/wiki/Extension:RegexBlock [19:36:57] yes Special:RegexBlock is what i currently have installed but unsure why the blocks dont work globally [19:37:37] >This extension works best when used along with setting shared database and memcached. [19:38:13] so what i need to do is create a database called Regexblock [19:38:57] Probably not, no [19:39:20] well than how do i make it work across multiple wikis [19:39:34] You don't need a seperate database [19:40:20] perhaps you should read up on https://www.mediawiki.org/wiki/Manual:$wgSharedDB and https://www.mediawiki.org/wiki/Manual:$wgSharedTables first [20:03:58] https://www.irccloud.com/pastebin/VjORsWtT/ [20:04:12] i made this table and added this to localsetting php however still not working [20:04:56] probably because RegexBlock has no such DB table [20:05:27] is there one i can use? [20:08:56] https://github.com/wikimedia/mediawiki-extensions-RegexBlock/tree/master/sql [20:09:11] perhaps this one? [20:23:05] You need to set $wgRegexBlockDatabase to tell the extension which DB to use for the tables - they should get created automatically by the update script (update.php) - whether or not you need to add it to $wgSharedTables, I don't know, I've not installed the extension in forever. [20:35:17] https://www.irccloud.com/pastebin/X0sz4cs2/ [20:35:33] well both of these are added to both databases and unsure why its still not working... [20:36:25] Why is the database and the table the same? [20:37:37] because thats what i named the database table [20:39:51] Considering the extension has specific tables it creates... [20:39:56] CREATE TABLE /*_*/blockedby ( [20:39:58] CREATE TABLE /*_*/stats_blockedby ( [20:41:36] it does say those 2 exist already [20:43:54] https://usercontent.irccloud-cdn.com/file/cStNOO7l/FireShot%20Capture%20022%20-%20cPanel%20-%20MySQL%C2%AE%20Databases%20-%20server123.web-hosting.com.png [20:55:09] still unsure why its not working [20:55:14] $wgRegexblockDatabase = "filmnprl_Regexblock"; [21:13:58] did i miss something? [21:54:02] what else do i need to do it seems not to be sharing the blocks from both databases? [23:54:07] so i created the databases and used $wgRegexblockDatabase = "filmnprl_Regexblock"; along with used https://github.com/wikimedia/mediawiki-extensions-RegexBlock/tree/master/sql what am i missing