[03:11:17] what's that shortcut for inserting a timetstamp into a mw page? [03:11:26] mostly used on discussion pages iirc [03:22:15] oh, i was thinking of the talk/discussion page ~~~~ shortcut [07:20:26] Hi. Good morning. [07:21:55] I have have some spam in my moderation queue. But when I click reject i get an error " Fatal exception of type "Error"" [07:24:20] https://paste.tnonline.net/files/Y1ItClOsndth_PSX_20231027_092348.jpg [07:33:33] Forza: set $wgShowExceptionDetails = true; in the LocalSettings.php file to get a more detailed error + stack trace; the "Fatal exception of type ""Error"" is basically useless and impossible to debug on its own [07:36:04] ashley, thanks. I get Error: Call to undefined function wfReadOnly() [07:38:27] Moderation should be pretty well maintained AFAIK so I'm surprised if Edward hasn't fixed that yet...you could and should probably try upgrading Moderation first, but if the issue persists, replace "wfReadOnly()" with "MediaWikiServices::getInstance()->getReadOnlyMode()->isReadOnly()" and it should get rid of at least that particular error [07:38:56] https://gist.tnonline.net/ZY [07:39:59] Ah . Thanks. Ill try updating. I do use the mwuodater.phar tool to update, but maybe its not accurate [07:50:57] I see it eas fixed last year, but no new release has happened since then [07:50:59] https://github.com/edwardspec/mediawiki-moderation/commits/master/action/ModerationAction.php [07:55:55] All is good now. Thank you ashley [07:56:23] super, glad to hear that :D [09:29:33] is there a way to get just a result count from codesearch.wmcloud.org? [09:35:47] meh, doesn’t look like https://github.com/hound-search/hound/blob/main/api/api.go really supports it, but I can curl the underlying codesearch-backend API and pipe it into jq .Stats to at least avoid rendering all the results in the browser [11:02:47] Is there a way to make MediaWiki create symlinks or something for old thumbnail files when a File: is moved to a new name? I've recently increased wgCdnMaxAge and worry that people will often be served cached HTML with tags referencing thumbnails that were since removed due to page moves. [11:09:46] taylan: sadly, no, and I'd be interested in such a feature, too [11:19:32] Hmm that's unfortunate. I've just done a bit of testing and the move operation indeed immediately removes the old thumbnail so when I refresh the page in an incognito window I immediately get a 404 since I keep being served the cached HTML from Nginx, even if I tell the browser itself not to cache. [11:19:57] However, I just noticed that if I close and reopen the incognito window, I actually get fresh HTML. It seems that MW sets a session cookie even when you're not logged in? [11:20:25] (And the Vary: header includes Cookie so Nginx serves a fresh version...) [11:21:07] That's actually very surprising. Doesn't it mean that every individual visitor gets a fresh version, so the server-side caching becomes practically useless? Could as well let people's browser handle the caching then. [11:25:12] Nginx is not a good caching layer for MediaWiki. Use varnish [11:48:33] I've looked into Varnish but it would overcomplicate things quite a lot... I wonder how Varnish solves this issue anyway, since I thought any caching proxy has to obey the Vary: header? [11:52:56] The config here https://www.mediawiki.org/wiki/Manual:Varnish_caching seems to imply that whenever a cookie with "session" in the name is found, caching is skipped, so the same problem would apply? [12:02:27] taylan: MediaWiki sends PURGE request to the caching proxy layer when a page is changed (directly edited, a new version of an image is uploaded, a template changes...), but only Varnish supports clearing the cache on PURGE requests. Nginx does not. This means your visitors are most likely not seeing newer edits once they're cached [12:04:25] I know, and I think that's acceptable... What I don't get is how CDN caching is supposed to work if every new visitor gets a different session cookie even if not logged in. [12:28:19] When I check the cache-related headers when visiting mediawiki.org pages, it seems I hit the cache even when the sessionId cookie changes, so it must be doing something special. [12:29:40] The configuration here https://www.mediawiki.org/wiki/Manual:Varnish_caching must be outdated or wrong then, unless I'm misunderstanding what it does, because it seems to pass the cache if it finds a cookie containing the string "session" [12:30:03] If I knew how it really works, maybe I could make Nginx do the same thing... [12:40:42] The current sample config on the page seems to be from August 2021 [12:46:44] oh BTW, Nginx actually supports PURGE and I tried to make MediaWiki work with it a few months ago but gave up since it was unclear to me whether it would work reliably; my summary of the situation is here: https://www.mediawiki.org/wiki/Topic:Vk4cd0dhpbtdd5po [12:47:34] But that's a topic for another day. For now I just wish to find a solution to the Nginx cache becoming near-useless due to the {dbname}mwuser-sessionId cookie :/ [12:47:51] taylan: are you a subscriptor of Nginx Plus? [12:48:52] MediaWiki doesn't start sessions on each page view. That must be a misbehaving extension [13:17:40] Vulpix: No Nginx Plus but my understanding is that most of the functionality is replicated in free software plugins. I'm using the nginx-extras metapackage for Ubuntu from sury.org which includes a third party extension called "Cache Purge" which I guess implements HTTP PURGE. [13:18:36] The session isn't for each page view but for each new visitor. E.g. if I open a new incognito browser window, it gets a fresh mwuser-sessionId cookie. [13:19:06] Sadly I couldn't find any documentation of this cookie so far so I'm not sure why it exists... [13:26:11] Try disabling all extensions [13:34:07] Vulpix: It's referenced from some core files like SessionManager.php so I doubt it's added by an extension, though I couldn't yet find where it's first set. The wiki is live so disabling extensions would be troublesome... [13:42:04] sessions are necessary for MediaWiki, but they're (or should) only started on account creation or page editing. That's how it works for me. But of course, there are extensions that may need to init a session for other reasons during a normal page view [13:46:46] oh, I guess an extension may be triggering MW's built-in session mechanism to make it start a session, so the cookie is from core but it's the extension that causes it to be set [13:52:44] aha, it's set in resources/src/mediawiki.user.js (via mw.cookie.set) any time someone calls the JS function mw.user.sessionId() and it's not set yet. so yeah, that would be very easy for an extension to trigger. [18:51:58] https://www.irccloud.com/pastebin/U7VUZIYm/ [18:52:15] How do i fix this error for wiki sets? everytime i try to create a wiki set this error occures [19:25:14] Cocopuff2018: which exact MediaWiki version, which exact CentralAuth version and branch? [19:27:43] what is the full and complete content of that line? [19:57:03] Its 1.40 [19:57:14] @andre