Manual:Short URL/Apache



These instructions help setup Short URLs on 1>Special:MyLanguage/Apache configuration|Apache. The LiteSpeed webserver is Apache compatible and can be configured in relatively the same way. For information on what Short URLs are or to get instructions on configuration for other servers see . If you don't know what webserver you're using since you're using some sort of web hosting service, it's very likely that your host is using Apache.

Plan
Before starting, you need to decide on the name of your virtual "short url" path.

In this manual we'll recommend/assume the following. Remember to use your own paths if they are different.


 * The MediaWiki directory is located at:  
 * The desired short url format is:  

These following instructions have been included in an automated wizard (requires MediaWiki 1.17 or later):


 * http://shorturls.redwerks.org/

If you just want your wiki configured quickly or you find the guide confusing then you may want to try that tool first. Please note, however, that it will not work on firewalled or private wikis. In the latter case, you can still try it out by making your wiki temporarily public by setting   to  . Remember to change it back to   once you are done.

Otherwise, follow along.

Find the right file
The recommended way to set up short URLs in Apache is by editing the Apache config files. This requires that you have access to the server configuration. If you are on a shared host, you most likely don't and will need to use a   file instead. Using  </> files is less efficient and doesn't give you as much control when it comes to fancy setups with multiple domains but they are powerful enough to set up most short url configurations. LiteSpeed users should use the <tvar|hta3> </> method.

Use the instructions in one of the following two sections, depending on whether you have root access or need to use <tvar|hta> </> instead.

Find the Apache configuration file (root access)
The correct configuration file to edit for root configurations may be in one of a number of places.

Most linux distributions setup Apache with set of <tvar|code1> </> and <tvar|code2> </> folders setup. The correct config file to edit is the one in <tvar|code3> </> where the configuration for your wiki has been setup. If you haven't set one up and are using the default <tvar|code4> </> for your wiki setup then you can edit <tvar|code5> </>.

Don't forget to enable overrides by <tvar|code> </>. It is disabled by default in Ubuntu 12.04 and Ubuntu 12.10.

If your distribution does not have those directories, then you should edit the Apache configuration file directly. This file should be at <tvar|code1> </>. Note that it used to be named <tvar|httpd1> </>, if you have a <tvar|httpd2> </> and no <tvar|apache> </> then <tvar|httpd3> </> is the one you want to edit.

If your Apache config isn't in any of these spots you should consult the documentation for whatever system you used to install Apache, and find the location of the Apache configuration file.

If you're on a shared host without access to Apache config files you'll have to use a .htaccess file instead.

In an Apache config file you will likely have a VirtualHost block containing your wiki. If you do have one then that is the location where your rewrite rules will go. RewriteRule config does not inherit so don't put these config options in the global config if you are using a VirtualHost.

After you've setup the config as below inside Apache you're going to need to restart Apache to make it apply the new config.


 * If you are using Plesk or cPanel it should have a method of restarting the server.
 * From the command line the command is usually something like <tvar|code1> </>, <tvar|code2> </>, <tvar|code3> </> or as on the latest Fedora releases <tvar|code4> </>. These commands need to be run as root, usually by prefixing them with <tvar|sudo> </>.

Where to put <tvar|hta>.htaccess</>
On Apache the <tvar|code1> </> controls whether .htaccess files are allowed to control server configuration. If these rewrite rules do nothing at all you may have to modify the <tvar|code2> </> setting in the Apache config to include <tvar|code3> </>. It also requires <tvar|code4> </> for the directory.

If you're using a <tvar|htaccess> </> file you'll need to edit or create the file. Find the path that contains both your script path and your virtual path. Usually this means the top directory of your site, but let's look at a few examples:

Note that if you want to make a redirect from the main domain to your wiki's Main Page (e.g. <tvar|code> http://example.org/ http://example.org/wiki/Main_Page </>). Then you always have to set up the .htaccess file in the top level, even if the other directories are nested deeper.

Setting up the rewrite rules
It's easier to understand the rest of this section after a glimpse at the Apache syntax, but this synopsis is not a substitute for the full Apache documentation:

The <tvar|RewriteCond> </> directive defines a condition that must be true before a RewriteRule that follows it may be applied. One or more RewriteCond directives may precede a RewriteRule directive, and all the RewriteCond directives that precede a RewriteRule must be true before that rule may be applied to a URI. In the examples that follow, <tvar|TestString> </> takes the form of a reference to server variables, e.g. <tvar|code1> </>. Although many <tvar|CondPatterns> </> exist, the examples that follow use <tvar|f> </> (true when TestString is a regular file) and <tvar|d> </> (true when TestString is a directory), and they are preceded by a negation symbol, <tvar|!> </>.

