[12:14:45] Hi guys, I updated php, what is the best way to test if everything is ok/works? [12:16:19] try to use the wiki? [12:16:34] read pages, edit pages, etc [12:17:46] i thought there is maybe a script [12:27:41] Torsten552: What would that script do? [12:28:30] Torsten552: Internet Search Engines find script when searching: script to test mediawiki [13:57:35] duesen: apergos: did the FeaturedFeeds fix not work? (I see the additional try/catch also landed, which I thought wouldn't be needed) [13:58:24] Also, how is this try-catch in the extra check different from the slightly higher up catch added by Aaron yesterday? [13:59:00] y0 and BIG thanks for the awesome MediaWiki that powers so much knowledge gathering [14:00:06] (Storing values naturally serialises them and throws, so shouldn't be needed to serialise a second time) [14:00:50] If I can ask.. how would one go about transcluding or otherwise including information from Wikipedia categories to a non-WMF wiki? Transclusion is already enabled, but I don't know if / how it will work for categories [14:01:23] I mean I wanna transclude a whole category in an non-WMF wiki [14:01:32] .. into an article [14:02:05] Krinkle the second patch covers more cases (not just async). But you are right that it seems wasteful. We can probably attache the cache key to the error info by adding another catch/rethrow in a strategic place. [14:02:44] My motivation is to avoid manual replicating and the ensuing problem of them getting out of sync, unless manually checked for any additions [14:03:48] Krinkle: the intent is to protect against similar issues in the future, not just find the current instance. [14:04:31] duesen: there's no added protection, we throw either way both up to last week and with this patch [14:04:43] just better logging [14:05:05] also, this causes offending code to throw in tests. that would otherwise not happen when WANObjectCache is backed by EmptyBagOStuff or HashBagOStuff, since they don't serialize [14:05:06] Iamahuman: there is wgEnableScaryTranscluding which might do what you want, check out its documentation [14:05:21] Majavah: got that enabled already [14:05:34] For non-async we didn't see the issue, but also for non-asynx the trace will tell you the issue already [14:05:42] duesen: [14:05:51] That's why Aaron didn't add it there [14:05:59] Iamahuman: did you also enable iw_trans for those interwikis [14:06:09] Majavah: yes [14:06:16] still not working? [14:06:27] how does it not work? what syntax are you using? [14:07:27] Majavah: I haven't tried yet. I was just searching on this issue. I haven't ever transcluded a category so not quite sure about how this will work [14:08:11] So sorry for the channel noise. Like not trying to figure it out by yourself for 5-10 minutes before making channel noise is not cultured behaviour, my bad P-; [14:08:31] you want the category description its members or something else? I haven't tried either but I'd guess that will just give you the description [14:09:21] duesen: serialise was removed from hash as optimization, if that's principally reverted long term this way we can bring that back. Still no need to serialise twice for all keys in prod :) [14:09:33] Krinkle: you are right that the current form of the patch is probably redundant. My intent is really to trigger deprecation warnings on anything that isn't fulyl JSON serializable. [14:09:34] Also not the current use case since tests are passing [14:09:38] Majavah: I would like the category to be displayed under a heading (which states this is a transclusion from Wikipedia) in a similar way as when viewing the category in Wikipedia [14:10:45] duesen: yeah, agreed. But consider medium bag or base bag and to override serialise as part of the transition. Eg actually store as JSON (and encode once) [14:13:24] Krinkle: how about this: revert the double-serialization on master, keep it for wmf.29 and wmf.30. [14:14:23] (in a meeting now) [14:14:46] Ok [14:15:13] Can you confirm that the FeaturedFeeds fix didn't suffice? [14:15:39] How would I know? [14:15:41] (I assume that's the reason the try catch patch was merged) [14:16:09] Well if the FF fix landed and roll out didn't make the error appear in logs [14:16:14] If we deployed the FeaturedFeeds and didn't see the error any more, that would be inconclusive. we don't know what causes it, and we don't know how to reproduce [14:16:42] so we want to first add logging, see it in the wild, track it down, than merge the FeaturedFeeds fix. [14:16:54] Right I remember now. [14:17:07] But didn't the Ff fix get deployed earlier today? [14:17:12] the problem is that the error is very infrequent. so not seeing it is inconclusive. [14:17:54] tim merged the featuredfeeds patch last night [14:18:43] Krinkle: oh. Tim pushed it out. I wasn't aware of that. [14:19:09] I would have preferred for that to wait. oh well. [14:19:37] Yeah I read Ariel and yours plan too [14:19:39] Anyway [14:19:44] fyi: train is moving forwards currently [14:19:54] Majavah: Looking at https://www.mediawiki.org/wiki/Manual:$wgEnableScaryTranscluding the {{w:}}-syntax expects a template name or a main namespace article and when I tried just putting {{w:Category:Bible translations by language}}, the preview states The document has moved here: https://en.wikipedia.org/wiki/Template:Category:Bible_translations_by_language?action=render. Seems it defaults to thinkng the input is a missing template. [14:21:03] Iamahuman: according to the documentation {{wiki:main namespace page name}} should work [14:21:20] I'm busy with other things currently so can't look into this atm, sorru [14:21:35] ok. no probs, thanks for your help Majavah [14:22:15] Hey guys can I just update my php from v 7.0 to 7.3 (mediawiki v 1.31) by simply installing the new version? [14:22:43] Or do I need to follow some instructions? Could find a help page regarding this [14:24:39] Thomas098765: according to https://www.mediawiki.org/wiki/Compatibility mw 1.31 should work with php 7.3 so I don't see why it would not work [14:24:59] I'd recommend updating to a newer version of mediawiki in any case [14:25:29] So simply update the php version. This page I have also read, but thank you for the answer [14:27:51] Thomas098765: iirc you install php 7.3 alongside 7.0, so there are probably a few conf things to do before switching over. Disclaimer: I'm not sure. [14:28:36] maybe that was just a particular case that I had both versions on one system.. dunno [14:46:22] As for my case... using '{{w::Category:Bible translations by language}}' leads to the right place, but it is a link to a rendering of the category on Wikipedia, whereas I was hoping for a clean way to transclude categories on my wiki [14:48:02] but this is no urgent issue... I need to think what I want to do if the "Wikipedia category rendered on another wiki as it is rendered on Wikipedia"-thing doesn't work [16:27:53] duesen: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/662959 [16:29:45] Krinkle: wmf.30 has been cutm right? [16:30:12] Yeah, it's done overnight for us europeans [16:30:49] duesen: I think we should revert it from prod as well. It adds no additional events, since the try-catch from yesterday was already merged and backported and does the same thing. It doesn't add anything. The sync case already throws with a useful stack trace. It's only the async stack trace that has the issue where logstash doesn't tell us the code causing the problem. [16:30:56] and the double serialize could be a serious hit [16:31:16] If it's for longer than a day, I'm reverting it. Too many perf regression to deal with already. [16:31:20] we know this caused issues in the past [16:32:17] the CI use case is lower prio, and should indeed be fixed differently if we consider the perf hit worth it in terms of slowing down process caches and phpunit/parser tests. [16:32:23] yea, if it causes issues, revert it. [16:32:30] i just gave it a +2 on core. [16:32:39] i'll leave it on wmf.29 [16:35:28] and wmf.30 was cut after " WANObjectCache: throw on Closure " landed [16:35:32] so no action needed there