All in with WordPress

About a year ago, I described a massive relaunch of all my personal web projects from a custom solution to WordPress and Drupal. At the time, I said Drupal code had better readability than WordPress, and I also said Drupal’s strict naming conventions in the global namespace emulated object-oriented programming.

Today, Drupal is no longer part of my stack.

I moved all my blogs over to WordPress back in November. Part of it is professional need — my office is migrating a particular Drupal site to WordPress, and I wanted to get a feel for how such a migration would happen. Mostly, I just prefer the user interface of WordPress over Drupal.

I’ve also created custom plugins for both systems, and while the “Drupal way” has far more structure, the WordPress system of hooks is incredibly versatile. It took less time to create a connector plugin to the Musicwhore.org artist database in WordPress than it did to create a similar connector in Drupal for my record label Observant Records.

Drupal loves abstractions and does everything it can to shield developers from its inner workings. That can really get in the way if something goes wrong far below the surface of the abstractions. It also makes its database schema probably more complex than it should be.

WordPress, by contrast, has a surprisingly compact database schema. So compact, in fact, that the opposite problem occurs — database tables doing multiple duties. In some instances, WordPress code is too tightly coupled to its database.

Neither Drupal nor WordPress has a particular good template system, but I found WordPress to be slightly more readable than Drupal. Or maybe the widget system in WordPress has a better user interface than the block system in Drupal. Conceptually, they operate very similarly.

As a result of all this work, I find myself getting drawn deeper into the WordPress platform. Am I slowly becoming a specialist in one application instead of being a general PHP developer? And should I be reluctant to adopt such a role?