Recovered from the Wayback Machine.
The primary focus of Leatherwood Online is on what’s in the pages, not on the technology behind the pages. Moving parts for the site are kept to a minimum and preferably hidden, as much as possible.
Some of the technology is directly accessible by the readers, such as movies, and the forum, but much is behind the scenes: providing ad review sites for the customers and file uploading for the photographers, that sort of thing. After all, trying to send an 18 MB file through the email nowadays isn’t going to make through one filter or another.
Allan is the man behind the user interface and all the page look and feel. My job was to provide help putting together the moving parts necessary for the release, and then help out as we go forward with more ambitious projects. Putting the bits together has been fun at times, considering that Allan is in Tasmania and 17 hours ahead of me in time, but we managed.
“What time is it where you are? Shouldn’t you be in bed?”
“I never sleep, Allan.”
Reminds me of the good old dot-com days.
We’re not into building from scratch. Rather than code any specific component of the overall system, what would happen is that Allan would ask for pecific functionality and I would then shop around at the open source and freeware/shareware sites for tools, utilities, and scripts, usually coded in PHP or Perl. Once I had some good candidates, I install them and test them, and then have Allan try the products. He would either ask for modifications or accept as is and we would load it on to the site.
If there was any user interface to the tool, such as the ad approval pages, that was Allan’s baby. I enjoy playing around with the look and feel of my own sites, but I am not a front-end person.
Now, as new and more sophisticated functionality is added, very gradually, to the site, we’ll continue with this approach – open source as much as possible, small components, specific functionality, and minimum moving parts.
You may have noticed that a weblogging tool is not used for any of the pages; surprising considering that both Allan and I are webloggers. Early on we did discuss using Movable Type, but it was about that time that some of the security and spammer problems started becoming a real issue, and Allan, rightfully so, did not want this kind of vulnerability at Leatherwood. In addition, we weren’t sure when Movable Type 3.0 was going to be out, and couldn’t hold the work waiting for it. The decision was made to move ahead with static pages, use the forum for reader interfaction, and then look at implementing main category pages such as the Travel page or the Tastes section after the opening, using a weblogging tool. These types of pages are very dynamic and change weekly and a CM tool would be very helpful.
A major decision was whether to go dynamic or static pages. At this time we are looking at dynamic weblogging tools, with functionality provided through PHP/MySQL. Though dynamic pages can be prohibitive with sites that have heavy traffic, we’re not expecting Leatherwood Online to be Slashdotted every day. Well, at least, not right away. Rebuild times, particularly with a page that will allow reader interaction is a concern and makes dynamic paging an attractive alternative. (And as we’ll see later, data caching does allay some of the performance concerns.)
We also picked PHP over Perl, because most of the other functionality at the site is PHP-based. The reason for this is primarily because PHP, like Microsoft’s equivalent product, ASP, is a very readable technology. Though PHP provides enough functionality to meet the needs of most tasks, it’s still very approachable. It’s fairly simple to see what’s happening in the code, and to make alterations and adjustments, even if you don’t have much of a programmer’s background.
Perl, on the other hand, can be very cryptic and hard to follow even for very experienced programmers. In fact its claim to fame is that you can code an entire content management system in 20 lines of code or less. But it will be the most complex 20 lines of code you’ll ever read.
Based on these two critera–PHP and dynamic–two weblogging tools we’re looking at are WordPress and pMachine’s new ExpressionEngine. WordPress is open source, and free; Expressengine is closed source and commercial (and has a hefty price tag – 199.00 US for a year of updates, costs after that year can’t be determined from site at this time).
I installed WordPress on my site and created a simplified version of this site, and it only took me about an hour to install and port my posts and comments, as well as re-create some of the look and feel. In addition, I also had some time to look around the code, and it is what I expected – very easy to follow, and quite simple to hack if needed. Best of all, if we did have to hack, and the hack’s a good one, we could work on re-incorporating that hack back into the WordPress source itself, so that it’s accessible to everyone.
I also installed ExpressionEngine, but this time using one of the provided templates that I rather liked. ExpressionEngine has 12 different templates you can use to start your site, but, like WordPress, provides templates that you can alter to suit your needs.
As you can see, both products are nice looking, and were surprisingly easy to install. Both provide support for trackback and comments, categories, multiple authors, and all the goodies we’ve come to expect from a weblogging tool. Most importantly, both provide security to prevent spamming and other problems.
ExpressionEngine has support for a ‘nonce’, which is a generated time-specific value that can’t be easily spoofed and should help prevent automated posting. In addition, it checks specific data points for duplication and prevents it, provides a configurable time interval between comment postings by the same person, trackback throttle, and, most importantly, site registration.
WordPress also has throttling included, as well as member registration. In addition, it has site moderation, which can delay posting of a comment pending approval.
ExpressionEngine makes use of template tags, but WordPress uses direct PHP function calls. However, both products seem to be fairly simple to modify for unique design. I would give WordPress a slight edge in simplicity.
ExpressionEngine is a commercial product and has a lot of bells and whistles, including nested categories, and emoticon support. Just think – all the smiley faces you can possible want. The big thing it has, though, is the ability to create dynamic database fields and have these incorporated into the tool. However, before you start drooling over that one, you have to remember that if you go beyond the traditional weblog data fields, you’re locking yourself into the tool.
WordPress may be a simpler product, but it also provides all you need, and more, in a weblogging tool, including multiple categories. But no nested categories, at least, at this time.
There is one killer difference between the products: WordPress has software to import your weblog tool data, such as pMachine, Blogger, and Movable Type. ExpressionEngine only imports pMachine data at this time. I’m not sure if this restriction is because the creators are still working on imports, or if its because they’d rather not have to deal with Movable Type users porting over and bitching about differences. Hard to say.
Bottom line: if you’re a Movable Type user and you want to migrate your data, ExpressionEngine is not an option at this time. Still, this isn’t a problem for Leatherwood Online because any weblog use at the site would be brand new.
Returning to issues related to dynamic pages. There are a couple of concerns folks have raised about dynamic weblog products that I wanted to address with both tools. The first has to do with search engine friendly URLs for dynamic pages. In particular, since we are webloggers, how will Google treat your pages?
To prevent the Googlebot from overloading a dynamic system, Google does restrict the bot’s activities when it sees a URL such as http://www.somesite.com/index.php?id=2&page=1. Also, URLs of this nature provide more information than you want about your system, and are, to be honest, ugly URLs.
An additional concern for many Movable Type users such as myself, is that we have adapted our weblog pages to be ‘cruft free URLs’, as discussed by Mark Pilgrim. Our pages are organized into sub-directories based on date or category, file extensions removed, keyword or post titles used for titles and so on. If a new tool doesn’t provide the same support, redirection will have to used on the pages, and for some of us that have been through more than one tool migration, that’s probably one redirection too many.
To support search engine friend URLs, modifications need to be made to the .htaccess page to rewrite requests, internally at the web server, from a friendly URL, such as http://burningbird.net/wp/fires/2004/02/09/this-is-a-test-title/, to the actual page request, similar to the above.
ExpressEngine does provide a search engine friendly url, which you can see at the test site. With this, search bots won’t know that the pages are dynamic, and bypass your content. ExpressEngine will also add the modifications for you to the .htaccess file. However, ExpressEngine does not provide the dynamics necessary to match the MT specific URL.
WordPress provides a utility that you can define a URL format and it provides the content to add to the .htaccess file. Simple copy and past. You can modify it, and the rewrite rules for .htaccess to fit your current URL configuration, and you shouldn’t have to need redirects once you port. If you look at the test WordPress site, you’ll see that my individual entries are search engine friendly, and backwards compatible with existing MT entries. Right now, page extensions aren’t supported, but this could be added by a couple of tweaks.
Unfortunately, my own configuration can’t be supported, but that’s more my fault, than any products. I liked using the primary category to define my URLs, in addition to adding a graphic to each item on the main page. However, categories, by their very nature, usually don’t have a ‘primary’ or ’secondary’ status – they just are. In WordPress, there is no functionality to mark a category as primary, and therefore I would have to hack something to get this.
A second aspect of a dynamic page system such as these is caching – caching local versions of just accessed data to make the next request of it that much quicker because it doesn’t make another round trip to the database. This has been an important aspect of major application servers such as Web Logic and Web Sphere, but I saw caching implemented with both WordPress and ExpressEngine.
ExpressEngine caches to a local file and WordPress caches to memory, but both should scale to meet the needs of even high profile sites. With the caching, the typical behavior of a reader – access a main page, access a specific item, comments, then return to main page– should be that much quicker because the data has already been pulled from the database.
So, what’s next. Well, Allan will have to review the products and make his choice on which system to use for Leatherwood, but for my own purposes, I am going to be porting all of my weblogs over to WordPress.
When I wrote Stepping Stones to a Safer Blog what I was doing, in effect, was acting like a human CVS (source code control) system. I was taking code from four different sources and mapping out a step by step plan to merge the efforts without adverse effects.
This type of activity is just no longer acceptable to me. Either I’ll go with a commercial product, and be able to hold the company accountable for the product’s security and reliability; or I’ll go completely open source and be able to not only code what needs to be fixed, but reincorporate that code back into the main product for others to benefit.
Either/or is acceptable, but not this half-in, half-out world of Movable Type. I have a lot invested in Movable Type, and a lot I like about it, but it’s time to move on.
Enough of this tech stuff. Following is another amazing photo I stole from Leatherwood, from a most unusual photo collection of local chefs.