Talk:Eliminating index.php from the url

Sub-Pages

/Sy's mod_rewrite rules

Too complicated

Latest comment: 18 years ago4 comments2 people in discussion

This is all too complicated. How about the easy solution? http://devpit.org/wiki/Installing_Mediawiki#How_to_make_nice_wiki_URLs . As far as I can tell, everything on this page can be replaced with the two solutions found at the link above. -- Bilbo1507 22:02, 5 May 2006 (UTC)Reply

I agree that it is too complicated. I couldn't get anything on the content page to work. However, the above only works if you have access to the httpd file. I don't, moving on ... -- JulieC 13:21, 9 May 2006 (UTC)Reply

Good point. There's essentially no organization at the moment and everything is very confusing. Actually the article is terrible -- it's just a bunch of "try this -- it might work" suggestions. How about changing the structure to below? Then we should merge in the relevent parts of the Devpit article linked above. -- Bilbo1507 18:43, 15 May 2006 (UTC)Reply

I like it! I also suggest putting comments about what versions of MediaWiki tips apply to. I'm not sure how much things have changed, but I did run into version diffs during my efforts. --JulieC 14:07, 18 May 2006 (UTC)Reply

Suggested Restructuring

Each bullet describes one best-practice approach. Combining approaches and jumping around is unnecessarily confusing. Let's clearly document what the best-practice is for each situation. Put the other solutions in the alternatives section.

How to use a virtual subdirectory
- In httpd.conf
- In .htaccess
How to use /
- In httpd.conf
- In .htaccess
How to on Sourceforge
Alternate approaches
- / without mod_rewrite #1
- / without mod_rewrite #2
- / without mod_rewrite #3

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 Together

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:

where can I find the httpd.conf file (I don't have full root access)?
What is a Virtual Host Container, what should it look like, and where should it be added within the httpd.conf file?
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?
Are all of the instructions at this page (or that you are answering now) valid for MediaWiki 1.3.1 ?
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

Working ReWrite Rules

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

JulieC's working rules, MediaWiki 1.6.5

Thank you very much ! it worked!!! I don't have access to httpd, so I had to do this the hard way. I took a great deal of trial and error. Hopefully it will save someone else the headache!

I have MediaWiki 1.6.5 installed in <myroot>/w

No .htaccess in /w

In .htaccess in <myroot>, these are the key lines - SAME AS Nidego's (thank you), with "wiki" (non-root directory) modification:

DirectoryIndex w/index.php 
RewriteEngine On
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 ^wiki/(.*) w/index.php?title=$1 [L,QSA]

In /w/LocalSettings.php, this is the related lines:

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

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:

Installed the wiki into the htdocs root and configured
Removed the *.phtml files
Renamed index.php to wiki.php
Used Multiviews to allow wiki to point to wiki.php
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

Latest comment: 19 years ago1 comment1 person in discussion

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)

You probably want to create the .htaccess in your root directory. Each .htaccess applies to the directory it is in, so an .htaccess in the root would apply to your whole site, unless overridden by .htaccess's in subdirectories. Leave the other files untouched. --Shellreef 00:15, 8 September 2005 (UTC)Reply

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.

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

None 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

Latest comment: 19 years ago1 comment1 person in discussion

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)Reply

Search

Latest comment: 19 years ago2 comments2 people in discussion

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)Reply

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

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]

Tested Solution

I have created a comprehensive article on this subject.

I have URL rewriting working in IIS6. I'm using ISAPI_Rewrite, a product similar to IIS Rewrite mentioned above. The full version of ISAPI_Rewrite is not free, but there is a lite version that is completely free and provides all the necessary functionality for URL rewriting in Mediawiki. I am successfully rewriting article as well as action links. That means that in addition to Wikipedia-style article links, I can type something like /wikiDir/articleName/action to get directly to the edit interface or to do purges and deletes from the address bar. Here are the relevant settings in my LocalSettings.php:

