Manual:Maintenance scripts

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  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.

Configuration
The and  configuration variables must be set in order to run maintenance scripts that need to alter the structure of the database (like  ) if the user configured in  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 .

MySQL
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, then the following SQL would create such a user who can exercise superuser privileges on localhost.:

Once the account exists, the account name should be set in the configuration variable. Like other configuration variables, should be set in. A password for must be set in the  configuration variable.

PostgreSQL
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 or  at all.

Running the scripts
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, one can use the SSH command line tool introduced in Windows 10 or alternatively use a third-party tool such as PuTTY shown below or use Windows Subsystem for Linux.

Required program for Windows users: PuTTY or any terminal emulator


 * Step 1: Download and run PuTTY, a terminal emulator.


 * 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  to see what folder you are currently in. The maintenance folder is in the root mediawiki folder.


 * Step 6: Execute the maintenance script that needs to be run:


 * If you get an error (for example: php.exe is no valid Win32 application), try the following:


 * In Windows, the command is:

Standard command-line options
Almost every PHP script in  supports several standard options:
 * --help
 * Displays help message


 * --conf &lt;path&gt;
 * Location of LocalSettings.php, if not default (at parent directory of the script)


 * --dbuser &lt;username&gt;
 * 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 &lt;password&gt;
 * 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


 * --globals
 * Output globals at the end of processing for debugging


 * --memory-limit &lt;value&gt;
 * Set memory limit for the script. Accepts ordinary numbers, standard php.ini abbreviations (1024K, 20M, 1G),  for no limit (will be used by default if omitted) and   for no change.


 * --quiet
 * Suppress non-error output


 * --wiki &lt;id&gt;
 * Wiki ID for wiki farms. This may be of the form  or  . LocalSettings.php will be run with the   and   constants defined accordingly.


 * --profiler
 * Profiler output format (usually "text").


 * --mwdebug
 * Enable built-in MediaWiki development settings.

MediaWiki installs that use symlinks
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.

MediaWiki installs that use shared settings (family type)
Sometimes MediaWiki is installed as a family for many languages and settings ( LocalSettings.php ) are split to common part and language parts (see ) 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:

No shell access
On many shared hosts, you won't have shell access. The following extensions may be useful to run maintenance scripts via the web: and.

List of maintenance scripts
Instead of this probably-outdated list,


 * 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)
 * 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  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.