Hi we have a media wiki hosted by a cloud provider and I need to move the content to a new one I have setup on our local network. I have tried the export and import but am confused by the Interwiki prefix error. What do I need to enter into the field ?
Also is there any way of exporting the user accounts to the new wiki?
Thanks in advance
@Megacubic sorry for messing with your original questions. But I think you can use MySQL for this.
If you follow my instructions you get a complete copy of your wiki.
As far as I have found there is "only" these: Extension:UserExport / Extension:ImportUsers- this will export in .CSV format.
However it looks like you will be allowed to see the passwords, and that may giver some issues... depending on your users views/needs for privacy... if this is at all an possible problem you should perhaps prompt the users to create new logins. (Some GDPR issues may pop up?)
I do not know if you can make/reserve the usernames with random passwords, then mail them.. and ask/force them to change the password! (also, perhaps take a look at this: Wikimedia Security Team/Password strengthening 2019 )
Can't you take a dump of the database (mysql) and import it to the new server?
Thanks - That is what I would try next, only I do not know if that will work goring from 1.18 to 1.32 - has the tables changed and do I finally need to run some PHP (that I do not have access to.. ) .
Also I would think that I am not the only one that will have this, very basic, problem.. (sorry this was about the users, my current problem is regarding the export/import that is apparently not working for categories)...
Exporting the contents of the database isn't a problem if you upgrade, because after importing the contents of the database you'll do an upgrade (if you also copy the LocalSettings.php file with required modifications like database and paths).
See Manual:Moving a wiki for explanations and alternatives.
Thanks, I am not sure if the "upgrade" will do all what I need as I try to import the 1.18 MySQL tables, into the 1.32 tables. - I may have to run the rebuildall.php, but I do not have the PHP command line probably also because I have no access to PHP command line at the host I chose.
I Looks like I managed to get this done in few simple steps.... I will naturally first need to test if everything is working.... and the I will post at the Manual:Moving a wiki page. ;-)
I must admit that I find the move/upgrade as the most difficult task here, to many alternatives/options/choices with unknown consequences.. and I have to learn a lot of different tools, only to find that they are not fit or not needed. The entire process could be much more easy, if not automated.
But there are also a lot of stuff that can go wrong, say I have the 1.18 in utf-8 (on an W7 laptop), while the hosted Installatron installed 1,32 in binary... and it seems like there are 'more' tables in 1.32. -only time will tell if I need the data in these tables and if I then somehow need to convert the missing data to utf-8.
The "easy" way would be to mirror the 1.18 and upgrade it on the laptop, but can that be done in one take, will installing the latest PHP/MySQL version invalidate the laptop... that is slowly dying.
The idea of moving a wiki is not import 1.18 data in 1.32 tables, but to copy the 1.18 tables to a new database on the new hosting, leaving it the same as 1.18. Then run update.php to upgrade the 1.18 schema to 1.32 (or the version you're using on the new host), giving the correct database credentials in LocalSettings.php
I did that - on a Installatron supported host - and it seems to work OK, only i wonder if there are some MySQL data that was lost.. I does not look like things are missing,but I wound not know that until I hit something that is affected.. this requires that you have a little bit of understanding on MySQL, tables, their naming and the different users/passwords...
In my case the host has cPanel/Installatron support... to make this work with the backup features you must first install a "blank" Wiki, inspect how Installatron refers to the MySQL tables, as you need to change this setup (both regarding database name and db-prefix. I do not have the option to run update.php - but i did run mw-config and after that I used a cPanel function to upgrade 1.32 to 1.32, I don't really know what effect that has!?
This is what I did:
* I create a new table, in phpMyAdmin (the user/password is the one that you use in Installatron)
* Create a New Wiki and I Export the MySQL tables, New Wiki to a file (inspect this installation, and try to match this database/prefix to that of the original table. Parameters can be seen in localsettings.PHP)
* I changed the table name and prefix of tables, by edit of the file exported file - to match the final result
* I load the new version of New Wiki tables
* I then Export the data from the Old Wiki... and
* Again, I changed the table name and prefix of tables, to match the final result
* I Load the Old Wiki data - it will drop all existing tables and keeps those that are new between versions
* I run mw-config - see https://www.mediawiki.org/wiki/Manual:Config_script
* and I update the localsettings.PHP to match the final results (the users/passwords are preserved, but the pw for the tables are that that was set in step one!)
* Finally I used the edit function of (<your web path to:>'/installatron/index.cgi#/installs' to match the new parameters for the MySQL tables....
Doing this I managed to move a 1.18 Wiki to 1.32... the two final steps would be:
* Upload all files in the /images folder as-is, these will work fine as they are registered in the MySQL.
* Install all extensions that was (and are to be) in use in your Old Wiki...
The only thing that I think may go really wrong, would be that I needed this CHARSET=utf8; and not CHARSET=binary; - where binary seems to be the default (or perhaps a "wrong choice" made when I used Installatron to set up the new Wiki...) - I needed this to support Scandinavian languages, and I don't know if binary is a better or worse solution.
Note that the installer no longer gives the option to choose a utf8 charset (binary will be the default). See phab:T196092.
Thanks @Ciencia Al Poder - that would be a bit of a problem, along the way? I imagine that I should convert the tables asap, perhaps there is some SQL option that will tell that all input is utf8, but the new table is to be loaded using binary... I can however find a bunch of ways to convert from binary to utf8, not the other way!
utf8 will still be supported, but maybe in the future the collation must be changed manually.
Thanks again - I must take a look into this, (just a bit later as I have some 400 pages I need to reorganize, that was the initial task I was to take on)..
And as you can see, I found that I had added a brand new namespace - but when doing that I an old namespace to that, thus the old-namespace came up twice and the links was not working.
@Ciencia Al PoderYour help is much appreciated - and I hope I will eventually be able to provide some help back to the community ... Now I can finally get to work! ;-)