$wgArticlePath = "$wgScriptPath/$1";
$wgActionPaths['view'] = "$wgScriptPath/$1/view";
$wgActionPaths['watch'] = "$wgScriptPath/$1/watch";
$wgActionPaths['unwatch'] = "$wgScriptPath/$1/unwatch";
$wgActionPaths['delete'] = "$wgScriptPath/$1/delete";
$wgActionPaths['revert'] = "$wgScriptPath/$1/revert";
$wgActionPaths['rollback'] = "$wgScriptPath/$1/rollback";
$wgActionPaths['protect'] = "$wgScriptPath/$1/protect";
$wgActionPaths['unprotect'] = "$wgScriptPath/$1/unprotect";
$wgActionPaths['info'] = "$wgScriptPath/$1/info";
$wgActionPaths['markpatrolled'] = "$wgScriptPath/$1/markpatrolled";
$wgActionPaths['validate'] = "$wgScriptPath/$1/validate";
$wgActionPaths['render'] = "$wgScriptPath/$1/render";
$wgActionPaths['deletetrackback'] = "$wgScriptPath/$1/deletetrackback";
$wgActionPaths['print'] = "$wgScriptPath/$1/print";
$wgActionPaths['dublincore'] = "$wgScriptPath/$1/dublincore";
$wgActionPaths['creativecommons'] = "$wgScriptPath/$1/creativecommons";
$wgActionPaths['credits'] = "$wgScriptPath/$1/credits";
$wgActionPaths['submit'] = "$wgScriptPath/$1/submit";
$wgActionPaths['edit'] = "$wgScriptPath/$1/edit";
$wgActionPaths['history'] = "$wgScriptPath/$1/history";
$wgActionPaths['raw'] = "$wgScriptPath/$1/raw";
$wgActionPaths['purge'] = "$wgScriptPath/$1/purge";

For these beautifications, here are the necessary rewrite rules where wikiDir = $wgScriptPath:

RewriteRule /wikiDir/([\w:]+)(?!/)(?:(?:\?)(.+))? /wikiDir/index.php\?title=$1&$2 [I]
RewriteRule /wikiDir/(?!Special)([\w:]+)/((?:view)|(?:watch)|(?:unwatch)|(?:delete)|(?:revert)|(?:rollback)|(?:protect)|(?:unprotect)|(?:info)|(?:markpatrolled)|(?:validate)|(?:render)|(?:deletetrackback)|(?:print)|(?:dublincore)|(?:creativecommons)|(?:credits)|(?:submit)|(?:edit)|(?:history)|(?:raw)|(?:purge))(?:\?(.+))? /wikiDir/index.php\?title=$1&action=$2&$3 [I]
RewriteRule /wikiDir/(?=Special)([\w:]+)/([\w:]+) /wikiDir/index.php\?title=$1&target=$2 [I]

A note of caution: I am not a Mediawiki expert and have discovered most URL variations used in Mediawiki on my own. It's quite possible that I have yet to discover some lesser-used variants that are not handled by my regular expressions. I have been using this set up for awhile with success, though, so whatever I might have overlooked is obscure. If you discover problems, ISAPI_Rewrite provides a handy test tool you can use to refine the rules I listed.

non-latin characters issue

I tried your solution with IIS 5.0, MediaWiki 1.5.7,PHP: 5.1.2 (cgi-fcgi) ,MySQL: 4.1.14-nt and ISAPI_Rewrite 1.3.0.16 on Windows 2000. It almost worked. But with your regular expressions for the httpd.ini file, I can't deal with encoded URL containing Chinese information, like : http://127.0.0.1/%E9%A6%96%E9%A1%B5 . It said "The page cannot be found".

I tried Apache's mod_rewrite too. I used the regular expression "RewriteRule ^(.*)$ /index.php/$1", which worked very well with the encoded URL. Can anyone help me covert a ISAPI_Rewrite version expression of "RewriteRule ^(.*)$ /index.php/$1", making it can cope with converting "http://127.0.0.1/%E9%A6%96%E9%A1%B5" to "http://127.0.0.1/index.php?title=%E9%A6%96%E9%A1%B5"and "http://127.0.0.1/%E9%A6%96%E9%A1%B5&action=edit&section=44" to "http://127.0.0.1/index.php?title=%E9%A6%96%E9%A1%B5&action=edit&section=44"?

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:

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?

Mishaps with Recent Changes page

Is there a particular reason when using [this] that the items in Recent Changes do not have a rewrite added to them?

One More Redirect

This combines some of the other advice. I personally like the results... your mileage may vary.

