Evan Sims, a recent convert from Flickr to SmugMug, has whipped up a little something to help make getting to those SmugMug unfriendly URLs a little bit easier - SmugUrl:

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.

In a new post Edin Kadribasic shares his method for getting a Serendipity (a popular PHP-based blogging system) website up and running on a lighttpd server.

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.

Doing everything in just PHP can be a great thing when you're working with web applications, but what happens when a project comes along that was already using something like Ruby on Rails? You'd have to get in there and learn the language to get up to speed. One thing that can help, though, is a "transition" piece to show you what functionality matches up with the language you're familiar with - PHP. This new article (series) from LoLoCoJr aims for just that.

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)

Sometimes developers just don't think about how much trouble they'd cause with a rewrite of existing software. They think that moving up to the latest and greatest is the way to go, and that it makes perfect sense to say out with the old and in with the new. Aaron Wormus disagrees. Well, sometimes - it depends on the circumstances, really.

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.

On Dikiki.net today, there's a new post that's a continuation of a series (first post, second post) dealing with macro programming in PHP.

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

There are code examples (of how it should work) and explainations of the issues PHP would face to accomplish this goal.

In a (very) brief post on Simplesem.com today, there's some suggestions to help you and your site be properly noticed by Google and other search engine spiders out there.

It's common tendency for Search Engine Optimization specialists to avoid use of dynamic URLs and not groundlessness. Search Engine Spiders don't index URLs overwhelmed with dynamic parameters.

So if your site is PHP-based and resides on an Apache Server then you might consider carrying out these four simple steps to boost your traffic.

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.

Pierre has posted about an update to his zip extension he created and added to the pecl repository. This version is a complete rewrite, and uses libzip instead of zzlib.

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.