A few weeks from now I’ll throw the switch and redirect Cryptosmith web traffic to its new home.

For now, cryptosmith.com still goes to the old site, though popular content and the RSS feed go to the new site at b.cryptosmith.com.

It’s ironic that I’m moving to WordPress. My first site with a modern content management system was a self-hosted WordPress site several years ago. I migrated to Drupal a year or two later. I’ve had a terrific time with Drupal as a plaything, but I’m tired of maintaining it. My son Alex did web software for a few years and tried hard to move me back to WordPress.

I’m leaving Drupal because I’m tired of patches and upgrades. Drupal core revisions are especially painful: you must do it all by hand. You delete all the old files by name. You check to be sure you don’t accidentally wipe out configuration files. Then you copy the new files in. There may be a more automated way of doing it, but it requires more tools, tech, and training than I’m willing to invest.

I’m moving my site to WordPress.com, where they maintain the server software for me. I tried to find a similar Drupal site, but they were all too expensive.

The last straw fell last month. I spent the summer revising my textbook and traveling. Meanwhile Drupal went through two or three core revisions (I lost count). I spent a day in September installing revisions.

I spent a few days searching for cost-effective hosting that would let me import my existing Drupal site content. Nothing was available. The best price was Drupal Gardens, which apparently doesn’t support site import.

I decided there were more benefits to going with the 800-pound gorilla of blog hosting – WordPress.com – than there were to staying with Drupal. Moreover, WordPress offers a lot of premium features at a relatively low cost. I can produce a nice, customized web site without having to personally keep the underlying software up to date.

I received another push last week when Drupal announced a really serious security flaw. Attackers could, in theory, use the flaw to read and write the site’s SQL database without logging in. The flaw allows an SQL injection attack. Ironically, the buggy code is in the software intended to prevent such injection attacks on other code.

Why did I bother with Drupal?

Drupal is a hacker’s delight – using the old sense of the word. Drupal lets you do amazing things. It’s essentially a graphical interface to a web-friendly SQL database. I’ve always believed:

All of the really tough problems in computing are database problems.

Drupal applies this to web site design and construction. A few really specific things caught my attention:

• Sites targeted for a lot of attacks use Drupal – notably whitehouse.gov.
• Drupal supports hierarchical “books” as a way to post and structure the blog’s articles. WordPress.com now supports this for “pages” though they don’t support it as well.
• There appeared to be a “core” versus “add-on” architecture. In theory this makes it more stable as it expands. In practices this isn’t as well architected as I would like.
• There was native support for emerging semantic web formats like the Resource Description Format (RDF) that, again in theory, should have made the content more accessible. In practice I got not benefit out of this.

I invested the time and energy needed to learn how to do Drupal coding. I wrote a simple Drupal plugin module and got it to work. I customized some page CSS. I created a custom “Glossary” node type and used it to store my cyber security glossary. I also used the idiosyncratic “Views” module to create a flexible glossary display.