Manual talk:Wiki in site root directory

Relocate directory after installation

What happens if you try to relocate the directory after install and config? e.g, I installed to webroot but want to move everything down one directory to webroot/wiki. Would I need to update any settings or links in the database? — Preceding unsigned comment added by 97.80.139.67 (talk • contribs)

No, you'd just have to change $wgArticlePath and possibly some other variables in LocalSettings.php --Catrope 12:38, 9 March 2009 (UTC)

one letter path

i get Error 403. 83.68.75.33 18:28, 11 April 2009 (UTC)

.wiki domains

I was happy to find a page dealing with this issue, and just wanted to note one more case where the trailing /wiki/ can be strange-looking and unfortunate — .wiki domains. I own one and was hoping to move my Mediawiki installation onto it, but the resulting article URLs (domain.wiki/wiki/foo, domain.wiki/wiki/bar, etc.) look really strange and stuttery. Huwmanbeing (talk) 20:14, 16 February 2017 (UTC)

Fear, Uncertainty, and Doubt

That is what most of this article spreads, much of it completely inaccurate. What should be abundantly clear is that Wikipedia should retrofit it's own url structure to be more user friendly. Imagine how many bytes of data could be saved in a year, if they simply got rid of /wiki from all of their pages! It is obvious that the original design was based on wikis being only one part of a site, and so assuming a subdirectory made sense in the url path. However, this has become hardened into fear, uncertainty and doubt into all systems that don't install MediaWiki in a /w subdirectory. What a crying shame. The reality is, most, if not all, things work, and whatever is broken can be fixed. We are talking about the a webserver (Apache or other) which can control routes to the MediaWiki files. --Jeffmcneill (talk) 05:53, 26 April 2017 (UTC)

I agree that effort should go into making root installation better supported. The advent of the top-level .wiki domain makes it even clearer how strange the current limitations are: anyone setting up such a site would no doubt prefer the scheme foo.wiki/Article, but will nevertheless be pointed toward using the oddly redundant foo.wiki/wiki/Article. Huwmanbeing (talk) 16:58, 23 August 2017 (UTC)

Completely agree. I've run a wiki for 15 years with a example.com/pagename structure without any problems at all. Jonathan3 (talk) 23:36, 20 May 2021 (UTC)

Lucky you. I cannot confirm this from my experience. Anyhow, yeah this will be very nice indeed. [[kgh]] (talk) 09:08, 21 May 2021 (UTC)

I just took the plunge. Day 0. No problems so far. Kudos shorturls.redwerks.org — it worked for me. — tbc (talk) 20:46, 6 March 2024 (UTC)

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

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 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: http://foo.wiki/wiki/Bar The advent of the .wiki top-level domain makes the /wiki/ look even stranger. Huwmanbeing (talk) 20:30, 16 February 2017 (UTC)

Those aren't really issues. 1. Six additional characters won't make any difference for printing. 2. The same applies to downloading code, since all servers compress pages. Google already say long URLs don't affect rank. 3 and 4. Nobody types full URLs nowadays; people use search engines or type the domain name and then go to the internal search system. Ciencia Al Poder (talk) 23:24, 28 December 2021 (UTC)

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:
  • http://wiki.example.com/favicon.ico
  • http://cookbookwiki.com/robots.txt

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 can't tell by whom or when the above bullet points were written, but good .htaccess short URL rules don't have an effect on existing files and directories. I've amended the manual page to make this clear. Jonathan3 (talk) 11:08, 5 December 2022 (UTC)

• Add following two lines to the MediaWiki:Titleblacklist to prevent Users creating page which redirect to other domains.

\/.*
WikiAction*

• The above looks good. I've tried it and it works with just the first line. I don't know what the second line would do. I'll add it to the manual page. Thanks. Jonathan3 (talk) 11:18, 5 December 2022 (UTC)

• I've installed MediaWiki in the document root directory of my dedicated web host. It feels silly and tautological to use wiki.example.com/wiki/ as the replacement for my former wiki.example.com/index.php/ (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 wiki.example.com/w/ — 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.

Removal of inaccurate text

I have removed:

as it may lead to conflicts with other files and directories. For example, if you have your images in the /images/ directory, you wouldn't be able to access a page named "Images" in your wiki, and since you probably want to control how search engines index your site with the use of a robots.txt file, you can't create a wiki article named "Robots.txt".

I use the example.com/pagename format, and example.com/Robots.txt would show a wiki page (example.com/robots.txt shows the actual robots.txt file), and example.com/Images would show a wiki page (example.com/images would redirect to example.com/images/). Jonathan3 (talk) 23:42, 20 May 2021 (UTC)

@Jonathan3: Good idea. I've also never run into any of these problems in a long time of running wikis with pages at the root level. :-) —Sam Wilson 01:15, 21 May 2021 (UTC)

Cheers. I've heard two sensible reasons for advising against the example.com/pagename approach. One is that it's slightly harder so would lead to more support queries. The other is that it's easier on the server to send a 404 than create a wiki "There is currently no text in this page" page. I've not had any problems with that even when on a slow shared server... unless that's why it was slow :-) Jonathan3 (talk) 08:23, 21 May 2021 (UTC)

Removal of links to guidance pages

I removed three links that appear on Manual:Short URL under the warning "These guides are old and are almost entirely bad advice. These will eventually be deleted one by one as our official guides above are created for different webservers." Two of the pages describe themselves as "bad advice" and the other says it has been "tested with MediaWiki 1.21 through 1.27". I replaced them all with a link to Manual:Short URL. Jonathan3 (talk) 09:22, 16 September 2021 (UTC)

Expanding on the "need for special rules"

I edited this part. It previously just said "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." I added "might" and also that you might not need special rules, and gave an example of Apache .htaccess code that appears to me to mean that you won't. Jonathan3 (talk) 09:35, 16 September 2021 (UTC)

Reorganisation of manual page

I have reorganised the manual page, trying to summarise and synthesise what was on the manual page and also what is on this talk page. By going through the talk page in detail I found at least one useful nugget of information hidden away. The manual page now contains a table, with potential problems in the left column and associated potential solutions in the right column. I hope that the new format is more useful for people. Jonathan3 (talk) 16:10, 5 December 2022 (UTC)