David's Tech Blog

On the old version of my site I had a page about a module I wrote for Drupal 4.7 that added a filter using the PEAR Text_Wiki package. At the time I wrote it, there were no other good options for wiki markup in Drupal filters. I used the module on several sites, but I didn’t release it on drupal.org because I didn’t intend to maintain or support it over the longer term.

Since then, other people have created modules to provide wiki markup and other wiki-like functionality to Drupal. There’s a PEAR Wiki Filter module, which does basically what my module did except is maintained and has versions for Drupal 5 and 6. There’s also the new Flexifilter, which looks very promising but doesn’t have a “stable” release yet. And of course the Wikitools module goes a long way toward integrating wiki-like functionality into Drupal well beyond just markup.

I’m not sure if I was picking a product specifically for wiki that I would choose Drupal. Drupal is an excellent CMS and community collaboration tool. However, wikis are really their own thing, and there is quite a bit that wiki software does normally that has to be pieced together back into Drupal, making it work differently than it really is designed to work. I think that Drupal is the leader in what it is good at. That doesn’t make it the solution for everything.

On the other hand, if you need to use Drupal for some other reason, or if you have a Drupal site that needs some wiki functionality, take a look at the modules I mentioned. I think they will do the job better than resurrecting my old module.

I have quite a bit of experience using Drupal, at this point more than with any other CMS platform. In the past I’ve run a variety of others, but by a good margin most of my development on these types of things has been on Drupal. I’ve written several modules for Drupal 4.7 and 5.  Of course, I’ve also developed a number of apps and sites that were built from scratch, or on my own code base, or on miscellaneous other products that someone else implemented and then I got to fix, but those are a different issue altogether.

I have been facing the release of Drupal 6 with some trepidation. I have a number of deployed Drupal 5 modules out there (I think all of the 4.7 sites that use my modules have been updated by now), and the job of updating the modules is daunting. There needs to be a pretty compelling reason, I think, to update them, considering the amount of work that is going to be required.

I should probably say that none of these modules are released publicly. They were all to solve specific business needs, mostly of my primary employer (Food for the Hungry). Updating the modules would mean updating the private sites that use them to Drupal 6 as well.

Now that Drupal 6 has been released, I don’t see any compelling reason to bother. Yes, Drupal 6 has a number of very good improvements. Its a good product, and they are continuing to take it in a very promising direction. But the improvements for an established site don’t rise to any huge reason to spend significant time updating these sites. And it would take quite a bit of effort, since the changes are considerable.

I also considered moving this blog back to Drupal, since that is the software on which I base so much of my ongoing work. There is little chance that my development work will stop emphasizing Drupal. However, Drupal does not do anything like the nice job on basic blogs that WordPress does. I guess that’s partly a difference between a more generalized content system (and for me framework for business process automation oriented modules) and a more specialized blogging package like WordPress. I’m fairly confident I would not try to do the things with WordPress that I can do with Drupal. On the other hand, for a basic blog, WordPress is much nicer.