[00:38:29] hello [00:40:49] i have a bunch of categories on my wiki for which I don't want to create pages, but I want them to work as if they have empty pages created [00:41:22] so that links to them are normal, not ?action=edit, and that their pages display normally, without "this page doesn't exist" [00:43:05] Save with no content [00:43:58] i don't want to save each page [00:44:00] there are thousands [00:44:22] i just want category links to ignore the check for known pages [00:44:30] and display regular links instead of red links [00:46:54] !hook TitleIsAlwaysKnown [00:46:54] https://www.mediawiki.org/wiki/Manual:Hooks/TitleIsAlwaysKnown [00:47:11] I guess you could do something with that hook [00:47:44] that looks promising [00:47:45] thanks [00:48:27] basically something like `return $title->getNamespace() === NS_CATEGORY;` is probably enough [00:48:48] i guess $isKnown on that page refers to $result [00:49:06] oh, sorry, yeah [00:49:12] don't return [00:49:23] $result = $title->getNamespace() === NS_CATEGORY; [00:49:39] * Reedy sighs [00:49:43] I see the docs are as up to date as usual [00:50:34] fixed [01:09:54] that worked great, thanks Reedy [01:10:04] sweet :) [01:17:11] another question: can I add tracking categories dynamically, i.e. not in extension.json? [01:19:03] In theory you can use $wgTrackingCategories, but... [01:19:06] * @deprecated since 1.25 Extensions should now register tracking categories using [01:19:07] * the new extension registration system. [01:19:50] So I wouldn't really advise it [01:20:34] meh, too bad, i guess i'll have to find some other way around it [01:20:48] Why do you need to do them dynamically? [01:21:48] i have a bunch of "namespaced" parser functions, i.e. each registered parser functions is actually made up of several (sometimes many) subfunctions, which are called with {{#function:subfunctionæ [01:21:51] ahem [01:22:09] ... which are called with {{#function:subfunction|...args}} [01:22:23] and I want a tracking category for each subfunction [01:23:11] i can put it all in extension.json, i guess I'll have to [01:23:41] but it'd be nicer if I could do that in the function where i register parser function hooks [01:26:00] It's not impossible something like that could potentially be added... But I don't know if it'd be reccommended etc [01:28:36] a shower thought i've been having for 20 years: all extension parser functions should've been namespaced from the beginning, {{#extension:function|...args}} is a much saner use of parser function namespace, plus the syntax is symmetric with template calls, with args following the first | [01:29:04] hindsight is a wonderful thing ;) [01:29:17] hey, I proposed it in 2001, i think [01:29:27] heh [08:48:54] @bawolff figured out the HTTP/2 issue from the other day - it's fixed by disabling output compression on LocalSettings as discussed on https://phabricator.wikimedia.org/T235554 [10:53:56] well I think I see where the issue is with the constant spam of "PHP Warning: curl_multi_setopt(): CURLPIPE_HTTP1 is no longer supported" [10:54:11] indeed the option itself is nowhere in sight in the source but [10:54:31] line 451 is: curl_multi_setopt( $this->cmh, CURLMOPT_PIPELINING, $pipelining ? 3 : 0 ); [10:54:54] CURLPIPE_HTTP1 is 1 [10:55:27] so when $pipelining is true, CURLPIPE_HTTP1 is set [10:56:43] judging by https://curl.haxx.se/libcurl/c/CURLMOPT_PIPELINING.html it might be worth it to simply remove this curl_multi_setopt() call altogether [10:57:15] and most likely this happens in SquidPurgeClient [10:58:09] deferred/CdnCacheUpdate.php: ->createMultiClient( [ 'maxConnsPerHost' => 8, 'usePipelining' => true ] ); [11:13:44] filed as T264735 [11:13:45] T264735: MultiHttpClient has hard-coded deprecated cURL option used by CdnCacheUpdate - https://phabricator.wikimedia.org/T264735 [14:10:55] after commenting out that call I no longer get errors [14:12:14] Do we know where the addition of the deprecation warning comes from? Newer PHP? Newer curl? [14:14:44] going to check [14:15:33] the PHP manual says "As of cURL 7.62.0, setting the pipelining bit has no effect." but nothing about warnings [14:18:11] Reedy: https://github.com/php/php-src/blob/master/ext/curl/multi.c#L451 [14:19:39] I am getting the "no longer supported" warning as opposed to the deprecation message before, I guess [14:20:54] oh, this has been happening for a while I guess, I just did not have the output before (I have the job running script started by nohup) [14:21:00] Jul 22 11:11:36 web pkg[65596]: curl-7.71.1 installed [14:21:49] https://github.com/php/php-src/commit/72e1da81b6792d4141b4b41f6fc3e92b68aa0f3e been a while indeed [14:21:49] so buster.. debian stable would presumably be noisy https://packages.debian.org/buster/libcurl4 [14:22:08] https://github.com/php/php-src/commit/72e1da81b6792d4141b4b41f6fc3e92b68aa0f3e [14:22:17] Ok, it's a PHP 7.4 issue [14:25:58] I tend to update packages at least once a week so most of my software is usually "latest stable", guess this is why I hit all these weird things [14:26:13] heh [14:26:40] (FreeBSD ports stuff) [14:45:54] Definitely a bug, anyway [14:48:57] yay [14:52:51] I tagged platform to look at it.. but when it's fixed, should be at least be backported to 1.35 [15:20:10] Reedy: I also added the person who committed that block (according to blame), hopefully they can take a look at that [15:20:33] Looking at the code it is/was mostly Tim/Aaron [15:20:57] yes the particular setopt call was added by Aaron [15:36:18] Hello [15:39:30] I have problems in Content Translation [15:45:27] abijeet I have problems with Content Translation [15:53:26] I try to delete some bullets but I can't [15:53:42] Uploaded file: https://uploads.kiwiirc.com/files/9e6a6a749c52538a8d0764e0b2ce6531/Screenshot_20201006-125225_Chrome.jpg [16:07:31] Need help [16:57:58] Hi [16:58:00] I have recently upgraded mediawiki to version 1.34.4 (from 1.24) in a fresh directory and found that SyntaxHighlight extension is not working well.There is no color applied for all the langs I tried (especialy ksh one).As in the under post, I guess there is a link with the Python version used.Both Python V2.7.9 and V3.4.2 are available on the [16:58:01] server but I can not figure out wich one is used by the PHP interpreter.Her are the specs :OS: Linux DistributionHosting: OVH Shared hostingPHP version: 7.3.20 (cgi-fcgi)Mediawiki version: 1.34.4SyntaxHighlight: 2.0 (embended)Does anybody have a clue ? [17:00:12] user73: syntaxhighlight switched between some version. check the release notes: you have to modify your localsettings [17:01:05] https://pypi.org/project/Pygments/2.5.2/ [17:01:09] Requires: Python >=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.* [17:02:15] I did check my Localsettings. The syntax was alredy good : wfLoadExtension( 'SyntaxHighlight_GeSHi' ); [17:04:46] @Reedy : I don't understand. The MediaWiki Wiki stands that Python 7.3 is needed for this version of the extention : https://www.mediawiki.org/wiki/Extension:SyntaxHighlight [17:05:27] No it doesn't [17:05:39] >The version of this extension bundled with MediaWiki 1.31 requires Python version 3 (python3) to be installed on the server. This is a change from the version bundled with MediaWiki 1.30, which used Python version 2 (python). Note that the python3 binary must be installed in the execution PATH of the PHP interpreter. [17:06:35] @Reedy : Sorry . I mean Python 3 [17:07:17] So Python 3.4.2. is available on the server [17:07:43] with Python 2.7.9 [17:08:06] I don't know how to check wich version is used by the PHP interpreter [17:09:05] PHP doesn't care [17:09:25] in the default config, it uses the bundled pygmentize binary [17:09:39] that uses whatever `#!/usr/bin/env python3` resolves as [17:12:00] OK [17:12:10] I think you're talking about : [17:12:12] extensions/SyntaxHighlight_GeSHi $ grep -nri python3 *Fichier binaire pygments/pygmentize correspondantpygments/create_pygmentize_bundle:1:#!/usr/bin/env python3pygments/create_pygmentize_bundle:19: #!/usr/bin/env python3pygments/create_pygmentize_bundle:60: f.write(b'#!/usr/bin/env python3\n')SyntaxHighlight.lexers.php:505: 'python3' => true, [17:12:48] kind of [17:12:49] f.write(b'#!/usr/bin/env python3\n') [17:12:56] so the extention explicitly uses python3 [17:13:04] no [17:13:09] the extension doesn't care [17:13:17] you can point it at a different pygments binary if you want [17:13:48] I order to what ? [17:14:23] use a newer/older version [17:14:47] I red that , but don't understant what would be the point to use another version than the one embeded with this MW version [17:15:00] but I tried [17:15:05] but didn't achieve that [17:22:10] Is there a way to gather some logs on that process ? [17:24:17] If there's no colour applied, it's either the binary isn't being run (though you'd probably see an error), or there's an issue loading the CSS [17:27:37] OK. The directory is a fresh one ... not the D.B. [17:28:20] so, the CSS should clean [17:28:27] should be clean [17:36:05] I have to go. I'm locked. Nevertheless, thank you Reddy for your help. [20:53:11] Hi all, I could need some help with a wiki I'm helping with. We recently set up short URLs, but something weird happened. At the same time as that was set up, it became impossible to interact with the wiki – users can't log in, and those who are still logged in can't edit. When I try to edit, it says editing is only possible for the user group "Users", which I'm obviously in. Any idea what could cause it? I'm not 100 % sure it's related to the short UR [20:53:11] L change, though it is suspicious that it happened at the same time. [21:02:04] Jhs: can you pastebin the LocalSettings? [21:25:39] legoktm, sure [21:29:58] legoktm, https://pastebin.pl/view/9817a8b8 [21:31:53] bah, my copy was a bit out of sync I just noticed. I have added the $wgArticlePath and $wgUsePathInfo settings as well, though they aren't in the pastebin [21:34:10] so...your permissions look correct to me [21:34:59] Jhs: you said people can't log in? what error are they getting? [21:35:52] legoktm, incorrect password [21:37:15] except the $wgArticlePath stuff we didn't change the LocalSettings.php in any other way for this though. The main change was in the nginx config file [21:37:27] that's...bizzare [21:38:22] have you tried undoing the short URLs to see if that fixes it? just to verify that that in fact was the cause [21:38:44] I really can't think of what would cause this, your config looks correct to me [21:39:06] the other thing I'd suggest is to disable the various caching you have enabled, just in case that isn't working properly [21:39:29] oh, I read too quickly, all of those are set to false already [21:40:43] actually, when I visit https://oslobyleksikon.no/side/ I'm still getting an HTML cached page but your LocalSettings has $wgUseFileCache = false; - so something's off [21:42:11] I think the other guy who worked on this (too many cooks...) tested something, so the cache stuff is set like this currently: [21:42:14] $wgJobRunRate = 0.01; [21:42:14] $wgEnableParserCache = true; [21:42:15] $wgCachePages = true; [21:44:18] oh, and $wgUseFileCache is true as well, I notice. I really need to get this synced [21:50:54] Jhs: I'd suggest turning off all the caching one by one to see if that is also interfering (and then re-enable if its not) [21:52:51] legoktm, thanks, I think you're on to something here. Will try, but have to wait until tomorrow to see the results [23:47:30] So I've got this extension that was written by someone else years ago, and I'm upgrading it to work with 1.35. The original author seems to have used the parser hooks format, but he's essentially creating parser functions (like {{#lowercase}} or something). Is there any viable reason to add functions in as a hook with onParserFirstCallInit or is this just overkill? Becuase I feel like it's overkill. [23:48:21] No, I think that's right [23:49:21] I don't think there's any other way to do it (no extension registration way currently at least) [23:56:48] Ah, okay. There was a separate section for parser functions in the manuals on mediawiki.org, so I figured maybe he did things the wrong way [23:57:12] If they did, we're still doing it wrong in ParserFunctions [23:57:21] and I guess you could consider that extension the canonical example... :D [23:57:27] True! [23:58:16] While we're at it, do you happen to know what wfGetDB(DB_SLAVE) was replaced with? [23:58:26] DB_REPLICA [23:58:32] Thanks! [23:59:00] I think wfGetDB() is going to be deprecated at some point... But that point is not now [23:59:09] What's the modern way? [23:59:16] I'd rather just fix this now [23:59:39] Depending on what exactly you're doing..