[09:06:23] Hello, I have a question about https://www.mediawiki.org/xml/ the entry export-0.11 is missing there. but apparently the page is there https://www.mediawiki.org/xml/export-0.11/ where should I report the missing link? [09:08:25] unicard-ic: you can report it in Phabricator: https://phabricator.wikimedia.org/ [09:13:24] OK thank you. I thought this was just for bugs in the software [09:16:52] the /xml/ subdirectory is a bit weird since it's not part of the wiki, it's maintained alongside the software [12:23:59] Hi. Is there a analytics plugin like matomo that doesnt rely on javascript? [12:24:48] I can't think of any that won't [12:25:09] Because website front ends are just a mashup of html/JS+CSS [12:27:49] Yea. I suppose so. I thoughgt maybe there was a backend option. I don't really need detailed tracking, just some stats etc. [12:38:07] I mean you can probably scrape Apache/nginx access logs for data [12:38:12] If it's basic stats [14:15:09] Hello all, anybody with a good understanding/experience of Cargo? [15:32:10] I've had this weird issue where some special pages are cached and won't update since upgrading from 1.29.1 to 1.35.2. A couple specific examples are the DoubleRedirects, UncategorizedPages, and UncategorizedTemplates pages. I initially suspected it was varnish, but CURLing the backends still shows the same cache date (which is the date the update went live). What are the possible causes here? [15:45:33] jfolv: my guess would be that those special pages are marked as being expensive to generate [15:45:42] so the data are not generated on the fly when a user request them [15:45:56] instead the admin should call maintenance/updateSpecialPages.php from time to time [15:46:09] which will do the heavy computation, store the result in the cache and then the page will serve that content [15:48:17] https://www.mediawiki.org/wiki/Special:UncategorizedPages for example got generated on August 1st [15:48:20] That doesn't seem very intuitive... Why would the cache not have a natural expiration? Even if it's an expensive query, it can't just stay static forever until someone runs the script, surely? [15:48:36] This wasn't a problem before upgrading [15:48:51] maybe some page got flagged as expensive since 1.29 [15:50:05] hmm no they were marked expensive [15:51:23] so maybe you had a cron / timer to run the update script [15:51:45] jfolv: or check whether you might have `$wgMiserMode = true;` which would cause those pages to rely on a cached version [15:51:56] the default is `$wgMiserMode = false;` [15:52:59] https://www.mediawiki.org/wiki/Manual:$wgMiserMode [15:58:16] I don't have miser mode enabled [15:58:23] I even did a grep -r to check [16:03:21] Ah, there we are. It IS enabled via wgConf [16:04:58] But isn't there some way to force the cache to update itself every so often? [16:05:19] I feel like it should have a way to set an expiration [16:21:15] jfolv: the intent is that you update it via cron on whatever schedule makes the most sense for your wiki size and server load [16:22:00] (or a systemd timer instead of cron, or whatever other task scheduler you feel like using) [16:22:05] So then what changed between 1.29.1 and 1.35.2? Was there previously a "cache expiration" that was removed in favor of manually using cron? [16:22:35] I can respect the intention there, but I am curious why this is only a problem post-upgrade. [16:23:13] nothing changed with MiserMode between 1.29 and 1.35 in that regard [16:23:54] it's possible your cache setup wasn't working quite correctly before, perhaps [16:36:46] I realize what happened now. I had to replace the old servers when I upgraded, so the old admin's cron job never got ported over. Just need to set one to run daily. [16:37:01] Thanks for the help, folks! [17:05:05] Another issue I've been having: Our file upload wiki is automatically adding ==Summary== to every upload post upgrade (again 1.29.1 to 1.35.2). I checked MediaWiki:Upload-default-description, but that's blank. Was this an internal change? [17:16:49] jfolv: great to see you found the issue about special pages not being updated! :] [17:17:16] jfolv: for upload file, I don't have any idea from where it can come from. I am not familiar with that code [17:24:28] Hello folks, I am having some issues with Cargo. I think it's either me or the documentation :) More specifically, I am trying to have a situation where a field in a Form (say, Projects) lists the items contained in another Cargo table (say, Employees) [17:25:19] Basically, this example https://www.mediawiki.org/wiki/Extension:Cargo/Quick_start_guide [18:39:48] Working on creating an extrawiki for stakeholders and cooperators. I'm seeing {{NUMBEROFARTICLES}} resolve to 2, when Special:AllPages shows 5 articles. Another worrysome point is that VisualEditor occasionally fails when it is loading up with "Error contacting the Parsoid/RESTBase server (HTTP 404)" and buttons "cancel" and "try again". How freaked out should I be? [18:42:19] Please say don't be freaked coz Debian11 is coming in 10 days time and then I hope the hosting guys do their installation images foremostly intelligently and not take million years at it [18:43:58] 404 means the resource does not exist, right? So what is causing the resource to sometimes be accessible and sometimes not? [18:51:42] NUMBEROFARTICLES depends on https://www.mediawiki.org/wiki/Manual:$wgArticleCountMethod and https://www.mediawiki.org/wiki/Manual:$wgContentNamespaces and may not be the same as the actual number of pages on the wiki [18:53:38] as for the HTTP 404, it's hard to guess (and i don't really have time to debug), but maybe one of the subtasks of https://phabricator.wikimedia.org/T266971 is the same as your problem, and you might find a solution there [19:06:31] Thanks MatmaRex. I logged in and I noticed I was already subscribing to this ticket. I'll look into which one could be the same case. As to the first one changing it to '$wgArticleCountMethod = 'any';' and running 'sudo apachectl graceful && sudo service memcached restart' didn't change the situation. Still the magic word resolves to 2 when there are 5 articles in the main namespace [19:07:19] i think there's some maintenance script you'd have to run to re-count them [19:07:34] "Changing this variable will not retroactively affect the existing count. To update it, you will need to run the maintenance/updateArticleCount.php script." [19:30:48] ok thanks I'll run that now .... just finished making and verifying backups and taking a snapshot of the system disk [19:41:28] I'm looking to "correctly" format a date in JavaScript and actually unsure what we recommend today. I see `mw.languages.months` but it seems apart from tablesorter nothing known to Codesearch actually uses that [19:41:43] It also doesn't say where and how to format the number. [19:42:07] I do see `january-date` messages in core, but mw.language doesn't export those, and I was unable to find any code anywhere that actually uses those messages. [19:42:33] do we render any kind of data anywhere in JS in any MW extension? [19:42:36] date*\ [19:44:14] it seems Echo always uses "time ago", even for dates more than 1y ago [19:44:25] ... and has no tooltip with the actual date [19:44:53] and VisualEditor's source code date is ISO-formatted [19:48:00] It seems a sensible/miniaml approach would be to load the `january-date` messages, and then pass mw.language.convertNumber() as the first parameter. [20:18:54] ok this is weird... I ran the update script with --update, which set the article count correctly at 5, but this started exhibiting only after removing and readding the {{NUMBEROFARTICLES}} to the same page. go figure.. [20:40:38] Krinkle: Echo uses (used to use?) Moment.js, for which there's a module in MW core. that's probably a good way [20:52:20] We're seeing MediaWiki 'forgetting' a skin exists [20:52:33] Signs like formatting not showing [20:52:45] Getting messages saying invalid value for useskin