[15:44:51] <dexgs>	 hi, i'm having an issue with the ParserBeforeTidy hook. The docs I've read claim it can be used to insert raw html into pages, but since 1.44 it doesn't work this way anymore and the output of this hook is still getting (partially) HTML-escaped. For instance, if your hook function outputs a literal "&" it gets replaced with "&amp;" in the output HTML. It didn't work this way on prior versions of mediawiki and furthermore many extensions seem to assume it works
[15:44:51] <dexgs>	  the old way. In my case, I use the widgets extension to add some templates that use javascript and my scripts are broken by the fact that & is replaced with &amp;.
[15:44:56] <dexgs>	 Any help sorting this out is appreciated!
[15:46:56] <dexgs>	 s/ParserBeforeTidy/ParserAfterTidy/
[16:00:00] <bd808>	 dexgs: the latest release note I'm seeing explicitly related to ParserAfterTidy was in 1.35. Your question is probably worth either a wikitech-l email or a Phabricator bug report.
[16:05:09] <ihurbain>	 I incidentally ran into https://phabricator.wikimedia.org/T406391 today, which MIGHT be related. it MIGHT be that we now go through Remex in cases where we weren't, and that there is/was something working not exactly right there. there's a patch for that issue that might help if you can apply it. maybe.
[16:05:40] <ihurbain>	 (no guarantee, I'm doing heavy pattern matching on something I coincidentally saw today, so it may have nothing to do with your issue and/or not fix it entirely)
[16:06:52] <ihurbain>	 otherwise, as mentioned above, phabricator is probably the right avenue indeed
[16:18:11] <bd808>	 `With an extension outputting <script> tags with & (if-statements) during ParserAfterTidy etc.` -- that sure sounds like T406391 is the same issue.
[16:18:12] <stashbot>	 T406391: Ampersand (&) in raw-text tags output by extensions should not be encoded during OutputTransform - https://phabricator.wikimedia.org/T406391
[16:26:01] <rovanion>	 I just upgraded from 1.34 to 1.35 and whenever someone tries to view the history of a page a SQL query starts that never terminates. Anyone experienced this before?
[16:26:06] <rovanion>	 ---TRANSACTION (0x7f178061f380), ACTIVE 14054 sec starting index read
[16:26:22] <Reedy>	 1.35 isn't very supported and is pretty old
[16:26:38] <rovanion>	 Absolutely, but I need to pass through it in order to update to a supported version.
[16:26:46] <Reedy>	 So it may have been fixed in a newer release, but people aren't really going to spend much time helping ;)
[16:44:04] <tgr_>	 rovanion: a query not terminating sounds more like a problem with your DB server than with MediaWiki
[16:44:25] <tgr_>	 normally, PHP shouldn't be able to do that
[16:45:41] <rovanion>	 tgr_: Why not? Writing an infinite loop in SQL is not impossible.
[16:52:28] <rovanion>	 But yeah, I've tried increasing the innodb_buffer_pool_size 1GB without affect, so I don't think it's just slow.
[17:05:23] <rovanion>	 Viewing the history of a page with only one entry in its actually finishes after 6.5s.
[17:12:01] <rovanion>	 I've found and ran analyze on the query that's taking so much time: https://paste.debian.net/1400217/
[17:12:25] <rovanion>	 It does a join with what I read as 7106 resulting rows.
[17:14:51] <Reedy>	 I mean, you want to make sure your data migrates ok.. But at the same time, the amount of time and effort debugging these things on ancient versions..
[17:15:15] <rovanion>	 Yeah, I don't want to take the next step until I've verified that the content is okey.
[17:15:30] <Reedy>	 Have you got a backup from before?
[17:20:37] <rovanion>	 A sql dump yeah.
[18:20:28] <rovanion>	 The reason why the query is slow is because all users are compared against all comments. 
[18:22:04] <rovanion>	 Joined rather. With 618 users and 7106 comments the same comparison runs 4391508 times.
[18:35:25] <rovanion>	 I found the problem. revision.rev_comment and revision.rev_actor are all 0.
[18:46:57] <Reedy>	 Have you run update.php?
[18:47:40] <rovanion>	 Yup, and it said nothing interesting. But I'm finding now that it may have incorrectly marked some migrations as done although they weren't.
[18:49:11] <Reedy>	 you did migrate to the latest point release of 1.35 too?
[18:49:30] <rovanion>	 I'm on 1.35.2 which I think is the latest.
[18:49:56] <Reedy>	 Nope
[18:50:00] <Reedy>	 1.35.14 is
[18:50:17] <rovanion>	 Why on earth did I end up with .2 then...
[18:50:20] <Reedy>	 It is entirely possible any migration bug(s) you're finding were fixed in those newer point releases
[18:51:01] <Reedy>	 I'd restore your SQL backup, and then try again with 1.35.14
[18:51:13] <Reedy>	 Though if you're starting on 1.34, you can go straight to 1.39
[18:51:37] <rovanion>	 I can? Thought I had to pass through every LTS on the way.
[18:52:17] <rovanion>	 Now I just have to dump out the changes that were done over the last two days when the wiki was up but in a bad state.
[18:52:23] <rovanion>	 Thank you for the help!
[20:02:20] <Reedy>	 rovanion: https://www.mediawiki.org/wiki/Manual:Upgrading#Check_requirements
[20:02:25] <Reedy>	 >Since version 1.36, MediaWiki commits to supporting upgrades from up to two LTS releases ago (see T259771). Upgrades from older versions of MediaWiki have to be performed in multiple steps. For example, to upgrade from 1.34 (or earlier) to 1.44, first upgrade your wiki to 1.35 (or 1.39), and then, you'll be able to upgrade to 1.44.
[20:02:25] <stashbot>	 T259771: RFC: Drop support for older database upgrades - https://phabricator.wikimedia.org/T259771
[20:02:56] <Reedy>	 https://github.com/wikimedia/mediawiki/blob/REL1_39/includes/installer/MysqlUpdater.php
[20:03:02] <Reedy>	 1.39 has patches back to basically 1.31
[20:07:02] <rovanion>	 Man. The mediawiki-extensions repo stopped added tags after release 1.35. I had just set up a puppet module built on the existence of those tags.
[20:11:10] <Reedy>	 Yeah, it's not ideal
[21:14:57] <rovanion>	 I think I see where this all went wrong. When this puppet code was written they added an exec of `install.php` if LocalSettings.php did not exist. What it did not take into account was of course that this could be on a production machine where the database does exist but the source code folder is new. So install.php seems to have gone in, created or modified tables without migrating data to the
[21:14:59] <rovanion>	 new schema, and when I manually ran `update.php` later on it concluded that the database was of the right schema and that it therefore was nothing that needed to be done.