Its funny that when you look at web developers who work daily with a CMS, unless they are designers they have the worst web pages (mine being a prime example.). When I finish work spending my day working on a website, I rarely feel like blogging or tweaking my website. So I thought about redesigning my website, streamlining my content types, and changing it's focus to a blog. Since most of my friends and family are in the UK, I thought I would also attach the site to a .co,uk domain. This would give me the opportunity to blog about life in the US from the perspective of a "New American" who's still a cockney at heart. As it becomes more fleshed out and copy had been migrated across I would eventually redirect my .com to the site.
I didn't want the new site to become a heavy project, as my spare time is limited, so I gave myself the following criteria.
- Must Have a responsive theme, my prime work environment for writing will be my tablet.
- As much as possible, use a premade theme as the focus is on writing.
- Easy to write workflow from idea to publish.
- Add new features over time as I migrate off the old site.
- Improve the site through "progressive enhancement" rather than have it complete on day 1.
My main requirement was a responsive theme and none of the Drupal "out-of-the-box" themes appealed. The Omega Theme gives me all the flexibility and control I would want, but adds a development element, which I wasn't happy to do at the start of the project. I want to be up and writing as soon as possible, not tweaking an Omega sub-theme weeks into the project.
So I decided to use WordPress and turn the UK site into a straight forward blog with a responsive theme as there is a wealth of great responsive themes out of the box and it's very quick to get up and running. So I installed and configured WordPress and I had my blog up and running in little to no time and was happily writing away. I also downloaded the WordPress Android app to my tablet and I had a nice writing workflow in place—so far so good.
My Thoughts on WordPress
It has been a while since I used Wordpress and it has always impressed me with the attention to usability of the admin interface. Using progressive disclosure on admin elements to reduce clutter. The admin panel is simple and fulfills the need of a blogger very nicely.
So I am up and running with a simple blog and I knock out a couple of articles. On my first free weekend, I decided to look at building the site up a little, to include an "About" page and a Contact me page. The about page is no problem, but to add the form I need a plugin, so I installed the Contact form plugin and I am up and running quickly enough.
My next change is I wanted to add a simple block on the front page with a short bio and link to the about me page. WordPress widgets make it very easy to add blocks, but very difficult to position them with any form of "context" so a block appears on every page, not just the "frontpage". To get around this I had to install another plugin, so I installed the Widget Logic Plugin which provides a simple context you can apply on each block.
Not bad for my first weekend, I had my objective done and with only a little "Google time" to figure out the Wordpress way of doing things.
From a discussion at work, we talked about a blog post for which books developers use and it got me thinking of adding a new page for book reviews to my site. Simple page with a custom URL, an intro paragraph and then repeating rows with the books themselves. Using very simple markup and as a developer I thought of just knocking out the blog post directly in HTML and CSS, as it should have been simple to do. So I built out a simple structure and started coding away....
Only to discover my markup changed each time I saved my article blowing up the layout of the page. This isn't a bug, it's a feature of WordPress as it's primarily designed for people who don't know markup and want a simple page, so markup is handled and interpreted by WordPress each time you write a post. If your focus is just to write a post, this is a handy feature. If you want to do anything outside of writing with a page, you'll run into difficulty. It's a known problem and there are a number of plugins that will give you the ability to remove this feature and render your markup as you write it. However, as this was my first post with custom markup, these plugins fixed this one page, but then broke all my previous articles. To translate this issue into Drupal terms, we have the choice of an input filter when we write content, with WordPress the choice is made for you.
This problem set me back hours writing a page that would take me minutes in plain html or in Drupal. I was starting to become frustrated with WordPress as each problem required research and most of the time a 3rd party plugin to resolve the issue. I will be the first to admit that the problem is one of comfort level with the tools and my knowledge of the package. I know more about Drupal than I do about WordPress. But I did notice a trend that most problems with the core package, required external plugins to fix. From my own experience, I could have resolved all of these pain points from the start if I was using Drupal with features available in the core distribution.
By the next weekend, I had come to a decision, I am not a typical blogger and thinking I can ignore some of these tweaks will slowly drive me insane over time, (most developers and designers I know have their fair share of OCD traits). So I decided to go back to what I was familiar with - Drupal.
At this point my site was laid out and had some initial content, migration would be easy. My About page and contact form were straight forward by enabling the contact form in core. Adding the block to the front page is as easy as adding a filter condition to only show on the "front" page. The issue with rewriting my markup isn't an issue on Drupal as I can change my input format per post, so having a page with more involved layout wasn't a problem. As I started to markup the page, I thought this would be something I would probably build upon, so i decided to install Views and create a new content type called "Book Review" and using 3 lines of CSS and Rewriting field output in the "view", I had a nice page in place for my book reviews along with a pager for when the page gets past 10 books. The best part of this approach was that once the view was in place, adding the books was a snap.
The entire process of converting my site from WordPress to a point where I could release it as a Drupal site was a single afternoon.
I am very impressed with WordPress and if you're a blogger I think it's an excellent platform. I was up and running very quickly and very pleased with my initial website. The areas I ran into problems came about when I wanted to stray from the purpose WordPress was designed for and although they were easily resolved in WordPress it required a 3rd party plugin or resorting to coding. Considering this is how I spend my day, I didn't want to do the same in order to put up a website that does what I want it to do without resorting to extensive reading online and possible coding to replicate a feature available in Drupal core (Although I have seen this same argument leveled against Drupal).
The other thing I should mention is, I am very comfortable with Drupal so I know (most of the time) the answer to any problems I encounter when putting a page together. My lack of expertise in WordPress means I would be slower to find a solution as I would have to research the issues. My decision to move back to Drupal was after I noticed a trend that the answer to most problems was either a plugin or custom code in WordPress, which isn't one of my criteria for this website, the prime focus was writing, not tweaking the code. I could have ignored these issues as WordPress is a great publishing platform and built for this purpose, but the pages wouldn't be the way I want them and that compromise would drive me mad over time (see previous comments about OCD and web developers.)
I do miss the Android application for WordPress, it's very polished and was a very handy tool for editing content while away from my laptop and I think documentation is much easier to read in the WordPress codex rather than on it's Drupal equivalent. There's more code examples on the WordPress site, whereas on the Drupal equivalent I see a lot of rehashing of the core functions, rather than see different examples of how they can be used. The documentation is easier to get to grips with if you're new to WordPress.
I have always regarded Drupal as more of a framework whereas WordPress is an application built for a purpose but with the ability to expand through plugins. Drupal has a lot more in core, before we need to resort to 3rd party modules but both systems can be extended through themes and modules.
Overall, I am impressed with WordPress. It fit my initial requirements for a publishing system. However, as my needs grew, I found I was better suited to using Drupal. Both systems have a supportive community and very mature code base, when making a choice as to which package to use, I think it's a question of choosing the right tool for the job. With wordpress while my requirements were light, it was the right tool. The moment I decided to do more work with it, I ran into limitations which eventually lead me back to Drupal.
I think Drupal can learn something from the wordpress development and documentation teams, Drupal's Admin interface in 7 and in the upcoming version 8 have come along way from the dark days of Drupal 6, putting more focus on usability and workflow which makes it a much more pleasurable experience to work with. Documentation is very thorough on drupal.org, but could include more user snippets and examples as in the wordpress codex or even the php.net website. More sample code and less printing of the API function would be handy for new developers coming to Drupal.
So in the end, I am back on Drupal. I think the initial exercise with WordPress was worthwhile as we can learn from other Open Source projects and in return become better developers in the tools we build.
Moving from Wordpress to Drupal
Drupal vs. SharePoint from a Developer's Viewpoint