Andy Chase

I’ve been tinkering with Drupal 5.1 in one capacity or another for the last 2 or 3 months, but by and large it’s been from an on-and-off, complete-newbie perspective; install some modules, click around, add some lorem ipsum content, and wonder if you did it right.

I have spent some time learning about module development, but not knowing enough about the “right” way to do things, even the successes I’ve had there feel like a bit of a question mark.

I’ve finally started getting my hands dirty with Drupal over the last couple of weeks, going through the process of actually building a site versus adding a couple of pages and menu links here and there to see how it works, and now poking around under the hood to learn how to extend it.

Adding a bunch of pages in a row using the standard interface is usually a pain in any CMS, and Drupal is no exception: Click to expand all of the option fields, click through another screen to attach the new page to a menu, try and remember the weight of the last item you added, repeat.

Half the problem when trying to learn a new language or platform on your own is finding a practical application for it. You never get very far with “Hello, World”.

I’m really surprised there are no Drupal modules out there facilitating the import of existing content and/or menu structures. At least, none that I have been able to find other than the excellent WordPress Migration Utility . I used that to move the last 5 1/2 years’ worth of blog entries over to Drupal.

So, there’s my first practical application: a module that imports either a page hierarchy, creating a menu and stub Page nodes, or possibly even importing actual content.

I’m not sure what the import format will be. The smart way to develop this would be to make the import tool pluggable, so other people could write drivers to import whatever format they need. I think that’s overly ambitious for the first version of this plugin, but I’m beginning to get a sense of how that could be accomplished without too much trouble in Drupal.

31 January, 2009 It took me a while, but I did ultimately build just such a module. It’s in the Drupal contributions repository, and it’s called Bones.

I like the automated aspect of the Textpattern comments form, except for how darn big the Message textarea is. Unfortunately, this is not something that can be remedied via CSS, since the form size is specified in the style attribute of the textarea itself, which trumps any styles declared further up the food chain. It is easy enough to fix, however.

Hack that Form

Open up textile/publish/comment.php in your Textpattern installation directory, and head for line 183, which should look like

It’s like a bad hangover, adopting that white-text-on-black-background, transparent-spacer-pixel, tables-within-tables approach to design; you wake up the next morning knowing that you overdid it, but you have to deal with the headache and nausea for the rest of the day. In the case of HTML 4 abuse, you have to deal with it for the next four years.In the inaugural post of his newly-redesigned web site, Jason Kottke uses a phrase that resonated quite strongly with me the moment I read it: “The ghost of Siegel,” as in

“Most pages on the site are valid XHTML 1.0 Transitional. CSS for layout. The ghost of Siegel has been exorcised. The cobbler’s children have shoes at last.”

Those of you who have been tinkering with this HTML stuff since the mid-nineties will probably remember David Siegel from the book that launched a thousand splash pages, Creating Killer Websites.

I confess, I was seduced by the “Killer Sites” mentality when I was teaching myself this stuff in my spare time, hoping to get a real internet job back in 1997.

Splash Pages are Dumb. This was my home page?

It’s like a bad hangover, adopting that white-text-on-black-background, transparent-spacer-pixel, tables-within-tables approach to design; you wake up the next morning knowing that you overdid it, but you have to deal with the headache and nausea for the rest of the day. In the case of HTML 4 abuse, you have to deal with it for the next four years.

I began using CSS fairly heavily during my tenure at Stan Lee Media four years ago, about the same time I began using PHP… that’s probably not a coincidence. When you start writing scripts to generate things on the fly, you quickly learn how magical it is to wrap a form label in <span>, give the span a “formlabel” class, and have done with it… no more finding and replacing all the <font color="#CCCCCC" size="3"> with <font color="#C0C0C0" size="2"> across 57 different files, some of which have the "color" and "font" attributes transposed so that you have to fix those by hand.

But when you’re still locked in the mindset that every element of your page design must render exactly the same down to the tolerance of a single pixel in every browser on every platform back to Netscape 4 in 256 color mode, you’re going to find yourself fighting CSS and trying to subvert it into a print formatting tool the same way you did HTML 4.

The problem with writing code for a living, be it HTML, PHP, or Java, is that you never really get to point at a thing you’ve made and say, “There. That one is done, and whatever happens to it now is out of my hands.” No matter how badly you want to wash your hands of it (Or tell the creative director to go to hell) It’s too easy to open up the editor, fix a typo, and upload the new version of the page. Lather, Rinse, repeat… it never ends.

