Mike asks,
I came across your site as i'm a member of NWEN. My current site is built on a wordpress template and I want to change it as it's pretty rough. What are the pros/cons of having a site built with Drupal vs. word press?
The simple answer is, WordPress is for designers, and Drupal is for engineers. Kind of.
Like any simple answer, that's only part of the story.
WordPress is perhaps THE content management system for web designers. While any content management system forces you into some sort of template design that can be repeated across multiple pages, in WordPress, template design comes first. Your content then gets shown where the designer wants it.
Everything about WordPress is optimized for designers, making it easy to make a site that looks exactly the way they want it. And as a solid blog platform, it's pretty decent at organizing content, too -- stories appear in chronological order out of the gate, monthly archives are built in, there's a category system and a tagging system, and static pages you can use for menu items. If that's all you need, pick Word Press -- you're done.
Even if that's not all you want, if you can find a widget to embed in your page, you're also done. Basically, Word Press is about as easy as it gets to make a web site look the way you want it to look.
Drupal is very, very different.
It's all about the information
In Drupal, instead of being the template/theme that's front and center, it's the information. If you dig into the taxonomy system, you quickly get to information theory and ontology, all sorts of academic structures. The central thing in Drupal is the "node", which is basically an item of content. Everything in Drupal revolves around the node.
The Taxonomy module and add-ons provide a variety of ways to classify nodes, with rigid hierarchies, free-form tags, geographical locations, and more.
The "content construction kit" (CCK) helps you define multiple types of nodes, each with a specific set of additional fields of all kinds -- text, image, video, location, etc.
Views provide a powerful interface for showing a collection of nodes matching any criteria.
Rules provides an administrative interface for making certain things happen to nodes (or data in nodes) in response to a variety of events.
Access modules define which users can create, read or update which nodes.
Workflow turns nodes into a state machine, where different access rules can be applied, and providing state transitions to trigger rules.
Display Suite lets you fine-tune the format of which fields appear when you view nodes in a particular context.
And much, much more.
Why should I go to all that trouble?
If your needs are modest, don't. For a huge number of businesses who are just looking for an online presence, Drupal is overkill. It can certainly do the job, and we'd be happy to help if you have a decent budget to work with -- but a simple WordPress site may be all you need.
If you have great visions of an information-rich, interactive site down the road, you can start with a site on Drupal Gardens, or another hosted service that keeps things affordable by limiting what you can customize. Going this route you can start with a simple site and when your needs exceed what can be done, you can take the site to a company like us to manage whatever customizations you would like to do.
Here are some examples we've built, large and small:
Personalized control over information, Pethub.com
Pethub is a great project to do in Drupal. It makes extensive use of all sorts of things you'd be hard-pressed to build in WordPress or other CMSs. There are a couple dozen different types of content, some interrelated (like pet vaccination records, an overall medical record, the "pet card" for a pet, pet activities, and more) and some more typical (article, blog post, business listing).
We've built out systems to allow pet owners to control which information to share with whom, and users may make different decisions from each other. You need a robust, flexible platform to support this level of complexity.
If you own a pet, by the way, head over and get a pet tag while they're still free! The pet tag has a QR code that will take people who scan it with a smart phone to your pet's ID page, where you can choose what details to share.
Build and share an itinerary, OlympicPeninsula.org
The functionality on this site is much more modest, but was relatively simple to do. Using a module called "Flag", site visitors can bookmark pages throughout the site, storing it in their "backpack." After creating an account or logging in, the user can save their backpack and share it with friends.
Reserve a booth at a conference, WallCeilingShow.org
For a convention, among other things we set up a booth registration product. Exhibitors can fill out a form that actually creates content directly on the site, and "check out" that content through the shopping cart. When payment is received, the content is automatically published to the exhibitor list, and the booth they selected shows the name of the exhibitor when you mouse over it.
This nicely illustrates how all the various parts of a Drupal site are unified by its information -- we created a content type for exhibitors, set it up as a product that could be purchased through the store, and showed collections of that content on both a list of exhibitors and a custom SVG-based graphical map. Oh, yeah, we also skipped using Flash for that site -- if you're using Firefox or Chrome or another browser with native SVG support, this map does not use Flash.
Keeping up with changing business needs
There's one other really great reason to use Drupal -- its ability to change over time as your requirements change. Adding or removing fields from different content types, changing what fields are available in reports or on particular pages are trivial. A skilled Drupal administrator can make a huge amount of changes in a short amount of time, without requiring a developer, if the site was well architected to begin with. And even if it wasn't, it's generally not that difficult to change the architecture without any data loss, with some developer help.
It hasn't always been this way. Back in the days of the Drupal 4 series, just updating site modules to current releases was risky and usually broke things. Over the years, with constant developer attention, the rough edges have been largely smoothed out. With the rise of "super" modules like Views, CCK, Rules, and a few others, a huge amount of attention has been paid to maintenance and upgrades that don't break anything. And with Drupal 7, we're getting a built-in test framework that should add a huge amount of reliability to the upgrade process, with hundreds of thousands of automated tests to help prevent bugs that keep re-appearing.
It's also easy to find sites built with a ton of custom modules with no easy upgrade path. Drupal is very much a living project, with major improvements getting rolled out on a regular basis. You can either choose to spend time and money as you go to keep up with the constant changes as they come, or you should plan on a fairly major upgrade project every 2 or 3 years to catch up.
When you need Drupal
Some of our lower end sites could probably be done in WordPress, but nearly all of them have some feature or functionality that was enough easier to do in Drupal to offset the cost. So all that said, here are some guidelines for helping to choose:
- Is having a stunning graphic design the most important part of your sites? If so, lean towards Word Press.
- Do you want to manage different kinds of information on the site? Drupal.
- Do you need to have not just different levels of access for users, but different groups of users with access to different things? Drupal.
- Can your current and future web site content needs be completely satisfied with articles, blogs, pages, and a category/tagging system? Word Press.
- Do you want to have content organized by something more than tags and categories -- geographical location, date (other than the published date), relationships to other content? Drupal.
- Do you want to have e-commerce on the site?
- Is your e-commerce limited to simple subscriptions, donations, or products? You can probably get by with Word Press -- though be very careful about where you're hosting the e-commerce parts of the site.
- Do you want to sell more than one of the following -- subscriptions, donations, products, form submissions, ability to publish on the site, event registrations, or other things you dream up? Drupal all the way -- e-commerce integrates so tightly with everything else that all of this can be done far more easily than in nearly any other platform.
- Would you rather be able to instantly add widgets to your site, each with their own information source? WordPress means you manage the widgets, and may end up with copies of your information in lots of different places. Set up is quicker and easier, but you're setting yourself up for maintenance challenges down the road when your information changes.
This last point is probably the crucial distinction, and the one we started with:
In WordPress, you can easily add widgets from all over the web to your site, but ultimately you're going to spend more time either managing information or developing systems to manage information.
In Drupal, you have to spend more time setting up and organizing your information at the outset, but then managing it becomes far easier. You'll spend more developer time refining forms and blocks, doing theme-related improvements to usability and design, while the information management shines.
Add new comment