[15:54:41] Can you use hooks within core, or can they only be used by extensions/skins? [15:55:20] What do you mean by use them? [15:55:25] Subscribe? Create them? Run them? [15:55:42] uhh, implement them, i.e. do X action when Y hook is run [16:08:13] It's not common, but no reason why not [16:08:23] Rather than an arbitary function call put in [16:11:14] yeah that's what I was thinking [16:17:08] davidwbarratt: Looks like it's done in newer code at least (see Auth stuff) [16:17:20] lol [16:17:21] // Registering hooks from core is unusual, but is needed here to be [16:17:21] // able to call the AuthPlugin methods those hooks replace. [16:17:45] haha, I mean, it's very event-driven in a way, so I kinda like that aspect of it [16:19:06] I was wondering about this https://phabricator.wikimedia.org/T152462 because we have to set the cookie on non-cacheable responses (i.e. EditPage, AccountCreation, API:UserInfo, etc.) [16:20:15] although, I don't think there's a hook that would allow you to determine if a response is catchable or not. :/ so it might be a matter of whitelisting pages anyways [16:22:36] dmaza ^ [16:28:51] <_joe_> davidwbarratt: when planning to add a cookie in the MW response, if it's not already there, please reach out to SRE traffic [16:30:13] <_joe_> it's going to be ok with 99.99% probability, but they usually like to know [17:04:03] T193414 if someone wants a puzzle :) [17:04:04] T193414: Strange non-deterministic parse+Tidy output - https://phabricator.wikimedia.org/T193414 [17:09:36] subbu: bar on the same line is hosts running Debian Jessie, bar on a different line is hosts running Debian Stretch. I only checked 4 hosts, 2 of each [17:09:53] aha .. [17:10:22] i was just testing it with mwdebug1002 and it is always on the same line .. and i was about to try it with different servers but you nailed it looks like. [17:16:38] legoktm, do jessie & stretch come with different versions of tidy? or something else off with the config? [17:16:56] they do have different versions of libtidy, yes [17:17:42] we recently discussed a backport of old libtidy for CI+stretch in https://phabricator.wikimedia.org/T191771#4125612 [17:18:08] at the time we didn't think there was any production impact, but maybe there is? [17:18:59] i have tidy5 installed locally .. and i don't see this breakage with it. [17:19:23] are you using wikimedia's hhvm build? [17:19:54] no. [17:20:08] (also it's possible I'm wrong about the OS, maybe 4 hosts wasn't a large enough sample size) [17:20:12] [subbu@earth:~/work/wmf/deploy] dpkg --list | grep tidy [17:20:12] ii libtidy5 1:5.2.0-2 amd64 HTML/XML syntax checker and reformatter - library [17:20:12] ii tidy 1:5.2.0-2 amd64 HTML/XML syntax checker and reformatter [17:20:29] I guess try reproducing with parse.php on a prod stretch server? [17:20:44] or target a specific server with an action=parse api request? [17:21:52] can you write a script to test this and just hit all servers .. so we have full information? [17:29:02] probably, it'll have to be after class though [17:29:04] * legoktm afk [18:09:23] subbu: Sanity check: is your local installation where you can't reproduce it using Raggett? Did you remember to pass --tidy to maintenance/parse.php? [18:11:01] yes to both. [18:12:32] I don't know then. I can reproduce it locally with parse.php when I set $wgTidyConfig = [ 'driver' => 'RaggettInternalPHP' ] in my LocalSettings.php and use --tidy. [18:17:15] anomie, ah .. i git updated master earlier . and i forgot i now have to explicit set the config to RaggetInernalPHP .. null no longer works. [18:17:30] subbu: Hence the sanity check ;) [18:19:42] * anomie reconfigures his local dev wiki so he can just "--wiki=pgwiki" or hit pgwiki.local.wmftest.net to test things with PostgreSQL, instead of having to change a flag in LocalSettings.php. And similar for SQLite. [18:23:38] anomie, do you see anything broken iwth https://gist.githubusercontent.com/subbuss/a0e83362d84ac115340934cfdabf4698/raw/cd52b1a4ae82eea40f2fe48dd08b3ff43952fb34/gistfile1.txt ? [18:23:55] because i now get [18:25:25] subbu: Does tidy show up in the output of `php -i`? [18:25:52] nope. [18:25:55] If not, do you have the right package installed for the PHP tidy extension (e.g. php7.0-tidy if you're using PHP 7.0 on Debian) [18:26:27] i didn't change anything recently except update mediawiki ... but, ok, will investigate there. [18:26:37] Or you could just try 'RaggettExternal' instead of 'RaggettInternalPHP'. [18:27:33] Although in that case you'll probably need to add 'tidyConfigFile', 'debugComment', 'tidyBin', and/or 'tidyCommandLine' into your $wgTidyConfig. [18:27:42] ah, so, this now uses libtidy5 which has broken output. ya .. maybe that is it .. external. [18:40:21] anomie, yes, i had to set it to external and set bin, configfile, commandline .. and it is functional again now. [18:41:19] so, yes, the mystery is basically down to differing tidy versions. [18:42:46] Switch everything to Remex and we don't have to worry about it ;) [18:43:11] right. in 2 months. [21:27:12] https://gerrit.wikimedia.org/r/#/q/topic:derpecation can't help but wonder if the typo is intentional… ;) [21:30:07] lol [21:31:09] MatmaRex, MaxSem: Love it. [21:32:18] No it's not. I still sometimes typo it as deprecation though [21:33:33] :>