Help:Using a very short URL

From GRWiktionaryHelp

The page describes the steps needed to set up MediaWiki to use URLs in the shortest form possible, e.g.:

http://mywiki.site.tld/Article_name

These instructions are intended for Apache 2 only; it is very likely that problems will occur if you attempt to do this with Apache 1.3.

Due to problems in Apache's pattern matching, you either have to patch Apache or perform a kludge.

This page is current as of MediaWiki version 1.4.5.

Contents 1 Warnings and disclaimer 2 The ampersand problem 3 Modifications 3.1 Patching Apache 3.2 httpd.conf 3.3 MediaWiki 4 Kludge

Warnings and disclaimer

This configuration is totally unsupported by the Mediawiki development team. Therefore, future versions may have modifications that break this setup. Indeed, Mediawiki's current code must be modified in two places before it can work.

Also, it usurps your entire URL namespace for wiki pages. Serving up non-wiki content using the same hostname may be quite a hassle.

Do not follow these directions! The page area should ALWAYS be isolated in a subdirectory, leaving the root free.

The ampersand problem

A correct edit URL in this scheme would look like:

http://wiki.site.tld/Article_Name?action=edit

One of the many problems with this scheme is that you cannot separate edit pages and other dynamic content from the plain page views in robots.txt. This means you either must hide your entire site from search engines, or you will receive much more load from spiders than you would like.

After rewriting, we want the URL to look like this:

http://wiki.site.tld/index.php?title=Article_Name&action=edit

There is no need to patch Apache -- using [QSA] on the rewrite rule does this automatically.

Modifications

Patching Apache

A few Apache 2 packages are built with this patch already applied (e.g., Gentoo's). Otherwise:

Get the Apache 2 source. Download the patch. Apply, compile, install.

httpd.conf

In httpd.conf, you'll need to enable some RewriteRules for the wiki's website. Add the following in the appropriate place (e.g., in a VirtualHost):

RewriteEngine On

# Don't rewrite requests for files in MediaWiki subdirectories,
# MediaWiki PHP files, HTTP error documents, favicon.ico, or robots.txt
RewriteCond %{REQUEST_URI} !^/(stylesheets|skins|images|config)/
RewriteCond %{REQUEST_URI} !^/(index|redirect|texvc).php
RewriteCond %{REQUEST_URI} !^/error/(40(1|3|4)|500).html
RewriteCond %{REQUEST_URI} !^/(favicon.ico|robots.txt)

RewriteMap ampescape int:ampescape
RewriteRule ^/(.*)$ /index.php?title=${ampescape:$1} [L,QSA]

Note that the line that prevents rewriting requests for error documents may vary from site to site.

MediaWiki

Function getLocalURL in includes/Title.php needs to be modified as follows. As of 1.4.5 this was line 655:

-  $url = "{$wgScript}?title={$dbkey}&{$query}";
+  $url = "/{$dbkey}?{$query}";

As noted above, this will destroy the ability to separate dynamic requests from page views in robots.txt and will create useless extra traffic for your server. It is highly recommended that you do not do this.

Function view in includes/RawPage.php needs to be modified as follows. As of 1.4.5 this was line 59:

-  if( strcmp( $wgScript, $_SERVER['PHP_SELF'] ) ) {
+  if( 0 and strcmp( $wgScript, $_SERVER['PHP_SELF'] ) ) {

This disables protection against a cross-site scripting vulnerability for Internet Explorer clients. DO NOT DO THIS!

In LocalSettings.php, make sure these variables are set as follows:

$wgScript = "";
$wgScriptPath = "";
$wgArticlePath = "/$1";

Fin.

$wgScript should always be set to an actual URL path to the script. Making it empty may create invalid form actions and other URLs, and may break on some browsers.

Kludge

If you aren't going to use a patched Apache server, do the following:

• Apply the changes to MediaWiki as instructed in the previous section, except that the line in includes/Title.php has an ampersand instead of a question mark:

$url = "/{$dbkey}&{$query}";

• Apply the changes to httpd.conf as instructed above, except:
  • The RewriteMap line is omitted;
  • The final RewriteRule line is:

RewriteRule ^/(.*)$ /index.php?title=$1 [L]

This solution generates URLs that contain ampersands where the question marks should be. The RewriteRule will insert the question mark in the proper place.

In practice, it works fairly well. Smart URLs, such as those used in Firefox, will need to have an ampersand where the question mark would normally be. There may be other situations in which it could cause problems.

Don't do this either -- it will create a large number of broken links if you ever change back to a correct configuration. It's also completely unnecessary, as the problem it's meant to solve doesn't require patching Apache. Use the [QSA] option on the rewrite rule. (The ampescape patch is for a different issue, which as far as I can see this would not help with.)