Talk:Eliminating index.php from the url

MyTips!'s Working Setup

I have a site at http://www.mytips.info

I tweaked a little bit from the tutorial to get this work - i.e. http://www.mytips.info/html/Firefox

In httpd.conf:

   # close the php security hole...
   php_flag register_globals off
   # first, enable the processing - Unless your ISP has it enabled
   # already.  That might cause weird errors.
   RewriteEngine on
   # Rewrite /html to index.php and stop
   RewriteRule ^/html$ /w/index.php?title=Main_Page [L]
   # Rewrite /html?xxx as w/index.php?xxx and stop
   RewriteRule ^/html/(.*)$ /w/index.php/$1 [L]

In LocalSettings.php:

$wgScriptPath       = "/w";
$wgScript           = "$wgScriptPath/index.php";
$wgRedirectScript   = "$wgScriptPath/redirect.php";

## If using PHP as a CGI module, use the ugly URLs
$wgArticlePath      = "/html/$1";

What to do in 1.4 beta6

Is there an update to the rewrite code? This is how i installed my wiki:

http://wiki.mydomain.com and i setup the subdomain to redirect to the /wiki folder where the wiki is installed.

Can you please tell me the code to put in the .htaccess and localsettings.php files so this could work:

http://wiki.mydomain.com/Main_Page would show the main page, and http://wiki.mydomain.com/newarticle would create a new article? Basically it's exactly like wikipedia.org has setup, where they use en.wikipedia.org/article for example. If the mods could post how this is done it would be real cool. I don't have access to httpd.conf, just htaccess. Thanks. -- 16 Feb 2005 (UTC)

No, nothing's different in 1.4 that should affect rewrites. MediaWiki does not do any URL rewriting; URL rewriting is something done externally in the web server. There are various samples of config code for this in Rewrite rules. --brion 22:04, 21 Feb 2005 (UTC)

The trick for me in upgrading to 1.4 was to restore this line:

$wgArticlePath      = "/$1";

- Dan Kohn

Gwicke's reverts

Reverted most changes because:

• phtml files are deprecated, wiki.phtml for example includes index.php
• PATH_INFO and index.php avoids some problems with edit urls (they looked like /myarticle&action=edit...)
• The ? in the rewrite rules caused errors in one install, and it works fine without. Not sure about the reason though.
• $wgScriptPath = "/"; doesn't work, that produces ugly edit urls like /?title=myarticle&action=edit instead of /myarticle?action=edit

-- Gwicke 13:41, 26 Mar 2004 (UTC)

403 Forbidden error

---

Using the htaccess given I got a 403 Forbidden. After asking around in the channel, it was decided that Rewrites were not allowed globally on my server. Make sure if you have a similar problem to contact your system administrator.

---

What was the exact problem that gave you the 403 Forbidden ? I have just tried installing the wiki locally (124) and am getting that same error when I try to put in the modrewrite rules. Since this is my dedicated server I can probably make any required changes to the config. BTW I have been using modrewrite on other domains (on this server) with no problem. I am running Apache 2.0.40, PHP 434, MySQL 40.18 -- Paul Saturday, April 24, 2004 5:06 PM

Make sure that you include the RewriteEngine on directive and that mod_rewrite is enabled in your apache config file. --HappyDog 15:37, 21 May 2004 (UTC)

HappyDog's solution

I had a lot of trouble getting the rules to work. Here is what I eventually came up with (for anyone else with a similar problem:

# Rewrite requests which have GET args only (e.g. from edit page links)
RewriteRule ^wiki/$ /wiki/index.php [L]

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

# Rewrite http://wiki.domain.tld/article properly, this is the main rule
RewriteRule ^wiki/(.*) /wiki/index.php?title=$1 [L]

This is modified from the example given on the page in the following ways:

1. Backward compatability code removed
2. Wiki is located in /wiki/ sub-dir, not root so have modified URLs accordingly. Note that in the conditions and on the left side of the rules the initial / is needed, but that it should be omitted on the left-hand-side of the rewrite rules.
3. Styles are stored in style directory, not stylesheet (default install)
4. index.php/$1 didn't work for me. I had to replace it with index.php?title=$1
5. This meant that any edit pages failed because it would be searching for index.php?title=?title=etc so I added the first rule which rewrites any calls to the wiki root directory to point to the index file. This works because any GET arguments supplied to the URL are removed before the rewrite, so for wiki/?title=etc REQUEST_URI=wiki/ (the arguments are added back after the rewrites).

Hope that saves other people a few headaches. --HappyDog 15:31, 21 May 2004 (UTC)

Actually - I've just found out that this isn't saving any edits. I'm going to try and figure out why, but in the meantime if anyone has any suggestions then I'd like to hear them. --HappyDog 16:36, 21 May 2004 (UTC)

Fixed it. The problem was that in the submit form the trailing slash after the directory is omitted. This is fixed by changing the left hand side of the first rewrite rule from

^wiki/$

to

^wiki/?$

which indicates that the trailing slash is optional. --HappyDog 16:45, 21 May 2004 (UTC)

OK - I've just found a setting error that solves most of the above headaches. I changed $wgScript=$wgScriptPath to $wgScript=$wgScriptPath."/index.php" in my LocalSettings.php and now any edit and save URLs are constructed properly and we don't need to user mod_rewrite to fix it (plus the URL string looks nicer now too!). I also moved the .htaccess file from the root of my server to the /wiki/ sub-directory. Note that the left hand side of the rewrite rule is relative to the directory containing .htaccess, but the right hand side is relative to your web root, so bear that in mind if you decide to move the file! For reference, here is my current .htaccess file:

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} !^/wiki/style/
RewriteCond %{REQUEST_URI} !^/wiki/(redirect|texvc|index).php
RewriteCond %{REQUEST_URI} !^/wiki/error/(40(1|3|4)|500).html
RewriteCond %{REQUEST_URI} !^/wiki/favicon.ico
RewriteCond %{REQUEST_URI} !^/wiki/robots.txt

# Rewrite http://wiki.domain.tld/article properly, this is the main rule
RewriteRule ^(.*) /wiki/index.php?title=$1 [L]

Hope that helps! --HappyDog 17:25, 21 May 2004 (UTC)

Don't forget the [L,QSA] at the end of your rule, otherwise the Search engine and all the pages working with parameter won't work: RewriteRule ^(.*) /wiki/index.php?title=$1 [L,QSA] --FxParlant

AdrianB's solution

Non of the suggestions here worked for me. My goal was to make MediaWiki work in a sub directory with the rewriting rules. After way too much time spent on trying I finally got it working. This is how...

