Ryfujk

I'm absolutely new at this, so please bear with me. I installed MediaWiki on Lighttpd with no problems, except that when I try to follow up redwerks instructions on how to shorten the urls for MediaWiki on Lighttpd, I always get a very frustrating 404. This is what I did:

on lighttpd.conf:

## MediaWiki

url.rewrite-once = (

    "^/wiki(/|$)" => "/w/index.php",

    "^/$" => "/w/index.php",

)

url.rewrite-if-not-file = (

    "^/w/images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$" => "/w/thumb.php?f=$1&width=$2",

    "^/w/images/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$" => "/w/thumb.php?f=$1&width=$2&archived=1",

)

on LocalSettings.php:

$wgScriptPath = "/w";

$wgScriptExtension = ".php";

$wgArticlePath = "/wiki/$1";

$wgUsePathInfo = true;

Help is so appreciated, I might start crying soon.

The crying-free method is using Redwerks' superb configuration generator.

Note: This attempt at an answer is a fail as well; it simply does not work. The official MediaWiki page on this exact topic states the following:

Warning: This Short URL page contains bad advice on how to configure your server that could lead to some pages on your wiki not
working and/or may cause you issues while upgrading.

It goes onto suggest using the Redworks generator, but that still doesn’t seem to work. Also, the official MediaWiki page sends mixed messages on what might work. I did find this page on $wgUsePathInfo that states this interesting tidbit:

Note: These often break when PHP is set up in CGI mode. PATH_INFO may be correct if cgi.fix_pathinfo is set, but then again it may not;
lighttpd converts incoming path data to lowercase on systems with
case-insensitive filesystems, and there have been reports of problems
on Apache as well. To be safe we'll continue to keep it off by default
in these instances.

Haven’t tested this cgi.fix_pathinfo idea yet, but posting this here as a reference. If someone can post a canonical answer, please go ahead and do so! Feel free to copy my answer if needed! Just somehow let’s get this mishegas settled so.

Rest of answer—that does not seem to work—follows below.

The posted answer by Tgr is excellent, but if you look at the output of that generator via their default settings for Lighted version 1.5+, this is the output:

## MediaWiki

url.rewrite-once = (

    "^/wiki(/|$)" => "/w/index.php",

    "^/$" => "/w/index.php",

)



# Protect against bug 28235 (ported from MediaWiki's .htaccess file)

$HTTP["url"] =~ "^/w/images/" {

    $HTTP["querystring"] =~ ".[^\/:*?x22<>|%]+(#|?|$)" {

        access.deny-all = "enable"

    }

}



# Deny access to deleted images folder"

$HTTP["url"] =~ "^/w/images/deleted(/|$)" {

    access.deny-all = "enable"

}



# Deny access to folders MediaWiki has a .htaccess deny in"

$HTTP["url"] =~ "^/w/(cache|languages|maintenance|serialized)(/|$)" {

    access.deny-all = "enable"

}



# Just in case, hide .svn and .git too

$HTTP["url"] =~ "/.(svn|git)(|$)" {

    access.deny-all = "enable"

}



# Hide any .htaccess files

$HTTP["url"] =~ "(^|/).ht" {

    access.deny-all = "enable"

}



# Uncomment the following code if you wish to hide the installer/updater

## Deny access to the installer

#$HTTP["url"] =~ "^/w/mw-config(/|$)" {

#   access.deny-all = "enable"

#}

Seeing that url.rewrite-once at the top is the same between the original poster’s config, one can assume the issue is this url.rewrite-if-not-file chunk:

url.rewrite-if-not-file = (

    "^/w/images/thumb/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$" => "/w/thumb.php?f=$1&width=$2",

    "^/w/images/thumb/archive/[0-9a-f]/[0-9a-f][0-9a-f]/([^/]+)/([0-9]+)px-.*$" => "/w/thumb.php?f=$1&width=$2&archived=1",

)

So I would recommend simply setting the initial chunk of code for Lighted like this:

url.rewrite-once = (

    "^/wiki(/|$)" => "/w/index.php",

    "^/$" => "/w/index.php",

)

And the settings for LocalSettings.php look fine as is:

$wgScriptPath = "/w";

$wgScriptExtension = ".php";

$wgArticlePath = "/wiki/$1";

$wgUsePathInfo = true;

If you can get that working, then add in the other access.deny-all stuff to lock the install down and you should be good to go.

But past any of that, the issue could be that the original posters path to an article is not /wiki/ and the relative path to the index.php file is not /w/index.php. It could be simply /index.php.

Yes, this is confusing… But some ideas to help others attempting to achieve this goal.