Kyle D. Skrinak

I don’t intend this post to be comprehensive (nor introductory) but it will address what worked for me after much googling and finding many contradictory pages on the matter.

For Drupal to use “Clean” URLs, you must enable server URL rewriting. On apache, this is a trivial task. On lighttpd, much less so. Here’s what I did to enable a Drupal directory specific rewrite capability while staying within what appears to be a best practice approach to extending my lighttpd configuration:

• This site’s page on setup worked best for me, (consider this instruction a variation on it) but reading it without understanding some fundamentals on lighttpd will not be helpful
• sudo apt-get install the necessary lighttpd, php5 and mysql packages. I need phpmyadmin, and ubuntu’s setup worked in its default install correctly. There’s plenty of mainstream documentation on this to refer to.
• Do include lighttpd-mod-magnet — we’ll need that.
• Enable the mod_magnet:
  sudo lighty-enable-mod magnet
• Here’s what is now key to me after re-inventing the wheel: much on-line documentation has you editing the lighttpd.conf quite heavily and without context. Spend 30 minutes NOW on the basic structure of the lighttpd.conf file structure and its ability to specify conditionals. You’ll save hours later. Conditionals allows you to set up specific configurations by virtual hosts, while leaving the defaults alone.
• Notice that lighttpd uses directories to manage module functionality. Fastcgi, phpmyadmin and others are modules that are enabled by their placement in the /etc/lighttpd/conf-enabled directory. Many on-line instructions ignore this fact and have you update the lighttpd.conf file directory directly, when the “right” code is already on your computer. Avoid this trap.
• In the lighttpd.conf file, comment out the lines regarding the “Debian Policy Manual” at the end of the file. It’ll mess up everything else, and I’m curious why they include this, but not enough to dig further.
• Modify your /etc/hosts file so that “drupal.localhost” (the name is arbitrary but you name need to be consistent for your project) points to 127.0.0.1.
• Download the drupal.lua to the /etc/lighttpd/ directory. I got mine from here and it works well:
  sudo wget -P /etc/lighttpd/ http://pixel.global-banlist.de/drupal.lua
• Update drupal.lua so that the line containing local prefix = ‘/drupal’ matches your needs. For mine, it was an empty string.
• I need a virtual host established so “/root” urls work correctly. So I set one up in the lighttpd.conf file. (Note you can create a conf file per virtual host, or use a mysql mod and store this in my mysql db — but, jeesh, I just want to get back to drupal dev already.) You can make this as complex and sophisticated as you want, the below suits my local machine development needs. You’ll have to make the appropriate path adjustments for your configuration:
  $HTTP["host"] == "drupal.localhost" {
server.document-root = "/home/$HOME/Documents/drupal"
index-file.names = ( "index.php" )
url.access-deny = ( "~", ".inc", ".engine", ".install", ".module", ".sh", "sql", ".theme", ".tpl.php", ".xtmpl", "Entries", "Repository", "Root" )
magnet.attract-physical-path-to = ( "/etc/lighttpd/drupal.lua" )
}
Note that magnet. line and it points to the drupal.lua file we downloaded.

After all that drupal 6.6 now allows me to enable clean URLs. I haven’t tested the above instructions from scratch, so reader beware.

Outlining is a very effective way of brainstorming — capturing a lot of information randomly and then ordering the information in a more coherent manner. I find outlining indispensable at the start of projects, such as scope definition, quoting, task identification and sorting, and so on. I’ve used Microsoft Word’s outlining feature for some time now. It is easy to use, but the canned style sheets are overkill and I invariably turn them off. Additionally, keeping Word up to date has costs and it consumes a lot of computer resources. I work on avoiding resource-intensive software as they collectively slow down computer performance as the day goes on. Just because I can install 4 GB of RAM in my computer is a lousy reason for using resource-intensive software. There is another product I used and it is extremely well-designed for usability and functionality: OmniOutliner. However, I don’t use it as it’s Mac only. I would pay for it if it were open-platform.

Enter vim. Vim is small, open source, fast but, yes, the polar opposite of user-friendly. Here’s an interesting digression about user-friendly — this notion is the premise of how easy a software package is to get started on using. Regardless of the application, in short order you should be past the novice stage, or at least should be. At what point in your discipline do you “kick off the training wheels?” Anyhow, vim is cross-platform and maintains a furious development cycle. Vim is extensible, and there’s a set of scripts that combine into “vim outliner” or vimoutliner that I find fast to use. I can pop up a vimoutliner session in a terminal or in gvim on any platform.

Back to my learning-curve digression. The first mistake I made was when I treated the vimoutliner scripts and gvim as if it were GUI-based — and I was wrong. There’s just enough GUI in the gvim version to trip you up. vim is design to be GUI-less, and so is vim outliner, although the gvim version has menu items for when you forget the colon commands. Spend time with the vim tutorial firstly (time well spent) before running vim outliner.

This article got me back on the vim outliner track, here’s another learning reference and one more. Share any if you know one. Now to get back to this project proposal…

I’d love for this post to be a painstakingly methodical and thorough comparison between the two; but it ain’t. The skinny: Camino is very unsexy. Few extensions, widget and rich text rendering is problematic, text insertion doesn’t always map correctly. Yet, it is “fast” (quick to load and open a page) and, using Gecko rendering, the second most targeted browser spec for page rendering (IE being # 1, of course) so I don’t have too many “wigged out” pages, such as overlapping text objects. Also critically important, Camino maintains a svelte memory usage over a long period of time. Just because I can afford to run FF doesn’t mean that I want to be sloppy with my resource allotment.

Firefox is my favorite on ubuntu; oddly, konqueror, while fast, has similar rendering issues as Safari does. Not reliable enough to keep running. An open-source parallel to the Mac platform, I suppose.

WebKit (usually updated nightly) IS fast and pretty, but rendering isn’t as reliable as it is with Gecko-based browsers. I’ve heard that Epiphany is adopting webkit. Should be interesting to see what happens.

Like an ugly but ever-faithful mutt, Camino is always the browser that I want to leave but end up coming back to.