WordPress on Lighttpd

It’s easy to make WordPress work together with Lighttpd, and thanks to the FastCGI, it runs even faster. And setting up PHP through FastCGI is also not a big deal. Just switch the FastCGI on by

$ sudo lighty-enable-mod fastcgi

and then install essential packages php5-cgi. The last step is to add this line

cgi.fix_pathinfo = 1

to the php.ini file located at /etc/php5/cgi/.

Then WordPress should be very easy to install.

But one shortage of Lighttpd is that it doesn’t support Apache’s .htaccess at all. Therefore you have to set the rewrite rules in the configuration file yourself. Even unfortunately, sometimes the rewrite rules you can play with inside the configuration file is not enough to generate the same effect as .htaccess does, so after you customize the premalink in WordPress to make the URL more readable and search engine friendly, you may find out that the rewrite rule which supposed to be written into .htaccess file as follow can not be easily translated into Lighttpd’s rewrite rules.

 RewriteEngine On
 RewriteBase /~dngpng/wordpress/
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteRule . /~dngpng/wordpress/index.php [L]

Because in the RewriteCond part, it judges if a request path/file exists on the server, but with Lighttpd’s rewrite rule, this can not be achieved.

Before there is a dirty work-around, which is to redirect the error path to index.php, so when there is a unaccessible path/file, the request is handled by index.php

However, with the power of mod_magnet, you can easily handle the request in Lighttpd.

Magnet works with Lua, a lightweight programming language, and modify the request to the web server flexibly. It can be installed by

$ sudo apt-get install lighttpd-mod-magnet

and be switched on by

$ sudo lighty-enable-mod magnet

Here is just how to tweak it to make WordPress’s premalink work. More detailed information can be found at http://trac.lighttpd.net/trac/wiki/Docs%3AModMagnet.

Suppose we have our WordPress installed at /var/www/wordpress, we create a configuration file

$HTTP["url"] =~ "^/wordpress" {
   magnet.attract-physical-path-to = ( "/etc/lighttpd/wordpress.lua" )

This enables magnet to attract a request and process it with the Lua script defined by the absolute path.

The Lua script looks like this

attr = lighty.stat(lighty.env["physical.path"])
if (not attr) then
   lighty.env["uri.path"] = "/wordpress/index.php"
   lighty.env["physical.rel-path"] = lighty.env["uri.path"]
   lighty.env["physical.path"] = lighty.env["physical.doc-root"] .. lighty.env$

It change several path information to redirect the request to index.php if the path/file requested does not exists.

After restart the web server. The premalink of WordPress should work correctly. (If you only modify the Lua script, there is no need to restart the server.)

But I still come across a problem. If the module userdir is also used, and the WordPress is installed in a user’s home directory ~/public_html/, then the judgement of the physical path will always fail therefore all the path/file will be redirect to index.php, which means all the images, CSSes, etc. will be gone. Currently I have not find a good solution, except using the dirty trick mentioned above. Any help or comment is appreciated.


About this entry