Manual:Moving a wiki

This page explains how to move a wiki to another server. This is often needed when moving to a different web server or domain (or both).

(Note: if you are looking to just move your wiki e.g. from /var/www/html/ to /var/www/html/mywiki/ instructions are here).

Versions and upgrading
The instructions on this page should apply more or less evenly to any given version of MediaWiki. Ensure, prior to moving, that any upgrading of the software and database schema is done. You should only move a database into another MediaWiki installation if they both run the same version. If you need to do both, make sure to upgrade before migrating to a different web server.

File transfer
Choose a method for transferring files:
 * SCP or WinSCP
 * SSH File Transfer Protocol (SFTP)
 * Using an FTP client.
 * Using rsync
 * The hosting company might provide a file manager interface via the web browser, check with your provider.
 * Some other method, there is a list of these at List of file transfer protocols

Overview

 * 1) Back up the database
 * 2) Back up the MediaWiki files
 * 3) Re-create the database, user and permissions
 * 4) Import the database backup
 * 5) Import the MediaWiki files
 * 6) Check the configuration file
 * 7) Test

Back up the database
To move or copy your wiki, you need to start by making a backup of everything. You should probably copy at least the following:
 * The wiki's database content. See Manual:Backing up a wiki.
 * Images and other media files, i.e., the contents of the images and if modified any files from the skins directory.
 * Favicon and .htaccess files.
 * Configuration files, e.g., LocalSettings.php and (on older wiki's maybe AdminSettings.php as well).
 * The contents of the extensions folder.

Extract uploaded files (images)
Requires shell access to the server:

php dumpUploads.php > listOfMediafiles.txt mwstore://local-backend/local-public/7/7a/STAT-Folnode6_c_3.gif mwstore://local-backend/local-public/9/90/STAT-Folnode6_c_4.gif mwstore://local-backend/local-public/d/d9/STAT-Folnode6_c_5.gif ... xargs -a listOfMediafiles.txt cp -t /my/wiki/maintenance/backup
 * Go to the maintenance directory
 * Create a subdirectory backup
 * Use DumpUploads.php to extract the location of the uploaded images
 * The content in listOfMediafiles.txt looks like
 * Replace in a editor mwstore://local-backend/local-public/ with the (absolute) path to the /my/wiki/images/ to have a file list
 * Call
 * Now your uploaded files/images are in the backup directory and can be copied and reimported with importImages.php</tt>

Set up the destination database
On the destination server, create a new MySQL database and a user, and grant that user permissions on the database. SELECT, INSERT, UPDATE and DELETE permissions should suffice. You also need DROP, CREATE and ALTER to import the data base. You may need to consult the MySQL documentation, your hosting provider's control panel documentation, or the documentation of any other utilities you are using for information on how to do this.

Note: The destination database may have a different name, user and/or password. If that is the case, you only have to update the configuration file on the new server (after you completed the following steps, though).

Import the database backup
The next step is to import the database backup. This creates the tables in the database and populate them with data. Duplicating the database on the other server. Importing takes a variable amount of time, depending upon the number of pages, users, edits, etc. in the wiki.

Possible methods
See Manual:Restoring a wiki from backup for the full details. Possible methods for performing the import include:
 * From the command line using mysql
 * With phpMyAdmin via a web browser (not recommended for large databases due to potential timeout problems that could leave the database only partially imported, and perhaps in an inconsistent state, e.g., with revision metadata imported but not the corresponding revision text)
 * From an XML dump
 * Using BigDump if you don't have command-line access and your MySQL administration tool has an upload size limit that is lower than the size of your database.

Import the MediaWiki files
The final "large" step in the moving process is to upload/copy the MediaWiki files (the "wiki" folder) to the destination server. If you followed the instructions above, and backed up the entire directory, this includes the images and extensions directories, plus custom skins, etc. and the configuration file.

If you backed up only portions of the directory, e.g. images, extensions, etc. then you must first upload or copy a fresh install of the MediaWiki files, then transfer the backed-up directories and files into the correct locations in the new filesystem.

Update the configuration file
The final step is to update the LocalSettings.php file. Certain entries in this will almost undoubtedly require changing.

Check the following configuration options:

You might also need to check the paths to diff3</tt>, ImageMagick, etc.

Test
At this point, try to use the wiki on the new server. Log in as a sysop and a regular user and check that viewing, creating and editing pages and uploading files still works. Fix any problems reported either by PHP or MediaWiki itself.

Frequent problems
The column md_deps in the module_deps table contains absolute file paths, which are used to locate the images and LESS files that CSS depends on. These paths break when the wiki is, e.g., moved to another folder or another server. After your move, you might see PHP warnings that certain files could not be accessed. In current versions of MediaWiki, this can be solved by running update.php, thus clearing caches.
 * Inaccessible files after the changing the domain

In versions older than MediaWiki 1.25 (where T37472 is not implemented), update.php does not delete the contents of the module_deps table. For these versions, the workaround is to manually fix wrong entries in the module_deps table:

This can be used to update wrong path segments and to fix the error.

A similar issue can happen when MediaWiki tries to read resource loader messages. In this case the solution is to truncate the according tables: