After 4 hours of trail & error, and consuming lots of support in IRC #wordpress, I was able to set up and bring my new personal blog online on WordPress’ latest stable release 3.0.5!
Dave Reid inspired me to approach this challenge when he mentioned that he’d test several other systems in IRC #drupal-contribute. Not that I didn’t play with the idea already, but Dave’s initiative ultimately pulled the trigger.
What should have been a quick intermezzo turned out to be a quite interesting challenge and adventure. Conclusions I gathered along the way:
Note: Obviously, my review is biased. Most links in this post are pointing to Drupal equivalents of WordPress functionality.
- Drupal’s installer excels WordPress’ installer. Looks like we’ve not only catched up, but also went ahead. However, Drupal’s text formatting, especially of file references and command lines, needs work though.
- WordPress installation ends with 11 tables in the database. Compare that to ~74 (?) of Drupal.
- Had to tweak a couple of mod_security rules in order to log in to WordPress.
- There’s no .htaccess file by default; WordPress only tries to create it when configuring Permalink (URL alias) settings. Of course, that fails. Without my pre-existing knowledge, I wouldn’t have been able to figure out how to make that auto-write work. Aside from that, the interesting part is that WordPress is basically able to generate (and write) customized .htaccess files depending on its configuration.
- After installation of WordPress, there’s demo content (a static page and a [blog] post). I edited the page, deleted the post. I always objected to do the same for Drupal, still not sure whether that is actually useful.
- You end up in WordPress’ admin interface. No idea what the actual site looks like. Minus points on that. And most of you probably know that I’m heavily opposed to front-end/back-end separation in general – Joomla! and WordPress always did this, Drupal didn’t attempt to do it until D7, and I still state that the fundamental idea and direction is utterly wrong for many reasons – which do not fit into this post.
- WordPress’ default theme comes with a range of customizable theme settings, including the background color/image, and an “header image“. But the point it gets really exciting is that you can upload a 2MB+ file for the header image, and it’s not only automatically scaled down to ~940px, but you also get a JS-driven image crop tool right afterwards to select the image part that shall be displayed as header image. The original file is not stored however, so you can’t change your mind without re-uploading – minus points on that — after granting countless of points for the image upload and crop functionality in the first place, of course.
- WordPress truly excels Drupal with its built-in extension browser. Not the browser itself, but merely the fact that you can search themes and plugins from within your site. There are no filtering or sorting options though. Searching for “twitter” yielded a stunning result of 1,200+ plugins. wordpress.org isn’t any better. Over there, plugins can be sorted by relevance, popularity, and user rating. (Note that WordPress has no notion like tablesort built-in, so all you get is a pager.) None of the options improve the results. Asking others in #wordpress for how that amount is useful in any way and how they’re choosing plugins for their sites didn’t result in any better conclusions, other than to refine your search through additional keywords and just trial & error.
- Took me more than one hour to figure out which plugin I should use for the simple Twitter feed widget in the right sidebar. If you ever faced a scenario like this, you will understand my strong opinion and objection with regard to allowing duplicated projects on drupal.org (unless there is a very good reason for the duplication).
- The uploader/installer worked flawlessly, both locally on Windows and remote on Linux (via FTP and SFTP, both built-in).
- WordPress’ admin interface consists of regions and widgets (blocks). A few simple settings pages only consist of plain page content, but most other admin pages entirely consist of blocks instead. You can not only collapse and expand, but also drag and drop all of the blocks on a certain admin page (type) to your personal liking – which includes moving (jQuery UI $.sortable) blocks from one region to another, and all of this sticks. Reminds of Panels, but affects the entire page.
- The admin interface permanently shows a navigation menu in the left sidebar (similar to Admin module), whereas top-level links can be expanded (one level) to see the links below by clicking on special icons. Takes a bit to grasp this. Obviously, the fundamental pattern and idea only works with a very limited set of top-level and sub-level links, so it doesn’t leave much room for modular expansion and isn’t very insightful for new users either (unlike Drupal’s Administration menu module, which – as a matter of fact – was originally derived from Joomla’s administration interface).
- A different color scheme for the admin interface can be applied to every user. Handy, but probably over-sized and too inflexible in the long run.
- Plenty of unexplained options and functionality everywhere in WordPress’ admin interface, without any tooltips or whatsoever. Accessible mode needs to be toggled per page or globally in the user account. Drupal 7 wins on both fronts here. Overall, the user interface and help systems of WordPress and Drupal seem to be on par though.
- Usernames cannot be changed in WordPress. Each user has an additional nickname, which can be changed, as well as a real name. Additionally, each user has a display name, which can be configured individually to be the username, nickname, first name, last name, or full name. The display name is nice, but overall, the username/nickname separation is extremely confusing.
- WordPress comes with a range of convenience content authoring and publishing features built-in:
- A WYSIWYG editor (TinyMCE) with a custom theme and plenty of additional editor plugins — actually, now I finally understand. Apparently, it looks like acquia’s Drupal Gardens merely tries to resemble all of this in Drupal…?
- A combination of Media, Insert, and Inline modules as well as advanced plugins to support extremely rich uploading and inserting of images, videos, audio, and other media via the editor. The entire uploading and management of media happens in jQuery-driven dialogs. Files can be uploaded via swfupload or native browser uploads; you can switch methods in a single click.
- Pathauto, directly shown below the title field, and you can edit the alias while editing in a neat, JS-driven UI. WordPress confronts users with geeky terms like shortlink; i.e., the internal/system path of a content piece.
- Drafts and revisions, a trash bin, publishing status, as well as publishing schedule workflows functionality is built-in. Didn’t see diffs between revisions yet, but might be missing something. (After all the hype and buzz for D7, I actually expected a more awesome user experience in WordPress…)
- WordPress prompts you whether you really want to leave a page (form) after editing. But actually, that’s TinyMCE’s (confusingly named) Autosave extension, not WordPress. Hence, just enable the plugin in Wysiwyg.
- Built-in support for pingbacks and trackbacks, auto-closing comments after a configurable time-frame, comment notifications, only publishing comments of already known (anonymous) authors, automatically unpublishing comments containing more than X links, URL/IP/author/text blacklists automatically unpublishing comments, as well as author pictures via Gravatar.
- Content is created upon editing, not after saving. You have a new content (draft) right after attempting to create a new post, smart! Even more funky, it automatically saves a new revision every couple of seconds. Holy cow.
- WordPress allows you to preview your draft version (new or existing post) in the front-end, by appending a ?preview=1 parameter to the URL. Doesn’t take page additions into account though (such as widgets/blocks; e.g., comments, comment form settings, etc), but regardless of that, it’s very helpful to see a preview of the final result.
- WordPress content supports a notion of Custom Fields, which basically is a key/value store for arbitrary meta data to input per post and simply output in the theme. Drupal obviously beats that with its fieldable content types and entities, allowing you to store data in a more meaningful way.
- Closely listening to #wordpress during this adventure additionally clarified that WordPress’ support for custom content types lives in code only. No UI for that yet; i.e., comparable to Drupal 5.
- Themes are able to plug into the content editing form to allow customization of page/post-specific theme-related settings. Wouldn’t have noticed that if I hadn’t installed the semi-commercial, but featured Platform theme. That’s interesting, because stuff like author information and regions or blocks to show or hide indeed belong to the theme system, and allowing per-page/entity customizations for a particular theme makes sense.
- No idea what “featured” actually means, but seems to be something along the lines of Drupal’s golden contrib idea — definitely useful for newcomers. I already learned that there are gazillions of other themes, but to test-drive, I just simply wanted anything non-default, community-approved, and working. Let’s adopt that for Drupal.
- WordPress has built-in support to submit new posts via XML-RPC and via e-mail; the latter through a full-blown POP3 mailbox e-mail handler, so you can basically post new content from anywhere. Drupal removed the built-in Blog API support from core for D7, and the mailhandler module was never really used outside of drupal.org (and even there only years ago).
- Content supports both Tags and Categories at the same time. No idea what to use. Learned from friends in #drupal that they’ve seen Tags being used more often on up to date WordPress blogs…
- While typing this blog post, some JS in WordPress seriously eats my browser’s performance. :( And yes, a smiley filter is built-in, too… :-/
- Although similar in size of users, the IRC #wordpress channel is much more silent than #drupal. Also, as mentioned before, there are many more questions (stupid, like my own) from users about Which plugin to use for xyz?
- WordPress has extensive and elaborate online docs about individual topics, which explain all details about usage but also implementation. Although Drupal has its API documentation readily available, this level of detail is hard to find in drupal.org handbooks, which is one of the things we want to improve for Drupal 8.
- Had to be reminded by folks in #wordpress that WordPress is not backed by Automattic, but the WordPress community. Only the hosted wordpress.com is commercial. Let’s make sure that this kind of confusion never ever happens with acquia and Drupal.
- Oh, and WordPress has an awesome logo and the logo is provided extremely professionally.
In the end, I can only encourage everyone to attempt this (or a similar) challenge on your own. It really helps to understand differences and similarities in approaches between open source content management systems, and see how others are solving or struggling with the same issues that we also have.
There are a lot of things that we can learn from. Serving both as positive and negative examples. The intention and goal should not be to simply copy features — which unfortunately seems to be the case for many of the new user experience and usability features in Drupal 7, as far as I can see. — Instead, we want to learn about good and bad ideas, patterns, and techniques, and should always discuss the fundamental idea from scratch for Drupal.
This post mainly focused on initial experience and usage. What I’m even more interested in is an in-depth review and analysis of WordPress’ API design, data storage, and code logic, which I might be following up on in a separate post.