[06:32:14] T264735 makes me sad [06:32:15] T264735: MultiHttpClient has hard-coded deprecated cURL option used by CdnCacheUpdate - https://phabricator.wikimedia.org/T264735 [06:32:36] to quote tstarling, ‘I think a rewrite of CdnCacheUpdate is not part of this task. Third party users can just follow WMF and use HTCP if they want performance. It's unclear whether anyone actually needs or wants a rewrite of CdnCacheUpdate.’ [06:33:37] what it feels like to me is, if you have a single-server self-hosted instance of mediawiki you are really on your own now [06:34:01] vhtcpd is abandoned and purged requires Kafka and all that enterprise luggage [06:39:46] Remilia: or you or someone else could contribute a patch to make it work? [06:40:56] Is the loss of HTTP 1 multiplexing that big of an issue for you? [06:41:28] I do not care about multiplexing really, it is more that CdnCacheUpdate itself is essentially abandoned [06:42:29] so it is a matter of time until this falls out of scope entirely [06:42:37] well no [06:43:35] I think you mean $wgCdnServers and/or $wgHTCPRouting isn't actively used by Wikimedia [06:43:43] or at least that purge logic [06:44:04] afaict CdnCacheUpdate:purge() is still used [06:45:59] yes, this is what concerns me; let's say I actually get to implement an extensible HTCP daemon like I planned before, but who is to say the HTCP logic will not be removed in 1.38 because to Wikimedia it falls into deprecation category? [06:46:21] same with HTTP PURGE logic [06:48:55] I should probably look instead into making a simple proxy-like service that would convert multiplexed HTTP/2 into HTTP 1.1 for Varnish hmm [06:49:27] I mean, wouldn't you just implement your own EventRelayer class then? [06:49:36] since GuzzleHttp seems to support HTTP/2 [06:49:44] I am *really* bad at PHP [06:50:11] anything that is not machine code, PL/I, Ada, Rust, or C stresses me out [06:51:42] you can write PHP extensions in Rust now, it's actually quite nice [06:52:41] I guess I will look into all this this week [06:52:54] But anyways, this seems like an entirely different problem. I do not believe the ability for you to use HTCP purges will be removed from MediaWiki, it just might require another extension or something. Which I don't think is unreasonable, given that most people don't run MediaWiki behind a frontend cache and those who do should be technically competent to install an extra extension for purges [06:53:35] https://phabricator.wikimedia.org/T264735#7468710 that was kind of my proposal haha [06:54:25] I think the follow-up comment to yours is the right way forward [06:56:56] time to learn how to design an MW extension, I guess… there is a first time for everything [06:57:27] frontend cache is unavoidable in my case [06:58:19] removing Varnish from the pipeline bumps server load average from 0.4 to 7.2 on that 4C8T Xeon [07:01:19] you could probably use EventBus as a base [07:04:27] thanks for the pointers [07:06:50] honestly I feel like using MW for this relatively-high-load wiki (high for a niche thing, of course, there is a mere 500-1000 requests per second) was a bad idea due to how the data is structured and what kind of edits occur in general, but three years ago no one could have predicted this haha [07:07:33] I never expected it to hit even 5 users per minute mark [07:08:49] I don't think there's another wiki platform that's as scalable as MW :-) [07:10:55] legoktm: MW is really really nice [07:12:03] but I have underestimated people's love for Digits and Tables, so I should have made something like a statically-generated-from-JSON website with MW only used for non-data-driven stuff [07:12:31] the huge problem is that 95% of the content right now is basically templates with values produced from JSON files [07:12:52] and it is really stupid to run that pipeline [07:13:55] (I have 5 more MW instances on the same server which are actually sane and do not use Cargo and a ton of external scripts used to convert JSON into wikitext) [14:10:56] haha Remilia your 'why did I used MW for that???' problem is not unfamiliar :) [18:55:28] Hi. Is this the IRC for wikimedia? [18:56:10] It's the IRC channel for the software MediaWiki... Which is used/maintained by Wikimedia to run most of its websites [18:56:45] Thanks for confirming. This is my first time using an IRC. [18:58:02] I was looking for a way to contribute to wikimedia projects. [19:00:37] I have knowledge in web development especially Front-End web development. Is there something I can help with? [19:00:41] KhalidS: https://www.mediawiki.org/wiki/New_Developers may have some of the information you need to get started. [19:00:48] Also https://www.mediawiki.org/wiki/Outreach_programs [19:02:22] Thanks bd808 [19:17:25] KhalidS: there are a lot of different "channels" (groups) on IRC, this is just one of them https://meta.wikimedia.org/wiki/IRC/Channels [20:55:10] Hi all, I need small help with instalation mediawiki on synology NAS. [20:55:11] All works well - but after instalation -> i can't login at all. [20:55:11] I get error: "Wydaje się, że wystąpił błąd z Twoją sesją zalogowania; to działanie zostało anulowane, aby uniknąć przechwycenia sesji. Prześlij formularz jeszcze raz." [20:55:39] Any ideas - what I could do wrongly in configuration? [20:56:11] Most people here probably don't read Polish ;) [20:56:42] But looks like you're getting the session highjacking error [20:56:46] https://www.mediawiki.org/wiki/Manual:How_to_debug/Login_problems [21:05:15] Reedy yes - that's true - but I don't know why:/  and how to check what could be the reason [21:05:34] Look at the link that was sent? ;) [21:12:34] Yes Reedy i read that. [21:12:34] That line works: [21:12:35] "If the problems are happening on your own wiki, check what session backend is being used ($wgSessionCacheType), and make sure it works (data is actually persisted between requests). The most safe configuration is $wgSessionCacheType = CACHE_DB;. If you're unsure about how it's configured, add this setting at the end of your LocalSettings.php." [21:12:42] but do you have any ide why? [21:13:37] *idea