Working With MediaWiki

tag. If you don’t know how best to set all of these tags, it’s a good idea to look up their meaning, and how they should be best used for SEO.
    You can find more information about WikiSEO here:
https://www.mediawiki.org/wiki/Extension:WikiSEO
    If you’re using infobox-style templates on most pages, a good strategy is to place the tag within the templates, so that you don’t have to add it manually to each page; and then populate it with specific parameters from the infobox.

Running a wiki farm
    It’s not uncommon for organizations and corporations to want to run more than one wiki; sometimes many more. A company that runs public wikis on different topics, for advertising revenue or any other reason, may end up running a large number of them. Internally, companies may want to host more than one wiki as well. Access control to data is one reason, as noted here : the most secure way to keep a set of wiki data restricted to a defined group of users is to keep it in a separate wiki. And different departments within an organization could each want their own wiki, either to keep their data restricted or just because they have little need for sharing data with other groups. In a very large company or other organization, the number of such independent subdivisions that would want their own wiki could number even in the hundreds.
    Of course, each group that wanted their own wiki could simply set one up themselves; if they all use MediaWiki, installation is free and generally not too difficult. (That, in fact, is how wikis have historically been introduced into organizations: small groups setting them up themselves, in what’s known as "skunkworks" projects). But that kind of setup can quickly become unwieldy: if a different person needs to become a wiki expert for each wiki to be created and maintained, that’s too much work being expended. Even if all the wikis are managed centrally by a single IT person or department, that can become a tedious amount of work when it’s time to upgrade the software.
    In such a situation, what you should be using is what’s known as a “wiki farm”, or sometimes “wiki family”: a group of wikis that are managed from a single place, and to which it’s easy to add additional wikis. In MediaWiki, there are a variety of ways to create a wiki farm. The best reference for reading about the different approaches, and how to set up each one of them, is here:
https://www.mediawiki.org/wiki/Manual:Wiki_family
    There are many approaches listed on this page: single vs. multiple code bases, single vs. multiple databases, single vs. multiple instances of LocalSettings.php, etc. However, there’s only one approach we really recommend, which is to use a single code base, multiple databases and multiple settings files. This essentially corresponds to the “Drupal-style sites” approach described in that page.
    We won’t get into the full technical details here, but the basic idea is this: you have a separate database for each wiki, as well as a separate settings file. Each per-wiki settings file gets included from within LocalSettings.php. The individual settings files set the database name for each wiki, and let you customize the wiki’s settings, including standard features like the wiki name, logo, skin and permission; in addition to allowing for extensions that are only included for some wikis.
    The “Wiki family” manual includes a simple combination of a PHP and shell script for this approach, that together let you create and update the database for each wiki.
    You also need to decide on a URL structure for the different wikis: the two standard approaches are to use subdomains, like “wiki1.mycompany.com”, or subdirectories, like “mycompany.com/wiki1”. This structure has to be handled by a combination of LocalSettings.php (which has to figure out which settings file to use, based on the URL), and the server configuration, which, if Apache is being used, is usually the file httpd.conf. The specific settings for both are covered within the “Wiki family” manual.
    If you know ahead of time that you’ll have multiple wikis, it may be helpful to have shared user accounts across all of them, so that users don’t have to create a new account on every wiki that they want to edit. Wikipedia does this in a complex way, using the “CentralAuth” extension, but for other wikis, this can be done in a much simpler way, by just having the various databases share a single set of