Drupal

Clearly, I haven’t found much motivation to complete a blog post lately. In my defense, I haven’t been entirely idle. Recently I’ve released two projects related to the excellent Zen starter theme for Drupal: Zenophile lets you create Zen subthemes quickly, and Zen Midnight is a starter theme for themes which will use a light-on-dark color scheme (such as white text on a black background). There’s also been the utilitarian boringness of Menu Clone and Compound Eye (which lets you monitor the status of several Drupal sites at once - or will some day, anyway). Then there’s activities at work; we’ve finally got our own private server (of the virtual sort, for now), so I’ve been having a lot of fun and learning a lot as I’m getting it set up. Linux and Apache? That’s for wussies! We’re running FreeBSD and Lighty! Having full control of HTTP headers and being able to install things like Xcache means that we’re able to serve pages faster than ever before.

On a decidedly less nerdy note, I’ve also created a mini-fansite (it’s only one page long) for one of my favorite new bands, Fatblueman. Check it out here. I’ve included a list of all of their music I could find on YouTube - which is a heck of a lot - so if you’re interested in finding some new candy for your ears, check it out and give some of the vids a lesson. You can even download their albums (legally) for free! Give ‘em a try - maybe they’ll become one of your favorite new bands too.

There’s some kerfluffle in the community for the Python programming language. I would not be among that community; I experimented with Python for a bit, and didn’t hate it, but I also played with Ruby and found it to be more my style - but ultimately went crying back to PHP due to its ease of setup and omnipresence among web hosts. But for others, that’s not an obstacle. To each their own.

Anyway, the contention is about the recent release of the Python 3.0 interpreter. This version of the language breaks backward compatibility bi-directionally; code written for previous versions of the Python interpreter will generally not work with the Python 3.0, and code written for Python 3.0 will not run on previous versions of the interpreter.

The changes in the new version of the language are quite extensive. Many antiquated or redundant libraries were tossed out, and standard 8-bit Python string types were obliterated - all strings are in Unicode now.

The changes are going to mean bajillions of man-hours of labor to convert older codebases to the new system. Many Python-powered web sites use a framework such as Django or Pylons; the substantial codebases of these frameworks are going to have to be rewritten themselves before the sites using them can take advantage of Python 3’s improvements. It’s quite likely that many of these larger projects are going to be maintaining two codebases for a while (just as the Python organization themselves are) - one for Python 2.6 users, and another for Python 3.0 users.

For some, this is ludicrous. Python user Jens Alfke asks, on his blog, “Python 3.0: What’s The Point?” He argues that the improvements to the language are not worth the jarring and rewriting the 3.0 transition is going to cause.

On the other side one James Bennett, who titles his post, “Let’s talk about Python 3.0.” With a humorous story about monkeys, bananas and a fire hose, Bennett makes the argument that Python and its users are going to end up for the best in the end by implementing Python 3.0’s improvements now rather than later.

I see parallels with Drupal. With every major Drupal release, changes to the API mean that modules and templates for the previous version are not likely to work with the current one - and this is happening every eighteen months or so when a new major version of Drupal is released. Many developers have difficulty working with this concept. The result is that, even though Drupal 6 is the current version (its first standard release was in February) and Drupal 7 development is occurring full steam ahead, Drupal’s own main site still frequently showcases on its front page sites built with Drupal 5 - and the Drupal.org site itself is still using Drupal 5. Gradual process in the porting of many frequently-used modules such as Views to Drupal 6 forced many site admins to wait until the modules they depended on were upgraded before taking the plunge. In the [Drupal modules] and themes directory, you will to this day find many projects which do not have Drupal 6 versions available, even in pre-release form - and every once in a while you’ll come across a project which doesn’t even have a Drupal 5 version available, the coder instead going no further than one of the Drupal 4.x releases. It’s aggravating sometimes, and it’s going to all happen again when Drupal 7 is released.

And yes, some people whine and complain that all this updating and breakage is doing more harm than good. But I side with Bennett and those who think of the progress as a feature, not a bug. From a programmer’s perspective, the improvements in Drupal 6 over Drupal 5 are substantial - the menu system is much improved, and the improvements to the templating system are powerful and certainly make life easier. And when Drupal 7 hits, its new database interface is going to be a dream - but all Drupal 6 modules will have to be rewritten to take advantage of it.

But that’s progress. Look at the Mac. The transition from Mac OS 9 to Mac OS X required applications to be rewritten, sometimes substantially. The transition from PowerPC to Intel processors also caused some pain for Mac developers. Next around the bend is the transition to 64-bit codebases, which already has Adobe smarting. But the Mac is incalculably better than it was in the OS 9, PowerPC-only days - and it can keep its svelteness without Classic mode and Rosetta (backwards compatibility tech in OS X to run OS 9 and PowerPC apps, respectively) gunking it up.

Upgrades - and break-ups - can be painful. But life will be better if you do it sooner rather than later. Time to make a clean break, Python users.

