one aspect I didn't like was their URL scheme. They have good reasons for doing it, and I can't fault them for trying to maintain the privacy and security of their users. Heck, I applaud them for it. Still, I like my URLs pretty, and more importantly search engine friendly. So, I decided to take matters into my own hands and build SmugURL.

His example replaces this - http://evansims.smugmug.com/gallery/4717671_Ywtjp#279209234_a2ALu - with this - http://smugurl.com/evansims/myst_online...much more readable. He's even created a little bookmarklet you can drop into your bookmarks to make creating the URLs quick and easy. Check out for more.

Well the basic install went pretty smoothly, but I wanted, of course, to use "friendly" URLs. For that Serendipity supplies .htaccess file with Apache mod_rewrite rules. With a little bit of effort it was possible for me to convert those into rewrite rules that lighttpd would understand.

He includes all of the rewrite rules lighttpd needs to mimic the responses of an Apache server in a rewrite-once statement, and a limitation on the files the server can send with an access-deny config line.

In recent weeks I was busy converting a fairly large PHP application to Rails. The existing PHP application is about 65.500 lines of intermingled PHP and HTML/CSS code. Yep, a classic PHP application without any database abstraction layer, no templating, no MVC.

This is just part one of the series, but it jumps right in to things - the list of deliverables to break out the application into easy to chew chunks and a look at a Ruby config and database connections (MySQL to PostgreSQL)

At ZendCon I talked about "Planning a PHP 4 to PHP 5 codebase rewrite, a practical approach". The talk was based on my own experience, as well as famous discussion of the topic such as Joel Spolsky's "Things you should never do" and the examination of "famous" platform rewrites.

Aaron gives an example of a large company making a move from a COBOL system out to C for a mission critical system. Based on his tale, they didn't put the thought needed into making this move - new development time, keeping old developers on staff, etc - besides the fact that customers don't like change and making a move to another platform is almost definitely going to be noticed by them.

Without going into theoretical details, some of which are quite alien to me, I'll try to describe some of the challenges that pattern patching rewriting macros might pose for a language like php. After brief explanation what kind of a beast is this, I try to explore some of the finer points, which might cause problems. The intent of this post is to sketch a design and highlight some of the possible issues.

He breaks up the post into a few sections:

• pattern matching rewrite only macros - a bird eye view
• Transformation time
• Basic/skeleton shapes and intermediate shapes
• Code generation issues specific to php
• Hygiene
• A rough macro shape outline
• Output/Status of the project

The steps are basic, but they are a good place to start if you're looking at getting started with "search engine optimization". The main suggestion is to use an Apache rewrite rule to change url parameters into part of the path (and vice-versa). Obviously, it's not the solution for everyone as you'd need access to the server's config to use it.

It is 100% backward compatible, you can use your old code transparently.

For PHP 5.1.x and up: Add create, modify and write support, from files or strings, stream support (read only), OO interface

For PHP 4.x and 5.0.x: Better zip read support, broken zip files with zzlib may now work smoothly.

For the old APIs, you can read the good old PHP manual. There is no documentation yet, but the examples contain all new features. It is the very first releases, consider it as alpha.

He reminds developers that feedback is always welcome, and that it can be downloaded directly from the pecl site. ]]> Mon, 06 Mar 2006 07:37:35 -0600