First,

In your root add this to your .htaccess

<Files ~ (wiki|redirect)>
        ForceType application/x-httpd-php
</Files>

Where wiki is the name of the file you wish to place in root (yes, root) that you want to appear to look like a folder. redirect same idea.

in your index.php and redirect.php in your wiki folder add the follow line at the top (after <?php of course):

chdir('wikifiles');

Where wikifiles is the name of where all your wikifiles are located. (Note: this may need to be different than fake folder you created above. It did on my system.)

Make the wiki file (without extension, at the rootpath--the root of your server not your wiki folder):

 <?php include_once('index.php');?>

Make the redirect file (without extension, at the rootpath--the root of your server not your wiki folder):

<?php include_once('redirect.php');?>

In LocalSettings.php, change the following:

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

To the following:

$wgScriptPath	    = "/wikifiles";
$wgScript           = "/wiki";
$wgRedirectScript   = "/redirect";

Where wikifiles is the name of where all your wikifiles are located; 'wiki is the name of the file you wish to place in root (yes, root) that you want to appear to look like a folder. redirect same idea.

Yet another way to redirect while keeping mediawiki in /wiki

Latest comment: 19 years ago1 comment1 person in discussion

I installed MediaWiki in /wiki/ and didn't feel like moving it to enable pretty URL's, so I took some hints from WordPress's .htaccess file and cobbled together that seems to be working so far for me.

php_flag register_globals off

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [S=1]
RewriteRule ^wiki/?(.*)$ /wiki/index.php?title=$1 [L,QSA]

This makes it so that any requests for files or directories that actually exist aren't redirected. I'm guessing this would even work in future versions. -- Zawersh 17:16, 21 September 2005 (UTC)Reply

Just tried that - works

Brilliant - works for me. - www.floralwiki.co.uk

Correction!

<Files ~ (wiki|redirect)>
        ForceType application/x-httpd-php
</Files>
DirectoryIndex wiki

Should be changed for:

<Files ~ (^wiki$|^redirect$)>
        ForceType application/x-httpd-php
</Files>
DirectoryIndex wiki

If you don't do that you'll have problems as soon as one page or image has "wiki" or "redirect" on its name.

-Eleazar

Doing it Math Jazz style

.htaccess

RewriteEngine On
RewriteBase /
RewriteRule ^/$ /wiki/Hoofdpagina [R]
RewriteRule ^wiki/([^/]+)$ index.php?title=$1 [L,QSA]

LocalSettings.php

$wgArticlePath      = "/wiki/$1";

Mike's .htaccess Solution

I wanted the ability to have no /w/ or /wiki/ in my url, entering URLs such as http://www.example.com/Main_Page so I created a rewrite rule that searches for pages that don't exist as well. While the URL may look like http://www.example.com/wiki/Main_Page after, they are redirect to this and can be entered in any way.

RewriteEngine on
RewriteRule ^wiki/?(.*)$ /index.php?title=$1 [L,QSA]
RewriteCond   /%{REQUEST_FILENAME} !-f
RewriteRule   ^(.+)                             /index.php?search=$1

Small htaccess method correction needed

Latest comment: 19 years ago1 comment1 person in discussion

The Using a rewrite rule in a .htaccess file method works fine for me except for one part. Since I had changed my directory from /wiki to /w, I had to follow the additional instructions to change $IP; it was not obvious to me, but apparently the only other LocalSettings.php item I needed to change was $wgScriptPath = "/w". It would probably be good to mention this detail in the article. FYI, my wiki, megsnjj.com/wiki, runs on a shared Dreamhost server. I'm running PHP 4.3.10 and Apache 1.3.33. --J. J. 14:17, 28 October 2005 (UTC)Reply

Performance difference between http.conf and .htaccess?

Latest comment: 19 years ago2 comments2 people in discussion

I am curious, how much of a performance hit a server takes when an .htaccess file is used compared to when http.conf is accessible and used instead. This Apache htaccess document is the best explanation I can find. I'm curious if anyone has any hard data about the speed of one over the other, though (specifically for MediaWiki). My guess is that there are more server calls, which eats up bandwidth a tiny bit faster and makes pages load only a fraction of a second slower. --J. J. 14:17, 28 October 2005 (UTC)Reply