(My directory where the MediaWiki is installed is /mediawiki/ and so I wanted my URL to be http://my.domain/mediawiki/. I'm using MediaWiki 1.2.6. The .htaccess file is in this directory too.)

In the LocalSettings.php I changed:

$wgScript           = "$wgScriptPath/index.php";

to:

$wgScript           = "$wgScriptPath/";

And:

$wgArticlePath      = "$wgScript/$1";

To:

$wgArticlePath      = "$wgScript$1";

This is how my .htaccess looks like:

# Allow wiki articles to start with a period
<Files .*>
  Order Deny,Allow
  Allow From All
</Files>

# Allow rewriting URLs
RewriteEngine on

# The subdirectory where the files and .htaccess file is. /Adrian 
RewriteBase /mediawiki

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

# These are not needed when in a subdirectory, or? /Adrian
# RewriteCond %{REQUEST_URI} !^/error/(40(1|3|4)|500).html
# RewriteCond %{REQUEST_URI} !^/favicon.ico
# RewriteCond %{REQUEST_URI} !^/robots.txt

# Make sure there is no query string. /Adrian
RewriteCond %{QUERY_STRING} ^$

# Rewrite http://wiki.domain.tld/article properly, this is the main rule
RewriteRule ^(.*)$ /mediawiki/index.php/$1 [L]

Making sure that I only rewrite when there's no query string was what I had to do to get the edit and other query string pages working. Maybe there's some other smarter way than this, but this is my first installation of MediaWiki and it does work.

--AdrianB

Skippy: AdrianB's rules worked perfectly for me, also using the domain.tld/wiki/ structure. Thanks!

Skippy: Update: Adrian's rules work for these URIs:

http://www.domain.tld/wiki/

http://www.domain.tld/wiki/Some_Page

but they do not work for this URI:

http://www.domain.tld/wiki

Note the lack of a trailing slash. MediaWiki presents a blank page with a title like

/path/to/wiki

All my efforts to edit .htaccess yield 500 Server Configuration errors.

I am facing the same problem, Skippy. My .htaccess (listed below) does not allow me to use Search feature as well. I am using MediaWiki at /wiki directory under my domain.

RewriteEngine on
RewriteRule ^wiki/?$ /wiki/index.php [L]

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

# Make sure there is no query string. /Adrian
RewriteCond %{QUERY_STRING} ^$

# Rewrite http://wiki.domain.tld/article properly, this is the main rule
RewriteRule ^(.*) /wiki/index.php/$1 [L]

Maybe I should put another RewriteCond specificaly for Special:Search page. I'll try it and report success (if I get some) :) I would appreciate any feedbacks concerning www.domain.tld/wiki (without trailling slash) as well.

AlissonSellaro

brainsik's solution (no mod_rewrite)

Note: The following solution was created for MediaWiki v1.4 but will probably work for v1.3.

In your LocalSettings.php:

$wgScriptPath       = "/static";
$wgScript           = "/index.php";
$wgRedirectScript   = "/redirect.php";
$wgArticlePath      = "/$1";

In your Apache config (.htaccess or whatever):

Alias       /index.php                   /var/www/brainsik/mediawiki/index.php
Alias       /config/                     /var/www/brainsik/mediawiki/config/
Alias       /static/                     /var/www/brainsik/mediawiki/
AliasMatch  ^/(robots.txt|favicon.ico)$  /var/www/brainsik/mediawiki/$1
Alias       /                            /var/www/brainsik/mediawiki/index.php/

What's going on?

First off, if you look at LocalSettings.php you'll notice that $wgScriptPath is prepended to all the static content (images, skins, etc). Might as well rename this variable to a fake directory called "/static". This let's us easily match this type of content and has the added bonus that we do not need to specifically match against all the different names static content might be under (which means this will probably continue to work even if new directories are added in the future).

Since we modified $wgScriptPath we have to manually modify $wgArticlePath to be clean.

The hard to understand part is defining $wgScript to be "/index.php" and having our first Alias match this. What's up?? When I first setup my rules I was having the same slow page loading problems as everyone else. It was due to the browser being given URLs like http://yoursite/?title=-&action=raw&gen=js. Those were ending up in a redirect loop and the browser wouldn't show the page content until it had failed out on them. These links aren't actually critical to viewing the page, so most people probably aren't noticing. If you take a look at wikipedia you'll notice they have those kinds of links prepended with '/w/'. Aha! Why not prepend our links, and hey, why not just give them want they want? So, setting $wgScript to "/index.php" creates URLs like http://yoursite/index.php?title=-&action=raw&gen=js which we match for in our first Alias rule and gives the added bonus that we are backwards compatible with old link style. Yay!

-- brainsik

Rewrite in /wiki subdir with Search working

Fellows

I think I solved the search problem. My .htaccess file looks like this one:

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} !^/wiki/stylesheets/
RewriteCond %{REQUEST_URI} !^/wiki/(redirect|texvc|index).php
RewriteCond %{REQUEST_URI} !^/wiki/error/(40(1|3|4)|500).html
RewriteCond %{REQUEST_URI} !^/wiki/favicon.ico
RewriteCond %{REQUEST_URI} !^/wiki/robots.txt

# Make sure there is no query string (Unless user is making a search)
RewriteCond %{QUERY_STRING} ^$ [OR] %{REQUEST_URI} ^/wiki/Special:Search

# Rewrite http://wiki.domain.tld/article properly, this is the main rule
RewriteRule ^(.*) /wiki/index.php/$1 [L]

Note that my wiki is located under a /wiki directory in the server. I still couldn't get the www.wikiserver.tld/wiki (without trailling slash) to work, but I'm working on it.

AlissonSellaro

Putting All Toghether

Enemy down, folks :) Search, pretty URLs and no trailling slash needed anymore. My .htaccess follows:

RewriteEngine on

# Verifying if user forgot to put trailling slash. If so, we'll rewrite to Main_Page
RewriteCond %{REQUEST_URI} ^/wiki$
RewriteRule ^(.*) /wiki/index.php?tile=Main_Page [L]

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

# Make sure there is no query string (Unless user is making a search)
RewriteCond %{QUERY_STRING} ^$ [OR] RewriteCond %{REQUEST_URI} ^/wiki/Special:Search

# Rewrite http://wiki.domain.tld/article properly, this is the main rule
RewriteRule ^(.*) /wiki/index.php/$1 [L]

At LocalConfig.php, changed settings were:

$wgScript = "$wgScriptPath/";
$wgRedirectScript   = "redirect.php";
$wgArticlePath      = "$wgScript$1";

Hope it helps somebody else. AlissonSellaro

Alisson, it did. It helped me. :) However, it took me a minute to realize that I needed to move my .htaccess to my wiki directory. - moonlight_embrace

After a few minutes I realized something was wrong. It keeps the wiki part of the URL and will not let me edit any page except the main page. See The Complexity Here

How to change base URL?

How can I change the Base URL? (i.e. The domain my wiki is hosted on is not the same as the URL I wish to use, so all liks at www.myhost.com/... should be forwarded to www.mydomain.com/...)

Luhmann

To redirect an entire domain to somewhere else, do something like this:

<VirtualHost *>
ServerName www.myhost.com
RewriteEngine On
RewriteRule ^(.*)$ http://www.mydomain.com$1 [R=301]
</VirtualHost>

For a more elaborate example, you could look at our own configuration files. I've put up symlinks, you can find links at Apache config. There are some inter-domain redirects in redirects.conf. -- Tim Starling 02:17, 27 Jul 2004 (UTC)

Thanks, unfortunately, this doesn't work for me. It gives me an error when I put this text (modified to suit my domain) in my .htaccess file. I can't do anything until I remove it. I tried changing mydomain.com$1 with mydomain.com/$1, but still no luck.

I'm having just as bad luck with the Rewrite_rules web page instructions. Are they up to date for the latest nightly build? I want to replace /index.php/page name with /page name instead.

I have to say, I much prefer PHP packages that don't reply on Apache rewrite rules, as I almost never get them to work 100% correctly on my server!!!

You can't put <VirtualHost> in a .htaccess file, it can only go in httpd.conf. Perhaps you'd have more luck with a redirect script written in PHP. But that's got nothing to do with replacing /index.php/page with /page. Note that if rewrite rules inside .htaccess are ignored, it may mean that you don't have "AllowOverride FileInfo". -- Tim Starling 01:04, 28 Jul 2004 (UTC)

skippy: Thanks, AlissonSellaro, your modified rewrite rules work perfectly.

skippy: CORRECTION: Special:Recentchanges is broken with AlissonSellaro's rewrite rules! No changes are listed, and clicking any of the links to modify the Recent Changes display dumps me back to the Main Page. Any further suggestions are appreciated.

Local Settings

Skippy, you don't want your local settings set as Alisson describes above, at least not if you are using beta5 like me. You want them exactly as they appear on the Rewrite Rules page. At least, this is what worked for me in the end. I've spent a whole day on this!

Luhmann 22:43, 30 Jul 2004 (UTC)

• Login link doesn't work using this method

Site URLs

I still have the issue of the base URL which I would like to change. Here is the problem.

The hints I've been getting here on the e-mail list don't seem to address the real problem. You see, the url:

http://mydomain.net/Main_Page

works! This is already done through my URL forwarding from EasyDNS.org. What I want is for all the wiki URLs *within* MediaWiki to use

http://mydomain.net/

instead of the server actually hosting the site:

http://myhost.net/

This should be fixed in LocalSettings.php, right? I see that older versions of LocalSettings.php had a line:

$wgServer = "http://mydomain.net";

But adding this to my beta5 installation didn't do anything. Is there any way to get MediaWiki to us this as the base URL?

Luhmann 23:07, 30 Jul 2004 (UTC)

Correction: MediaWiki seems to not specify the base URL at all, in most links, so this doesn't seem to be the problem. The problem is that somehow things are getting rewritten the first time the page loads, so that the host URL appears instead of the forwarded URL.

