[01:13:11] !debug [01:13:11] 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 [11:55:44] Hello, I am in the process of upgrading a MediaWiki instance that has multiple sites running on it to the newest version. Do you have any recommendations on how to carry on with the upgrade so that there would be no downtime? [11:56:00] I am upgrading from a VERY old version. [11:56:20] And I know that there will be many problems with extensions used for example [11:57:22] Is is possible to setup a new MediaWiki with a fresh database, and then somehow move in the databases of each site (prefix method) one at a time? [11:58:00] I know that migrations are needed in between, so I can't just dump them in like that [12:02:42] harmaahy1je: best option would be to create a separate environment. 1. Set the wikis to read-only. 2. Copy code and data to the separate environment 3. Update code and databases 4. Place updated code and data on the old environment (there can be some amount of downtime depending how you execute this step). [12:02:49] harmaahy1je: are you Finnish btw? [12:08:13] Nikerabbit: yep [12:09:34] Nikerabbit: I was wondering if it is possible to set them read-only, that is nice. So then I can take dumps now and not worry about data added after that. [12:10:01] $wgReadOnly = 'Text that is displayed to users when try to edit'; [12:10:10] Nikerabbit: thanks! [12:10:23] and I think MediaWiki is able to surive also if mysql itself is made read-only. [12:12:18] harmaahy1je: if you need more hands-on help with upgrading feel free to contact me privately [12:12:38] I have a test "live" site, and local servers that I can work with. But I am wondering if it is possible to use the "live test server" for development, as it has a different domain. I am uncertain if the 'prefix' thing has an effect for that? [12:13:00] Nikerabbit: wonderful, thanks. I might do that at some time [12:14:01] harmaahy1je: if you have set $wgServer of $wgCanonicalServer in LocalSettings.php, make sure they are set appropriately on your test servers [12:14:38] the prefix is set in $wgDbPrefix (IIRC) and it by default doesn't even depend on the domain [12:14:38] I am working with several LocalSettings files, each for a different site [12:15:39] Good to know, if that is the case and the db prefix doesn't affect the domain, I can probably work that out [12:15:48] harmaahy1je: but I assume you have some kind of logic which chooses the right LocalSettings.php file [12:16:11] and not duplicating all mediawiki + extension code N times :) [12:18:00] Nikerabbit: yes there is some logic, but I can't remember it, I will take a look at the old settings files [12:20:21] Nikerabbit: Would it be possible to work on one site at a time. So that I make one site read-only, then somehow (if possible) dump only the database prefix'd stuff for that site, move it to the test site, make changes, move it to a new server or something, disable old site [12:21:54] the downtime will be much longer if I have to work on all sites at the same time, mostly due to the outdated extensions (some of which no longer work with latest version of mediawiki) [12:30:29] yeah the logic is in the LocalSettings.php file, which directs to the different sites based on the servername [12:32:06] Nikerabbit: it would seem to me that I can just change the wgServer and wgDBprefix, just like you said, and do the sites one by one [12:32:30] harmaahy1je: with "downtime" you mean read-only time? [12:33:17] harmaahy1je: I would advice against doing site-by site if they run from the same codebase, old MediaWiki is likely not going to work with the new SQL schema (and new mediawiki not with the old) [12:34:06] I mean read-only time, and the time to switch a site from the old server to the new server [12:35:12] Nikerabbit: I was wondering if I can dump the data with the site_prefixes one by one, then migrate them to the new schema, work on them on the test site, make a dump and move to a new site [12:35:34] new site = new server [12:35:56] harmaahy1je: yeah you can, I assume you can switch from DNS the invidial wikis to a new server [12:36:33] dumping database by prefix... I am not sure if that is trivial... You can always make a list of tables for each prefix and ask mysql to dump those tables [12:37:23] hmm [12:38:29] that's what the internet says at least: https://stackoverflow.com/questions/5268936/mysqldump-only-tables-with-certain-prefix-mysqldump-wildcards [12:38:35] I could also just leave the old sites be without read-only, make a dump, set up a dev server, fix all the problems with extensions, document the changes. And after that works, set the old sites read-only, make a new dump and repeat according to the documentation I made [12:39:34] yeah basically you would take a new dump and run updade.php for each wiki again [12:39:41] yes [12:39:47] maybe I will do that [12:41:34] then I don't have to deal with migrations for each site (dbprefix) alone, it might be problematic [12:42:28] Nikerabbit: thanks for your advice, I think I have it figured out a general plan now. I will (most likely) be back here, once I hit other problems. :) [12:45:18] harmaahy1je: okay, feel free to ping me (I don't watch this channel regularly) [19:27:23] Question... I'm setting up a wiki, but I want to approve users before they can make edits (for a local makerspace). Any recommendations? Should I create a new group "approved" and assign users accordingly and only enable 'edit' permissions for them? [19:29:28] I was also looking at the 'ConfirmAccount' plugin [19:38:19] That's one of the commonly used solutions, yeah