The <tvar|RewriteRule> </> directive may be invoked in both the <tvar|httpd> </> file and in any <tvar|hta1> </> file, but when the rewrite rule appears in .htaccess files, the implicit per-directory context affects the rule's  because rules are relative to the current directory. In <tvar|hta2> </> files, Patterns are not relative to the complete, original URI. For <tvar|hta3> </> files, Patterns should never start with a forward slash, <tvar|slash1> </>, because the URI sub-string will never begin with a <tvar|slash2> </>. The examples that follow use the <tvar|l> </> flag whose meaning is Stop the rewriting process immediately, and don't apply any more rules.

The <tvar|mod> </> module must be enabled in Apache or LiteSpeed servers for the examples that follow.

If you are using VirtualHosts, be sure that settings are placed inside the VirtualHost declaration

The first rule you'll need inside of your config is one to enable the rewrite engine:

Now we need a rule to make your article path a virtual path pointing to index.php. Be sure to replace <tvar|wiki> </> and <tvar|index> </> with the paths you plan>#Plan</>|choose in the beginning (if different).

If you decide to customize this, be sure to never include <tvar|code> </> or something like it in the rewrite. Including a query will cause MediaWiki's built in handling to be overridden and will create bugs on your wiki due to the fact that Apache's query rewrites are broken. The goal here is to alias paths to /index.php and then let MediaWiki itself take care of parsing and routing the url, based on the configuration in <tvar|ls>LocalSettings.php</>.

If you are using a root url instead of a normal short url you will need to use the following instead (to ensure that existing files and directories are not seen as article, e.g. "<tvar|index> </>" "<tvar|images> </>" etc.):

If you are using a script path and article path that match such as <tvar|myw-index> </> and <tvar|article1> </> you will also need to use the same two RewriteCond lines on your RewriteRule. However please note that there is no real valid reason to configure your wiki this way. If your article path is already a subdirectory you should just move your wiki's script path to another directory. Such as <tvar|w-index> </> and <tvar|article2> </> or <tvar|my-index> </> and <tvar|artticle3> </>.

Sometimes, the above example doesn't work. The following (you can't set this in a <tvar|hta> </>, you need root access for this!) might work instead:

Optionally, you can include a rule to show the Main Page on the path itself, to simplify navigation when people visit urls without a page title specified:

The end result should look something like this:

or, if you used the way with the "Alias" statement:

Make sure that the order of rules as given in the example is being preserved, i.e. "Short url for wiki pages" must be checked prior to "Redirect / to Main Page".

The <tvar|code1> </> in the config is important because different Apache setups use different regexps. Some want you to use <tvar|code2> </> and some want you to use <tvar|code3> </>. The <tvar|code4> </> in <tvar|code5> </> allows this rule to work in both contexts.

The <tvar|code1> </> in the config ensures that Apache has the correct non-ambiguous path. However it does not work on some badly configured free hosts. If you have 404 or 403 issues with your RewriteRules, remove the <tvar|code2> </> parts and try again.

If your SCRIPT_PATH leads to some other physical location (known as "symlink" in Unix, "shortcut" on Windows, "alias" in Mac OS X), you may need to allow Apache to follow those. You can do so by adding this line above the <tvar|RewriteEngine> </>:

If the path to your script directory is aliased by the webserver via an Alias directive, as it is in Debian among others, the RewriteRule will work as long as you add the PT flag (ie: change <tvar|l> </> to <tvar|ptl> </>) to Pass Through the request to the next handler - mod_alias, which will correctly redirect the request, as per [<tvar|stackoverflow>http://stackoverflow.com/questions/334111/how-to-use-apache-mod-rewrite-and-alias-at-the-same-time</> Stack Overflow]

<tvar|ls>LocalSettings.php</>
We need to make the following configurations in <tvar|ls></>:

If you get an "Internal error" page saying "Redirect loop detected!" after you finish configuration you may be using something other than mod_php. If so you need to explicitly turn on short urls using the following line in your LocalSettings.php:

If there is still an "internal error" check the log files of your server. Maybe you have to turn on <tvar|code> </> module.