Luhmann 14:45, 31 Jul 2004 (UTC)

It seems that the biggest problem was that MediaWiki uses an anti-framejacker defense shield, and domain forwarding often employs frames (EasyDNS does this). To turn it off, open the file stylesheets/wikibits.js and remove the following lines:

// Un-trap us from framesets
if( window.top != window ) window.top.location = window.location;

However, this is only half the problem. In order to work with the frame, the URLs must use the full path, with the domain name rather than the host name. I have not been able to figure out how to do this. One suggestion was to insert a "base" tag into the templates/xhtml_slim.pt file. Like this:

<base target="_top" href="http://mydomain.com/" />

However, while this works OK most of the time, it makes it impossible to save edits when editing a page. That's a real problem. Any suggestions would be greatly appreciated! There must be some way to do this without base tags, or to modify something in the script to work with such base tags when saving pages.

Luhmann 01:24, 3 Aug 2004 (UTC)

Try to set $wgServer = "" It was the solution to my problem (forwarding requests from a gateway to another server, using NAT).

robert

Also need RewriteEngine On

When cutting/pasting the example config make sure you also have

RewriteEngine On

in your httpd.conf

You can do it in a .htaccess if you use them, but then AllowOverride must be set to all in the global config file (maybe not that much, but it shouldn't be set to none).

Httpd.conf and other Unintelligibles to a Novice

Hello,

I'm most grateful for the presence of help here on prettifying the wiki URL's (not to mention the software itself!), but being as I am a novice to the server administration side of things, can someone tell me:

1. where can I find the httpd.conf file (I don't have full root access)?
2. What is a Virtual Host Container, what should it look like, and where should it be added within the httpd.conf file?
3. Are the sections "1.2.2 important ones" and "1.2.3 the key rule" necessary only for backwards compatibility or are they instructions for everyone?
   1. If the latter, where do these changes go?
4. Are all of the instructions at this page (or that you are answering now) valid for MediaWiki 1.3.1 ?
5. And while I'm asking, does anyone know why my installation (though it is the most recent apparently) doesn't come with the nice little editing help toolbar above the edit windows?

Thanks, Brettz9 07:16, 22 Aug 2004 (UTC)

None of this is valid on 1.3.3

Can anyone provide the .htaccess for a clean (not wiki or anything else, but http://www.domain.com/Main_Page) wiki installation? I have:

# Allow rewriting URLs
RewriteEngine on

# The subdirectory where the files and .htaccess file is. /Adrian
RewriteBase /

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

# These are not needed when in a subdirectory, or? /Adrian
# RewriteCond %{REQUEST_URI} !^/error/(40(1|3|4)|500).html
# RewriteCond %{REQUEST_URI} !^/favicon.ico
# RewriteCond %{REQUEST_URI} !^/robots.txt

# Make sure there is no query string. /Adrian
RewriteCond %{QUERY_STRING} ^$

# Rewrite http://wiki.domain.tld/article properly, this is the main rule
RewriteRule ^(.*)$ /index.php/$1 [L]

And the following LocalSettings.php file:

$wgSitename         = "Shurl";

$wgScriptPath       = "";
# $wgScript           = "$wgScriptPath/index.php";
$wgScript           = "$wgScriptPath";
$wgRedirectScript   = "$wgScriptPath/redirect.php";

## If using PHP as a CGI module, use the ugly URLs
$wgArticlePath      = "$wgScript/$1";
# $wgArticlePath      = "$wgScript?title=$1";

$wgStylePath        = "$wgScriptPath/stylesheets";
$wgStyleDirectory   = "$IP/stylesheets";
$wgLogo             = "$wgStylePath/images/wiki.png";

$wgUploadPath       = "$wgScriptPath/images";
$wgUploadDirectory  = "$IP/images";

$wgEmergencyContact = "webmaster@shurl.us";
$wgPasswordSender       = "webmaster@shurl.us";

Which makes single pages work, but anything that requires ?something=something generates 404's. Example of such link is:

http://www.shurl.us/Special:Userlogin?returnto=Main_Page

But http://www.shurl.us/ works. How difficult is to come up with something that will create the .htaccess (or at least spit it on screen) at installation time, so this nightmare would end? -- David Collantes

Everything after the question mark is the query string. If you keep that RewriteCond in there (which makes sure there is no query string) it won't ever get to the next RewriteRule. Take that RewriteCond out and change the RewriteRule to this:

RewriteRule ^(.*)$ /index.php/$1 [L,QSA]

This should make sure that the query string is appended to the url, so that pages like the one you referenced are processed correctly. 70.112.130.236

this worked for me

RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_URI} !^/(stylesheets|images)/
RewriteCond %{REQUEST_URI} !^/(redirect|texvc|index).php
RewriteRule ^(.*)$ /index.php?title=$1 [L,QSA]

RewriteBase / crashed Apache 2.0.52 for me

$wgSitename         = "ShareKnowHow";

$wgScriptPath       = "";
$wgScript           = "$wgScriptPath";
$wgRedirectScript   = "$wgScriptPath/redirect.php";

## If using PHP as a CGI module, use the ugly URLs
$wgArticlePath      = "$wgScript/$1";

$wgStylePath        = "$wgScriptPath/stylesheets";
$wgStyleDirectory   = "$IP/stylesheets";
$wgLogo             = "$wgStylePath/images/wiki.png";

$wgUploadPath       = "$wgScriptPath/images";
$wgUploadDirectory  = "$IP/images";

http://www.blah.com/Special:Userlogin?returnto=Main_Page <- this works.

This works allright, but makes pageloading incredibly slow... Any suggestions?

Cor

I had the same problem with slow-loading pages (Internet Explorer even crashed when loading them), and my setup looks pretty much identical to yours. I don't know what else played into it, but the slow loading magically disappeared when I changed the RewriteRule to:

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

Moments later the slow loading was back though (with no intervention from yours truly)... The pages aren't actually that slow to load either (the HTML is still retrieved very fast), but for some reason my browser keeps loading something without displaying the page for up to 10-15 seconds. Very weird. --- Qhimm

Update: I tracked down the slow browser problem to some internal bug which seems to appear when trying to do URL rewrites on a top-level wiki (e.g. wiki.domain.tld/Main_page), at least on version 1.3.11. The bug is that some URLs in the produced page (namely those for script and style imports) consist of "-" instead of the now non-present "index.php", probably it passed through some function that that tags empty strings, like the Title class does with query strings. These requests are patched on into the RawPage handler, which requires that the current request matches the $wgScript variable, or it redirects the browser to the "proper" request. Problem is this redirection also ends up as the "-" URL, meaning this won't match RawPage's requirements either and so the browser gets stuck in a loop of continuous redirects for the same page. Anyway, I was too lazy to track down the actual problem (and I didn't want to mess around inside the source code anyway), so as a temporary fix I added an additional RewriteRule before the others:

RewriteRule ^-(.*)$ index.php/$1 [L,QSA]

This rule simply catches these bad URLs and rewrites them to straight index.php requests. I admit it's kind of a backwards way of solving things, but at least now my viewing speed is tolerable (it was already slow because of the .htaccess rewrites, but the major slowdown was the bad browser redirects). Hopefully someone figures out the real problem (or has already done so for a newer release). --Qhimm

That's not a bug, that's a workaround for a serious Internet Explorer security bug. You should always set $wgScript correctly to the real script path, never ever to something different. --brion 23:03, 1 Mar 2005 (UTC)

Which is the workaround, rewriting URLs as "-" or double-checking that requests match $wgScript? Anyway turns out I had caused this particular problem myself when trying to get more page links (like discussion, edit etc.) to display according to $wgArticlePath. My problems were because I hadn't read up on the bug fix in place for exactly this thing, so my code turned out utterly incompatible. Sorry for the confusion, my comments would seem to not apply to untouched MediaWiki installations. --Qhimm 02:11, 2 Mar 2005 (UTC)

The use of - for some of the special stylesheet pages is entirely normal. The check for the script's canonical URL is the workaround for the IE bug. $wgArticlePath is used for page views; everything else goes to the script and is not expected to look 'pretty'. --brion 02:27, 2 Mar 2005 (UTC)

Do all RawPage requests use a "-" title?

No, only a couple of special cases for style sheets and such.

I can see the logic of not "prettifying" the URLs just used by the script, but I think that optimally all links clickable by the user should be subject to $wgArticlePath, even those with extra query strings. For example, edit links should logically be http://wiki.domain.tld/Main_page?action=edit instead of http://wiki.domain.tld/index.php?title=Main_page&action=edit -- it makes the wiki look cleaner and more consistent, but I guess at a slight performance hit since more URLs would need rewriting in Apache.

Those are still ugly, and can't be referenced in a robots.txt. In 1.5, additional $wgActionPaths will be able to be set, eg http://example.com/edit/Some_Page

I added some code into Title.getLocalURL() to get more pretty URLs, but it relies on recognizing RawPage and similar "internal" requests by checking for ($dbkey == '-')... is this safe, or are there requests with titles that require index.php to be there too? --Qhimm 05:42, 2 Mar 2005 (UTC)

That is not safe as it will fail on all raw page requests for specific titles. --brion 08:19, 2 Mar 2005 (UTC)

Right, thanks for the input. It's good to know improvements are on their way, $wgActionPaths are looking just like what the doctor ordered. In the mean time, could my getLocalURL() manually check for the action directive inside the query and apply $wgArticlePath on "relevant" ones? Or should I just do the right thing and wait until proper code comes along? :) --Qhimm 02:24, 3 Mar 2005 (UTC)

If you don't mind doing a little live testing ;) here's the changes: [1] [2] It hasn't been extensively tested yet, and there will probably be additional internal changes later. --brion 04:51, 3 Mar 2005 (UTC)

Nigedo's Solution for Apache 1.3.33

My site's URL's are ALL: http://www.mysite.com/Article_name and everything works at the correct speed.

OK, I'm not going to go into every detail of how I got to this, because it took me two days of trying and I don't want to frustrate anyone further.

This solution works for me on Apache 1.3.33 with my Mediawiki installation in the root (public_html) directory, on a shared hosting server and it is actually very simple.

The most important thing was for me to take note of Brion's comment above, that you should NOT change the default value of $wgScript. Many people on this page have found half a solution, but their pages load very slowly, or even crash (especially in Internet Explorer), because they have changed this value . Brion explained why this happens above. Just read his comments since he is one of the Mediawiki architects. :)

Anyway, here's my version. --Nigedo 21:52, 3 Jul 2005 (UTC)

LocalSettings.php content

$wgScriptPath		= "";
$wgScript		= "$wgScriptPath/index.php";
$wgRedirectScript	= "$wgScriptPath/redirect.php";
$wgArticlePath		= "/$1";

# If using PHP as a CGI module, use the ugly URLs
#$wgArticlePath		= "$wgScript?title=$1";

.htaccess content

RewriteEngine on

#URL construction
RewriteCond %{REQUEST_URI} !^/(stylesheets|images|skins)/
RewriteCond %{REQUEST_URI} !^/(redirect|texvc|index).php
RewriteCond %{REQUEST_URI} !^/(40(1|3|4)|500).shtml
RewriteCond %{REQUEST_URI} !^/favicon.ico
RewriteCond %{REQUEST_URI} !^/robots.txt
RewriteRule ^(.*)$ /index.php?title=$1 [L,QSA]

You may need to change the above line that applies to error pages, from .shtml to .html, depending on your server's settings.

RewriteCond %{REQUEST_URI} !^/(40(1|3|4)|500).html

1.3.3 Navigation different under Mozilla and IE?

We're just starting up a new Wiki, so I'm trying not to add new pages until we get the basics right.

From the Main Page, I can mouse the cursor over side navigational links and see the link URLs at the bottom of the browser.

The Apache part seems to be working okay, because typing in http://mydomain.net/Main_Page or http://mydomain.net/Current_events works as well as http://mydomain.net/index.php/Main_Page and http://mydomain.net/index.php/Current_events .

Under Mozilla v1.6, on Main_Page, when I move the cursor over Current_events, the URL appears to be http://mydomain.net/index.php/Current_events.

Strangely enough, when I use Internet Explorer v5.5, the same URL appears to be http://mydomain.net/Current_events .

Is this something in Mozilla, where I need to clear out the cache, or something? I am reloading the page. Or is this a problem in MediaWiki v1.3.3?

divirtual, September 25, 2004

Shift+Reload seemed to clear this caching problem up for me --Justinsomnia 04:06, 9 Feb 2005 (UTC)

Tell me if this is a really Bad Idea(tm) (resolved)

I haven't been able to get any of the sections above to work. I may have some conflicting .htaccess files somewhere, I don't know. Here's what I'm trying now:

I want my urls to look like this: https://me.domain.tld/wiki/Main_Page

So what I did was:

1. Installed the wiki into the htdocs root and configured
2. Removed the *.phtml files
3. Renamed index.php to wiki.php
4. Used Multiviews to allow wiki to point to wiki.php
5. Edited LocalSettings.php and changed $wgScript to "$wgScriptPath/wiki"

This works, but the page takes 5-10 seconds to load. If I change $wgScript to "$wgScriptPath/wiki.php", it loads quickly, but exposes the php extension. Is there something I'm doing wrong, or is there any way to speed this up? --Bamapookie 01:14, 10 Nov 2004 (UTC)

Update: It turns out that it wasn't content negotiation (multiviews) that was the problem. $wgScript needs to be set to the script name, whether it's masked or not. Here is what I'm using now (only the parts changed from the generated LocalSettings.php):

$wgScriptPath       = "";
$wgScript           = "$wgScriptPath/wiki.php"; # Keep in mind that I renamed index.php to wiki.php
$wgArticlePath      = "/wiki/$1";

I created wiki.var to handle the content negotiation. It's not really needed, because apache generates it on the fly, but it might speed things up a bit, so I left it. I also enabled Multiviews in .htaccess. I will eventually move this to an apache conf file so I can block access to php files if php is not enabled.

--Bamapookie 16:03, Nov 10, 2004 (UTC)

Unsure of which .htaccess file to use

I have MediaWiki running on an external host, and have it installed into my root-directory, with simply the http://www.mydomain.com. Can anyone clarify these questions for me?

• There is no .htaccess file in my root directory - do I simply create it and add the above entries to it, in order to experiment with the rewriting of URL's?
• There are a number of .htaccess files in my subdirectoriess - do these remain unaltered?

--Morten Blaabjerg 11:14, 30 Nov 2004 (UTC)

Redirection Limit???

When I try to do this, I get an error saying that the redirection limit for the URL has been exceeded... what is this and how do I get around it?

Same problem here! :(

You have created an infinite loop. You'll have to find the particular thing you did wrong and fix it. The Live HTTP Headers extension for Mozilla may assist you.

Same for me. I've just found out this, to put in your global or vhost conf:

 #Note: must be writable only by the server.
 RewriteLog "somepath" #From server root, or begins with a / or a |
 #Note: not too high in production!
 RewriteLogLevel 3

I got lots of redirection limit problems when experimenting with rewrite rules. It looks like most of the instructions are only partially working.

Sy's mod_rewrite rules

I also host this information on my own site at: http://sysy.homeip.net/mw/index.php/Mod_rewrite

I have moved my wiki into a subdirectory, and so I can no longer use these exact rules. I will have to revisit the rules to work with a subdirectory, because minor playing with these rules didn't work for me.

• http://meta.wikimedia.org/wiki/Rewrite_rules
  • http://meta.wikimedia.org/wiki/Rewrite_rules#Simplifying_the_url-_hiding_.2Fwiki.2Findex.php.3Ftitle.

I spent far too much time playing around with something which should be properly documented. Many of the other suggestions are broken to one degree or another, so I've been trying to integrate all that experience into something that would actually work for me. My goal is still to make one proper set of instructions appropriate for everyone interested. We need to obsolete all of those old notes. This is nuts.

Finally, the rules work as expected! Are there other things I didn't account for? Are there other entries I can add to the "testing" section? If you can help, especially if you can modify these rules with ones that work, please please email me so I can use those changes. (sy1234 at gmail)

I'm especially interested in making this universal for both those who use / and who use /wiki

-- Sy / ^(talk) 10:54, Mar 3, 2005 (UTC)

Special:Version

Mine reports this:

• MediaWiki (http://wikipedia.sf.net/): 1.3.11
• PHP (http://www.php.net/): 5.0.3 (apache2handler)
• MySQL (http://www.mysql.com/): 4.1.10

If your numbers are different, especially your MediaWiki version, things may work a bit differently for you. Don't despair.. try things out and if they don't work come chat and we'll work on the problem together.

LocalSettings.php

I don't use localhost/mediawiki/Main_Page or localhost/wiki/Main_Page or the like.. just localhost/Main_Page. This means that I changed references to /wiki to / and also customised my wgArticlePath:

$wgArticlePath = "/$1";

httpd.conf

modify apache's httpd.conf

Many installations have this done for you by default. To be safe, search for "rewrite" in your httpd.conf and uncomment the line which looks something like:

LoadModule rewrite_module modules/mod_rewrite.so

Append the following to the bottom of your httpd.conf:

The rules

# Allow rewriting URLs
RewriteEngine on

# If using a subdirectory like htdocs/wiki/  Not necessary when the wiki is in htdocs/ (i.e. the root)
# RewriteBase /wiki


# Don't rewrite requests for these MediaWiki subdirectories and files
# you may need to change "stylesheets" to "skins" (v1.4?)
RewriteCond %{REQUEST_URI} !^/(stylesheets|images)/
RewriteCond %{REQUEST_URI} !^/(redirect|texvc|index).php

# other notible conditions
RewriteCond %{REQUEST_URI} !^/error/(40(1|3|4)|500).html
RewriteCond %{REQUEST_URI} !^/favicon.ico
RewriteCond %{REQUEST_URI} !^/robots.txt


# Make sure there is no query string - unless user is making a search
RewriteCond %{QUERY_STRING} ^$ [OR] %{REQUEST_URI} ^/Special:Search


#I suspect that people who use /wiki will need the following line, but I'm not sure:
#RewriteCond %{REQUEST_URI} ^/wiki$

# Rewrite URI/foo properly, this is the main rule.
RewriteRule ^(.*)$ /index.php$1 [L,QSA,NE]		# Quirk: Truncates question marks (%3F)
#RewriteRule ^(.*)$ /index.php?title=$1 [L,QSA,NE]	# Fails with ampersands (not tested)

Issues

BUGS

• Some template links still point to "index.php/foo" and would have to be hand-edited somehow. This includes entries in the sidebar and page tabs.

RFEs

• the installation directory should be in a variable
• the "Main_Page" should be in a variable

Quirks

• Somehow the rewrite rules allow one to use lowercase searches to go to an uppercase page. i.e. "Main page" goes to http://localhost/Main_Page
• Ugly edit URLs: http://localhost/index.php?title=Main_Page&action=edit
• Everything after a questionmark is ignored. I don't know if MediaWiki allows page titles with questionmarks in them. Frankly, I don't mind this quirk and so I have not done any experimentation for a resolution.
  • The main rewrite rule is known to not work with question marks (%3F).
    • a solution via an apache URL rewriting patch is discussed at http://meta.wikimedia.org/wiki/Apache_config#Patches

Testing

Start URL	Goal URL	Current status
http://localhost/	http://localhost/	pass with http://localhost/Main_Page
http://localhost/Main_Page	http://localhost/Main_Page	pass
http://localhost/Sandbox	http://localhost/Sandbox (if it exists)	pass
http://localhost/index.php/Special:Search?search=Sandbox	http://localhost/Sandbox (if it exists)	pass
http://localhost/index.php/Special:Search?search=Special:Version	http://localhost/Special:Version	pass
http://localhost/Special:Randompage	http://localhost/Page (as appropriate)	pass

Htaccess working, but SLOW

I finally got htaccess url-rewrites working, but it is slow (note for anyone having that redirection limit exceeded: I had a / in my rewrite rule that is not necessary for directory level rewrites ; when I just removed it, it worked). I made the changes to my localsettings file (per the warning that it would be slow if I didn't) but it still takes up to 5 seconds for the page to load. I read some of the appache documentation for url-rewrite, and it comes right out and says that directory level rewrites are inherently slower than server level ones. Anybody have any other inputs or ideas? I think I'm going to live with the "ugly" urls, because I'm too cheap to get better a better hosting service. Too bad though... it's a cool feature.--Aerik 19:58, 17 Jan 2005 (UTC)

Okay, this is really wierd, with one host using the semi-clean urls "index.php/articlename" works just by changing to the clearn urls option in localsettings, with no url-rewriting; but with my other host I get a redirect limit error (both using the same version of php and apache). What gives? The second host has php in safe mode - could that be it?

Update: this is working well..

I tried the fake wiki directory and a rewrite for it, and it's working very nicely... from it's behaviour, it looks like this is what is used (or similar) at Wikipedia.

Local Settings:

$wgSitename         = "WikidWeb";

$wgScriptPath	    = "";
$wgScript           = "$wgScriptPath/index.php";
$wgRedirectScript   = "$wgScriptPath/redirect.php";

## If using PHP as a CGI module, use the ugly URLs
# try fictional wiki subdirectory
$wgArticlePath      = "$wgScriptPath/wiki/$1";

.htaccess:

RewriteEngine on
RewriteRule ^wiki/(.*)$ /index.php/?title=$1 [L,QSA]

I'm thinking that the way I was doing was creating a loop - not an infinite loop, that got me the redirect limit error, but maybe something else... I'm going to stick with this, seems to work well.--Aerik

httpd.conf settings 1.3.9

The following worked for me in httpd.conf. Then when I tried it in a .htaccess file (thinking I was on to something) I couldn't get it to work for the life of me. I kept getting 404 errors.

# Allow rewriting URLs
RewriteEngine on
	
# fix for URLs like this: hostname.tld/?title=page_title
# if the requested page is the root page "/"
# and the query string contains the title
# return the index page, query string will be automatically appended
RewriteCond %{REQUEST_URI} !index\.php
RewriteCond %{QUERY_STRING} ^title=
RewriteRule ^.*$ /index.php [L,QSA]

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

# Rewrite http://wiki.domain.tld/article properly, this is the main rule
RewriteRule ^/(.*) /index.php/$1 [L,QSA]

My LocalSettings.php variables are pretty standard:

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

--Justinsomnia 05:48, 9 Feb 2005 (UTC)

I have the .htaccess problem pinned down to this block...

# fix for URLs like this: hostname.tld/?title=page_title
# if the requested page is the root page "/"
# and the query string contains the title
# return the index page, query string will be automatically appended
RewriteCond %{REQUEST_URI} !index\.php
RewriteCond %{QUERY_STRING} ^title=
RewriteRule ^.*$ /index.php [L,QSA]

I am able to access pages if they are appended by a "?" so instead of "Main_Page" it is access with "?Main_Page".

I also changed this line in LocalSetting.php to get it to work for me

$wgArticlePath      = "$wgScriptPath/$1";

I'm going to keep poking at it, while I'm figuring out how to set it up without [QSA].

--Accornehl 05:12, 18 Feb 2005 (UTC)

Iubito's 404 error solution

For French users of free.fr hostring...

As of February 2005, we can't user URL Rewriting, but I found a way to get nice URL working.

I kept the default settings, script uses "index.php?title=MyPage" but what I made is only to give a nice URL http://mysite.free.fr/MyPage .

Due to Apache locking (and also bad config :p of free.fr) it was a bit hard, so I share my experience, and my codes.

I installed MediaWiki at my root dir.

In LocalSettings.php

$wgScriptPath       = "";
$wgScript           = "$wgScriptPath/index.php";
$wgRedirectScript   = "$wgScriptPath/redirect.php";
$wgArticlePath      = "$wgScript?title=$1";

At my site root, I created a .htaccess file containing :

ErrorDocument 404 /404.php

And my /404.php :

<?php
$title = ereg_replace("^/", "", getenv("REQUEST_URI"));
header('HTTP/1.0 200 OK');
header("Location: index.php"
       . ($title!=""
         ? "?title=$title"
         : ""));
?>

Special letters (UTF8) are managed.

Enjoy !

Iubito 23:40, 22 Feb 2005 (UTC)

Rewrite rules from en.wikipedia.org available?

I'd like to set up my (1.4rc1) wiki just like en.wikipedia.org, where articles can be accessed by /wiki/ARTICLE instead of /wiki/index.php/ARTICLE.

Are the exact LocalSettings and Apache options used on en.wikipedia.org available anywhere as a model?

(The Rewrite rules page is a confusing mess with contradictory and outdated info.)

--Gojomo 07:37, 5 Mar 2005 (UTC)

Here are the effective rewrite rules on *.wikipedia.org right now:

   RewriteEngine On
   RewriteMap ampescape int:ampescape
   
   # Uploads to the host-specific directory
   # First grab the subdomain from HTTP_HOST
   RewriteCond %{HTTP_HOST} ([a-z\-]+)\.wikipedia\.org
   # Now use it
   RewriteRule ^/upload/(.*)$ http://upload.wikimedia.org/wikipedia/%1/$1 [R=302]
   
   # Standard intrawiki rewrites
   RewriteRule ^/wiki/(.*)$ /w/index.php?title=${ampescape:$1} [QSA,L]
   RewriteRule ^/wiki$ /w/index.php
   RewriteRule ^/$ /w/index.php
   RewriteCond %{QUERY_STRING} ([^&;]+)
   RewriteRule ^/wiki.cgi$ /w/index.php?title=%1
   RewriteRule ^/wiki.cgi$ /w/index.php

Those include some backwards-compatibility URLs. To cut it down a bit:

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

This relies upon a patched version of the Apache web server to provide the ampescape function; this allows both & and ? to appear in page titles without breaking in the rewrite. A patch for Apache 1.3.x is included in the MediaWiki distribution, as maintenance/apache-ampersand.diff

To go with these rewrite rules, you want something like these in LocalSettings.php:

   $wgScriptPath       = "/w";
   $wgScript           = "$wgScriptPath/index.php";
   $wgArticlePath      = "/wiki/$1";

Note that you should always put the real script files and the virtual wiki directory at distinct, separate, non-overlapping points (eg, /wiki and /w). Some people like to try to overlap them (especially those at /), but this causes no end of trouble and limits you in what you can do. --brion 08:42, 5 Mar 2005 (UTC)

What does it mean to "put the real script files and the virtual wiki directory at distinct, separate, non-overlapping points (eg, /wiki and /w)"? Is this an Apache directive? Do I need to extra mediawiki directories in multiple places and point to each one separately? Something else? I'm confused...and I'm a bit green wrt Apache management. Many thanks if you can spell it out for me. --User:MattEngland 15 Apr 2005

Many thanks!

I'm using Apache 2.0 (as part of XAMPP 1.4.12) and there does not seem to be an ampescape patch for it. But, by changing the rewrite to pass the title in PATH_INFO rather than QUERY_STRING, all seems to work. Specifically, I changed your "cut down a bit" version to be:

   RewriteEngine On
   
   RewriteRule ^/wiki/(.*)$ /w/index.php/$1 [QSA,L]
   RewriteRule ^/wiki$ /w/index.php
   RewriteRule ^/$ /w/index.php

Ampersand titles are working well. Thanks again. --Gojomo 02:25, 13 Mar 2005 (UTC)

IIRC if you do that, titles with question marks break. --brion 02:37, 13 Mar 2005 (UTC)

Aha, yes, you're right. Ok, in the absence of an int:ampescape patch for Apache 2.0, I've set something up using the 'prg' facility of mod_rewrite. The rewrite section of httpd.conf (at the very end in my setup) is thus the same as your "cut down a bit" version, EXCEPT the RewriteMap line becomes:

   RewriteMap ampescape prg:/opt/lampp/mybin/ampescape.pl

Meanwhile, /opt/lampp/mybin/ampescape.pl is:

   #!/usr/bin/perl
   $| = 1;
   while (<STDIN>) {
       s/&/%26/;
       print $_;
   }

No doubt a tad less efficient than a patched Apache, but works for ampersand and question-mark titles for me with MediaWiki 1.4RC1 and Apache 2.0.

Thanks, --Gojomo 03:40, 13 Mar 2005 (UTC)

We switched to the patch from a similar external script because the script method is very fragile. It had a tendency to break and get out of synchronization, so people would get sent to seemingly random pages. --brion 11:03, 14 Mar 2005 (UTC)

infinite redirect loops

Got problems making this work. There's an infinie redirect loop when URLs of the form "/wiki/?title=-&action=raw&ctype=text%2Fcss&smaxage=18000&maxage=18000&gen=css&oldid=0" are requested. My wiki (most recent version) is running in the directory "/wiki". I run Apache 1.3.26

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} !^/wiki/skins/
RewriteCond %{REQUEST_URI} !^/wiki/(redirect|texvc|index).php
RewriteCond %{REQUEST_URI} !^/wiki/error/(40(1|3|4)|500).html
RewriteCond %{REQUEST_URI} !^/wiki/favicon.ico
RewriteCond %{REQUEST_URI} !^/wiki/robots.txt

# Rewrite http://wiki.domain.tld/article properly, this is the main rule
RewriteRule ^(.*) /wiki/index.php?title=$1 [L,QSA]

At the end it's working but very SLOW.

What's wrong?

$wgScript does not point at the actual script, so the security check for action=raw always fails. Internet Explorer's type detection creates an XSS attack vector if you can manipulate the URL in certain ways for a raw page view, so only the canonical form is allowed. Rewriting the main script breaks this. --brion 11:00, 14 Mar 2005 (UTC)

$wgScript is set to "$wgScriptPath/index.php" in the moment. But this gives me URLs in the form of http://blah/wiki/index.php/Hauptseite (I'm using the German edition of MediaWiki). I want the "index.php" hidden, for example http://blah/wiki/Hauptseite. What must I do in order to archive this??? --217.232.189.57 11:40, 14 Mar 2005 (UTC)

That's what $wgArticlePath is for... --brion

OK now it looks better. Every article can be reached by URLs in the form http://blah/wiki/da_article. I can edit them, actually I can do everything what you can do w/ wikis :-)

In the moment there's only on problem left: The links in the old documents still have "index.php" in the URL. New links don't have it, but they work too. How can I "rebuild" the old links without changing all the docs by hand? --217.232.189.57 11:50, 14 Mar 2005 (UTC)

Do a DELETE FROM objectcache; to clear all the rendered pages stored in the parser cache if you're using 1.4. You could also update $wgCacheEpoch in LocalSettings.php. (As always, see DefaultSettings.php for formats and default values. Never change DefaultSettings.php) --brion 12:11, 14 Mar 2005 (UTC)

rofro's solution

non of above soulutions was working for me. here is modified solution that works for http://gimp.org.pl/wiki

Local Settings:

$wgScriptPath	    = "/wiki";
$wgScript           = "$wgScriptPath/index.php";
$wgRedirectScript   = "$wgScriptPath/redirect.php";

## If using PHP as a CGI module, use the ugly URLs
$wgArticlePath      = "$wgScriptPath$1";

.htaccess:

RewriteEngine on

# Verifying if user forgot to put trailling slash. If so, we'll rewrite to Main_Page
RewriteCond %{REQUEST_URI} ^/wiki$
RewriteRule ^(.*) /wiki/index.php?tile=Main_Page [L]

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

# Make sure there is no query string (Unless user is making a search)
RewriteCond %{QUERY_STRING} ^$ [OR] RewriteCond %{REQUEST_URI} ^/wiki/Special:Search

# Rewrite http://wiki.domain.tld/article properly, this is the main rule
RewriteRule ^(.*) /wiki/index.php/$1 [L]

Understanding how links are formed

I am making progress with setting up URL rewriting, but let me just state the obvious for newbies as it took me two days of frustration just to reach this point.

If you use mediawiki in it's default setting you get URLs like:
www.mydomain.com/mywiki/index.php?title=MyPage
Mediawiki can tidy up the URL a bit by setting $wgArticlePath = "$wgScript/$1"; in LocalSettings.php
You can go a step further by getting mediawiki to remove the index.php and optionally other elements of the URL, but if you do this you have to use mod_rewrite to expand the URL again behind the scenes, so that mediawiki can interpret it correctly.

I have a tld and the wiki code is in a subdirectory of the home directory for this tld:

/home/tld.com/www - this is where code for home page goes
/home/tld.com/www/wiki - this is where mediawiki code is

I wish to keep the wiki element in the URL but loose the index.php,

www.tld.com/wiki/index.php/MainPage is displayed as www.tld.com/wiki/MainPage

LocalSettings.php (key elements)

  $wgScriptPath	    = "";
  $wgScript           = "$wgScriptPath";
  $wgRedirectScript   = "redirect.php";
  
  ## If using PHP as a CGI module, use the ugly URLs
  $wgArticlePath      = "$wgScript/wiki/$1";

.htaccess (key elements)

 RewriteBase /wiki
 # Rewrite http://wiki.domain.tld/article properly, this is the main rule
 RewriteRule ^(.*)$ /wiki/index.php/$1 [L]

This is working for the initial page, but links within that page are missing the wiki element, ie. they are www.tld.com/index.php/AnotherPage

Nothing I have tried will change how these links are written. Can anyone give me some pointers on how to correct this problem?

$wgScript MUST REFER TO THE ACTUAL SCRIPT, THAT IS index.php. DON'T EVER MAKE IT BLANK. DON'T CONSIDER MAKING IT BLANK. DON'T THINK ABOUT MAKING IT BLANK. DON'T DO IT. DON'T EVER EVEN THINK OF DOING IT. IT'S WRONG AND WILL SCREW UP YOUR WIKI 100%.

If you want to change how URLs to article views are generated, change $wgArticlePath. CHANGE NOTHING BUT $wgArticlePath FOR THIS. DON'T CHANGE ANYTHING ELSE. ESPECIALLY DON'T CHANGE $wgScript!!!!

Now, if you've made a change to these variables you'll find that the old URLs are still cached. Use action=purge to purge and re-generate an individual page and force it to re-render. --brion 21:09, 1 Apr 2005 (UTC)

Thanks for the action=purge tip, it works!!! (even with $wgScript blank). --User:phoebebright

Chovy's Solution

The following mod_rewrite rules can be used with MediaWiki (when files are located in ./htdocs root):

Change LocalSettings.php (This removes the /index.php/ in the url on all the links of the pages).

From:

$wgArticlePath      = "$wgScript/$1";

To:

$wgArticlePath      = "$wgScriptPath/$1";

Then use .htaccess for mod_rewrite url rewriting:

RewriteEngine on
# Verifying if user forgot to put trailling slash. If so, we'll rewrite to Main_Page
RewriteCond %{REQUEST_URI} ^/$
RewriteRule ^(.*) /index.php?tile=Main_Page [L]

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

# Make sure there is no query string (Unless user is making a search)
RewriteCond %{QUERY_STRING} ^$ [OR] RewriteCond %{REQUEST_URI} ^/Special:Search

# Rewrite http://wiki.domain.tld/article properly, this is the main rule
RewriteRule ^(.*) /index.php/$1 [L]

Known bug: Does not work with Wiki pages that contain "?" in them, such as "What Is SEO?". I think it's conflicting with the rule using %{QUERY_STRING} since "?" signifies a query string in a url. Anyway, the quick fix is to move "What Is SEO?" page to "What Is SEO" and then change the link to the page to something like this:

[[What Is SEO|What Is SEO?]]

Notice addition of "?" in the anchor text only, not used in the url (before the "|").

  - in your solution above, should tile be title?
        RewriteRule ^(.*) /index.php?title=Main_Page [L]

MattEngland's solution

(Preface: My apologies for my multiple revisions of this discussion saved to the dbase...I'm a MediaWiki newbie and am feeling my way around...and I'm used to TWiki's save-only-one-rev-in-local-time feature; for what it's worth, I was using the Preview button here and there. If I could delete the unecessary revision points I would; is there a means to do this? -Matt)

Summary

2 key questions:

1) Does this solution not work in all scenarios? (ie, is the solution too simple?)
2) How can I get my original objectives in Goal #2 working?

1 key point:

I suspect this solution works as simply as it does because I have root access to my system (to change httpd.conf and restart Apache). Not sure what to do if one does not have this. Any comments?

Details

Note: I'm using MediaWiki 1.4.0 and Apache 2.0.52 (as a part of XAMPP 1.4.9a) on my site.

Description

Maybe I'm missing the goals/purpose of this endeavor, so let me try to be clear on mine (goals/purpose):

(Assume meta.wikipedia.org as any arbitrary domain name...)

Goal #1:

Substitute (ie, accept from a browser's address field)...
http://meta.wikimedia.org/wiki/My_Title

...in place of:
http://meta.wikimedia.org/w/index.php?title=My_Title

Goal #2:
Substitute...
http://meta.wikimedia.org/wiki?title=My_Title&action=edit

...in place of:
http://meta.wikimedia.org/w/index.php?title=My_Title&action=edit

I could get #1 to work, but have not yet accomplished #2. So, I instead tried the following Substitution for Goal #2:

http://meta.wikimedia.org/wikibin/?title=My_Title&action=edit

(referencing a wikibin "breakout" directory; see how I implemented this below)...but that did not work, either. Next I tried to accomplish this substitution for Goal #2:

http://meta.wikimedia.org/wikibin/index?title=My_Title&action=edit

(no ".php", which I can presumably get to work because I have MultiViews set in Apache)...but that did not work. So at last I settled upon my final substitution workaround (for now, at least):

http://meta.wikimedia.org/wikibin/index.php?title=My_Title&action=edit

...which is basically the same thing en.Wikipendia.org currently does, except I use "wikibin" instead of just "w".

Solution

The following shows how I did this. Note that this solution is EXTREMELY simple compared to the ones above, and that leads me to wonder: Is it too simple? Did others already try this and it broke in some scenario I have yet to try? (I've tried several scenarios on my site...which is not public, it's behind an SSL wall becuase it's a private-development-collaboration site.)

Diffs from my original LocalSettings.php (from MediaWiki 1.4.0):

------- LocalSettings.php -------
25c25
< $wgScriptPath     = "/wiki";
---
> $wgScriptPath     = "/wikibin";
30c30
< $wgArticlePath      = "$wgScript/$1";
---
> $wgArticlePath      = "/wiki/$1";

The ONLY changes I've made to my httpd.conf:

    Alias /wiki    "/www/example.com/mediawiki/mediawiki-1.4.0/index.php"
    Alias /wikibin "/www/example.com/mediawiki/mediawiki-1.4.0"

(In this case, "example.com" replaces the real domain for my site, only for privacy purposes.)

The following commented-out lines of my httpd.conf represent my failed attempt(s) to get the original objectives for Goal #2 working (the RedirectMatch line tried mutually-exclusively of the RewriteRule stanza). None of them succeeded, or at least not consistenly. Any comments/suggestions to this point?

    #RewriteEngine On
    #RewriteMap ampescape prg:/root/bin/ampescape.pl
    #RewriteRule ^/wikinbin/index.php(.*)$ /wikibin/$1 [R=permanent]
    #RewriteRule ^/wikinbin/index.php(.*)$ /wikibin/${ampescape:$1} [R=permanent]

    #RedirectMatch permanent ^/wikibin/index.php(.*)$ /wikibin/$1

Thanks for reading...and thanks for any suggestions or reviews!

- MattEngland 23:58, 15 Apr 2005 (UTC)

what's wrong with these rules?

in localsettings: $wgArticlePath = "/site/wiki/$1"; and as rewriterule: ^/site/wiki/(.*)$ /site/wiki/index.php?article=$1

My own subdomain progress

I'm making slow progress getting this working with my own wiki.

I'm trying to get it to work in a subdomain, this it my .htaccess which I have located in the root directory of the subdomain, along with the wiki files.

RewriteEngine on

# Verifying if user forgot to put trailling slash. If so, we'll rewrite to Main_Page
RewriteCond %{REQUEST_URI} ^/$
RewriteRule ^(.*) /index.php?title=Main_Page [L]

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

# Make sure there is no query string (Unless user is making a search)
RewriteCond %{QUERY_STRING} ^$ [OR] RewriteCond %{REQUEST_URI} ^/Special:Search

# Rewrite http://wiki.domain.tld/article properly, this is the main rule
RewriteRule ^(.*) /index.php/$1 [L]

These are the relevant areas of my LocalSettings.php

$wgScriptPath       = "";
$wgScript           = "$wgScriptPath/";
$wgRedirectScript   = "$wgScriptPath/redirect.php";

## If using PHP as a CGI module, use the ugly URLs
# $wgArticlePath      = "$wgScript/$1";
$wgArticlePath      = "$wgScript$1";

At the moment all this seems able to do is redirect http://wiki.domain.tld to http://wiki.domain.tld/Main_Page which it does with reasonable speed. Links within the wiki still point to index.php?title= and load in the address bar like that. Typing in http://wiki.domain.tld/Some_Page gives me an error about too many redirections.

Any suggestions as to how I can make this work properly? --213.78.188.23 16:08, 10 May 2005 (UTC)

Search

Everything is working fine, I'm simply using:

Rewrite Engine On
# I don't know why I need to add this, Apache should not
# rewrite the url twice ! But it doesn't work without it
RewriteRule ^guide/index.php$ guide/index.php [L,QSA]

# Only rewrite words (like wiki/Word), not subdirectories (like wiki/skins/...)
RewriteRule ^guide/([^\/]+)$ guide/index.php?title=$1 [L]

However, searches don't work. I get "Search results For query "" Badly formed search query"" on http://www.centerofchaos.com

I have tried putting the following in:

# Make sure there is no query string (Unless user is making a search)
RewriteCond %{QUERY_STRING} ^$ [OR] RewriteCond %{REQUEST_URI} ^/guide/Special:Search

It doesn't seem to make a difference however. A little help would be wonderful :-).

--219.88.163.103 05:00, 28 May 2005 (UTC)

Use the query string append option on your rules. --brion 05:24, 28 May 2005 (UTC)

Thanks for the reply :-), I tried "RewriteRule ^(.*)$ wiki/index.php/$1?%{QUERY_STRING} [L]", however that gives me an internal server error. Any other ideas? I assume it is something different with my server config. --219.88.163.103 06:19, 3 Jun 2005 (UTC)

i just had the same problem. this works for me:

RewriteRule ^lab/?(.*)$ /w/index.php?title=$1%{QUERY_STRING} [L]

"w" is the actual installation, and "lab" the alias. --Anarchitect 17:26, 4 Jun 2005 (UTC)

Clean urls almost working, but :-chars mucking up

This is what I use for my http://wiki.xth.se/ to get urls like: http://wiki.xth.se/Main_Page

# first, enable the processing - Unless your ISP has it enabled
# already.  That might cause weird errors.
RewriteEngine on

# I don't know why I need to add this, Apache should not
# rewrite the url twice ! But it doesn't work without it
RewriteRule ^index.php$ index.php [L,QSA]

# Only rewrite words (like wiki/Word), not subdirectories (like wiki/skins/...)
RewriteRule ^([^\/]+)$ index.php?title=$1 [L]

But urls containing ":" still doesn't work, like: http://wiki.xth.se/Special:Recentchanges Someone that have any idea of a fix?

Rewriting URL under IIS?

Has anyone got the URL rewrite to work under Windows with IIS? I have Wiki at my company, which uses IIS. Any tips would be greatly appreciated. Otherwise, if I can't, just let me know. Thanks.

Possible Solution

IISRewrite is a really good mod_rewrite style tool for IIS. It works under IIS5 and IIS6, isn't very expensive and does a full on regex thing. Here is an example.

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

Using httpd.conf and a two level subdir (/something/wiki)

Well, I read the article more carefully, and I realized it only works when the alias is different from the real path. So, this works:

$wgArticlePath = "/corp/giki/$1";

with

Alias /corp/giki/skins somepath/corp/wiki/skins
Alias /corp/giki somepath/corp/wiki/index.php

Original message:

Hi,

I tried what is posted on the main page, and it seemed to work. I could access pages with sitename.com/corp/wiki/Page_Name

Problem is I cannot edit them. If I try, the edit URL looks something like this:

sitename.com/corp/wiki/index.php?title=Page_Title&action=edit

BUT, the page says "Editing index.php". And so I cannot edit anything.

Here's my config:

$wgScriptPath = "/corp/wiki";
$wgScript = "$wgScriptPath/index.php";
$wgRedirectScript = "$wgScriptPath/redirect.php";
$wgArticlePath = "$wgScriptPath/$1";

Apache:

Alias /corp/wiki/skins somepath/corp/wiki/skins
Alias /corp/wiki somepath/corp/wiki/index.php

I also tried with the Rewrite rules, but I get 404s.

Thanks!

Why must set to be "www.example.com/wiki/index.php?wiki=

I have installed a mediawiki successfully. ]

But it is not able to visit with the URL: www.example.com/wiki/index.php

and it works well with another URL: www.example.com/wiki/index.php?wiki=

I just cannot solve this. Can every one help?

Thanks very much!!!!!!!!!!!!!!!!!!!!!!!!!!

A review of the concepts

If you've gotten this far, you're probably about to cry because none of the above suggestions works completely. Take a deep breath and review:

It's better if the PATH and the URL are different. For example ("w" vs "wiki"):

• path in filesystem: /home/web/w/index.php
  • $wgScript = "/w/index.php";
• url: http://www.site.com/wiki/index.php
  • $wgArticlePath = "/wiki/$1";

Get the CGI types of URLs working first. Example: http://www.site.com/w/index.php?title=Main_Page

Then, once CGI works, get the mod_rewrite stuff to work. Example: http://www.site.com/wiki/MainPage

Don't try to install the wiki in your docroot directory (at least not first!)

The URL rewriting is only for *articles*. Search, edit and other functions uses the standard CGI format. Examples:

• an article: http://www.site.com/wiki/Main_page
• an edit link: http://www.site.com/w/index.php?action=edit&title=Main_page

Add "action=purge" to your URLs if you changed LocalSettings.php and the pages haven't changed For example:

• http://www.site.com/w/index.php?title=Main_page&action=purge
• http://www.site.com/wiki/Main_page?action=purge

Know what the mod_rewrite flags do. example:

• R=Redirection (browser sees new url)
  • RewriteRule ^$ /wiki/Main_Page [R]
• L=Last Rule (don't match any more rules)
• QSA=Query String Append
  • RewriteRule ^wiki/?(.*)$ /w/index.php?title=$1 [L,QSA]

And if your host uses CGI-fast (FCGI) for the Apache API you might have mod_rewrite installed, even though you can't see it in phpinfo())

That summarizes the learning curve I had. Good luck!

Solution for german provider 1und1

For some reason you need to put in another dir into the rewrites (I got error 500 otherwise). This works like a charm (on 1und1 shared servers):

.htaccess

Options -MultiViews
RewriteEngine on
RewriteCond %{REQUEST_URI} wikidir/u/(.*)$
RewriteRule u/(.*)$ /wikidir/index.php?title=$1 [L,QSA]

where "wikidir" is the directory where the wiki software is installed and "u" just a random char (can be replaced with whatever you want).

LocalSettings.php

$wgScriptPath	    = "/wikidir";
$wgScript           = "$wgScriptPath/index.php";
$wgRedirectScript   = "$wgScriptPath/redirect.php";

$wgArticlePath = "/wikidir/u/$1"; 

The resulting URL for the Main Page is http://www.domain.tld/wikidir/u/Main_Page - not that pretty but better than nothing.

Hope this helps.

How to mod_rewrite?

I've put wikipedia in main root :

http://www.mysite.it/index.php?title=Pagina_principale

I've seen many solution for /wiki .... but none (working) for /

Pls help me! Thanks a lot

Davide

---

I wish I could help, but I'm trying to do the same thing.

However, here is the proper page for such discussion:

http://meta.wikimedia.org/wiki/Using_a_very_short_URL

Kerim Friedman 9 July 2005 14:11 (UTC)

Apache ServerName

I had a problem with a wiki I had set up that would function rather well, but would send me to localhost after I'd try to save an edit. It was running on a box in my local LAN, and I had been accessing that box over the IP. Turned out I had commented out ServerName in my httpd.conf, which didn't lead to any other problems except for the one I just described. Now I don't know how many people do something as silly as commenting out their ServerName, but I thought it might be worth mentioning at the very least in the Talk page.

Does anyone think it'd be useful to include this in the guide itself?