Andy Chase

Last night I decided to get more familiar with CCK and Views integration by way of rebuilding the Chords module, which is functional in its current state but doesn’t do much.

So, I’ve begun work on Chords 2 for Drupal 6. Major architectural changes:

• The original module has been split into two:
  • The Chords API module provides basic functionality around calculating and rendering chords (and keeps the original module namespace)
  • The Chords UI module contains the simple chord builder tool from the original module.
  • New modules are on the way:
  • A Chords Field module will provide a new CCK Chord field and some useful formatters
  • A Chords Views module may provide Views 2 integration, if Chords Field doesn’t cover it.

I know better than to state a timetable, as these things have a way of languishing when other shiny objects catch my interest. However, if you’re interested in playing with the latest and greatest code, check out the CVS HEAD.

Back from the dead, I finally found an archive of the ColorChip library I wrote 7 years ago. Currently PHP4-only (the class has a method called ‘clone’, which is a reserved keyword in PHP5) but I plan to fix that pretty quickly. In the meantime, I’ve hosted the project code on Google. You can grab the latest release from the project homepage at:

http://code.google.com/p/colorchip/

Released under the GPL license.

I’m working with some old code that needs to run PHP4… on my desktop machine I was able to throw it into MAMP and just check the PHP4 option, but our dev environment on Dreamhost is PHP5-only… that is to say, you don’t get to choose PHP4 or PHP5 when setting up a new host.

However, the DreamHost wiki has a pretty slick shell script that will download & compile PHP4 as a CGI executable… and with a little tweaking to some of the install paths there’s no reason this shouldn’t work for pretty much any environment:

http://wiki.dreamhost.com/Installing_PHP4

The Drupal Form API is a wonderful thing… once you’ve been using it long enough, it’s easy to forget all of the laborious validation and post-submit processing you used to do by hand for each and every HTML form in your solution.

The FAPI does things its own way, though, and if you’re building especially complex forms that involve multiple steps or dynamically generated options, you may encounter the following error upon submitting your form:

read more

When it comes to programming problem-solving, I usually do pretty well thanks to the internet; you can find an explanation and/or example of darn near anything if you choose your search terms carefully.

That’s usually all I need; it might take me a while to absorb whatever new technique or classes/functions I’m using, but the path is usually clear.

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.

When digging around for Drupal Forms API examples make sure you know which version of Drupal the examples you find are for; the differences between 4.x and 5.x are just subtle enough so as to be terribly confusing.

Finally, I found this discussion thread. For a clear, functional example see the second comment down by pwolanin, “Wrong code above, and 2nd point: form_id”. The code works, and the explanation of how the form_id is named is tremendously helpful:

http://drupal.org/node/119117

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.

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.