[19:54:07] <firespeaker>	 I'm trying to upgrade an old version of mediawiki incrementally, and successfully applied minor patches with no trouble
[19:54:20] <firespeaker>	 I'm having trouble figuring out how to get from a minor version to the next major version
[19:54:35] <firespeaker>	 the supplied .0 major version patch fails spectacularly
[19:55:01] <firespeaker>	 it seems to even assume a major version release notes file exists
[19:55:18] <firespeaker>	 which makes me think I have to go through the release candidate for that version or something
[19:55:46] <firespeaker>	 but there's no patch file for that
[19:55:51] <firespeaker>	 what am I missing?
[19:56:37] <moonmoon>	 you don't use patches for version upgrades, generally speaking (they're provided for minor version upgrades as a convenience, but major version upgrades want you to wholesale replace all of the wiki files)
[19:56:52] <moonmoon>	 firespeaker: what version are you currently on, and what version are you trying to go to?
[19:58:40] <firespeaker>	 I'm on 1.32.0 and want to get to at least 1.42.4
[19:58:47] <moonmoon>	 ok
[19:58:48] <firespeaker>	 I got it to 1.32.6 no problem
[19:58:52] <moonmoon>	 so you'll need to upgrade in two steps
[19:58:57] <firespeaker>	 (I read that I need to get it to 1.35 first)
[19:58:58] <moonmoon>	 1.32 -> 1.39, then 1.39 -> 1.42
[19:59:05] <firespeaker>	 er yeah, 1.39
[19:59:16] <moonmoon>	 you do NOT need to upgrade to each individual intermediate version in between those
[19:59:28] <moonmoon>	 can just leapfrog directly to 1.39, and from there directly to 1.42
[19:59:30] <firespeaker>	 actually it says 1.35
[19:59:39] <firespeaker>	 how?
[19:59:46] <firespeaker>	 > Upgrades from older versions of MediaWiki will have to be performed in multiple steps. This means that if you want to upgrade to 1.43 from 1.34 or earlier, you'll first have to upgrade your 1.34 wiki to 1.35 (or 1.43), and, from 1.35 (or 1.43), you'll be able to upgrade to 1.43
[20:01:27] <moonmoon>	 firespeaker: there's some templating wierdness in that blurb
[20:01:39] <moonmoon>	 it should say "1.35 (or 1.39)" instead of "1.35 (or 1.43)"
[20:02:33] <firespeaker>	 oh interesting
[20:02:52] <firespeaker>	 okay, so grab the latest 1.39 tarball, extract, run the upgrade script?
[20:03:09] <firespeaker>	 *update script lol
[20:03:35] <moonmoon>	 anyway, the general process is to make a backup of files+db, extract the 1.39 tarball to a *fresh* directory, copy over your LocalSettings and images, grab fresh versions of all of your extensions, then run the update script
[20:03:49] <moonmoon>	 then repeat for 1.42
[20:03:52] <firespeaker>	 got it
[20:04:09] <firespeaker>	 should it be 1.39.0 or is 1.39.11 better for this?
[20:04:12] <moonmoon>	 (you can extract over the existing files too, but that may leave files lingering around that are no longer used/needed)
[20:04:15] <moonmoon>	 1.39.11
[20:04:24] <firespeaker>	 ah makes sense
[20:04:26] <firespeaker>	 okay, cool, thanks
[20:04:29] * firespeaker attempts
[20:18:16] <firespeaker>	 okay, upgrade script failed: https://dpaste.org/wmtSU
[20:18:33] <firespeaker>	 seems to not like monobook??
[20:19:54] * firespeaker chowns everything and tries without sudo ....
[20:20:18] <firespeaker>	 same deal
[20:20:25] <Nikerabbit>	 probably your extension/skin path is incorrectly set
[20:20:36] <firespeaker>	 oh hm, okay, will investigate
[20:20:49] <firespeaker>	 wfLoadSkin('MonoBook');
[20:21:14] <firespeaker>	 no path listed, might need to investigate a vanilla LocalSettings
[20:23:05] <moonmoon>	 yeah gonna say your LocalSettings.php might be off
[20:23:51] <moonmoon>	 if it was generated over a decade ago you might want to get a LocalSettings from a clean install and then migrate customizations back over
[20:26:03] <firespeaker>	 this version hasn't been touched since 2019
[20:26:11] <firespeaker>	 the first version of it was like 2004 though
[20:26:26] <firespeaker>	 I'm having trouble finding a vanilla version to look at
[20:26:46] <firespeaker>	 oh gotta use the generator I see
[20:29:02] <moonmoon>	 yeah, run the installer without having a LocalSettings in place
[20:30:46] <firespeaker>	 oh that's annoying
[20:30:49] <firespeaker>	 okay
[20:31:17] <firespeaker>	 annoying because I can't just do it in a terminal ;_;
[20:33:46] <moonmoon>	 you can: https://www.mediawiki.org/wiki/Manual:Install.php
[20:36:04] <firespeaker>	 oh why was I looking at https://www.mediawiki.org/wiki/Manual:Installing_MediaWiki
[20:38:19] <moonmoon>	 the web installer is the most typical way to install MW and provides the best experience. The cli installer mostly exists for unit tests, but works for advanced users as well that don't need the hand-holding or some of the extra features provided by the web one
[20:38:32] <moonmoon>	 (e.g. large wiki farms scripting creation of new wikis)
[20:39:07] <firespeaker>	 I'm already using the web interface so I'll just continue
[20:39:24] <firespeaker>	 hmm it wants to upgrade the database before it'll give me a LocalSettings.php file
[20:40:44] <moonmoon>	 yep. localsettings is the very last thing it does
[20:40:55] <firespeaker>	 interesting
[20:41:01] <firespeaker>	 scary though
[20:41:10] <moonmoon>	 that upgrade is the same thing upgrade.php does
[20:42:10] <firespeaker>	 yeah, I guess I was thinking based on what you said earlier that I should worry about fresh versions of extensions before upgrading the db
[20:42:28] <firespeaker>	 (I put them in place, but couldn't test them)
[20:42:41] <firespeaker>	 hm this db upgrade sure is taking its time
[20:43:05] <firespeaker>	 I'd rather see a backtrace than a browser spinner ... guess I should've done cli afterall
[20:48:07] <firespeaker>	 still cranking away o_O
[20:50:19] <firespeaker>	 done
[20:50:28] <firespeaker>	 "Ask me more questions" / "I'm bored already"?  Lol
[21:10:57] <firespeaker>	 okay, LocalSettings merged.  One of my extensions isn't compatible with 1.39.11, but I'm upgrading anyway, so will worry about that if it's still a problem when I get to where I want to be
[21:11:05] <firespeaker>	 everything else is looking good
[21:14:10] <moonmoon>	 nice :)
[21:14:20] <moonmoon>	 firespeaker: after upgrading extensions, run update.php again in case those exts have schema changes
[21:14:24] <firespeaker>	 I'm gonna go straight to 1.43
[21:14:27] <firespeaker>	 okay
[21:14:41] <firespeaker>	 1.43.0 is stable, right?
[21:14:50] <moonmoon>	 1.43 is both stable and LTS
[21:14:56] <firespeaker>	 perfect
[21:15:03] <firespeaker>	 someone should update /topic
[21:15:24] <moonmoon>	 oops yeah
[21:21:58] <firespeaker>	 I'm not sure whether it's more reassuring or scary to see the database upgrade log go by
[21:23:44] <firespeaker>	 ooh, I have a working 1.43.0 wiki, with extensions apparently not complaining (but will check functionality...)
[21:25:31] <firespeaker>	 hmm I had some [[Image:...]] that linked out to commons iirc, but now they're not resolving
[21:25:45] <moonmoon>	 check for $wgUseInstantCommons = true; in your LocalSettings
[21:25:59] <moonmoon>	 (it should be there, and be true instead of false)
[21:26:31] <firespeaker>	 aha
[21:27:00] <firespeaker>	 ah yes, that did it
[21:27:20] <firespeaker>	 I also had some inline urls for off-site images that now just show as urls
[21:27:40] <moonmoon>	 couple of ways to approach that, depending on what you're after
[21:28:26] <firespeaker>	 just some images embedding in some tables
[21:29:00] <firespeaker>	 I can semi-automatically adjust all the urls if needed
[21:29:13] <moonmoon>	 if the wiki is private or you strictly control who is able to edit (and you trust those people), then $wgAllowExternalImages = true; Conversely if your wiki is publicly editable I do not recommend that as it may allow tracking of wiki visitors or people putting in images you'd rather not have appear
[21:30:07] <moonmoon>	 the opposite option is to upload them all locally (via upload-by-url) -- $wgAllowCopyUploads = true; and $wgGroupPermissions['sysop']['upload_by_url'] = true; will let admins do this
[21:30:28] <firespeaker>	 ah, interesting
[21:30:32] <moonmoon>	 oh and $wgCopyUploadsFromSpecialUpload = true;
[21:31:20] <moonmoon>	 and then the in-between route is to still allow externally-hosted images, but only from a short allowlist of valid URLs.
[21:31:23] <firespeaker>	 I think it makes more sense to have these off-site, and only a few other people other than me have ever had edit access to this wiki and I trust all of them
[21:31:34] <firespeaker>	 ah that's an interesting option
[21:32:04] <moonmoon>	 there are two ways to accomplish that: one via config only $wgAllowExternalImagesFrom and the other $wgEnableImageWhitelist which enables the page [[MediaWiki:External image whitelist]]
[21:32:28] <firespeaker>	 does one allow regex urls?
[21:33:00] <moonmoon>	 AllowExternalImagesFrom is a dumb prefix match. The external image whitelist page is regex
[21:33:15] <firespeaker>	 nice
[21:33:21] <firespeaker>	 just found some docs on it, will go that route
[21:34:40] <firespeaker>	 oh lol I already had that implemented
[21:34:48] <firespeaker>	 just didn't move it over in my LocalSettings
[21:34:52] <moonmoon>	 aha :)
[21:35:13] <firespeaker>	 whitelist last edited by me in 2018, damned if I remember doing it...
[21:35:24] <moonmoon>	 also dang I feel old now, apparently I added that feature in 17 years ago :<
[21:35:36] <firespeaker>	 haha nice, I know how you feel....
[21:35:55] <firespeaker>	 somehow my first edit of the page is listed as 2001 though
[21:36:06] <firespeaker>	 but that can't be right, I didn't have this wiki going yet then
[21:36:22] <firespeaker>	 oh one server it was on had a bad clock battery for a while
[21:37:42] <firespeaker>	 forgot to move in my .htaccess, now that's working too
[21:55:04] <firespeaker>	 hm, I'm getting some weird timeouts sometimes associated with some weird errors in the log
[21:55:35] <firespeaker>	 [Wed Jan 15 16:54:18.493245 2025] [php:error] [pid 17476:tid 17476] [client 98.115.185.109:47036] PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /data/server/[redacted]/includes/libs/rdbms/TransactionProfiler.php on line 570, referer: [redacted]
[21:56:00] <firespeaker>	 maybe it's trying to do some maintenance and I should let it take longer?
[21:59:34] <firespeaker>	 no, it's just when I try to open or search for specific pages
[22:01:27] <firespeaker>	 [Wed Jan 15 17:00:42.865920 2025] [php:error] [pid 18574:tid 18574] [client 98.115.185.109:34350] PHP Fatal error:  Maximum execution time of 30 seconds exceeded in /data/server/[redacted]/includes/debug/MWDebug.php on line 458, referer: https://[redacted]/Main_Page
[22:05:02] <firespeaker>	 it seems to be just one page that behaves like this??
[22:05:29] <firespeaker>	 it's probably the most edited page on the wiki
[22:08:33] <firespeaker>	 cranked it up to 60 seconds and got this:
[22:08:50] <firespeaker>	 [Wed Jan 15 17:08:01.546577 2025] [php:error] [pid 19310:tid 19310] [client 98.115.185.109:33330] PHP Fatal error:  Maximum execution time of 60 seconds exceeded in /data/server/[redacted]/includes/GlobalFunctions.php on line 953, referer: [redacted]
[22:12:35] <moonmoon>	 cranking up timeouts is almost always the wrong choice. would be good to know why it's happening. is it an extension? something else?
[22:17:17] <moonmoon>	 might want to double-check your cache settings. misconfigured caching (or not configuring caching) will absolutely murder wiki performance and can cause php timeouts. https://www.mediawiki.org/wiki/Manual:Performance_tuning
[22:39:16] <firespeaker>	 pretty sure I have no extensions in use on that page, but I could be forgetting something
[22:39:21] <firespeaker>	 will look into cache stuff
[22:40:54] <firespeaker>	 okay, got APCu installed
[22:41:35] <firespeaker>	 similar behaviour
[22:41:52] <firespeaker>	 how can I look into what's causing the issue
[22:42:19] <firespeaker>	 checking the error log and trying to remember if I'm using extensions on the page are obviously insufficient
[22:44:50] <firespeaker>	 huh, times out when I try to edit the page too
[22:44:54] <firespeaker>	 but not other pages
[22:45:04] <firespeaker>	 maybe something going on in the database??
[22:48:30] <firespeaker>	 page_id is 792
[22:50:57] <firespeaker>	 738 rows in `revision` with that `rev_page` id
[22:57:40] <firespeaker>	 rev_id of latest is 11573
[22:57:50] <firespeaker>	 (trying to track down the actual contents)
[23:00:54] <Vulpix>	 you can enable the debug log and also log the database statements it's running on the database
[23:00:56] <Vulpix>	 !debug
[23:00:56] <wm-bot>	 For information on debugging (including viewing errors), see https://mediawiki.org/wiki/Manual:How_to_debug . A list of related configuration variables is at https://mediawiki.org/wiki/Manual:Configuration_settings#Debug.2Flogging Also see https://mediawiki.org/wiki/Manual:Errors_and_symptoms
[23:01:17] <firespeaker>	 oh good idea, Vulpix, thanks
[23:02:09] <Vulpix>	 the debug log add timestamps to each log entry (IIRC), which may help to see where's taking a lot of time
[23:03:56] <firespeaker>	 +1