I started a new project at Drupal.org today. It’s called Ubercart Auction, and, as you may have guessed, it’s a module which adds auction capabilities to the excellent Ubercart shopping cart system for Drupal. (At the time I posted this, the lovely D.o robots had yet to pack the code together into a downloadable dev release yet, but hopefully it’ll happen soon.) It was written for a client whose site isn’t live yet who is going to want to sell things via auction on their store. After seeing how well the module was progressing and how useful it could be for other people, I asked our contact there if they would be cool with us releasing it for free, and he gave us the okay.

Drupal’s other e-commerce solution, appropriately named Drupal e-Commerce, already has an auction solution. However, Ubercart seems to have more momentum nowadays. It’s a bit complicated to set up, and the D6 version isn’t up to snuff yet, but it’s quite the capable little bugger. Heck, anything’s better than the horrid tangle of code that is osCommerce (or, as a friend and I dubbed it last night, posCommerce).

I also started work last night (on my own time) on a little module which would provide a block telling site visitors how many form submissions the lovely anti-spam service Mollom has blocked on your site. I was hoping to have it done tonight, but Mollom’s servers seem to always report that it’s blocked zero submissions, which can’t be right. If I can get these issues resolved soon, I’ll probably create a project for it over the weekend.

Here’s a list of stuff I’m currently working on.

PIRETS 2.0

My first big project when I joined Precision Intermedia was that of a real estate company, Benchmark Realty. They wanted to have searchable real estate listings on their site. The local realtor’s association provides a database of such listings through a third party, which is accessible using a protocol called Real Estate Transaction Standard (RETS).

When I was hired, work on this project was underway by some programmers who work out of the office, but they weren’t getting very far; as budgets and deadlines became increasingly doomed, I was brought into the project to see if I could help. And though I may sound immodest, I did end up finally wrapping my head around RETS and bringing the project to something resembling a state of completion. Among the problems were that the documentation for RETS is all sorts of confusing at first, and that even once you think you’ve got it, the company that was providing the RETS server sometimes had things implemented differently than was in the documentation.

Most annoyingly pointless, though, were the field names. You’d think the property ID number and price would be in fields with names like PROP_ID and LIST_PRICE, right? Nope, they’ve got names like LIST_105 and LIST_87. The server does provide a metadata option which provides a list of fields and what they mean, but you’d think the field names themselves could be a little more self-explanatory. And some fields plain did not work. The client wants properties which are listed as active or are pending with contingencies to appear on the site. The server will tell us if a property is active or pending (I think it was LIST_32 or something), but even though the metadata tells us there’s a field for letting us know if a property has contingencies (LIST_55, maybe?), it’s always empty. The hack we ended up implementing was searching for “contingen” in LIST_78 (the description field).

So it should go without saying that PIRETS, as we called it (Precision Intermedia RETS; we are so clever) is a messy, hulking, fragile behemoth built by too many cooks which we did a whole lot of unpaid debugging on even after we went live, well past the deadline and over budget.

Fast forward a year; we have another realtor client who wants another searchable web site. Only this time, I know what I’m doing and what the client is expecting, I’m aware of Drupal’s presence and how it can make life easier, and my own skills have increased manifold. It was time for PIRETS 2.0.

This time, instead of bothering with trying to query the RETS server for each search a visitor does, we’re instead caching all of the property data locally and just searching on that. The hard part has been making sure the local cache is reasonably up-to-date with the RETS server… and handling pictures, which are their own special headache because they must be requested one at a time. And if we want to hotlink the pictures off of the RETS web server (the alternative is caching those locally as well - no thanks), we have to - get this - actually download the image, then just peek at the headers the web server sent us for the “Location:” header. The rest of the data is disposed of. Sadly, this seems to be directly to RETS spec, so I can’t blame the data provider for this one.

Anyway… I’m hoping by early next week to have something worthy enough to show the client. From there, we might even end up taking it back to Benchmark and saying, “hey, we did it for reals this time!”

SigFeeder 2.0

After that tl;dr-age above, I won’t go into depth about SigFeeder. I’ll just say that I’m glad to see that so many people are still using it, yet frustrated that I can’t use it myself since it’s incompatible with the feeds Drupal provides. So I’m rewriting it - in Drupal, of course. Progress is slow since I don’t really feel like working on it very often; I’m just now at the point where I’m starting to figure out how I’m going to fetch the incoming feeds. FeedAPI’s the word. Like many other third-party APIs, it’s kind of poorly-documented, but it’s small enough that I was able to wrap my head around it without too much difficulty. Still a long ways to go before it goes live… If I recall correctly, I spent about a month and a half coding the original SigFeeder, and that was when I didn’t have anything resembling a full-time job.

Pathologic Beta 12

I released a new version of Pathologic today, to squash a bug. I even managed to get the correct files uploaded to CVS on the first try this time. Go me!

Project X

I have another project I’m working on, but since I’m contributing to it anonymously, I don’t want to link it with my real name; at least, not yet. Let’s just say that it has to do with using Drupal as a wiki. There’s various modules to help with this, but I’m not satisfied with a lot of them - I might end up reinventing more wheels than I really should.