Manual:Wiki in site root directory

Jump to navigation Jump to search

Why, or why not, to use the root directory of a Web site as the wiki directory.

Template:Wiki-in-docroot links here and is used in Manual:Short URL. Details needed below.

Reasons why putting wiki pages in the root directory of the web site is bad[edit]

  • You need special rules for "robots.txt" or "favicon.ico", also for all wiki support files like skin images, extensions that load content from the "/extensions/" folder (such as CSS, JS, or images), and root scripts like api.php, thumb.php, and image_auth.php. See [1]
  • Periodically bugs pop up with various configurations and root URLs because MediaWiki was not designed for them. Even in the latest versions after we've thought all the root URL bugs were ironed out we find new bugs in core. These are being tracked in task T34620; currently these are the outstanding issues:
  • Any scheme which does this is not supported by the MediaWiki developers. So if your scheme doesn't work with a new MediaWiki version, you're on your own.

Use the configuration used by Wikipedia if you want to be on the safe side.

TODO: Add mailing list references and expand the above

MediaWiki on dedicated servers with wiki-specific domain (or subdomain) names[edit]


I like these two examples for sites that are predominantly wiki. If wiki is to be the dominant paradigm of a site, then no special wiki directory is needed and to use one is redundant and counter intuitive.

Why should above be deprecated? Please be specific, of course.

Frankly, I'd agree. There should be better guides to getting this to work - I've tried everything on this site, including the Mediawiki type one (which I wouldn't prefer, but would be better than the huge and ugly URL I'm getting at the moment - /mediawiki/index.php/Main_Page is a huge waste of space when I only need /Main_Page for my site.
I strongly agree as well. This is really irritating -- we want to put the site's main wiki on a separate machine, and is silly versus
I too strongly agree. is stupid, as is and w:en:Bar_Baz. I also think it would be nice to be able to make all pages - editing, discussion, etc use pretty permalinks... Why mix pretty and ugly ones? Surely all the same is best? Caesarsgrunt
I also want my wiki location at http://domain.tld/ and not http://domain.tld/wiki/ The additional folder is not necessary. By the way, what did you write? "Short URLs which hide complex programming code from the page address are good for webpage visitors"
Disadvantages: 1. The additional /wiki/ folder can be to long for beeing printed in offline media because it does not fit in one line. 2. The additional /wiki/ adds more code to the source code which makes my page load longer and rank worse on search enginges. 3. The additional /wiki/ folder is more difficult to spell on the phone. 4. The additional /wiki/ folder steals time because everyone needs to type more characters.
FYI another useful example URL: The advent of the .wiki top-level domain makes the /wiki/ look even stranger. Huwmanbeing (talk) 20:30, 16 February 2017 (UTC)


  • Why running a MediaWiki installation is troublesome if the article's name instantly follows the domain name after the slash in the URL?
  • The above is troublesome because some automated agents (web crawlers) and some user agents (web browsers) would inevitably request some files from your root directory that are not articles. Have a pair of good examples:
It would not be good to reply as if they were requesting articles.
  • If you are running Mediawiki in the root, then you are really running Mediawiki for the whole site. So these two examples really should be wiki pages, or redirects. Is there a way to set up an article to be something other than an HTML page that includes navigation, etc.? If not, then we just have to configure our web server to respond to those specific examples. The whole point of "Cool URLs Don't Change" is that mapping requests to "files" is the whole point of the web server. The fact that these two conventions mirror typical names for "files" is an unfortunate historical accident.
  • I've installed MediaWiki in the document root directory of my dedicated web host. It feels silly and tautological to use as the replacement for my former (and it also does not provide much shortening). What should I do?
  • You should choose and use some much shorter name for your virtual directory — such as — but consider the following restrictions:
    • You may not use such a name if you have already used w/ subdirectory to store MediaWiki engine there physically (e.g. if you did exactly as Manual:Short URL recommends): the name of your virtual directory must not conflict with a name of any physical, real directory. In such a case, choose another one-letter word.
    • If you are running a dedicated wiki server, then you probably have installed the MediaWiki engine directly in the document root (and not in a subdirectory), and thus you are free to use w/ but you must not use t/ (it's a real name of a MediaWiki's subdirectory).
  • When you have chosen your letter, take the following steps:
1) Edit or create the file robots.txt in your site's root; the file should contain the following lines:
User-agent: *
Disallow: /engine/
Disallow: /w/Special:Search
Disallow: /w/Special:Random
where /engine/ is your real MediaWiki directory (skip this “Disallow” line if you have installed MediaWiki in the document root of your site), and /w/ is your virtual short path.
2) Find the following lines in your LocalSettings.php:
## The URL base path to the directory containing the wiki;
## defaults for all runtime URL paths are based off of this.
$wgScriptPath       = "";
$wgScriptExtension  = ".php";
(your actual $wgScriptPath may be non-empty, if your MediaWiki installation does not reside directly in the document root of your site). Add two more lines to it:
$wgArticlePath = '/w/$1';
$wgUsePathInfo = true;
3) Make your webserver understand the /w/ path. For example, if you have Apache installed, add a line to your httpd.conf file:
Alias /w /full/path/to/your/wiki/index.php
The path should be real, starting from your file system's root, not the server's “document root”. (In Windows, such a path would be something like “c:/folder/of/website/index.php”, starting from the drive letter.)
4) Having altered httpd.conf, you should make the server reread it. You may restart Apache, or run apachectl graceful (or a similar command) as root, or use features of cPanel or similar software.