I encountered a thread on LinkedIn today that referenced this infographic comparing WordPress, Drupal and Joomla! and found several pieces of data in the graphic to be intriguing and a couple downright surprising.
- Joomla! has overtaken Drupal in a number of statistical categories indicating popularity.
- Drupal is at least twice as expensive to set up and customize as either of its rivals.
- Average monthly maintenance costs for Drupal are 3-6 times that of the other tools.
- Both WordPress and Drupal are updated more often than Drupal but not at dissimilar rates between them.
- Joomla! has gone through six major revisions in its eight years compared to seven for Drupal in 12 years and only three for WordPress in 10 years.
- Drupal and Joomla draw nearly the same number of visitors to their main sites each month, just under 30,000. WordPress? 50 million!
- Joomla! is in use on almost twice as many sites in the top million sites as Drupal, but both are under 3% compared to WordPress’ 14.3%.
Progress Report #1
I started out quite hopeful about using Pagelines for my WP development framework/platform. After spending two hours in preliminary assessment, I’ve been forced to take it off my list because it:
- seems overpriced compared to other solutions
- suffers from outdated and poor documentation as far as I can tell (complaints in their user forums and my own conclusion)
- has a Web site with at least one very significant broken link which makes it quite difficult to explore it in any depth
All of these may be erroneous conclusions and certainly most of them can be fixed easily. But in a situation where I’m evaluating several alternatives and don’t have time to test all of them in depth, I have to screen out unpromising candidates early.
I’m still waiting for a demo site to be set up for me on Ultimatum (without which I cannot really include it in my second round either), so I’m moving away from the drag-and-drop approach to the minimalist starter theme / lightweight framework category where Bones has an early lead just because of recommendations from colleagues.
My post about my new adventure in exploring how best to tackle WordPress site development (vs. blog work) has sparked a very interesting and informative discussion on LinkedIn. The richness of the responses and the care participants give to their thoughts are the main reasons I’ve long preferred LinkedIn to Facebook or any other social network when it comes to having a real discussion.
During the past couple of weeks, I’ve been reassessing my commitment to WordPress as my main site-building platform and seriously considering returning to my roots as a Dreamweaver user. In the process, and after consulting with one of the most intense WP developers I know, I’ve discovered that the problem doesn’t lie with WordPress but with my inefficient and perhaps wrong-headed tool selection and usage.
As a result, I’m recommitted to WordPress but I’m completely altering my workflow and methodology. I’m writing this long post in the hopes that some other developer may run across it and save a lot of frustration, anxiety and agonizing effort that comes from not stopping to re-think the best ways to approach WordPress development tasks.
As a quick summary, I was having a number of issues dealing with WordPress and its associated themes that, on analysis, turned out to boil down to a few categories of problems:
- I was constantly frustrated trying to identify which specific CSS object or element to tweak when I wanted to make a change to a Theme’s defaults. I am comfortable enough with CSS that I can almost always make the change when I spot its position, but styles.css and other theme-supporting stylesheets refused to yield their secrets to me all too often. I’d spend valuable time trying to figure out what the Theme developer named the heading in that widget or div so that I could adjust its vertical spacing or change its font.
- Trying to avoid problems of file synchronization while maintaining URL sanity, I tended to do all my development work right in the WordPress Dashboard environment, augmented by a few plugins. As I learned the hard way, the built-in editor sucks. And the inability to do multi-file searches meant that, once again, I spent a lot of valuable time figuring out where and in which file a specific change needed to be made.
- I’d spend hours finding a theme that looked as close as I could come to the design I had in mind only to discover that the way the design was achieved was awkward (at least to my mind) and difficult to decode. So I’d have to disassemble the Theme and put it back together again, negating the value of the theme in the first place.
There were at least a dozen other, lesser issues, but the more I studied the problem, the clearer it became that these were the core concerns I had developed over three years of working with WordPress.
I won’t bore you with all of the perfectly understandable reasons I had these issues; that’s not relevant to this discussion.
Read more →
Last week, I entered a drawing held by DesignHash, a great Web design site where professionals display their wares. I ended up winning! My prize? A developer subscription to ElegantThemes, where there are 80+ WordPress themes and some awfully nifty-sounding plugins.
I don’t know how many winners they drew (nor do I care). I just like winning. This is actually only the third thing I’ve won online in the 18 years I’ve been doing Web design and development. So that’s exciting in and of itself.
But this drawing also shows the power of having such events to build traffic and awareness. I’ve told a half-dozen of my artistically inclined graphic designers and artists about DesignHash and at least four of them were impressed enough to investigate.
Meanwhile, I have access to some very nice professionally designed WP Themes. And did I mention their plugins? Sexy!