That leads to the endless start-and-abandon cycle that I’ve been doing for 8 years. Start something new, learn a bunch of stuff, pause and notice all the dumb stuff I did that would be a big pain in the ass to fix, scrap everything and start from the ground up, and throw in a link back to the old stuff. (Learn a bunch of new stuff, pause and notice all the dumb stuff I did… and so on.)

Content management tools like Movable Type go a long way towards making sweeping site-wide changes a matter of hours rather than a matter of days or weeks, but there’s still the problem of what to do with all my old stuff, random pages, photographs, or gizmos that I’ve put together over the years that aren’t necessarily blog entries or even stand-alone pages. What about my portfolio site? Suppose I manage to comb through my archives back to 1996, and somehow put all of the stuff I want to keep under the control of some magical CMS… there are still all of those grotty old sliced images and <font> tags that need to be fixed and brought into the 21st century.

It’s no small task, which is why even this half-assed XHTML/CSS template set still isn’t finished after its first six months in existence. I have plenty of ideas of things I could do to improve the site here and there, but I just haven’t had the heart to sit down and do an honest-to-goodness white board session with myself over the design and organization of all these ones and zeros I’ve generated over the years.

I just added about 70 photos to the site. These were all available on the site I began in September of 2001, and sort of disappeared sometime during the spring of 2002.

The earliest photo at the time of this writing was taken on 9/26/1999, an astonishing 4.25 years ago.

Having added the photos to Movable Type using the dates upon which they were taken, the archives now go all the way back to 9/1999, which is somewhat mind-blowing to me.

When I started spending the occasional Saturday or Sunday driving around Los Angeles and taking photos, I had vague aspirations of creating a site like the excellent Roadside Peek, but again and again the prospect of managing such a site statically was just too much of a downer for me to ever make a serious effort. By late 1999 I had come to the conclusion that managing content-oriented websites with static HTML pages was a losing proposition, but lacking PHP and database knowledge at the time I didn't know what to do about it.

So the photos accumulated... first on Zip disks and then on CD-ROMs. Some of the backlog made it onto my 2001 web site, but many, many more photos remain scattered across those old CD's.

Enter iPhoto - A great tool for organizing groups of photos, and Movable Type - a great tool for putting content online. Connectivity between the two is still lacking, but I feel like a solution is in sight, and it will probably involve some combination of AppleScript, ImageMagick and PHP. My holy grail is to manage photographs in iPhoto - import them, label them, add comments, and then run an automated process to take that information from iPhoto, resize the photos for web use, build Movable Type Entry and Excerpt HTML, and push it all to the webserver.

Eric Sigler's jaw-dropping iPhoto2Weblog plugin comes so close, but the current release doesn't quite give me the flexibility I want.

Nevertheless, this is exciting stuff that I couldn't have imagined getting my hands on when I got my Olympus digicam back in 1999. Who knows what this site will look like by the end of 2004?

I recall that posting photos was the perfect activity for when I didn't feel like writing, but wanted to add something to the site... so there's no reason I shouldn't get back into that habit as well.One thing that still bugs me about Movable Type, and Blog-related, web-based CMS in general, is the lack of good, native support for photo management.

Back when I started this site, my intention (aside from trying to keep up daily entries and seeing how much traffic I can generate) was to build out a personal blog system that would give people a simpler alternative to Slash or PhpNuke.

Well, at the end of this month it'll be three months since I started the site. I've done a lot of tinkering, but I have to confess I haven't kept other hypothetical blog administrators in mind. I'm guilty of a couple of kluges here and there, and documentation is poor at best.

An e-mail from a friend yesterday got me thinking about cleaning this thing up for public consumption once I get around to finishing the photo thumbnail indices. For one thing, I had an OOP epiphany a couple of weeks ago - I've been using PHP classes for some time now, and I've written a few of my own, but I was still thinking of them in terms of clumps of functions (which they are) as opposed to properties and methods of an "object".

I've been struggling with the whole "object" thing since I picked up a "Teach Yourself Java in 21 Days" book about 5 years ago, when the most recent language I had programmed in was C64 Basic. I read the examples and understood them on a basic level, but it wasn't until this year with PHP that I stopped wondering "Why would I want to write a program to turn a motorcycle on and off?" Such is the life of a self-taught programmer.

Even after that, the classes I wrote myself weren't really very useful in OOP terms; object methods would depend on global variables rather than object states, or they would be so specific as to limit the class' usefulness in future projects.

But, I think I get it now, and I should probably go back over the scripts that make up this page and see if I can't simplify things a bit with a nice blog class.

