The maintenance scripts are used to perform various administrative, import, maintenance, reporting and upgrade tasks. The scripts are written in PHP and live in the
maintenance subdirectory of MediaWiki installs.
There are dozens of scripts with varying degrees of general utility and quality. You should carefully read the documentation on a script before using it; if a script isn't documented, take additional care running it.
$wgDBadminpassword configuration variables must be set in order to run maintenance scripts that need to alter the structure of the database (like Manual:Update.php) if the user configured in Manual:$wgDBuser doesn't have enough permissions. Alternatively, you can pass the --dbuser and --dbpass parameters to the script. The values for these variables differ based on the database engine that is being used to power your installation of MediaWiki.
If not configured, it will use the user configured in Manual:$wgDBuser.
Some of the maintenance scripts require database permissions that, for security reasons, the main MediaWiki database account should not have. A separate database account with 'superuser' privileges for just the MediaWiki database should be created (if it does not already exist.) If the database that you use for MediaWiki is called
wikidb, then the following SQL would create such a user who can exercise superuser privileges on localhost.:
GRANT ALL PRIVILEGES ON wikidb.* TO 'wikidbadmin'@'localhost' IDENTIFIED BY 'strong-password';
Once the account exists, the account name should be set in the
$wgDBadminuser configuration variable. Like other configuration variables,
$wgDBadminuser should be set in LocalSettings.php. A password for
$wgDBadminuser must be set in the
$wgDBadminpassword configuration variable.
PostgreSQL uses a different security model than MySQL and the same PostgreSQL server account used for day-to-day operation of the MediaWiki installation must also be used for running the maintenance scripts. This is necessary to ensure that the owner for new tables created by the maintenance scripts is set correctly. You don't need to set
$wgDBadminpassword at all.
Running the scriptsEdit
The maintenance scripts must then be run from the command line. Users who do not access the server directly from its terminal will usually establish a connection through ssh. For Linux/Unix users this is by using the ssh client in a shell. For Windows users the use of a ssh client application such as the one introduced below is required.
- Step 2: In PuTTy, under the Host Name (or IP address) enter the IP Address of your web hosting site (Contact your website provider if necessary) and click Open.
- Step 3: A command screen will pop up. At the login as: line enter the FTP user name.
- Step 4: Enter the FTP password.
- Step 5: Change the current directory to the maintenance subdirectory. You can type
pwdto see what folder you are currently in. The maintenance folder is in the root mediawiki folder.
$ cd maintenance
- Step 6: Execute the maintenance script that needs to be run:
$ php rebuildall.php
- If you get an error (for example: php.exe is no valid Win32 application), try the following:
$ php-cgi rebuildall.php
- In Windows, the command is:
$ C:\path\to\php\php-win.exe C:\path\to\mediawiki\maintenance\rebuildall.php
MW_INSTALL_PATHenvironment variable to point to the root of your MediaWiki installation. This will help scripts to find the necessary files, and is particularly relevant when running maintenance scripts provided by third-party extensions.
Standard command-line optionsEdit
Almost every PHP script in
/maintenance supports several standard options:
- Displays help message
- --conf <path>
- Location of LocalSettings.php, if not default (at parent directory of the script)
- --dbuser <username>
- Database account to use instead of the one specified in LocalSettings.php, not used for scripts that don't require a database connection or when SQLite database backend is used
- --dbpass <password>
- Database password to use instead of the one specified in LocalSettings.php, not used for scripts that don't require a database connection or when SQLite database backend is used
- Output globals at the end of processing for debugging
- --memory-limit <value>
- Set memory limit for the script. Accepts ordinary numbers, standard php.ini abbreviations (1024K, 20M, 1G),
maxfor no limit (will be used by default if omitted) and
defaultfor no change. (introduced in 1.17)
- Suppress non-error output
- --wiki <id>
- Wiki ID for wiki farms. This may be of the form
dbname-prefix. LocalSettings.php will be run with the
MW_PREFIXconstants defined accordingly.
- Profiler output format (usually "text"). (introduced in 1.22)
- Enable built-in MediaWiki development settings. (introduced in 1.31)
In cases where the MediaWiki php files are symlinked to a central installation, you will need to specify to the maintenance script the path of the LocalSettings.php file. For example:
php maintenance/importImages.php --conf /var/wwwdata/website.org/wiki/LocalSettings.php /tmp/wikiimages .jpg .png .svg
Otherwise you will get this error:
A copy of your installation's LocalSettings.php must exist and be readable in the source directory.
Sometimes MediaWiki is installed as a family for many languages and settings (LocalSettings.php) are split to common part and language parts (see Manual:Wiki family#Shared Settings) where common part is located outside of /w directory and accessed using relative link (
In this case maintenance scripts will not work when running them in /w/maintenance directory.
Run them from /w directory instead:
$ php maintenance/rebuildall.php
No shell accessEdit
List of maintenance scriptsEdit
Instead of this probably-outdated list,
- Browse the latest contents of the
- https://doc.wikimedia.org/mediawiki-core/master/php/ - View its generated documentation summary. (Files > File List > maintenance in the tabs or left-hand navigation sidebar)
Here is the list of files included in the
maintenance subdirectory located at the root of a MediaWiki installation. You can contribute to this manual by keeping this list up to date, adding a description of these files' specific purpose and of how an administrator should use them (command line examples, etc.). Be aware that these were created and named on an ad hoc basis so have some usability issues.