[07:46:18] hi, i have installed mediawiki (1.31.1) on opensuse tumbleweed. the installation is complete, i can login. but when i click on "read" for example, i get the message that localsettings is not found. but it´s there. also i have no styles nor images. what else do i have to do? [07:50:09] checking the file access permissions [07:50:23] https://www.mediawiki.org/wiki/Manual:Errors_and_symptoms#The_wiki_appears_without_styles_applied_and_images_are_missing [07:57:09] thanks [08:05:26] @samwilson posted in API meta=userinfo shows different rights between ApiSandbox and OAuth - https://discourse-mediawiki.wmflabs.org/t/api-meta-userinfo-shows-different-rights-between-apisandbox-and-oauth/1249/1 [11:39:42] Nikerabbit: hey! I', looking at the message cache issue [11:39:56] can you help me understand when and where MessageCache::loadFromDB is called? [11:47:30] duesen_: MessageCache::load perhaps? :D [11:47:46] there is bunch of caching there, which falls back to DB [11:49:39] Nikerabbit: i can't reproduce the issue, loadFromDB seems to work correctly [11:50:00] Nikerabbit: T218983 said: "After resaving any of these pages, it works for a short while, and then it's lost again." [11:50:01] T218983: Swedish Wikipedia is no longer getting local system messages - https://phabricator.wikimedia.org/T218983 [11:50:18] i wonder what could cause that - do we have caches there that onlöy last for a few minutes?... [11:51:17] it's quite complicated... not sure if there is two or three layers of caching there (process, local dc, all gc) [11:51:50] yes, it's a *bit* convoluted [11:52:10] so... how about the script that pulls in stuff from twn? i forget what it'S called... [11:52:22] how often does it run? could it cause the "reset"? [11:53:14] I would investigate: is it reverting back to defaults (we used to have this issue earlier) or is it taking an older version from local MediaWiki namespace [11:53:44] If the latter, I would think that there is perhaps limit 1 type of query without correct ordering [11:54:16] if former, there used to be an issue that if loading of the cache fails (taking too long, whatever) it falls back to default texts (and then it cached that!, but I think this was fixed) [11:55:26] Something similar could be happening again... maybe a server which is out of sync... or something fails on php7... [11:57:44] According to https://phabricator.wikimedia.org/T218918 it was showing "My edits" which is not the mediawiki default [11:58:26] Which leads me to believe that there is either a server out of sync, or something is not ensuring it is loading the latest revision, or version contents are mixed up [11:59:24] duesen_: probably irrelevant, but on my development environment a lot of pages were showing "this page has no visible versions" error, but I could access them via history... Once I truncated objectcache table in db that got resolved [12:02:58] Nikerabbit: that's pretty odd! [12:03:11] also, good catch re "My edits" not being the default [12:03:37] I assuemd it was. I'll do more digging, perhaps you are right about the limit 1 thing. [12:03:46] this shoudl just join against page_latest. but does it?... [12:05:31] duesen_: I don't see explicit join conditions... [12:07:38] var_dump( MediaWiki\MediaWikiServices::getInstance()->getRevisionStore()->getQueryInfo( [ 'page', 'user' ] ) ); [12:07:53] for me it only says page_id = rev_page [12:09:50] duesen_: aha: https://github.com/wikimedia/mediawiki/commit/f7afe42713a53452ac808ea337eb8390414b47eb#diff-f223536992b5c4022330ffc43515b64eL545 [12:10:17] duesen_: clearly that is where page_latest got replaced with page_id [12:11:11] Nikerabbit: yes. i was looking at that diff for a while now (and before - i reviewed and merged that patch). i didn't spot the fact that page_latest got missing. [12:11:22] your comment about the limit 1 query tipped me off [12:11:36] i just confirmed by stepping though - the query now fetches all revisions, not just the latest. [12:11:39] that's indeed it. [12:11:45] will fix. [12:12:28] duesen_: the join to text table is also removed... does this mean it will now do separate queries to fetch the content? [12:13:33] I understand this was already the case for wikimedia wikis, but not for example translatewiki.net [12:14:20] Nikerabbit: yes. that's in fact the purpose of this patch. Direct joins of the text table are no longer possible with the MCR schema [12:14:49] eek. [12:15:05] Nikerabbit: in the future, we may bypass the text tyble entirely when using externalstore [12:16:23] if absolutely necessary, it would be possible to put this optimization back. But the code would somehow have to know about the configured blob storage mechanism. with the new storage infrastructure, this is intentionally hidden from callingt code. [12:16:32] I guess the hacks at translatewiki.net to avoid loading most of things in NS_MEDIAWIKI avoided breaking up everything due to that [12:17:38] Nikerabbit: i didn't quite get that, what do you mean? [12:18:36] trying to fetch the content for thousands of message page individually would probably be too slow and timeout, bringing the wiki down [12:18:56] with the hacks it's loading maybe few hundred message pages [12:19:20] so you think it's ok? [12:19:42] (i assume you mean $wgAdaptiveMessageCache) [12:19:48] duesen_: yeah must be since it is still working [12:21:58] once this migration reaches MessageCollection of Translate... that might be a bigger concern [12:22:21] Nikerabbit: well, what is $wgMultiContentRevisionSchemaMigrationStage set to on twn? [12:22:47] duesen_: whatever is the default in semi-recent master [12:23:00] SCHEMA_COMPAT_WRITE_BOTH | SCHEMA_COMPAT_READ_NEW [12:23:14] so yea, it's using the new schema [12:23:24] join against the text table still work, but are ignored [12:23:29] hmm [12:28:32] duesen_: I don't see separate queries for each message in the log [12:31:23] so the join to text table is not being ignored (yet at least) [12:33:35] fix is up! thanks for the help, Nikerabbit! [12:33:42] https://gerrit.wikimedia.org/r/#/c/498363/ [12:34:08] yay [12:34:13] Re the text table join being ignored - it'S ignored by RevisionStore/Revision. MessageCache doesn't yet use that. [12:34:46] but Id044b8dcd7c9d09 changes MessageCache to go through RevisionStore. [12:35:03] do watch out for the performance hit [12:35:14] Ah, so also Messagecollection is still unaffected due to that [12:35:49] i suppose so. but that also means that it will break once we drop rev_text_id. [12:36:41] it can still use the text table in a bulk join if it doesn't use RevisionRecord. But it will have to do that join in a more complicated manner, via the slots and content tables. [12:36:54] and the text IDs are encoded in url-like addresses in the content table [12:37:09] duesen_: let's do it in a non-breaking manner, please :D [12:37:53] Id044b8dcd7c9d09 is not yet deployed to translatewiki.net [12:44:14] the non-breaking option is SCHEMA_COMPAT_WRITE_BOTH [12:44:41] I hope we can remove that in 1.34. Definitly in 1.35. [12:44:47] but as long as you have that flag set, the old code will work [12:46:08] Nikerabbit: perhaps make fixing MessageCollection a blocker/subtask for https://phabricator.wikimedia.org/T198557 [12:46:26] heh "This task is connected to more than 200 other tasks. " [12:46:27] yay [12:48:38] duesen_: probably there isn't such task yet... [12:53:12] Nikerabbit: make one :) [12:54:34] duesen_: eeh, that's not fun, I'll leave it to an actual work day :D [13:03:38] Nikerabbit: once the cache is live, is there a good way to purge the caches and make them reload the correct values? [13:04:19] running rebuildLocalisationCache.php for all projects may be a bit much [13:05:18] duesen_: it wouldn't even help [13:06:03] * addshore reads up [13:07:31] Nikerabbit: why not? [13:07:46] duesen_: unless it happens to call MessageCache->clear() [13:08:19] I'd expect so, but I'm not sure [13:08:21] basically LocalisationCache = cache of files, MessageCache = cache of wiki pages. They are not related [13:08:29] hm [13:08:52] can we just call MessageCache->clear() for all wikis? or would that trigegr a re-cache during a web request, causing a timeout? [13:09:33] I'm afraid the latter might happen, and I don't see a recache method [13:10:00] MessageCache::load()? [13:10:04] it's protected [13:10:29] easy enough for force access for a one-off [13:10:59] :D [13:12:53] clear() purges it for every language, for load() you would need to call it in a loop [13:14:34] and I'm not sure load() actually purges it properly... bit hard to say because the code is so complex [13:15:34] duesen_: on the other hand, the load() does some locking so that even if runs during web requests... single thread should do it while other wait [13:16:14] right [13:16:47] Nikerabbit: can you put some ideas of how to reload the cache on the ticket? [13:16:54] i'd like to go and write a regression test for this [13:17:05] also, i need food. [13:17:32] duesen_: I'm just having late lunch myself :D [13:18:37] right :) [13:18:46] I'll but something half cooked on the ticket [13:21:02] there is MessageCacheUpdate but that's not very helpful either for full purge [13:23:15] Nikerabbit: https://phabricator.wikimedia.org/T218918#5047905 [13:23:32] if you have thoughts or comments, please reply :) [13:35:39] done [13:37:57] I don't really know what I'm talking about, but i thought scap sync cleared the message cache? [13:38:32] I always thought jobrunner did that periodically [13:58:24] Zppix: that's possible - and probably the reason that messages that were fixed by purging reverted back to the bad state [13:58:31] in that case, it should just all fix itself [13:58:35] want to comment on the ticket? [13:59:06] ill take a look [14:23:05] Nikerabbit: why the hell do all cache entries created by leadFromDB get a blank space added before the message text? [14:23:14] Is that used as a marker? [14:23:23] of overwritten messages? [14:23:25] holy cow... [14:25:28] I "MessageCache.php" line 1052 suggests that is the case [14:26:57] yep [14:27:21] there is bunch of stuff that starts with !... [15:03:50] hm... how do i update a cherry pciked change to a new patches from master? [15:03:55] just cherry-pcik again? [15:03:59] on gerrit, that is [15:06:26] duesen_: cherry pick again might work [15:07:04] duesen_: can i borrow 5 minutes of your brain at some point if it isn't too busy trying to unbreak the world? [15:09:49] Nikerabbit: can you give a +1 or +2 on my patch, so it can be deployed? [15:10:14] https://gerrit.wikimedia.org/r/c/mediawiki/core/+/498362 [15:10:23] addshore: let me try the cherry pick. then sure [15:10:51] that worked. [15:11:01] addshore: so, what's up? [15:19:06] duesen_: https://test-commons.wikimedia.org/w/index.php?diff=722&oldid=718&title=File:Godward_Idleness_1900-dupe!.jpg [15:19:58] duesen_: with your mediawiki and wikibase knowledge, what cache is meaning those entities at some point were apparently deleted? but other languages of the same page they appear [15:19:59] hm yes? [15:20:00] duesen_: v [15:20:00] https://test-commons.wikimedia.org/w/index.php?diff=722&oldid=718&title=File:Godward_Idleness_1900-dupe!.jpg&uselang=de [15:20:51] Diffs themselves are cached [15:20:54] the full rendered html [15:21:03] that might be the one [15:21:16] no idea how to purge that :P [15:21:23] which cache even is that? [15:21:58] let me dig around [15:22:30] $cache = MediaWikiServices::getInstance()->getMainWANObjectCache(); [15:22:55] in where? [15:23:38] DifferenceEngine [15:24:03] that class has a $refreshCache flag that forced the diff to be rerendered [15:24:10] but I'm not seeing where that is ever set [15:24:14] ty, there might be another issue at play here too, might have to do more digging [15:25:20] not sure why it even managed to render a diff thinking that those entities did not exist in the first place [15:25:36] we had the same thing when we turned it on on beta, but after a while it went away [15:25:41] iirc, the "deleted" really means "failed to load" [15:25:49] or "does not exist" [15:25:54] yup [15:26:19] oh hm, these are cross-wiki loads? [15:26:28] yes [15:27:07] does CachingEntityRevisionLookup do negative caching? [15:27:43] ...doesn't look like it [15:27:49] that would have been an explanation [15:30:05] well, the big shared cache is shared between commons and wikidata too which is nice [15:30:30] \o/ [15:30:44] anyway, ill keep scratching my head [15:30:50] if you think of anything let me know [15:31:28] have you tried searching the logs for these entity ids? [15:32:02] not yet, just opened the ticket up [15:54:46] Hello, where can i find a version of the vector skin for mw 1.19 [15:54:59] or when it was first released. All i see when i look in git is the current version [15:55:04] or back to 1_23 [15:56:25] kevindank: why would you want such an old version? [15:56:32] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/Vector/+/REL1_23 [15:56:35] i have a wiki running mw 1.19 [15:56:45] https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/Vector/+archive/REL1_23.tar.gz [15:56:55] that repo only goes back to 1.23 though [15:57:10] addshore: right, thats what i mentioned. thanks for looking [15:57:35] Vector was part of MediaWiki core in 1.23 [15:57:47] and before [15:58:12] is there somewhere i can download mediawiki 1.19 again and just grab the skins directory? [15:58:21] kevindank: https://releases.wikimedia.org/mediawiki/1.19/ [15:59:20] however, be warned that this version is too old, it has no support and has probably security vulnerabilities [16:00:39] Vulpix: thanks, understood. Im working on trying to remove some redirects due to ads that a client added to his wiki which was running 1.19. I've explained that he should look to upgrade to the latest version...however he just wants this fixed for now [16:01:21] I originally thought it was a sql injection but after changing skins i noticed the redirect didn't occur. so i want to remove any of the bad code from vector that he modified and then convince him to upgrade to latest [16:04:26] Good! [16:05:39] Note also that old mediawiki usually means old PHP and mysql, which in turn would have security vulnerabilities, your client should also probably upgrade php and mysql [16:05:48] *need to [16:06:27] yep [16:06:35] was there anything special needed to have the victor skin display on mobile? [16:09:41] nvm, lookgs good. [16:34:31] Greg Rundlett @freephile posted in $wgLanguageCode does not change Tools menu - https://discourse-mediawiki.wmflabs.org/t/wglanguagecode-does-not-change-tools-menu/1251/1 [16:52:10] duesen_: i dug some more, https://phabricator.wikimedia.org/T218921#5048571 [16:52:17] i think im missing yet another layer of caching? [16:54:53] duesen_: wait, i think i was hitting an in browser cache [20:22:34] Man, ConfirmAccount needs a rewrite. I think I've got the extension.json done, but there's just so many other issues.