Manual:Wiki in site root directory

Why to, or not, 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
Use the configuration used by Wikipedia if you want to be on the safe side.
 * 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
 * Example of failure: http://docs.jquery.com/robots.txt 301 redirects to http://docs.jquery.com/Robots.txt as an article name. FAIL!
 * 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.

TODO: Add mailing list references and expand the above

Questions
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.
 * http://wiki.example.com/Article_name
 * http://cookbookwiki.com/Main_Page

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 wiki.example.com/wiki/ is silly versus wiki.example.com/


 * I too strongly agree. http://wiki.foo.com/wiki/Bar_Baz is stupid, as is http://barwiki.com/wiki/Bar_Baz and http://en.wikipedia.org/wiki/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

Answers

 * 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.
 * 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  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  but you must not use   (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  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  is your real MediaWiki directory (skip this “Disallow” line if you have installed MediaWiki in the document root of your site), and   is your virtual short path.


 * 2) Find the following lines in your :

$wgScriptPath      = ""; $wgScriptExtension = ".php";
 * 1) The URL base path to the directory containing the wiki;
 * 2) defaults for all runtime URL paths are based off of this.


 * (your actual  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  path. For example, if you have Apache installed, add a line to your   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, you should make the server reread it. You may restart Apache, or run   (or a similar command) as root, or use features of cPanel or similar software.