Stephen Downes

It was at 11:30 this morning I decided it wasn't going to work.

I got into the office a bit late today because I had to sign some papers related to my new gas furnace. First thing, I went to Google looking for information on how to install new modules in Drupal 5.0.

It's very simple. Modules have a name, say, 'foo'. There is a .module file associated with that module, 'foo.module'. There can be (but doesn't have to be) a directory with that same name, 'drupal/modules/foo'. Drupal, when it lists the modules that can be installed, checks the 'modules' directory and any subdirectories for a file called '.module'. That's it.

So why wasn't this working on my website? Why were new modules, uploaded and very carefully checked for permissions and all that, simply not found? I have no idea. The core modules were loaded OK because they are all listed in the 'modules' table in the database, no problem.

Once I was comfortable I fully understood the module loading, installation and initiation process, I was also comfortable in saying, my installation of Drupal 5.0 is borked. Which left me two choices: I could either delve into the code that loads the list of modules for admin/modules and try to fix the bug, or I could give up on Drupal 5.0 and try to use an earlier version.

And that's when I decided 5.0 wouldn't work. I poked around in the code for a while, looking for exactly where the script scans the directory structure looking for .module files, but I couldn't fine it. I did find this very nice way to navigate the Drupal fuctions, which helped a lot (I have linked to the source for index.php, and you can pretend your a computer and navigate all the functions yourself), but I wasn't really prepared to root around looking for it (and you have to root around, PHP allows variables to be valled as functions, something that makes coding more flexible but is just miserable to debug, at least to me).

But more to the point: it was very possible that Drupal couldn't find the list of modules because the current version of PHP didn't support it. Drupal might be trying to do some sort of crazy strsub on the directory names, for example. Who knows? So I decided to try Drupal 4.7 because that would also tell me whether it was a PHP problem, as opposed to a Drupal problem (verdict: it's a Drupal problem; Drupal 4.7 read the directories just fine).

So I installed Drupal 4.7. It took me about 10 minutes. Here's what I did:

- Deleted database 'downes', then recreated a new and empty database called 'downes' and gave my user access to it, just like before

- Downloaded the Drupal 4.7 package to my home machine and uploaded it to my website using gftp

- Opened a console window, used SSH to access my website, then used 'cd' to navigate to the 'www' directory

- removed the previous installation of Drupal using the command 'rm -r drupal' (note: be extremely careful using 'rm -r' because it wipes out directories recursively)

- then I executed the command 'tar xzf drupal-7.7.tar.gz'

- Executed 'mv drupal-7.7.tar.gz drupal' to move my software into a nice clean drupal directory

- removed my symbolic link from fallacies.ca to the drupal directory, then recreated it by typing 'ln -s drupal fallacies.ca'

- used gftp to download /drupal/sites/default/settings.php to my desktop, used gedit to change the username, password and database name for access to the database, save it, then uploaded it back to the computer

- created the new Drupal database structure by typing: mysql -u username -p databasename foaf module to my desktop, then uploaded foaf.module into the 'modules' directory. Now for the test: I navigated to admin/modules and... yes, there it was. I selected 'enable' and updated the page, and the new module loaded just fine.

Good. Then I decided to try the flexinode module. Same process, only the flexinode module got its own directory. With all the files loaded, I went to admin/modules again, and... there it was. I enabled it and then gave it a test run.

The idea of something like flexinode is that you define a new data type and then assign to it the fields you want for that data type. So I went to 'content types' and defined a new data type, 'Post', and then gave it fields for 'url', 'description', 'author' and 'publisher'.

Once done, I went to 'Add Content' and saw my new content type there. Great! But when I opened up the form to create some content, it was mangled. I had to play with the content types editor several times, but the form never did display. Ah, whatever, I could always define a new form.

Once I have created a test entry, I went into phpMyAdmin (which really lurches and complains on this installation of PHP - either this installation is really bad or (more likely) phpMyAdmin has overreached and now demands as 'required' PHP functions that are very optional and not typicall installed). I needed to see what a 'post' record looked like in the database before I could consider porting the data over.

I was disappointed. It was a very ugly hack. It was sort of like microformats, done badly. All the different fields were placed into the 'body' field, and the script used 'div' tags to delineate them. Well, OK, but the classes used to name the 'div' tags were not descriptive at all - they were 'flexinode.1', 'flexinode.2', and so on. So. basically, the flexinode script did the minimum to put the data in there, but that was it. Even worse, the names of the fields actually were in the data, delineated with tags, so they showed up when the record was displayed.

Well, by now it was noon, and I decided I needed a bit of a break. As I walked down to the Tim Horton's I thought about it.

Yes, I suppose I could repair flexinode, I thought. This is at least open source software, so if something doesn't work for me, I can always fix it. That is a reason why I chose a PHP content management system; it would be the most accessible type for me to do just that.

But as I walked back from the Tim's I realized it was a lot more than that. It's not just that I have my own data types in Drupal. No, more importantly, I have associated data types. That is, for example, I have a big long list of publishers. So when I create a new post, and add the name of the publisher to the record, this addition is associated with the publisher I have in the publisher list.

Just camming microformats into a 'body' element wasn't going to replace that. So as I returned to the office I was thinking (with some irony) how the old familiar problems were facing me again with this new software, and (somewhat morosely) that my existing software was better than Drupal, enough so that I would need to stay with my system rather than switch.

I sat down to read the email that had come in over lunch. And there, by itself, was a comment on Part Seven of this series, from an anonymous contributor: "I believe the CCK module was intended to replace flexinode - views module should also be relevant."

Oh.

Well.

I hadn't considered that there would be another module that might do what I wanted.

I navigated over to the CCK module (now there's an intuitive name for you - it stands for ' Content Construction Kit') and had a look. Yes, opaquely but undeniably there was this: "computed field: lets you add a PHP-driven "computed field" to CCK node types." Perfect. Just what I wanted.

I downloaded the CCK module and (included with it) the various data types sub-modules, and uploaded them all into the 'module/cck' directory. Then into 'admin/modules' I went and enabled them all. Then I went to 'admin/node/types' (Content types) and created one type, 'Publisher', and another type, 'Post'. I created an entry for 'Publisher' and then, when I went to create the Post, I found I could select from the list of publishers. Yes, the data was associated, just as I had hoped!

Some issues. I'm not sure yet how the 'widget' that allows for the selection to be made works. This is a concern, because my list of publishers is pretty long, which means that it will take a long time to load if it has to load anew each time. Moreover, there is also an 'autocomplete' version of the same feature, but this simply did not work at all; probably a compatibility issue with the Javascript and Firefox 2.0 on Linus.

But these are quibbles. I went to test my submitted data and it worked perfectly. You can see my publisher here. Now if you go over to my test post here, you will see, embedded in the display, a link to the publisher you just saw. Now I still want to fix up the display (which is why my anonymous poster would have mentioned the 'view' module). And at some point I am also going to want to change the URL from something like 'http://fallacies.ca/?q=node/3' to something like 'http://fallacies.ca/publisher/3' or at the very least, 'http://fallacies.ca/node/3'. One thing at a time, though.

So now it's 2:30. 30 minutes to try out the stuff I've just described, an hour to type up this installment. I have to see the doctor this afternoon so today is a short day. But thanks to a short note given to me on my blog, a good one. Things should start moving very quickly now, I hope.