The other thing I've been kicking ass with lately is authoring in DocBook, which you may recognize from HowTos of the Linux Documentation Project. DocBook itself is a piece of cake to learn, actually; Norm Walsh's O'Reilly book on the subject (including complete tag reference) is freely available in its entirety online, and if you learned to code HTML by hand, jumping into a text editor and using the DocBook XML spec is no big deal.

Where things get hairy is when you go to set up a processing environment to transform DocBook into HTML, LaTeX, RTF, or whatever. I wound up using Jade, and it took me the better part of a day to get Jade, the DocBook DTD, and the DocBook DSSSL stylesheets to play nicely together... and I still don't fully understand what's going on. But I do love that whole XML separation of content from presentation thing.

So, at work I've been writing a new PHP class for some database operations, and doing it properly this time; the class will be easily reusable by future projects, and make code easier to follow. At the same time, I've been documenting the class in DocBook as I go. So far this seems to be a much better methodology than trying to pound out documentation after the script itself is finished. When the next big project is looming around the corner, documentation tends to get the short end of the stick. By documenting as I go I can be a little more thorough, and sometimes the act of thinking a function through will help me see a better way it can be implemented.

Anyway, I'm thinking maybe I should take a similar approach to this blog system... put commonly performed tasks into a properly formed class, and document it so that people can use the API (wow, am I actually talking about designing an API?) to easily extend its capabilities if they want to. And of course release it to the public.

Should be interesting.

When I started monkeying around with category indices last night, I didn't fully realize what I was getting into.When I started monkeying around with category indices last night, I didn't fully realize what I was getting into; to date I had the site set up under the assumption that I'd only be making one post per day, regardless of category.

By indexing everything by category and date I can't realistically continue to structure the site using paths like /blog/year/month/day/index.html; in my need to play catchup with blog entries since last Thursday I'm going to have a couple of overlapping posts on the same dates but in different categories.

It's not a big deal to move to something like /categories/category/blogtitle.html, but it's a pain in the ass now that Google has crawled the old indexes for September, October, and November. I suppose I can keep those around and add a META robots tag telling Googlebot not to index or follow those pages any more. Eventually I'll have the server throw a 401 error and redirect hits to those pages somewhere useful. I'll probably maintain the /blog/year/month/index.html monthly indexes, but break the up the listings for each month by category then descending date.

Then there's the added complexity of having the site broken into much more distinct sections; it's now Category > Blog instead of Blog(Category). I'm already doing this to some extent using the categories' description field from the database, but it's still a little bit clunky.

Plus I want to clean up the icons a tiny bit now that I see them all side by side.

I can't be the only person out there who just wants a single-user blog that they can host on their own boxen without wading through all the extra features that come with the portal-style systems.I'm hardly an authority on Weblogs, seeing as I seem to abandon every single one I try to set up or maintain after about 5 entries, but I think that's largely because I haven't been happy with any of the ones available at Sourceforge and other free software sites; systems like Slash and its PHP equivalent PHPNuke are fantastic, but way, way more than I need to run my pissant little waste of bandwidth. I don't need polls, or Slashboxes, or a message board, or 8 dozen pre-defined topics that I'll never use, or the bad, bloated HTML that always winds up in the predefined theme templates. Sure, they're heavily customizable, but to effectively design your own theme you have to learn a whole new API and chances are you'll have to use nasty, crufty HTML to make everything look right and align properly. For that matter, I don't need an extensive user registration or comment moderation system. If (God forbid) I should ever find myself getting enough traffic to warrant a comments and moderation system, I'd just as soon build it myself.

So it comes down to this: It's time to roll my own. I've made abortive attempts at this before, full of convoluted, poorly commented code that I can't even figure out myself six months later, but this time I'd like to approach it as a project that might be of use to somebody else... I can't be the only person out there who just wants a single-user blog that they can host on their own boxen without wading through all the extra features that come with the portal-style systems. It will need to be well-written, easily customizable, and extensible. It will defintely be written in PHP, and it will probably use MySQL for its database, as much as I'd like to use PostgreSQL. (mmmmmm, foreign keys.) Lots more people use MySQL, at least at the time of this writing.

I've learned quite a lot about programming style and programming in general since I started tinkering with PHP at Stan Lee Media, and I've used one hell of a lot of free (as in speech) software in the process. The nagging voice in the back of my mind that tells me I should give something back has been growing steadily, and since I haven't really learned C yet it looks like PHP will be the way I can do it.