.htaccess files are read by the server, not the client, so you won't use up bandwidth any faster. 60.224.154.187 12:04, 3 November 2005 (UTC)Reply

Wikimedia 1.5 url rewrite update

Latest comment: 18 years ago6 comments4 people in discussion

I've been working on this a couple days and am pleased to say that I've gotten the rewrite to work on two different shared hosting service providers.
Here's my LocalSettings.php change:

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

And here is my .htaccess file:

RewriteEngine on
# Verifying if user forgot to put trailling slash. If so, we'll rewrite to Main_Page
RewriteCond %{REQUEST_URI} ^/agency$
RewriteRule ^(.*) /agency/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} !^/agency/skins/
RewriteCond %{REQUEST_URI} !^/agency/stylesheets/
RewriteCond %{REQUEST_URI} !^/agency/(redirect|texvc|index).php
RewriteCond %{REQUEST_URI} !^/agency/error/(40(1|3|4)|500).html
RewriteCond %{REQUEST_URI} !^/agency/favicon.ico
RewriteCond %{REQUEST_URI} !^/agency/robots.txt
RewriteCond %{REQUEST_URI} !^/agency/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 ^(.*) /agency/index.php?title=$1 [L,QSA]

This .htaccess file is in the subfolder "agency". I didn't put it in my main root folder.

My wiki is a sub-folder of a site. In this case, I have installed the program here: www.tld.com/agency I feel most of my problem was in conceptualizing the rewrite. I actually happened upon this final version by mistake. I thought my main rule had to be rewriting it in another folder so I would try the RewriteRule like this:

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

That failed for me. I once tested that RewriteRule by rewriting it to another folder that happened to have a wiki running. I saw the other layout and that was my clue. So for me, the folder you rewrite to is the same folder the program is writen in.

I've applied this to three different wikis on two different servers and all seems to be well.

It feels great to conquer this.

Best wishes. --Sagerock 03:58, 12 November 2005 (UTC)Reply

I can't get this to work (on Mac OS X). I get taken to /wiki/Main_Page but I get a "File not found!" error. 212.18.232.108 17:01, 17 November 2005 (UTC)Reply

