[02:04:17] <legoktm>	 CindyCicaleseWMF: https://www.mediawiki.org/w/index.php?diff=2865337&oldid=2864175&title=Gerrit%2FNew_repositories%2FRequests%2FEntries&type=revision
[02:16:32] <CindyCicaleseWMF>	 legoktm: Thank you so much! That's great!!
[12:40:36] <DanielK_WMDE>	 TimStarling: interesting find, re CoreParserTestSuite/DatabaseIntegrationTest.
[12:40:43] <DanielK_WMDE>	 the revert did not fix the test failure, thouogh
[12:41:10] <DanielK_WMDE>	 I'm going to see if i can replicate your findings, and see if it helps me to understand what'S going on.
[12:42:22] <DanielK_WMDE>	 I have another trick up my sleeve that I want to try to find this. Having a way to replicate the issue without running all the tests would certainly help
[16:38:46] <DanielK_WMDE>	 anomie: if you have time, please have a look at the Article patch https://gerrit.wikimedia.org/r/c/mediawiki/core/+/452708
[16:40:05] * anomie look
[16:41:12] <CindyCicaleseWMF>	 DanielK_WMDE: can https://phabricator.wikimedia.org/T201164 be marked as resolved?
[16:41:36] <DanielK_WMDE>	 CindyCicaleseWMF: yes, done!
[16:42:01] <CindyCicaleseWMF>	 DanielK_WMDE: thanks!
[16:53:59] <CindyCicaleseWMF>	 DanielK_WMDE: Can https://phabricator.wikimedia.org/T174044 be marked as resolved? That would be significant. It has one open subtask, but it isn't clear that it is a blocker.
[17:07:28] <DanielK_WMDE>	 CindyCicaleseWMF: the description says it covers the schema migration. that'S done-ish, though I'd like to see https://phabricator.wikimedia.org/T198561 happen before we say the mcd storage layer is deployed. Maybe even https://phabricator.wikimedia.org/T198308
[17:07:57] <DanielK_WMDE>	 these tasks mean we actually *use* the mcr storage layer, in vanilla installs and the wmf cluster
[17:08:20] <DanielK_WMDE>	 right now, we have the code live, and the databases updated, but we are not yet using it.
[17:08:30] <DanielK_WMDE>	 if it'S not used, is it deployed?
[17:09:24] <CindyCicaleseWMF>	 Makes perfect sense. I will add those two tasks as subtasks of T174044 to make that clear.
[17:09:25] <stashbot>	 T174044: Deploy MCR storage layer - https://phabricator.wikimedia.org/T174044
[17:09:39] <DanielK_WMDE>	 CindyCicaleseWMF: maybe edit the description as well, to explain this
[17:10:21] <CindyCicaleseWMF>	 will do
[17:12:32] <CindyCicaleseWMF>	 done
[17:14:41] <DanielK_WMDE>	 CindyCicaleseWMF: thank you!
[20:33:05] <James_F>	 reedy, legoktm: https://gerrit.wikimedia.org/r/q/hashtag:merge-in-mw-1.33 for breaking-changes-for-mw-1.33 if you know of any more.
[21:48:10] <TimStarling>	 sanity check: if you move LocalSettings.php away and go to your wiki, does it work? or does it say "Error: Requested template, NoLocalSettings, is not callable"
[21:49:42] <TimStarling>	 it's not callable because it's invalid PHP, and I'm digging in to lightncandy to figure out why, but git blame says the relevant bits haven't been changed for years
[21:49:59] <TimStarling>	 seems like someone would have noticed
[21:52:16] <TimStarling>	 oh...
[21:52:28] <TimStarling>	 it fails on hhvm, works on php 7
[21:52:51] <TimStarling>	 and I'm the first person ever to have a missing LocalSettings.php on an HHVM wiki
[21:53:02] <DanielK_WMDE>	 TimStarling: " LocalSettings.php not found. Please set up the wiki first."
[21:53:13] <TimStarling>	 have you got hhvm
[21:53:22] <DanielK_WMDE>	 nope
[21:54:02] <DanielK_WMDE>	 didn't read your comment re hhvm before i checked and replied
[21:55:11] <TimStarling>	 thanks anyway
[21:55:34] <TimStarling>	 I now have mw.localhost for HHVM and php7.localhost for PHP 7
[21:57:12] <legoktm>	 is lightncandy compiling it to something invalid?
[21:57:35] <legoktm>	 or maybe it's not roundtripping through the templateparser cache properly?
[21:58:29] <TimStarling>	 yes it's compiling it to something invalid, no there is no cache involved
[21:58:54] <TimStarling>	 because $config->get( 'SecretKey' ) returns false
[22:00:08] <TimStarling>	 specifically, in the two inverted sections, {{^localSettingsExists}} and {{^installerStarted}}, it produces a ternary operator with no expression after the colon
[22:00:36] <TimStarling>	 effectively ($localSettingsExists ? 'something : )
[22:00:45] <TimStarling>	 or rather ($localSettingsExists ? 'something' : )
[22:03:56] <TimStarling>	 I've isolated it
[22:04:38] <Krinkle>	 lightncandy has horrible code. I don't understand why it's caching model is executable code in a string. Seems like it would be as simple and nearly as performant if it caches as a flat array of token ints and process those on call.
[22:05:37] <Krinkle>	 It even has a fairly decent idea of a parser. but it's never stored.
[22:06:05] <TimStarling>	 it's a bug in HHVM's double quote parser
[22:06:47] <TimStarling>	 https://paste.tstarling.com/p/hxxiMN.html
[22:08:30] <TimStarling>	 line 1944 of lightncandy.php hits it
[22:08:50] <Krinkle>	 https://3v4l.org/UUUvO
[22:09:38] <Krinkle>	 Doesn't seem to happen there, but maybe I missed part of it
[22:09:41] <TimStarling>	 only up to 3.22, I'm on 3.27
[22:09:59] <Krinkle>	 Right
[22:11:54] <TimStarling>	 eh, whatever, I couldn't be bothered filing an upstream bug for those assholes
[22:13:05] <TimStarling>	 we're not going to upgrade to this version in production are we?
[22:29:28] <Krinkle>	 I suspect not. On 3.18 currently.
[22:29:39] <Krinkle>	 Might backport a few things as needed, though.
[22:31:28] <TimStarling>	 I now have coreonly.localhost, a plain install with no extensions for running core phpunit tests
[22:32:24] <Krinkle>	 TimStarling: Interesting. How do you share the source with the other mw. overlay fs or some such?
[22:33:02] <TimStarling>	 just a shared document root, similar to production
[22:33:21] <Krinkle>	 ah, right. conditional on loading the extension in settings.
[22:33:35] <TimStarling>	 but I have a separate apache virtual host for each one, so I can customise the image path
[22:34:02] <TimStarling>	 yes conditional loading, we should probably have more convenient support for that
[22:34:28] <Krinkle>	 TimStarling: btw, could you review or delegate https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/451011/ - we were waiting for Simetrical, but in his absence might need review from someone else instead.
[22:35:33] <Krinkle>	 I can work around it if needed, for the bug in RL/WikiModule. Just need to know :)
[22:36:50] <TimStarling>	 what about HTML comments
[22:37:31] <TimStarling>	 you know the script data escaped state in the HTML 5 spec
[22:40:57] <TimStarling>	 in the double-escaped state, </script> only goes back to the (single) escaped state
[22:42:28] <TimStarling>	 so if you injected say <!--<script> into a JS string then the script element would run on past the intended end tag, interpreting HTML as JS
[22:43:55] <TimStarling>	 see https://html.spec.whatwg.org/multipage/parsing.html#script-data-double-escape-end-state
[22:45:37] <TimStarling>	 I'll put that in a gerrit comment
[22:46:57] <Krinkle>	 Right, this is the HTML2 (or 3?) compat thing that allows the script to be wrapped in <!-- for older browses not rendering it as display:none by default.
[22:47:15] <Krinkle>	 Which we don't care about, presumably, but it can be triggered without us knowing.
[22:48:14] <Krinkle>	 TimStarling: Without fully understanding it yet.. would disallowing '<script>' as well address the issue?
[22:50:31] <TimStarling>	 disallowing '<script', without the closing angle bracket, case-insensitively, should do it
[22:51:14] <TimStarling>	 I spent days in those stupid script data states when I developed RemexHtml
[22:51:44] <Krinkle>	 Yeah. I'm impressed but not surprised you managed to respond with this internal parsing state just 2 minutes after asking.
[22:51:59] <TimStarling>	 instead of /<\/script/i you could have /<\/?script/i
[22:52:04] <Krinkle>	 yep
[22:52:25] <Krinkle>	 TimStarling: What about more generally, I suspect this could make xml screen scraping more difficult.
[22:54:56] <TimStarling>	 I think it's OK, it's not like we output valid XML, screen scrapers already have to use an HTML parser
[22:55:41] <legoktm>	 TimStarling: IIRC we can't upgrade HHVM any further because they dropped support for having php7 mode off
[22:57:25] <Krinkle>	 TimStarling: view-source:https://people.wikimedia.org/~krinkle/T200506-html-inlinescript-B.html
[22:57:56] <Krinkle>	 I'm actually still surprised that this breaks. I'd expect browsers only tolerate this at the start of such tag, maybe with whitespace before it.