MediaWiki/Guide/System Administrator

Jump to navigation Jump to search

A Guide to the role of System Administrator for MediaWiki in a hosted environment

This article is part of a series compiled as a guide to encourage and assist those building a MediaWiki-based website in a hosted environment.

Each article links to relevant documentation from the website and the website. Where the official documentation does not adequately cover the issues for a hosted site, or is too 'advanced', additional information, explanation and advice is provided.

Systems Administrator Role

A distinction is made here between the role of System Administrator and the role of Administrator for MediaWiki.

  • A System Administrator is responsible for the overall system. However, if MediaWiki is installed in a hosted environment the highest level of access will be to the root directory of the web site - access to the server itself, the command-line, or the web server, is not possible. Therefore, in practice, the role of Systems Administrator is limited to whatever can be achieved by editing the LocalSettings.php file, plus responsibility for maintenance, backup and recovery, security etc.. An extended list of roles is covered below.
  • A MediaWiki Administrator has access to the Special Pages, can create and manage users, and customize the MediaWiki interface - the role includes anything that can be done without access to the root directory or the LocalSettings.php file.

If you are the website owner for a hosted MediaWiki installation then, in practice, you would have both roles. But for a larger system with many users the role of Administrator can be delegated. has a Sysadmin Hub as a resource or portal for Systems Administrators. There is also a Manual for Systems Administrators. However, as noted above, some tasks described will not be possible in a hosted environment.

Develop a Structure for Users and Groups

As a System Administrator you have a design role. You can determine how users can be structured into groups and how permissions will be assigned to those groups for the purpose of granting rights to read or write content, or prevent access to content in custom namespaces.

Once the structure has been set up in LocalSettings.php it can be managed by an Administrator.

As an example, has published an overview of the User group rights used on that site.

A complex hierarchical structure is outlined in the Manual:Establishing a hierarchy of bureaucrats. This structure may be a good pattern for an Intranet, for example.

Develop a Structure for Content

MediaWiki content grows organically as users contribute and interlink articles. As a Systems Administrator you would not want to stifle creativity, but you may wish to develop a style guide.

However, if the content covers several very distinct areas maybe it should be segmented into different custom namespaces. This has the advantage that you can also specify user rights for namespaces, and even hide the content.

Content in a hidden namespace can be transcluded into a visible page. This feature means that whoever edits the visible page need only have read-only access to the original content, is unable to edit it, but can include it in a different context using tranclusion. It can be a very powerful strategy. MediaWiki does not normally permit transclusion within the Main namespace, but content can be transcluded into pages in the main namespace from custom namespaces.

Backup and Restore

If your MediaWiki installation is in a hosted environment then the sad news is that the two manuals proved by are completely useless. The content is quite technical and assumes access to the server itself and proficiency with command-line operations.

Your only option is to use whatever backup method is available through your host interface. You may be able to select a complete backup of the entire site, which will include the database. You may be able to schedule regular backups too - similar in value to the restore point in a Windows operating system. Although you may lose recent changes if a disaster occurs at least you will be able to restore the site from the most recent backup.

In addition, may I recommend maintaining a copy of all the MediaWiki installation files, and perhaps separately a copy of LocalSettings.php, in folders identified by date. The value of this is that if you make a mistake while adding or updating an extension, altering a setting, or changing a skin, you will be able to find the previous version and get back to how it was - without actually restoring the site from a backup.

Performance Tuning

As a Systems Administrator you would be responsible for the performance of the website.

The motto - if it isn't broken, don't fix it - is sound advice. If you are satisfied with performance, don't change anything.

However, when you install MediaWiki some settings in LocalSettings.php are disabled by default - you have to specifically enable them or set a value. This includes items like caching which is covered in the Manual:Performance tuning.

Security and Upgrading

Securing your MediaWiki site includes preventing spam and vandalism. The topic of security is quite broad so a complete section has been allocated for it.

Similarly, upgrading MediaWiki, particularly in a hosted environment, is covered in a separate section.


The information or advice provided in this Guide is based on, or links to, official documentation for MediaWiki and was accurate when this article was created. However, some variation may occur between versions of MediaWiki; and the specifics of web hosting varies by service provider. Consequently, you should always create an effective backup before making any changes; ensure that you can restore your database and website; read the Release Notes before upgrading; and apply best practices to the management of your website. Any action that you take based on information provided here is at your own risk and the author accepts no liability for any loss or damage.