I was getting a few problems until I cleared my objectcache table. Have you tried that? (in SQL, type

delete from objectcache

...putting your table's prefix if you have one) -Firecaster 19:44, 22 November 2005 (UTC)Reply

--
~~Unfortunately, this doesn't seem to work for me either. I get a nice endless loop of redirects. :)~~ Figured out what I did wrong. I can confirm that this works. Trying to "break" it now, and if I see no problems, it stays. Thanks! -Firecaster 19:36, 22 November 2005 (UTC)Reply

All's still good, this one's a keeper. ^^ --Firecaster 18:47, 23 November 2005 (UTC)Reply

I get a 500 Internal Server Error when trying this method. --MateoP 00:16, 6 January 2006 (UTC)Reply

--
Seb

works fine for me, it's actually the only method I've tried that doesn't give me any errors with 1.55. However, it doesn't seems to rewrite everypage: some links (example: http://www.whatever.com/wiki/index.php?title=Main_Page) are not rewritten if linked from some other pages, whereas in other pages, it will be rewritten correctly (sidebar on main page for example). A working method but not universal???

Need a new solution without moving files and works in 1.5

Latest comment: 18 years ago1 comment1 person in discussion

any have a recommendation? the 1 method i tried didn't work. --MateoP 23:39, 8 January 2006 (UTC)Reply

Need a solution without httpd.conf that works in 1.5.5

I've tried every method that doesn't require httpd.conf access without luck under 1.5.5. I have an old 1.5.2 site where the .htaccess method works fine: http://www.ping.com.au/wiki - but my new 1.5.5 site won't play along: http://www.weiley.org/wiki . notice that links on the left are going to /wiki/ but Edit and History and article links are going to /w/index.php. Any ideas? Viveka

Proposal for Arcticle

The explanations for the section "Using a rewrite rule in a .htaccess file" worked very well for me, except one point I had trouble with. Besides that you have to change the $IP in file LocalSettings.php if you move your wiki from "wiki" to a directory called "w" you also have to look at $wgScriptPath. Therefore I propose a new point to add at the end of the article stating s.th like this:

Also check if your $wgScriptPath is set to right directory: $wgScriptPath = "/w";

(tested with 1.5.6)

Weird problem

Latest comment: 18 years ago1 comment1 person in discussion

Many solutions posted here worked for me, but only for articles. None of the Special:* pages worked.

This is what I got:

Forbidden

You don't have permission to access /wiki/Special:Random on this server.

--MarioJE 11:20, 22 January 2006 (UTC)Reply

This article needs updating

Latest comment: 18 years ago2 comments2 people in discussion

none of the non-rewrite examples work under 1.5.6. Looks like we need new methods. --68.210.139.209 00:43, 11 February 2006 (UTC)Reply

W/O Mod rewrite breaks 7 navigation links

On a brand new install (from CVS) using Aevar's "without mod rewrite rules" it appears that everything but the naviation menu works fine. Articles and Special pages all use the site.dom/wiki/Page convention, but the navigation menu defaults to using site.dom/index.php/Main_Page.

I made a quickfix by making a link to the wiki file (ie. index.php renamed) from "index.php" by ln wiki index.php. This doesnt rewrite the url, so the index.php still appears in the url for those links, but the other links work correctly. -Foob 01:56, 15 February 2006 (UTC)Reply

Using `mod_rewrite` and having "pagetitle?action=foo" still work

Latest comment: 18 years ago1 comment1 person in discussion

Here is a(n untested) method for rewriting everything that should go to your index.php file to there without actually duplicating the file.

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

What it does:

looks for "wiki" at the start of the line.
If the next character is a slash or a question mark, it takes it and the entire URL afterwards
It pastes the result on to index.php

So, /wiki/Foo becomes /w/index.php/Foo, /wiki?title=foo&action=edit becomes /w/index.php?title=foo&action=edit, and /wiki/Foo_&_Bar becomes /w/index.php/Foo_&_Bar, rather than /w/index.php?title=Foo_&_Bar, and this avoids problems with amersands (and other characters) in pagenames. thetorpedodog! 18:33, 1 March 2006 (UTC)Reply

My edits for ABSOLUTELY NO index.php links

Latest comment: 18 years ago1 comment1 person in discussion

After playing around with the latest MediaWiki build, I've managed to make the URLs the way I wanted to.

Ex:

http://www.website.com/wiki/Main_Page

http://www.website.com/wiki/Main_Page?action=edit

The way I did it required some editing to the script itself, but I think it might be possible to incorperate it with minimal problems. My script assumes you installed the script under the /w/ directory of your site, and want to point it to /wiki/.

Like most people's scripts, this goes in the .htaccess file in the root directory of your site.

# close the php security hole... 
#  not actually needed but probably a good idea anyway
php_flag register_globals off

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

# uncomment this rule if you want Apache to redirect from www.mysite.com/ to
#  www.mysite.com/wiki/Main_Page
# RewriteRule ^/$ /wiki/Main_Page [R] 

# do the rewrite
RewriteCond %{REQUEST_URI} !^/wiki/(stylesheets|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
RewriteRule ^wiki/?(.*)$ /w/index.php?title=$1 [L,QSA]

# also rewrite the other scripts to use the virtual /wiki/ directory
RewriteRule ^wiki/?(.*)$ /w/$1 [L,QSA]

The LocalSettings.php file has this:

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

## For more information on customizing the URLs please see:
## http://meta.wikimedia.org/wiki/Eliminating_index.php_from_the_url
## If using PHP as a CGI module, the ?title= style usually must be used.
$wgArticlePath      = "$wgScriptPath/$1";

(Don't flip out because I changed the script path. That's what I'm trying to do here.)

The last part involves the editing of the script itself. Go under includes/Title.php and find and edit the following lines. They are both in a function called getLocalURL

Replace:

global $wgLang, $wgArticlePath, $wgScript, $wgMakeDumpLinks, $wgServer, $action;

With:

global $wgLang, $wgArticlePath, $wgScript, $wgScriptPath, $wgMakeDumpLinks, $wgServer, $action;

And replace this:

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

With:

$url = "{$wgScriptPath}/{$dbkey}?{$query}";

The two lines are near opposite ends of the function itself, and for the latest build, the function starts on line 753.

An example of it can be found at my site, http://www.toadking.com/wiki/

68.85.141.253 23:00, 7 March 2006 (UTC)Reply

Error of BaseSite

Latest comment: 18 years ago1 comment1 person in discussion

# RewriteRule ^/$ /wiki/Main_Page [R]

should be:

# RewriteRule ^$ /wiki/Main_Page [R]

otherwise, the http://www.site.org will go to http://www.site.org/index.html
I'm using MW 1.5.7--Farm 14:21, 14 March 2006 (UTC)Reply

If I don't have access to Apache, is there any other options?

Latest comment: 18 years ago2 comments2 people in discussion

I have a firm which hosts my apache program, therefore I don't have access to change apache, is this the only option, or is there other options. sorry if this is a silly qustion, i have never used apache before.Travb 20:35, 13 April 2006 (UTC)Reply

Please contact your hosting provider for technical support. --brion 18:48, 27 April 2006 (UTC)Reply

What will vanilla mediawiki urls look like in the future?

Latest comment: 18 years ago1 comment1 person in discussion

I'm ok with keeping the standard "ugly" urls (I've heard search engines are dealing with them better now), but am concerned that since many of the mediawiki sites are changing them that at some point in the future mediawiki will eliminate the current url structure for a shorter version. I'm a firm beleiver in NEVER CHANGING YOUR URLS once other sites start linking to you so I'm wondering if anyone has any knowledge (or guesses) as to url structure in future releases. I'm about to release my wiki to the world so now is the time. --Wrongdave 02:24, 12 July 2006 (UTC)Reply

My ampersand solution

Latest comment: 18 years ago1 comment1 person in discussion

If ampersands don't work in titles for you, check my small patch here: Fix for ampersand in titles -- Barrylb 19:41, 17 July 2006 (UTC)Reply

Moving from the project page

Latest comment: 18 years ago2 comments2 people in discussion

I am moving the following from the project page, this information seems as reliable as the dozen of suggestions above, and none have been tried out by a third party. Odessaukrain 05:03, 2 September 2006 (UTC)Reply

Another way, without mod_rewrite

Note: This section was written by an anon and I have not yet had chance to test it. Plugwash 01:54, 29 May 2005 (UTC)Reply

Note: This method uses separate php files (with includes) when it may be easier to just rename the original files.

I've had a chance to test this, and it works very well - whereas you may fall into problems with the mod_rewrite listed above. -Matt

Change your .htaccess :

DirectoryIndex wiki

php_flag register_globals off

ForceType application/x-httpd-php

Allow from all

</Files>

ForceType application/x-httpd-php

Allow from all

</Files>

Make the wiki file (without extension, at the rootpath):

<?php include_once('index.php');?>

Make the wikiredirect file (without extension, at the rootpath):

<?php include_once('redirect.php');?>

This solution may be faster than mod_rewrite

Yet another way, without mod_rewrite

Due to the way apache works putting this in a .htaccess file in the root path also works:

<FilesMatch "^wiki$">
    ForceType application/x-httpd-php
</FilesMatch>

Of course you'll also have to set

$wgScript = "$wgScriptPath/wiki";

in your LocalSettings.php. —Ævar Arnfjörð Bjarmason 14:30, 22 Jun 2005 (UTC)

An extension of the above method (yes, without mod_rewrite)

Put this in your root .htaccess file:

<Files ~ (wiki|redirect)>
        ForceType application/x-httpd-php
</Files>
DirectoryIndex wiki

And then in your LocalSettings.php, the following:

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

becomes:

$wgScript           = "$wgScriptPath/wiki";
$wgRedirectScript   = "$wgScriptPath/redirect";

Then you only need to rename index.php and redirect.php

$ mv index.php wiki
$ mv redirect.php redirect

Example: http://dev.frozenonline.com/ (except I'm not using 'wiki')

Still Yet Another Way without mod_rewrite

...and mind you, this is being contributed by a MediaWiki newbie, so it may be very bad in some way and may not work with future versions (works with 1.4.5).

Basically, it uses the Apache "not found" file to pull up a wiki page using the absent URI for a title, or for a name to use to redirect to a title. The full explanation is here; for an example, try http://wiki.vbz.net/arbitrary_title

It's not a complete solution, as there were some issues I didn't have time to work out, and I have no idea how it compares to other solutions as far as CPU load.

three questions

Latest comment: 18 years ago1 comment1 person in discussion

FIRST: If you didn't follow the instructions and installed MediaWiki in the directory for www.mysite.com/wiki, then you will need to move it to another directory, such as "w". You will need to change the various paths (such as $IP) in LocalSettings.php to the new location. -- What are all of the paths that a user needs to change in LocalSettings.php? Can we list them on the page?

Is this all of them:

From:

$IP = "/home/mysite/public_html/wiki";

To:

$IP = "/home/mysite/public_html/w";

From:

$wgScriptPath	    = "/wiki";

To:

$wgScriptPath	    = "/w";

SECOND: Replace www.mysite.com and /filesystem/path/to/my/site to suit your site. --What does this mean?

THIRD: Why can't I simply keep my old wiki file, why do I have to move all the files to the new "w" directory? Odessaukrain 05:08, 2 September 2006 (UTC)Reply

The biggest problem with this article: it doesn't work

Latest comment: 18 years ago1 comment1 person in discussion

Template:CleanupConfusing added, Template:Technical tag added.

The biggest problem with this article: it simply doesn't work.

It is obvious that there is no consensus on how to Eliminating index.php from the url because we have twenty users, and twenty different solutions on this talk page. I know little about this subject, and for the past week, while attempting to fix my wikipage, I have rewritten and edited this article, but my knowledge of this subject is severly limited. Someone else needs to do this. The same goes for Using a very short URL. Which I also changed a little, and will also tag. Odessaukrain 07:05, 4 September 2006 (UTC)Reply

RewriteRule

Latest comment: 18 years ago1 comment1 person in discussion

It worked for me by removing the ?

# do the rewrite
RewriteRule ^wiki/?(.*)$ /w/index.php?title=$1 [L,QSA]

-->

# do the rewrite
RewriteRule ^wiki/(.*)$ /w/index.php?title=$1 [L,QSA]

--Biberl 18:31, 14 October 2006 (UTC)Reply

Clean up of article

Latest comment: 17 years ago1 comment1 person in discussion

I changed the page layout of the article, hopefully improving it's usability and friendliness. I also removed two tags from the top, because it was cleaned up and made less confusing. --MZMcBride 21:23, 2 December 2006 (UTC)Reply

MediaWiki 1.9

Latest comment: 17 years ago1 comment1 person in discussion

None of these things work for 1.9, for $wgArticlePath doesn't even exist in the LocalSettings.php file. Where is $wgarticlepath in 1.9? I have searched and reinstalled, etc and it will not show up in the file unless added. When the element is added in php, the entire Wiki becomes unstable and gets errors.

Also, the wiki is located right in the main root directory, I don't use /Wiki or /w -- It makes it unclean.

Redirect Loop In MediaWiki 1.9

I have an IIS installation where the wiki was in a subdirectory off the root \Wiki. When I upgraded to 1.9 everything seemed fine. EXCEPT for my IE 6.0 users, who were getting the "Redirect loop detected!" error but ONLY when after successfully saving an Edit to a section of a page. Edit of the whole page worked fine for them. Their changes do get saved, but on the view action they get redirected to the redirect loop error page.

In order to work around this (as most people at my company are trapped on IE6.03) is to rip out the entire "else if" section of code in /includes/Wiki.php that checks for the redirection loops on the action = view.

This seems to have solved my problem. I worry about what would happen if I do end up with a redirection loop. But since there doesn't seem to be much information out there on how to fix it, and since it only happens to IE6.03 users (not IE7 and not Firefox) it's hard to pinpoint what the problem could be. Possibly that IE6.03 doesn't treat paths the same as IE7.0 or Firefox? ? ? Just a guess since a lot of the path stuff seems to have been altered in this version. MarkEldridge 20:45, 7 February 2007 (UTC)Reply

Nice URLs with a single click in Mediawiki 2.0

Latest comment: 17 years ago1 comment1 person in discussion

After two days of unseccessful trying to have nice URLs in address bar I gave up. I guess I have tried most of the advices here, but no luck. Sometimes I got redirect loops, sometimes 404 errors, sometimes 500 errors. Since I am not an expert in apache nor in php I just blind-copied the code from here, but... heh... no luck. I tried to install Mediawiki in wiki/ dir, then in w/ dir, I tried everything, but no luck. And I guess EVERY user of the Mediawiki wants to use nice URLs and EVERY user encounters these problems. I have i feature request for Mediawiki developers. Is it possible to implement an option in future Mediawiki releases "$wgNiceURL = true"? No editing of settings code, no editing of .htaccess, no hassle, just a single line in LocalSettings.php. It would be like a feature from an add "feature with a single click". Is it possible? Please. 80.43.94.8 00:12, 19 May 2007 (UTC)Reply

Support for both 'wiki/PageName' and 'wiki/index.php/PageName'?

Is there anyway to support multiple schemes? In my previous install (1.5), I could only ever get the "wiki/index.php/PageName" style prettifications to work. I can't get those to work at all anymore under 1.10, but I can get "wiki/PageName" to work, which is preferrable.

Problem is, there are links on external sites and mailing lists pointing to "wiki/index.php/PageName" style links, and these now all just end up at Main_Page.

I've tried every combination of RewriteRule and $wgArticlePath I could think of, every one either breaking the linkages or resulting in infinite rewrites. Any ideas?

RESTful URL without renaming wiki to w

The following method attempt achieve the same result and doing minimal changes wiki script:

File: LocalSettings

$wgArticlePath = "/wiki/$1";
$wgUsePathInfo = true;

File: .htaccess in DocumentRoot of wiki site

RewriteEngine On

RewriteCond %{SCRIPT_FILENAME} -f [OR]
RewriteCond %{SCRIPT_FILENAME} -d
RewriteRule .* - [L]

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

Comment: This solution make problem with login and singup. Links like wiki/index.php?title=Special:Login&type=signup don't works.

Add topic

Talk:Eliminating index.php from the url

Sub-Pages

Too complicated

Suggested Restructuring

Rewrite in /wiki subdir with Search working

Putting All Together

How to change base URL?

Local Settings

Site URLs

Also need RewriteEngine On

Httpd.conf and other Unintelligibles to a Novice

None of this is valid on 1.3.3

Working ReWrite Rules

this worked for me

Nigedo's Solution for Apache 1.3.33

LocalSettings.php content

.htaccess content

JulieC's working rules, MediaWiki 1.6.5

1.3.3 Navigation different under Mozilla and IE?

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

Unsure of which .htaccess file to use

Redirection Limit???

Htaccess working, but SLOW

httpd.conf settings 1.3.9

Iubito's 404 error solution

Rewrite rules from en.wikipedia.org available?

infinite redirect loops

rofro's solution

Understanding how links are formed

Chovy's Solution

MattEngland's solution

Summary

Details

Description

Solution

what's wrong with these rules?

My own subdomain progress

Search

Clean urls almost working, but :-chars mucking up

Rewriting URL under IIS?

Possible Solution

Tested Solution

non-latin characters issue

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

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

A review of the concepts

Solution for german provider 1und1

How to mod_rewrite?

Apache ServerName

Mishaps with Recent Changes page

One More Redirect

Yet another way to redirect while keeping mediawiki in /wiki

Just tried that - works

Correction!

Doing it Math Jazz style

Mike's .htaccess Solution

Small htaccess method correction needed

Performance difference between http.conf and .htaccess?

Wikimedia 1.5 url rewrite update

Need a new solution without moving files and works in 1.5

Need a solution without httpd.conf that works in 1.5.5

Proposal for Arcticle

Weird problem

This article needs updating

Using mod_rewrite and having "pagetitle?action=foo" still work

My edits for ABSOLUTELY NO index.php links

Error of BaseSite

If I don't have access to Apache, is there any other options?

What will vanilla mediawiki urls look like in the future?

My ampersand solution

Moving from the project page

Another way, without mod_rewrite

Yet another way, without mod_rewrite

An extension of the above method (yes, without mod_rewrite)

Still Yet Another Way without mod_rewrite

three questions

The biggest problem with this article: it doesn't work

RewriteRule

Clean up of article

MediaWiki 1.9

Using `mod_rewrite` and having "pagetitle?action=foo" still work

Support for both 'wiki/PageName' and 'wiki/index.php/PageName'?