17 Reasons WordPress is a Better CMS than Drupal

This blog post has been simmering inside me for while. Some might think it as link bait but frankly I don’t blog often because I don’t have the time to manage lots of comments. So the thought of posting something that will likely be controversial has me going against my better judgment (but it won’t be the first time I’ve done that. :)

Drupal is for Serious Web App Dev but WordPress is Just Blogware?!?

Say what?!?!? Although the conventional wisdom is that WordPress is really just a great blogging tools and Drupal is more appropriate when you need a full-featured CMS for business use, the conventional wisdom is unfortunately outdated. Since WordPress released version 3.0 in mid-2010 there are now very few if any good reasons to use Drupal instead of WordPress when your business needs a CMS.

Heresy?

Maybe, but history has shown much heresey to be the voice of truth later vindicated. However, rather than ask you to just take my word for it, I’m going to explain below 17 tangible and specific reasons why WordPress is a much better choice for a business CMS than Drupal. 

Just the Facts

But for those of you who can’t be bothered to read the details I can summarize in two (2) points:

  1.  Site Architecture and
  2.  Backward Compatibility

Drupal’s site architecture, which on surface appears quite elegant is in reality Drupal’s biggest weakness. Drupal projects can start very inexpensively with large initial wins but the costs to add increasing functionality are discontinuous and in my experience soon soar out of control. I’ve seen several Drupal projects fail simply because of Drupal’s architectural inflexibility; many projects becoming difficult if not impossible to complete On the other hand there is WordPress’ architecture which, while seemingly less sophisticated and with more code duplication nonetheless enables the perfect combination of flexibility and unlimited functionality in my opinion where the increase in cost for more functionality scales linearly starting from zero.

As for Drupal’s position on backward compatibility they only maintain compatibility between major versions, which means you’ll be probably be forced into having to do a fork-lift upgrade since they only official support one major version behind. Who in their right mind would put their business in such a position? WordPress, on the other hand, bends over backwards to maintain an upgrade path between 0.1 versions.

About Terminology

WordPress and Drupal have some different terms for similar concepts and the following might be confusing if you are not aware of how these terms relate.  What WordPress calls a "Custom Post Type" Drupal calls a "Custom Content Type."

In WordPress a developer uses the register_post_type() function to define a custom post type whereas in Drupal a developer or user defines a custom content type in the admin console using the "Content Creation Kit" module (a.k.a. "CCK".) WordPress calls all content items "posts" (which is the generic term for the more specific "Pages" and "Posts"; confusing, I know, but that’s for legacy reasons. Drupal on the other hand alternates between calling content items "Content" at times and "Nodes" at other times.

Both WordPress and Drupal use the term "Theme" to refer to the collection of files that collectively create the unique look and feel for a site. Themes are comprised of some or all of these items: PHP scripts, HTML, CSS, SQL queries, Javascript, Images, Flash and maybe more. Themes are designed to be interchangable so that by replacing a theme a site can be given an (almost?) completely different look.

For extensiblity both WordPress and Drupal support the concept of componentized functionality with WordPress calling their functionality "plugins" and Drupal calling their functionality "modules." Aside from some technical implementation differences both plugins and modules are conceptually the same; componentized functionality. They are both typically comprised of PHP scripts and HTML but like themes may also incorporate CSS,  SQL queries, Javascript, Images, Flash and more.

As for versioning, WordPress strives every four (4) months (but it sometimes takes six) to launch a "point 1" or 0.1 version increment (such as v2.9, v3.0, v3.1, etc.) whereas Drupal uses major and minor versions (i.e. v5.x, v6.x, v7.x, etc.) with no specific release schedule between major versions.

Now with that out of the way, on to the 17 reasons.

17 Reasons to Pick WordPress vs. Drupal:

  1. WordPress Allows Infinite Design Flexibility – Drupal not so much. Because of it’s fundamental technical architecture most Drupal sites have a certain look and feel that is very difficult to get away from (note the "I think though doth protest too much" quality of these three (3) posts),   WordPress is as flexible as HTML because of it’s architecture.

    More specifically when a browser requests a web page from a Drupal-based website, Drupal inspects the requested URL and then delegates reponsibility for generating parts of the HTML page to both applicable modules and to components of Drupal itself. Drupal then collects up the generated HTML and composes a completed  HTML page when it sends to the browser.  Drupal manages everything and this archecture is minimizes duplication of responsibilities and is an architecture that an engineer can truly love.

    Unfortunately Drupal’s architecture is also highly coupled and thus rather inflexible; when you want a web page that doesn’t fit into Drupal’s model you either 1.) learn complex and arcane methods to achieve what in pure HTML would be incredibly simple, 2.) rebuild major portions of Drupal functionality for your custom page or 3.) just give up and do it the way Drupal wants you to. Or as I like to say when explaining this unfortunate aspect of Drupal:

    As a Drupal developer you are constantly battling Drupal to get back in control of the HTML that it will output for any given URL. Drupal is like a "Roach Motel" for URLs: Once a URL enters Drupal it never leaves!

  2. Usability has been "Baked-in" to WordPress – With Drupal, usability was an afterthought until version 7 and they’ve been desperately trying to improve it; usability tests by the Univeristy of Baltimore identified many critical usability issues in Drupal (the video is a must watch.) But some things such as usability need to be central to the philosophy of the developers and not tacked on as an afterthought. In Drupal you frequently need to visit at least two different pages in the admin to affect what a user would see to be one external change. With WordPress the admin console was originally user tested by the project founder’s mother ("If mom can use it, anybody can!") and that fanatical concern for usability has permetated the project. In Drupal some of the more active developers are known to say "If you don’t find Drupal usable maybe Drupal is not for you."
  3. WordPress has a WYSIWYG Content Editor in Core – Also a usability issue but an important specific one, with Drupal there is no standard WYSIWYG editor leaving the site implementor to choose from thirteen (13!) suboptimal editor module choices, none of which are maintained at the same level of Drupal core.  In WordPress, TinyMCE has been a highly usable standard for more versions that I’ve been using WordPress. (Personally this was one of the biggest issues I had with Drupal and why moving to WordPress was such a godsend for me.)
  4. WordPress Strives to Maintain Backward CompatibilityDrupal wears as a badge of honor that they wipe the slate clean with every major version. Drupal mostly ignores backward compatibility with the prior major version because yes it is nicer for the core developers not to have to worry about backward compatibility. But for your business the reality is that if you implement a site using Drupal you are stuck on that major version until you choose to invest in an expensive rewrite of your website. 

    Ponder this issue for a moment.  In my opinion, choosing Drupal can result in a nightmare once the version of Drupal they are using becomes too obsolete and is no longer supported. This is such a huge negative that I can’t really see why any business that is doing their due diligence would ever choose Drupal no matter its feature set.

    With WordPress most upgrades are seemless and those that are not are usually easily fixed because of the attention to maintaining backward compatibility.

  5. A WordPress-based Website’s Source Code is Easier to ManageDrupal co-mingles user content with what is in effect a website’s source code in much more significant ways than WordPress does.  For example, to design of "Custom Content Type" in Drupal gets stored in the MySQL database; in WordPress "Custom Post Types" are stored as PHP code. For any business website managed by professionals it is critical to use a source code version control system and it’s easy to submit PHP code to version control but very difficult to submit records in a database to version control. This fact alone is a extremely strong argument for WordPress and against using Drupal for any serious website development project.

    Yes out-of-the-box Drupal is easier for a non-technical power user to add custom content types compared to with WordPress, but we are not talking about the needs of a housewife to organize her recipes, we are talking about which one is the better choice for a business CMS and WordPress wins hands down in this category. (BTW, there are plugins for WordPress such as Custom Post Type UI that provide the end-user with the same ease of use for creating custom post types that Drupal has for creating custom content types.)

  6. Collaborative Development is Easier with WordPress – This reason is a variant of source code being easier to manage. Without a good version control strategy it is much harder to get a local copy of a website for development. Developers in a Drupal shop have to spend a lot more time merging their databases so the up-shot is that many Drupal developers co-develop on the same installation, and often the live installation at that which results in overwriting each other’s code and limits a developers ability to roll back.  It’s much easier to develop with a local copy of WordPress so WordPress developers tend to do it more often.
  7. Revisions of WordPress-based Websites are Easier to Deploy – This reason is also a variant of source code being easier to manage. 1 but the headaches are seperate so I list is as a seperate reason. Because WordPress maintains a lot more of its logic in PHP code WordPress is much easier to deploy than a Drupal application. Drupal developers end up writing a lot more SQL code that they then need to test everytime they need to merge data used to control new application logic into the database of a production webserver on deployment of a revision to an existing website. The significance of this is hard to underestimate.
  8. Easier to Find Skilled Designers for WordPress –  To create a beautiful website design for WordPress designers need to be good at design, of course, but beyond that they really only need to learn how to copy and paste "Template Tags" as they able to have full design freedom when producing the HTML that will be used for a WordPress theme.

    Drupal designers, on the other hand, need to be skilled PHP developers too and with a rare exceptions those two skillsets are mutually exclusive. When you do find someone who can do both and do both well, they will be hugely in demand and thus outrageously expensive but the real problem is with Drupal you really won’t know if they are one of the rare few until after you’ve paid them a lot of money to either create a "house of cards", or a really ugly house.

    With WordPress you can get a great designer to work with a great developer, both of which are easier to evaluate than combined greatness, and you are set.

  9. There are More WordPress Professionals Available – A corollary to finding skilled designers, it’s simply much easier to find WordPress professionals to hire for projects than it is to find Drupal professionals.
  10. WordPress Professionals Charge Lower Rates – Another corollary to finding skilled designers and more WordPress professional being available is it is less expensive to find a WordPress professional than a professional for Drupal.  If you ignore the fact that there are many more WordPress professionals another factor is WordPress professionals don’t need to be as proficient in as many areas as their Drupal counterparts.  People who can really make Drupal sing are really expensive.
  11. WordPress’ Code is Much Easier to Debug – Drupal’s highly nested architecture makes it so that a developer spends most of his time looping through a few core functions waiting to find which code controls what they need to modify.  Often with WordPress the developer can simply set a breakpoint on the theme’s template file and debug from there.
  12. WordPress Sites Load Much Faster than Drupal Sites – Drupal runs upwards of 100 SQL queries for every page load because of its site architecture. With WordPress the number can easily be less than 10. And the time to run those SQL queries easily add up. Drupal advocates will claim those queries can be made insignificant by the creative use of caching but the reality is that you cannot cache most items in the admin console so the end user who is forced to use Drupal will be saddled with a level of fatiged and is just not necessary, if you instead choose WordPress.

    And lest you feel this is unimportant technical concern be aware that site performance is now something that Google uses to determine search engine result rankings. Host your website on a slow platform and prepare for an uphill battle when it comes to achieve top rankings in Google’s search engine results pages.

  13. WordPress Requires Less Expensive Hosting – A corollary to page load performance is that the typical Drupal site requires a lot more server to serve each of it’s pages than does a typical WordPress site. Those who choose WordPress for a seriously high traffic site will usually find they can serve more pages with the same servers and/or that the memory requirements for WordPress will typically be a lot less. And for a high traffic sites this could either be real money and/or it can mean that the site is less likely to fail in the case of a flash mob such as a Slashdotting.
  14. WordPress has the Most Integrations –  More companies or their 3rd parties offer plugins for WordPress to integrate with their services than another other platform, specially more than modules available for Drupal. Twitter, Facebook, Freshbooks, MailChimp; you name it, they all have WordPress plugins. If you need one for Drupal and it’s not a mainstream service like Twitter or Facebook chances are you’ll have to pay to have it written.
  15. WordPress has More Robust Extensibility Method – Both WordPress and Drupal use the term "hooks" to describe their exensibility mechanisms and while there are similar there is an important technical difference. In WordPress you associate a bit of functionality to either run or filter a value based on the name of the hook and you can have as many hooks of each type as are needed. In Drupal you do the same except that hooks are identified hook name prefixed with module name which means you can only use a given hook once in a module; if you need to use it twice you have to create another named module.

    Of course the module name limitation is an annoyance but not a huge problem. The huge problem comes when you need a module to disable a hook that was enabled by another module you otherwise need. This is a technique used somewhat frequently in WordPress but when it’s needed it is essential. In Drupal, even if you need to you simply can’t. And all because of Drupal’s architecture choices.

  16. WordPress has Far More High-Quality Attractive ThemesDrupal has almost two orders of magnitude less.  Why is this the case? Because it is so much harder to create a Drupal theme (as mentioned above), designers have to be good developers to theme Drupal (also mentioned above) and there are just so many more people using WordPress.

    Now having off-the-shelf themes is great for micro-businesses, startups and even tactical projects but most businesses will want a custom theme developed to showcase their brand in the best light possible yet the existence of so many commercial themes still benefits those who need custom themes.  Why?  Because it means that collectively WordPress custom theme developers have a lot more experience developing quality themes than their collective Drupal counterparts because many WordPress designer offer up commercial themes for sale in addition to their bespoken work.

    And then there are the theme frameworks for WordPress like StudioPress’ Genesis and WooTheme’s Canvas which create excellent headstarts for theme designers with lots of pre-built functionality that designers would often have to charge clients to develop.  Drupal does have the concept of theme frameworks but they are really an esoteric option for Drupal.

  17. Lastly (for my list, at least) there is a WordPress Answers but not one for Drupal – Yes an attempt has been made but there’s just not enough community support for a Drupal Answers (yet?) And while this reason may seem gratuitous, believe me it is not!

    The official support forums for both Drupal and WordPress and even the mailing lists for WordPress evidently encourage a level of disrespectfullness that is pervasive in so many open-source communities and it can be a huge time sink for the business person who just wants a problem solved. On the other hand the mechanism used by StackExchange‘s WordPress Answers brilliantly encourages timely and helpful support discourages such unproductive behavior with its reputation system.

    And whereas many support queries on the Drupal (and WordPress) forums go unanswered, the majority of questions receive a reasonable answer on WordPress Answers (currently at 94%.)  If you have a WordPress issue you need solved, or that your developer needs to solve, the existence of WordPress Answer compared with the non-existence of Drupal Answer means that solutions will come far more quickly and far less expensively.

So there you go.  17 Substaintial Reasons why WordPress "The open source blogging tool" is a far better pick when selecting a CMS for business use compared with "*The* (2009) open-source CMS" Drupal. (Oh, and the judges picked WordPress as the best CMS for 2010.) Need another opinion? See Wikipedia’s criticisms of Drupal and the relative lack of criticisms about WordPress.

Of course it would be unfair and disingenous of me to call out WordPress strengths and Drupals weaknesses without also telling you where I see weaknesses with WordPress and strengths of Drupal and for me not to tell you what are the use-cases where I’d be hard-pressed to dismiss Drupal in favor of WordPress. So here you go:

  1. Drupal Allows for More Flexible URL Design – Since WordPress grew up as a blog they hardcoded the URL routing logic which has resulted in some rather odious limitations in how you can design your URLS.  Drupal’s URL management is no panacea either — you can end up with a difficult to maintain mess — but at least Drupal *allows* you flexibility that is often just too hard to implement robustly with WordPress

    (Note: I have a plugin on the drawing board whose goal is to remove this limitation from WordPress. Once it sees the light of day  I believe WordPress’ URL routing will be much better than that of Drupal. But alas, at least today, Drupal wins in the URL category. If someone using WordPress really badly needs better URL routing in WordPress and can fund the plugin development please contact me as by nature my priorities are defined by my client’s needs.)

  2. Drupal Offers Out-of-the-Box Content Type and View Creation in the Admin – Yes, out of the box a saavy end user with adminstrator rights can create and define Custom Content Types with custom fields and even custom reports/queries called "Views." This enable and end user with the time to learn Drupal to build a content-based system without any developer help. And for certain scenarios this would be invaluable, such as in certain government or academic departments were there is zero budget for development today, there never will be budget, and the end user either does not want to or is simply incapable of learning how to write the simply PHP required to register custom post types in WordPress.

    On the other hand, there are WordPress plugins that duplicate the functionality of CCK and there are numerous plugins that expore the Custom Post Type registration via a UI in the WordPress Admin.  Still, as far as I know, there really is not WordPress equivalent of Views.

    Still, even though you can create custom post types in WordPress using a plugin that exposes an admin UI it doesn’t mean you always should. As I said above I highly recommend that anyone business that is having custom solutions built using WordPress not build them using an admin UI for defining custom post types but instead embed that logic into version-controllable PHP files.

    As for Views, it’s basically the same recomendations as for custom post types; rather than store them in the database like Drupal does it works much nicer just to code calls to WP_Query into PHP code; easier to version control and also easier to test, verify correct and certain that aspect of the site to be bug free.

  3. Drupal has Positioned Themselves Better in the Eyes of Large Enterprise – Here’s where I think Drupal has succeeded brilliantly. Because of the efforts Acquia‘s products, services and solutions there are many large companies that believe in Drupal. I believe they have done a much better job of courting the Fortune 500 crowd than WordPress has via Automattic and it’s VIP Support and Hosting offering.

    That’s not to say there are not some really phenominal companies delivering enterprise class solutions on the WordPress platform such as Voce Communications and TayloeGray just that there is a segment of decision makers in large business who will only consider working directly with the primary vendor and in these two cases the primary vendor for WordPress is Automattic and the primary vendor for Drupal is Acquia. And while I love WordPress and think highly of the team at Automattic it’s clear to me that Acquia have done a much better job of positioning themselves as a company that provides enterprise class support for their platform.

But what about Drupal for Community Sites?

One of the use-cases oft cited for Drupal’s superiority is for community sites.  But frankly, I don’t buy it. 

As an active member of the Drupal community for two years (speaking of which, I need to update my profile there) I found drupal.org to be an extremely frustrating website in which of participate in a community. The forums were not at all effective in the ways that other forums I’ve seen like vBulletin have been effective, and using them as a user was far more pain then pleasure (by contrast I find StackExchange mechansim at WordPress Answers to work brilliantly but alas it’s not software you can implment for your own community.)

Actually at this point I think it’s counter productive to set up yet another social network but if you are convinced your strategy makes sense I’d be included to launch it on BuddyPress instead of Drupal, and BuddyPress is now a plugin for WordPress. And one of the really great aspects of BuddyPress is it that it leverages the brilliant network/multisite feature of WordPress which has completely nailed the "single install – multiple website" architecture.

Who am I to Judge WordPress vs. Drupal?

Full disclosure, I’ve been making my living as a WordPress specialist for almost two years and I plan to launch a company that provides tools and support for professional website developers and interactive agencies who have chosen WordPress as their platform for client solutions. The reality is that I could easily choosen to do the same for Drupal but did not. 

I spent two years working with Drupal as my preferred platform, from mid 2007 through early 2009 and I gained experience working with versions 4, 5, and 6. I was drawn to Drupal by it’s elegant architecture (I’m an engineer by degree and thus appreciate elegant technical architectures) and frankly by the fact that Drupal was the only solution of the three main open source CMSes that  could actually be used as a CMS without obvious issues (why I avoided Joomla is the story for another day.)

Back in 2007 using WordPress as a CMS was simply not an option, so I moved forward and became enamoured with Drupal and it’s Custom Content Kit, Views and so many other (what seemed like) wonderful modules. I became active in the local Drupal Meetup group and spoke at several of their meetings. I registered a "DrupalCamp.com" domain with plans to launch a local DrupalCamp and more. I really drank the Drupal koolaid.

But then by happenstance I had finished a Drupal project and was looking for another when a 6 week project to write custom admin plugins for WordPress 2.7 fell in my lap.  Since I far prefer to develop admin functionality than full websites I figured "How hard can it be?" and took the job.  While I worked on these plugins I discovered WordPress much easier to develop for than Drupal but I still held on to the notion I’d return to doing Drupal work once the project was done. As the project progressed an inner conflict raged as I came to prefer WordPress all the while mourning what I would be loosing if I were to leave Drupal (CCK and Views, mostly.)

However by the end of the 6 weeks it became crystal clear to me; WordPress was a much better system than Drupal even without all the CMS features. I was reminded of how many personal Drupal projects I had unfinished simple because it’s do hard to get a good looking site completed in Drupal, the last 15% it pure hell to complete. So I decided I would build my own CCK equivalent and use WordPress instead. Honestly, it didn’t go so well with WordPress at first. Trying to create my own CCK was fraught with frustration and I wasted copious time trying to bend WordPress to my will. But I did and limped along.

Then v2.8 came out. And then v2.9. And then finally v3.0 was announce with Custom Post Types and fortunately I was in a position to just on the beta version. It soon became clear to me that the WordPress team got Custom Post Types right and that v3.0 was going to be a watershed release and, as they say, the rest is history. 

As I write this v3.1 is going into beta and with its Internal Linking Dialogs, Post Formats and more WordPress continues to prove that it really is the best choice for almost every business CMS need out there.

So Why Did I Write this Post?

Recently I met with a Senior Vice President of Strategy and Innovation at a large well-known non-profit who is planning to launch a major initiative and he’d narrowed his choices of platform down to two (2): Drupal or WordPress.  On a personal level we hit if off fabulously so if it were just personalities I think he might be inclined to take my recommendation on faith but I sensed he is enough of a real professional that he looks beyond the personality of the advocates to assess the actual best solution for this organization.

What he wanted to hear from me which platform I thought was the best and why. I had already reviewed their design brief and wireframes so I had a good idea of what they wanted, and on the surface it looked rather much like a community app. Because of this and also because he had previously talked with several Drupal advocates I think he was leaning towards Drupal.  But looking at his requirements and given my issues with Drupal that I detailed in these 17 reasons it was clear at the day is long that WordPress would be a far better platform to meet his needs.

Still, as I tried to explain to him why Drupal would not be a good choice I felt that I might have been coming across as a bit too much of a WordPress zealot whose opinion was not based on objective reasoning. So I decided that I should  writing this up to make the case using objective criteria for anyone evaluating the two.

But I still didn’t get around to writing it up because there are always too many other things to do in a day. It wasn’t until a series of posts on Quora with the leading title "Why do so many people use Drupal instead of WordPress?" that I got off my duff and finally wrote this post (even though I have clients whose projects I probably should be working on!)

In Summary

While Drupal had the lead as best open source CMS for many years, WordPress has eclisped Drupal as the best open source CMS as of mid 2010 with the addition of Custom Post Types.

More specifically Drupal’s site architecture makes it a less than ideal platform for business websites when compared with WordPress, and Drupal’s philosophy on backward compatibility make it really hard to recommend it to any company for almost any reason at all.

Postscript: About Comments and Revisions

If you are going to post comments:

  1. Be sure to include something specific about the post in your comment rather than a generic like "Yes I agree" or I might think is spam and delete, and
  2. If this post gets a lot of comments (which I fear it might) be aware that if your comment doesn’t appear for a few days it’s simply because my client demands have limited my free time and I haven’t had time to release it from moderation.

FYI, I plan to revise this post if new evidence comes to light, somehow I got my facts wrong, or I just identify more to add. Frankly I’ve never much liked the "write-once, forever outdated" form that most blog posts take, so why conform?

UPDATE (2010-12-13)

Alastair McDermott has just written a blog post on a very similar subject entitled "Why I Recommend WordPress as a CMS." It’s a good read.

UPDATE (2010-12-17) 

If you are going to leave an inflammatory comment criticizing my post then at least have the integrity to leave your full name, your email and a link to something where I can verify who you are and I’ll be happy to publish it (you know who you are.) Otherwise I’ll simply moderate your comment into the trash.

And for what it is worth, it looks like even the Drupal community knows about many of the problems with Drupal:

 

 

298 Replies to “17 Reasons WordPress is a Better CMS than Drupal”

  1. Mike,

    I agree WordPress doesn’t have any technical limitations that make it unsuitable as a CMS. It’s the WP “professionals” that are the problem. Even though there are many more people who work with WP, very few are capable of building non-bloggish type sites (by that I mean one main column of content + sidebars).

    The blog stigma is already going away, but it will take time as more WP service providers themselves learn how to provide more sophisticated solutions.

  2. Hey @Nick Ali:

    Thanks for commenting. Fair point on the level of WordPress professionals, I’ll give you that one.

    I’m just hoping this post can get a few more people to stop dismissing WordPress as a CMS, especially when they’ve heard Drupal is a panacea.

    -Mike

  3. Hmm. As a developer who switched from Joomla to Drupal about 2 years ago, with a few WordPress sites along the way, I disagree with many of your conclusions, but the biggest things you’ve got wrong are these:

    Drupal’s philosophy on backward compatibility – In the 4.x days, backwards compatibility sounds like a nightmare. Our first sites were on 5, and most of ours are on 6. And these days Drupal upgrade paths are really great. Drush, a command line tool for managing upgrades is indispensable. We recently upgraded a 4-domain very sophisticated site with workflow and tons of add-on functionality from 5 to 6, and it wasn’t bad at all, aside from re-implementing the theme.

    … and I’m sorry, but Word Press has nowhere near the capability of customization you’ve got in Drupal. When you can pick and choose between functionality that radically changes the entire behavior of the application — things like workflow, views, Ubercart, faceted search, Rules, Organic Groups — Word Press looks like a toy in comparison.

    I do agree with you that for a huge number of businesses with straightforward CMS needs, Word Press is great, all that’s necessary. And the number of designers available, the lower cost, less resources, all true. Drupal simply costs more to run, keep up-to-date, and develop for.

    But as soon as you want an integrated shopping experience (not just another application that you make look the same as your WP site but really is entirely different under the hood) or to delegate authority over sections of your site to have massive amounts of user contributions, or highly personalized dashboards for users, or integration with other business databases, or really a custom application with a CMS component, or build a location-based directory — well, Drupal’s a whole lot better fit, and you’re going to hit a wall with Word Press that’s going to end up being a lot less maintainable solution if you get there at all.

    It’s really a question of what you need the site to do. If it’s just content management, Word Press is great, and less expensive. It has certainly grown up from its humble blog beginnings to fill the needs of many company sites. Meanwhile the biggest criticisms you have about Drupal – hard to theme, wysiwyg support, debugging, performance, views/structure stored in the database – are mainly questions of knowledge and very easily mitigated with tools like drush, features, and experience. As I see it, Word Press fills the low end of the market up to the middle, while Drupal fills the high end of the market down to the middle… and there’s a whole lot of overlap there in the middle. Meanwhile poor Joomla’s been pretty much squeezed out of relevance entirely (and I say that after having built somewhere around 40 Joomla sites…)

    Cheers,
    John

  4. Hi @John Lock,

    Thanks for taking the time to comment. Since I’m not innundated with comments (yet?), let me respond:

    @John – “We recently upgraded a 4-domain very sophisticated site with workflow and tons of add-on functionality from 5 to 6, and it wasn’t bad at all, aside from re-implementing the theme.”

    What is your skill level? How many people did it take? How many hours?

    With WordPress it is often a “Click to Upgrade” and you done. Can you say the same for Drupal?

    I assume you don’t do these client upgrades for free, right?

    The point is, with Drupal upgrading becomes a project that needs to be planned and funded. When you are a Drupal development shop you may think of your hours as fungible and your skill level as given, but when you are a business person running a CMS is forced to upgrade it required their attention and it requires them to pay for the support. And when Drupal, that payment is significantly higher than it would be for WordPress.

    (Yes, there can be issues with WordPress upgrades but in general they are an order of magnitude smaller.)

    @John: “… and I’m sorry, but Word Press has nowhere near the capability of customization you’ve got in Drupal.”

    Sorry, that assertion is simply wrong. WordPress is infinitely customizable using PHP, jQuery, et. al. And I personally find it much easier to build plugins for than I found to build modules for Drupal.

    But if you had said Drupal has some modules for which there is not equivalent plugins I would agree. Specifically with Workflow and Rules (funny how building a workflow plugin for WordPress is on my agenda. :) As for Views, my comments above explained why I think using Views it not good for debployed business CMS with the exception of allowing end user to do ad-hoc queries.

    You also suggest that Ubercart makes Drupal superior but that reveals your ignorance of WordPress: there’s wp e-Commerce, Shopp and several others; I’d argue WordPress is stronger in eCommerce than Drupal. And as for Organic Groups again you ignore WordPress equivalents: BuddyPress.

    Faceted search? Don’t know enough about it other than this comments on drupal.org “Faceted Search is database-intensive. If your server can barely keep up with your traffic, this package will make things worst” which would scare me aware from it even on Drupal.

    But the fallacy in your assertion that “WordPress looks like a toy in comparison” is you compare apples to oranges; you ignore the vast thousands of WordPress plugins for which Drupal has no functional equivalent. So if missing 3rd party functionality is the only thing that brands a CMS as a toy then Drupal shares that playground with WordPress.

    @John: “But as soon as you want an integrated shopping experience (not just another application that you make look the same as your WP site but really is entirely different under the hood)”

    Sorry, but you really aren’t aware of eCommerce solutions that are WordPress specific are you?

    @John: “or to delegate authority over sections of your site to have massive amounts of user contributions, or highly personalized dashboards for users,”

    BuddyPress and all the related BuddyPress plugins.

    @John: “or integration with other business databases,”

    Not sure what you mean. I’d need more specifics to address that

    @John: “or really a custom application with a CMS component,”

    Don’t buy that. I’m doing it for clients more effectively than I was ever able to do with Drupal. My current project (which will be live by year end) is a highly custom CMS for large law firms and I would never have been able to make it work like the clients required without significantly rewriting portions of Drupal.

    @John: ” or build a location-based directory”

    WordPress is brilliant at building directories; I’m not seeing what you think Drupal has that makes it compelling over WordPress for directories, and I’m not sure that the “location-based” has to do with it.

    @John: “well, Drupal’s a whole lot better fit, and you’re going to hit a wall with Word Press that’s going to end up being a lot less maintainable solution if you get there at all.”

    That’s an assertion you are making with no specifics unlike the specifics I provided in the 17 points. And you have not addressed the biggest criticisms besides backwards compatibility: 1.) the “Roach Motel” site architecture and 2.) storage of application logic in the database.

    1.) The “Roach Motel” site architecture means Drupal developers are always forced to work around Drupal, begging Drupal for control. WordPress on the other hand enables the developer to request content from WordPress how and when it is needed. This distinction and the ultimate difference in effort required between the two systems can’t be overemphasized.

    2.) The storage of application logic in the database simple make deployment a nightmare which Adrian Webb goes into painstaking detail about how there’s no one good solution for deployment in Drupal in this months php|architect: https://www.phparch.com/magazine/2010/november/ Unfortunately Adrian’s article because it behind a paywall but in the spirit of “fair use” here is his conclusion:

    @Adrian Webb – “Mastering deployment is hard, really hard. I am not trying to tell you to do it my way. Heck, my way has issues that I am still trying to fix and compen- sate for. I guess what I am trying to do is give you an idea of what could be done. Maybe you have a system that works like a charm, and if so, you should contact me. I’d like to learn your secrets. I believe deployment is one of the most important aspects of development. It is a process that we have to per- form each and every time we create a new project or change a live project. It can wear us down if we don’t keep trying to make the process better. The tools are getting better all the time, but de- ployment still requires an integrated process and the discipline to follow it. I’m working on it. You should too.”

    Not exactly a ringing endorsement. Sounds most like steely-eyed determination bordering on resignation. Deployment on WordPress is also complex, but no where near as bad as on Drupal. The issues with deployment in Drupal were the final straw for me that had me fire myself from a consulting project (gracefully of course, after we reached a critical deadline) and vow never to work on another Drupal project again.

    @Josh – “the biggest criticisms you have about Drupal – hard to theme, wysiwyg support, debugging, performance, views/structure stored in the database – are mainly questions of knowledge and very easily mitigated with tools like drush, features, and experience.”

    I half agree and half disagree. Starting with the disagree part, I’d say that performance and views/structure stored in the database are systemic problems with the Drupal architecture and no amount of tools, features and experience can resolve them. Yes tools, features and experience can bandaid them but they can’t fix them.

    I do agree that issues for Drupal with theming, wysiwyg support and even debugging to a point can be resolved by tools, features, and experience. But ironically the need for that specialized and expensive experience drives reasons #8, #9 and #10 to select WordPress over Drupal.

    Riddle me this: You seem to really know Drupal. What is your hourly rate? Can I hire you for a project at US$50/hour? (If yes, please let me subcontract you to local shops who are begging for Drupal devs to work on some Fortune 100 projects. :) If not and your rate is higher than US$75/hour you are making my point #10. $50/hour is a rate you can hire many good WordPress developers.(ot all good WordPress developers will go that low, but depending on your needs many at US$50/hour will have required skills.

    You also missed the two main criticsms – the issues that result from the “Roach Motel” site architecture and the communities self-indulgent policies on backward compatibility.

    @Josh – “As I see it, Word Press fills the low end of the market up to the middle, while Drupal fills the high end of the market down to the middle… and there’s a whole lot of overlap there in the middle.”

    I agree that Drupal is perceieved to be at the high end of the market because it had CMS capabilities first and because Acquia are doing such a great job of promoting to the Fortune 1000. However, since v3.0 WordPress is pretty much on par and is easier to implement, the team members you need are less expensive, and it’s overall less risky to choose WordPress for a project than Drupal (based on many of the 17 points above.)

    As everyone knows in a modern society, it’s not always the best solution that is perceived to be the best, it’s the solution that’s marketed the best and so far Drupal wins that crown. But to debunk that presumed superiority is why I wrote this post.

    @Josh – “Meanwhile poor Joomla’s been pretty much squeezed out of relevance entirely (and I say that after having built somewhere around 40 Joomla sites…)”

    Now *that* at least *is* something we can agree on.

    Thanks again for the comments.

    -Mike
    P.S. I’ll definitely give that Drush is a useful tool. I’ve been meaning to look at it again, and I just reviewed the video here. Suffice it is say I now have another WordPress-related “to-do”; adding a Drush equivalent to WordPress. :)

  5. Hi,

    I’ll save specific points for a post on my web site ;-)

    But to address your two points above:

    “1.) The “Roach Motel” site architecture means Drupal developers are always forced to work around Drupal, begging Drupal for control. WordPress on the other hand enables the developer to request content from WordPress how and when it is needed. This distinction and the ultimate difference in effort required between the two systems can’t be overemphasized.”

    I really don’t understand what you’re trying to say here. There is very definitely a Drupal way of doing things, and if you try to go against it, well, sure, you’re going to get frustrated. But if you take the time to properly learn your tools, there’s a ton of power built into the framework. We’ve built some pretty sophisticated applications with only a couple hundred lines of custom code. We do spend more time deciding exactly where to hook into the system than actually coding — but this ends up making for a more maintainable, more reliable, better architected solution. If you’re rewriting chunks of Drupal core, quite simply, you’re doing it wrong.

    And where this power really helps is when you want to leverage the other powerful modules in the system. For example, we did a relatively simple “Backpack” itinerary feature for http://olympicpeninsula.org , which allows visitors to add destinations to their backpack, and if they register, they can store and share them with their friends.

    Also on that site, when you go to a “thing to do” associated with a particular location, you get lists of nearby lodging and other things to do, sorted by distance. That’s what I mean by location-based search.

    2.) storage of application logic in the database.

    “Features” is a module that’s quickly gained prominence as “the” way to export database configurations to code, where it can be managed with SCM. Simple GUI to create a feature module. Simple drush command to update from the database or apply an update to a different instance. Tools for viewing differences between stored code and database.

    As a result, you get the best of both worlds: the CMS doesn’t need write access to code on the server, where a vulnerability could lead to a hacked site (something I had to clean up two weeks ago from a Joomla vulnerability, and I’ve seen far more hacked WP sites than Drupal…), admins can make configuration changes as needed, and changes can be managed.

    There is overhead involved, it takes time setting these things up, knowledge to use, and coverage isn’t universal yet — but it does cover most of the things you tweak that need deployment and management, including views, rules, cck, node displays, taxonomies, and now even menu items.

    For businesses who only have one site, the investment in that setup probably won’t pay off if WordPress will do the trick. I’m not arguing your cost point — I’m just arguing that all the “serious” issues you highlight are not issues for professional Drupal shops, because we know how to work with them and get a great result.

    Like I said, I’m not arguing your cost point. No, you can’t hire me for $50/hour — our rates for project work are double to triple that, depending on how many hours you’re willing to pay for up front. Yes, we cost more.

    And that makes my point — Drupal is the high-end solution, for those businesses who need the tight integration it can provide, where the value of the solution exceeds the cost.

    Regarding other business databases, we regularly write modules to hook into legacy business systems of all kinds. This is always custom work, and it’s the kind of thing larger organizations have everywhere. Sometimes we import the data, sometimes we just connect and pull data on the fly as requested, sometimes we’re pushing data back into the other system. Here’s an area where the Drupal architecture shines — we can pick the best spot to hook into the other system based on the business needs, and leverage the other modules like Views, Rules, workflow, or Ubercart to do Drupal-y things with that data.

    The reason enterprises and high-end sites choose Drupal over WordPress is not because of Acquia’s marketing — it’s because it’s a more suitable platform for their needs. It’s clearly overkill for a lot of small businesses who don’t need a lot in the way of custom functionality. And like I said, as both WordPress and Drupal have matured, there’s a ton of overlap for medium-sized organizations where either is perfectly fine — the person doing the work will matter far more than the platform.

    But you pointed out in your response, that WP doesn’t yet have Rules, or Views, or Drush, or a great many power tools that are mature on Drupal today.

    Drupal is primarily competing with Ruby on Rails, Django, and other rapid development frameworks for custom applications, with the benefit of having a working CMS out of the box. It’s really meant for developers — it is too much work for a casual business user to figure out and expect to get running quickly and cheaply without professional help. So I’m definitely not trying to steer people away from WordPress — I’m just saying there are compelling benefits for custom applications that Drupal provides, and most of your 17 points (aside from the pricing ones) are straw-man arguments that can be very easily knocked down.

    Drupal is particularly strong if you have a lot of different people contributing content, especially if you don’t trust them, or if you want to deeply integrate your web site into your business processes.

    I’ve personally worked with WordPress, Joomla, Serendipity, Gallery2, Coppermine, OS Commerce, ZenCart, X-Cart, VirtueMart, Zend and a couple other frameworks as well as building custom extranet and e-commerce sites from scratch before those came along. We’ve settled on Drupal because it does everything those other platforms do, usually in a much more integrated cohesive way, it has the professional tools we need to effectively manage them over time (including major release updates), a truly anal security team closing vulnerabilities that only an administrator could exploit, and with Drupal 7, huge gains in test coverage, usability, and performance.

    And as a web professional, I’m going to pick the platform with the higher earning potential, not the one where everybody’s going for lowest cost! Especially when it shares the same philosophical benefits of being Open Source and is a better platform for what we do with it. The market has spoken, and our phone is ringing off the hook. I’m glad I can get more than $50 – $75/hour for what we do!

  6. What sold us on Drupal?

    I started several years back with WordPress and moved towards Drupal. I needed more flexibility and found WordPress poorly architected and inflexible. Even 3.0 remains so in my opinion. We still use WordPress for basic blogs and brochure-type websites, however, Drupal offers far more flexibility and is generally our CMS of choice.

    1. Drush, Features and Drush Make. These have doubled our efficiency and we can now deploy drupal websites out of the box with WYSIWYG, advanced UI, Permissions and Roles already setup. Then we have a blog feature that works much like core WordPress that layers over that – then the customization and degree of things you can do with features, drush and drush make are limitless.

    2. Contributed modules build on eachother – the greatest thing about Drupal compared to other CMSes is that MANY OF THE CONTRIB MODULES BUILD ON ONE ANOTHER. This is hardly true for Joomla, Plone and WordPress, in my experience. Does WordPress or Joomla have a UI for a system like Views, CCK or Panels?

    Because so many modules build on one another, some of the most successful Drupal developers don’t even know PHP. All you need to do is become proficient with the UI and Drush, and you can build powerful websites in a flash.

    3. More flexible theming – in my opinion you can do far MORE with drupal theming. Nowadays you don’t have to edit the template files – you can do almost anything you need now with Skinr and Fusion, Display Suite and Semantic Views.

    4. Ubercart and CiviCRM. Ubercart might not be the most powerful Ecommerce solution, but the degree to which it integrates with Drupal is pretty powerful. If you have a website with monetized content creation, look no further! CiviCRM is also a great solution for a Drupal backend, and if you do a little hacking you can do incredible things with Views and CiviCRM.

    5. Drupal Commons – Drupal commons emerged recently and has taken the Drupal world by storm. It is now super easy to build a social network with Drupal, and with the extensive library of modules that Drupal offers and the power of Organic Groups, Heartbeat, Views, CCK and Context, you can take it to another level. You can even throw in Spaces API and make groups act like their own websites!

  7. What does WordPress have that Drupal doesn’t?

    A LOT of custom themes. And much better looking themes. This is because WordPress has attracted some excellent themers with a good eye for typography and an efficient workflow. Drupal has some good base themes from which to build custom themes, however there are far more Contributed WordPress themes available.

    A name. People know what wordpress is because the name is out there, tacked on to millions of blogs. WordPress is something folks are familiar with. Drupal may be able to catch up on this end with Drupal Commons.

  8. Some interesting points on here. I wrote the post linked by Mike above from a slightly different perspective, rather than comparing directly with any competitor, it’s simply that WordPress has established itself as the leader in the CMS market place.

    There are many debating points that can be made for and against, but the single biggest issue is the scale. WordPress has an order of magnitude more users than other systems. An order of magnitude more developers than other systems. Two (!) orders of magnitude more themes available!

    With those kinds of numbers, technical issues become less of a road block. Usually there’s already a plugin available for something you want to do, you can more easily find a developer to build one than for other systems, or the WP core development team are working on integrating it soon.

    Another massive plus for WordPress is the continued focus on user-friendliness, way over and above other systems.

    I first installed Linux Slackware in 1996 off a bunch of floppy discs, it took all week to get a development environment set up. Then came Debian, which had this super apt-get system which made installing stuff a breeze, clearly a super technical solution, except that to install Debian itself required sacrificing a small goat or lamb during full moon, so it never took off in the mainstream. Eventually some folks realised that you can have a good technical solution *that is user friendly*, and they forked Ubuntu. Google Trends shows the tale nicely: http://www.google.com/trends?q=debian%2C+ubuntu

    All over the open source spectrum developers are building stuff primarily for themselves, while ignoring the user friendly features that would spread their app or platform further. WordPress is head and shoulders above the other systems not because of superior technology – they’re still behind but catching *fast* – but because of superior user experience.

  9. Corollary: (re: architectural pattern of content building being constructed in code vs. UI): I like to code in assembly language b/c that architectural pattern gets me closer to the bits.

  10. Mike,

    I only have time to skim this article now, but I’m 99.9% sure I agree with everything here. My brief experience with Drupal left me dazed and confused as I tried to figure out WHY Drupal is called a “developer’s cms” when we never once developed a blessed thing, just used a bunch of point and click modules. I love WordPress and how I can dig right into it’s functionality through a theme without needing to decipher which modules are necessary.

  11. This post is very disappointing.

    Sensationalizing a list post does nothing to really compare the features of these 2 OPEN SOURCE projects.

    You speak about charity websites like it some sort of corporate competition between the two, when in fact much of drupal’s functionality/community has grown around charity work ( unlike wordpress).

    Pitting two great open source projects against each other in such an amateur way helps no one.

    Next time maybe go into actual depth and write something more responsible, I have no respect for these types of posts.

    Ridiculous.

  12. @Amir Helzer – Thanks for the comment.

    I can honestly say that I used to think Views were a great thing, but no more. I’m now incredibly glad to be able to use calls to WP_Query in PHP code instead of using Views. I can version control my PHP code which I really could not do with Views. And I can develop my queries locally, test them, verify they work, and easily deploy them which I could not do with Views. I can know that my code is a more performant than Views WP_Query has fewer levels of abstraction than Views. And finally I can easily modify any query I need to modify by subclassing WP_Query, something I’m not ever sure is even possible with Views.

    So no, not only do I not miss Views my view is good riddance to Views (pun intended. :)

    Hope this helps.

    -Mike

  13. Thanks Mike,

    We dance with both WP and Drupal. I know that Views is considered a holy thing in Drupal and this explanation helps me see why something like that never evolved for WP.

  14. Hi @Amir Helzer,

    Thanks for the follow up. Don’t get me wrong, when I first came from WordPress to Drupal I pushed for my Drupal-like features, to the point of having some in the WP community dislike me for my advocacy. I even pushed for a CCK-like admin user interface for Custom Post Types.

    But then I really started using them and realized that putting Custom Post Types in code was a much better way for professional projects that storing it in the database via the admin. And I came to realize I was originally wrong for pushing for it (though nobody has every explained to me why WordPress’ approach was better, as I did for others above.)

    Anyway, you can now consider me a true believer in the WordPress approach and a disenchanted former believe in Drupal.

    -Mike

    P.S. For the skeptics, here’s proof I was once a heavy user of Drupal:

    http://www.meetup.com/drupalatlanta/calendar/6779397/

  15. Hi,

    Just wanted to clarify and agree with Richard. If you are going to compare BuddyPress, you need to compare apples with at least apples. It would have been a better comparison to make with Drupal Commons.

    So far Drupal Commons is great – easy to deploy, add onto, and use. Starting to use it on a project and happy with it. Also, I’m not a developer and more of a marketing/product manager type.

    Elizabeth

  16. Hi @Elizabeth, thanks for the comment (wish I would have had time to follow up on the longer comments from others. Soon.)

    As for Drupal Commons, it’s new so I’ve no experience with it so if you say it’s the comparison to BuddyPress I’ll take your word for you.

    I too was happy with Drupal when I first started using it, and like you for Austin I was one of the community organizers for the Atlanta Drupal community a few years ago. But the longer I worked with Drupal to more I came to realize how much trouble it was. My guess is you will too if you spent some time with WordPress like I did.

    BTW, I’m confused by your mention of being a marketing/product manager type and not a developer yet on your blog bio you list 9 programming languages as skills. I call myself a developer (and an entrepreneur, etc.) but that list of skills is longer than my skills that are current. What’s the relevance for mentioning? Are you saying that your product marketing/manager skills mean you are better to evaluate Drupal vs. WordPress? I would think someone with technical skills would be better able to evaluate. I’m confused.

  17. Love this thread. Have seen similar debates on Joomla vs WordPress. I spent years building Joomla sites, but now am 80% WordPress. WP 3 was a significant improvement though. Yes Joomla/Drupal still have specific benefits, but I’m finding them less important these days and have to look for a good reason to not use WordPress. A slick wordpress site up is up and running quicker and at a lower cost, (roughly a third) which opens up a bigger market for me within small businesses that are still running clunky static sites build in Dreamweaver etc.

    The other point that there are thousands of theme developers/partners available and the choice of superb plugins has exploded in 2010. Also, clients love the fact there’s things like an iPhone App available to instantly update site content and easy Desktop editing tools like Windows Live Writer, encouraging them to keep the site updated weekly, which helps SEO, traffic and business results.

    Drupal vs Joomla vs wordpress? It’s no contest really…

  18. I am not so familiar with these two platforms. I came to WordPress after learning about CMS as a Hubspot customer back in 2008. I rebuilt my site from scratch on my own as a non-programmer. And since then I have hired a couple of (very inexpensive) design and programming experts to assist me with customized layouts. I can usually get a site up and running beautifully in just a few days. On many occasions we have simply duplicated an existing design. I was able to single-handedly turn my business around by building my website on my own and optimizing it. I have written over 300 pages on it too. That would not have been possible with a platform like WordPress.

    To me, that a non-programmer can create really terrific websites that are easy to manage, easy to modify and are ideal designs for SEO is the true testament to the great work being done.

    Take care.

  19. I too find WordPress url’s limiting at times. One thing I would LOVE to see, is a plugin to be able to set up permalink structures that are different for each post type.

    e.g.
    regular wordpress posts:
    /%permalink%
    a custom post type of ‘recipe’:
    /%permalink%/%post-id%

    I have a recipe sharing site. And even better yet, one step further, would be to have recipe URL’s with post id’s on *user submitted* content, but to not include the post-id’s on my recipes as the site owner. That would make me so freaking happy.

  20. These points are very interesting but you haven’t addressed the one that I’ve heard is an issue – can WordPress actually handle larger volumes of ‘pages’, say 500?

  21. @Julian:

    Thanks for the question.

    Yes, of course WordPress can handle 500 pages. It can handle 5000 pages or more.

    But since you quoted ‘pages’ I think you might be asking if WordPress can handle more than 500 post_type==’page’; is that what you are asking? If that is what you are asking I’m assuming you’ve heard from someone else that if can’t handle a large number and it may be true that a site had an issue with >500 pages, but it’s not WordPress fault if so, it’s the site designers fault.

    For example, if the site designer creates a flat page structure and then tries to use the function wp_list_pages() with 500+ pages well *of course* the site will have trouble but only because of a brain-dead information architecture.

    Architect the site right and a WordPress site can have 50,000+ web pages of content, no problem.

    Hope this helps.

    -Mike

  22. I’ve been making my own cms because i have more design freedom when it comes to things like user login or registration. I also find it easier to make a page using pure HTML and php and not having to worry if it is a special content type or view. WordPress 3 and Drupal 7 are much better than they ever have been but there is something liberating about a purely customized solution.

    At the end of the day I’d rather depend on myself for solving a problem using php and SQL than wait for someone else to develop it for the cms I’m using. That’s just me tho and my style for designing websites. WordPress and Drupal even Joomla are great for people just starting to get online. What happens when they want to be competitive and be different than someone else who is also using wordpress or drupal? So to me innovation and design are very important and it is much easier to do so from scratch.

    I also fear spammers from Russia China and India who search for cms tip-offs so they can exploit a weakness. I understand updates and captchas but to me that shouldn’t even be an issue or concern espcially if someone is paying good money. All this is for me tho and I implore others to learn as much as possible and to always add new tools to their repertoire.

  23. @Jafar – Thanks for commenting.

    My take? Programmers love to code, and they look for any justification they can find that they are making the right decision to reinvent the wheel. How do I know? I am a programmer, and I love designing things and building them from scratch.

    But I’m also a business person who knows that by allowing myself the indulgence of building something from scratch I’m not helping the business that is depending on me to make a good business decision on their behalf. Building a CMS from scratch at this point in history is never a wise decision. There are hundreds of thousands if not millions of man-hours in the core WordPress code not to mention the available themes and plugins; you yourself will never match that level of robust, tested functionality.

    If you are doing it for yourself because you like to code, knock yourself out. If you are using that justification so someone will pay you to develop it for them then you are doing that person or company a serious disservice.

    As for “being competitive” it’s not the platform a smart business person competes on, it’s how they use the platform to deliver content to their customers that differentiates them. Find any angel investor or venture capitalist who will prefer you to develop your own CMS than to use an existing one and I’ll eat my words. Note if you are building a Software-as-a-Service business I typically would not suggest WordPress or Drupal, but then SaaS is not CMS and the point of this post as CMS.

    Lastly, security by obscurity is a fools errand; changes are much greater that WordPress has fewer security holes than code you write simply because of the vastly greater number of people working on it and trying to break it.

    Lastly, I’d recommend you to explore the concept of “Embracing Constraints.” By embracing constraints you become a better programmer. Here are some links on the topic:

    http://twitter.com/#!/donna_raetsen/status/23476145030701056
    http://gettingreal.37signals.com/ch03_Embrace_Constraints.php (If you knew me you would know how it pains me to link to 37 Signals, but in this case the content at the end of the link is relevant and well done.)
    http://www.assertivemagazine.com/2010/08/30/embrace-constraints-how-limiting-yourself-wont-limit-your-designs/
    http://tmousecmouse.blogspot.com/2010/10/embrace-constraints.html

    Hope this helps.

    -Mike

  24. Mike – Can you give me your opinion about Sitefinity a .net CMS ? I know there are other .net CMSs but their being owned by Telerik made me consider them. My little experience in Web Development is in .net so naturally I looked there first. SItefinity’s recent pricing change has me wondering if I can use them down the road for big projects (due to price). Small stuff, maybe so but it has opened the door for me to look to non .net CMS.

    Good article!

    Charlie

  25. I also must say that most or all the given reasons are wrong, especially when I take Drupal 7. I haven´t yet tested WordPress 3, but I will soon check it out, also Joomla 1.6 and Typo 3 4.5 & 5beta for a comparison.

    Expecially for content creators & bloggers WP is cool cause of the easy backend, with D7 this changed very much and now I can create different content types which are easy to understand for the client and much more flexible than all I know from WP 2.6x.

    Of course a good drupal system costs more efforts, money & time to set up, but if you want a little or much more than a blog I guess that drupal is the better choice. Let´s find it out … please be patient some weeks for my results.

  26. And concerning “answers” you just had to ask the right people.
    Most answers with drupal 7 in the past 3 month came withing a few hours including the patch, code or module update when I opened an issue in the modul-bug-queue. If you post your question somewhere in a group I guess – yes – then the right people won´t find it to answer.

  27. Damn, it was a long post, but really worth reading it – well done!

    When I got to choose my CMS some years ago, I loved WordPress because it was simple for me to get. It has never let me down since. I tried Drupal by than, but when I was on backend seemed like I was on front page of a badly designed site – did not stick with me.

    I have also had that inner question of why is Drupal held like the Open Source Enterprise CMS and WordPress has not reputation for that – you gave me a good answer for that – thanks!

  28. “Still, as far as I know, there really is not WordPress equivalent of Views.”

    … stopped reading right there. You just confirmed WP is a toy & not meant for serious development work. I’m sure it’s the right choice if the goal is to move a small biz site off DreamWeaver though.

    Best,
    — John

  29. @jharvey – Thanks for commenting.

    You may have stopped reading because of lack of “Views” but I assert its your own blindered view of things (pun intended) that keeps you from seeing that Views is a simply a heavily-baggaged crutch for those people who have no ability to write and code to create their own queries. (Yes, for those with no tech skills Views is a plus. But why someone who can write code would ever rely on Views simply illustrates how having such a feature can stunt the technical vision of normally competent developers.)

    Since switching from Drupal to WordPress I’ve never ever missed Views because the WordPress query engine is so much more of a joy to work with, IMO. AND I don’t have to worry about getting the Views configuration out of the MySQL database when time comes to deploy from my development server to my test server to my production server.

    And if you really, really must have Views you can use the Pods plugin for WordPress. I’m not fond of it because it’s not compatible with Custom Post Types, but it does pretty much replicate CCK+Views in WordPress; their warts and all.

    One parting question: Have you actually ever used WordPress for a real-world project, or is your view of WordPress merely based on conjecture?

  30. I very much share and appreciate your enthusiasm toward WordPress. It is an excellent application for the right sites and clients. However, I found too many inaccuracies in your description of Drupal and I am concerned about a the large number of incomplete sites that you built. These points plus a lack of knowledge of Drush are signals of an insufficient knowledge of Drupal to make a solid, unbiased representation of its strengths and weaknesses.

    I also feel that it is folly, as a developer, to choose one over the other when in reality they serve very different purposes and users. Drupal is not for every client or project, nor is WP. Choosing the correct application for the project and the client is the wise approach.

  31. Hi @Todd – Thanks for commenting.

    You mention “inaccuracies in my description of Drupal”; why not delineate my “inaccuracies” rather than mention them as heresay, which is a well known way to attempt to cast doubt without offering proof?

    Further, I find it very disingenuous for you to say that the sites I worked on were incomplete; my sites were completed. I wrote “I saw sites fail”, I didn’t write “I failed to complete sites.” So best I can tell you are using carefully chosen words to attempt to discredit me. That said, the Drupal sites I worked on were a damn site harder then they would have been if I had been using WordPress 3.x.

    As for your assertion that my “lack of knowledge of Drush are signals of an insufficient knowledge of Drupal to make a solid, unbiased representation of its strengths and weaknesses”, that is rather disingenuous, no? I did know Drush, I just hadn’t looked at it recently as in the past year. Yet another attempt to attempt to cast doubt in the eyes of the casual reader on on my analysis. Looking through my 17 points Drush would at best bandaid point #7, not eliminate it, so I don’t see how your point is at all relevant?

    Finally to your last point about “Choosing the correct application for the project and the client is the wise approach”, I agree in many cases. I also believe that that old saw has unfortunately been trotted out by people who have latched on to a solution without evaluating alternatives to rationalize really bad decisions far too often in the technology world. So while “yes” I agree that WordPress is not a good choice for all content management scenarios; there are many times when a more feature rich CMS is needed.

    On the other hand, from my experience in using it I believe Drupal is a BAD choice in almost any CMS scenario. For all the reasons stated above.

  32. I didn’t mention the inaccuracies because anyone truly knowledgable about Drupal would see them. I’ll mention a few to satisfy your request:

    “in Drupal a developer or user defines a custom content type in the admin console using the “Content Creation Kit” module (a.k.a. “CCK”.)”

    Content types are not created with CCK.

    “Drupal uses major and minor versions (i.e. v5.x, v6.x, v7.x, etc.) with no specific release schedule between major versions.”
    Drupal was launched in ~2001 and is on version 7. WordPress launched ~2003 and is on version 3.

    “Drupal on the other hand alternates between calling content items “Content” at times and “Nodes” at other times.”

    While I agree that Drupal has been inconsistent with nomenclature in some cases (Taxonomy for exemple), “node” has been a consistent term despite the “content type” label. I suppose though that it isn’t any less confusing than having posts and pages that are essentially identical but provide limitations in terms of menu assignment.

    “Because of it’s fundamental technical architecture most Drupal sites have a certain look and feel that is very difficult to get away from”

    A WordPress design can look like whatever you wish it to. This is no different than Drupal. There are no design limitations with either.

    “WordPress is as flexible as HTML because of it’s architecture.”

    Same

    “2.) rebuild major portions of Drupal functionality for your custom page or 3.) just give up and do it the way Drupal wants you to. Or as I like to say when explaining this unfortunate aspect of Drupal”

    What’s so hard about a tpl?

    “WordPress has a WYSIWYG Content Editor in Core – Also a usability issue but an important specific one, with Drupal there is no standard WYSIWYG editor leaving the site implementor to choose from thirteen (13!) suboptimal editor module choices”

    Drupal isn’t a true CMS. It’s a CMF. You build what you need. This provides choice. It doesn’t force you to build your sites like everyone else. That comes at a cost but it is strategically done to give the developer the opportunity to build their own Drupal distro. They aren’t forced to use a rigid, fast-food one-fits-all solution. And, TinyMCE is one of the options. Just add it to your profile or Drush make file.”

    “none of which are maintained at the same level of Drupal core.”

    Why would TinyMCE be better in WP than Drupal?

    “once the version of Drupal they are using becomes too obsolete and is no longer supported”

    You update WP too, right? Anybody still using 1.x?

    “WordPress most upgrades are seemless”

    WP also presents issues when upgrading.

    “For example, to design of “Custom Content Type” in Drupal gets stored in the MySQL database; in WordPress “Custom Post Types” are stored as PHP code”

    somewhat true if you add fields. However, if you’re looking to alter the design of the default tpl, its all in the file.

    “It’s much easier to develop with a local copy of WordPress so WordPress developers tend to do it more often.”

    It is no more difficult to move or localize a D or WP site. The command line makes this simple for either.

    In regards to your acusation that my response is disingenous I must reinforce that, despite the words chosen, if you’ve had many projects “fail” then that raises a red flag in regards to your familiarity with Drupal.

    In regards to Drush, these aren’t the words of someone who is familiar with it:
    “P.S. I’ll definitely give that Drush is a useful tool. I’ve been meaning to look at it again, and I just reviewed the video here. Suffice it is say I now have another WordPress-related “to-do”; adding a Drush equivalent to WordPress. :)”

    “Finally to your last point about “Choosing the correct application for the project and the client is the wise approach”, I agree in many cases. I also believe that that old saw has unfortunately been trotted out by people who have latched on to a solution without evaluating alternatives to rationalize really bad decisions far too often in the technology world”

    If your only tool is a hammer, everything looks like a nail. By building everything with one platform one is guaranteeing that some or many projects are on the wrong platform. WP isn’t the best solution for all sites unless you are working in a tight vertical and are building a lot of simple brochureware.

    “On the other hand, from my experience in using it I believe Drupal is a BAD choice in almost any CMS scenario. For all the reasons stated above.”

    I felt compelled to respond because of your accusations but the post just comes across as link bait and I regret having supported it by responding. It’s just too biased to be credible.

    Despite this I hope that you understand that I’m a big fan of WordPress. AND Drupal. They each serve their purpose. I don’t find them to be interchangeable.

  33. “I didn’t mention the inaccuracies because anyone truly knowledgable about Drupal would see them.”

    My post was written for those who don’t know Drupal and those who assume the common rhetoric that is it better for CMS to be true.

    “Content types are not created with CCK.”

    Okay… then how are content types created?

    “”Drupal uses major and minor versions (i.e. v5.x, v6.x, v7.x, etc.) with no specific release schedule between major versions.””
    “Drupal was launched in ~2001 and is on version 7. WordPress launched ~2003 and is on version 3.”

    How does that contradict what I said? You simply made another statement with related facts. And your comment attempts to obfuscate that WordPress has had 10 major releases since WordPress v2.0 they just use 0.x numbering where Drupal uses x.0 numbering. I’ll admit that 0.x releases are less ambitious, but I think WordPress’ incremental approach is better than Drupal’s “boil-the-ocean” approach.

    “”Drupal on the other hand alternates between calling content items “Content” at times and “Nodes” at other times.””
    “While I agree that Drupal has been inconsistent with nomenclature in some cases (Taxonomy for exemple), “node” has been a consistent term despite the “content type” label.”

    Consistently confusing is still confusing.

    “I suppose though that it isn’t any less confusing than having posts and pages that are essentially identical but provide limitations in terms of menu assignment.”

    I’ll admit that is less than ideal in WordPress, and that I was even a champion for it, but only because I argued that if they had changed the name they would be as bad as Drupal’s node vs. content-type.

    “”Because of it’s fundamental technical architecture most Drupal sites have a certain look and feel that is very difficult to get away from””
    “A WordPress design can look like whatever you wish it to. This is no different than Drupal. There are no design limitations with either.”

    Yes, someone who really knows Drupal can bend it to their will. But your response obfuscates the technical distinction between the two I was making and that is that WordPress delegates 100% control back to the page layout designer by doing a direct include on a .PHP file that controls the output of the entire page, and Drupal maintains control and parcels out bits of work for the layout designer to do for pages, nodes, blocks etc. Drupal’s way is foreign to most designers and I believe why there is around an order of manitude more quality themes available for WordPress than for Drupal.

    “”WordPress is as flexible as HTML because of it’s architecture.””
    “Same”

    Not the same, and from what I’ve described I don’t see how you can reasonably assert otherwise. You cannot take an HTML page developed by a designer and, as a whole, turn it into a theme template file like you can with WordPress.

    Too frequently designers will create layout that is impossible to slide and dice and get into Drupal without change by the designer, which the designer’s often don’t understand or appreciate. Not acknowledging that distinction discredits your argument.

    “What’s so hard about a tpl?”

    The tpl is not hard per se, but the way Drupal uses them, they require slicing a design that often cannot be sliced in the manner Drupal requires without breaking the implementation of the design. In part that’s because of limitations in CSS, but CSS is what we have to live with so CSS limitations define the constraints.

    Let me guess; you are both a designer and a developer? If I’m right, you simply don’t recognize the issues when designers and developers have to integrate their work.

    “Drupal isn’t a true CMS. It’s a CMF.”

    Then if Drupal isn’t a true CMS then why are you arguing against my post’s assertion?

    “You build what you need. This provides choice. It doesn’t force you to build your sites like everyone else. That comes at a cost but it is strategically done to give the developer the opportunity to build their own Drupal distro. They aren’t forced to use a rigid, fast-food one-fits-all solution. And, TinyMCE is one of the options. Just add it to your profile or Drush make file.”

    You’ve got a point there. And if I had the energy to revise the post I’d rename it “18 reasons why WordPress is a better CMS than Drupal” and add a reference to what you just stated. One of the bigger difficulties with using Linux in the business world is the lack of standardization with all the different “choices” in distros.

    Maybe it’s cool for developers who want to build their own thing, but from a business perspective the fact Drupal encourages said fragmentation is a negative to me, not a positive. And what I see most “choices” are simply developer hubris.

    “”none of which are maintained at the same level of Drupal core.””
    “Why would TinyMCE be better in WP than Drupal?”

    I don’t really understand the question, but the point of my comment was that 3rd party modules don’t get the same rigourous testing as modules in core. No where as many people use them so issues with them are not as ironed out as issues with things included in core.

    If Drupal were to add CKEditor as a core module, for example, it would address that criticism.

    “”once the version of Drupal they are using becomes too obsolete and is no longer supported””
    “You update WP too, right? Anybody still using 1.x?”

    Yes I updated WordPress. And I do it with a “One-Click Update.” And unless I’ve hacked core or are using poorly written plugins WordPress updates cleaner. You can do that with Drupal?

    I didn’t think so.

    “”WordPress most upgrades are seemless””
    “WP also presents issues when upgrading.”

    A pricked finger may draw blood, but it doesn’t require stitches. Drupal presents issues with upgrading BY DESIGN whereas WordPress tries their best to maintain backward compatibility.

    “”For example, to design of “Custom Content Type” in Drupal gets stored in the MySQL database; in WordPress “Custom Post Types” are stored as PHP code””
    “somewhat true if you add fields. However, if you’re looking to alter the design of the default tpl, its all in the file.”

    If I add content types then it’s all in the tpl file? How so? From my experience it’s in the database. Simply put Drupal stores a lot more of it’s configuration in the database than WordPress.

    You can dance around that subject but in the final analysis Drupal stores a lot more configuation into the database, and that makes deploying from test to production harder.

    “”It’s much easier to develop with a local copy of WordPress so WordPress developers tend to do it more often.””
    “It is no more difficult to move or localize a D or WP site. The command line makes this simple for either.”

    It has nothing to do with the command line and all to do with the comingling of configuration data in the database. Yes WordPress does it too, but Drupal has a lot more in the database than WordPress.

    Listen Adrian Webb wrote a painfully convoluted article on Drupal deployment in November 2010 PHP|Architect Unfortunately that artice is hidden behind a paywall here: http://www.phparch.com/magazine/2010-2/november/ I quote the closing as fair-use to peak interest in paying for the article for those that would like to read more (emphasis mine):

    “Mastering deployment is hard, really hard. I am not trying to tell you to do it my way. Heck, my way has issues that I am still trying to fix and compen- sate for. I guess what I am trying to do is give you an idea of what could be done. Maybe you have a system that works like a charm, and if so, you should contact me. I’d like to learn your secrets. I believe deployment is one of the most important aspects of development. It is a process that we have to per- form each and every time we create a new project
    or change a live project. It can wear us down if we don’t keep trying to make the process better. The tools are getting better all the time, but deployment still requires an integrated process and the discipline to follow it. I’m working on it. You should too.”

    So Todd, please ignore my comments for a moment and tell me how Adrian is wrong?

    Deploying Drupal is TOO DAMN HARD. Deploying WordPress is much easier.

    “In regards to your acusation that my response is disingenous I must reinforce that, despite the words chosen, if you’ve had many projects “fail” then that raises a red flag in regards to your familiarity with Drupal.”

    Why is it again that you say “you’ve had many projects” and “your familiarity.” They were NOT “my” failed projects; they were projects that I saw others working on. I can only assume you are being disingenous on purpose to paint me as not having enough experience to make an evaluation; shame on you.

    If a homebuilder writes that another homebuilder’s subdivision are failing, does that imply that he is not competent to build subdivisions by that evidence alone? Of course not.

    “”In regards to Drush, these aren’t the words of someone who is familiar with it:””
    “P.S. I’ll definitely give that Drush is a useful tool. I’ve been meaning to look at it again, and I just reviewed the video here. Suffice it is say I now have another WordPress-related “to-do”; adding a Drush equivalent to WordPress. :)”

    What part of “look at it AGAIN did you not get?!?

    “If your only tool is a hammer, everything looks like a nail. By building everything with one platform one is guaranteeing that some or many projects are on the wrong platform. WP isn’t the best solution for all sites unless you are working in a tight vertical and are building a lot of simple brochureware.”

    I never said “Build everything on WordPress.” Please quote me correctly. What I’ve said is “Don’t build using Drupal.”

    “I felt compelled to respond because of your accusations but the post just comes across as link bait and I regret having supported it by responding. It’s just too biased to be credible.”

    I could not give a damn about link-baiting. When I get a notice about a comment I actually thing “Oh shit, now I have to waste more time to go and respond to that comment.” Look at how rarely I post in the past several years and how infrequently I even comment. In general I don’t have time to deal with random people on my blog who want to disagree with my analyses using logical inconsistencies. I’d far prefer to spend my time doing something postive and productive such as .

    As for being biased, if having an opinion after using both is biased, then yes I am biased.

    If you knew me like my friends know me you’d know that I am far too idealistic (frequently to my own detriment) to take a position that I don’t passionately believe in. I wrote this blog post because I finally had enough of people recommending Drupal simply because it’s become branded as being the best open-source choice for CMS, and I rue the day that I decided to try and use it. It’s an awful choice for a CMS and far too many companies are throwing orders of magnitude more money at developing Drupal solutions than they could if they were to do on another platform, WordPress being one option.

    “Despite this I hope that you understand that I’m a big fan of WordPress. AND Drupal. They each serve their purpose.”

    Prior to WordPress 3.x I would have agreed. But today, with available plugins for WordPress, I am honestly unaware of a reason to choose Drupal over WordPress.

    As an aside,if you run into questions about WordPress, I’ll happily answer them for you at .

    “I don’t find them to be interchangeable.”

    On that hopefully we can now just agree to disagree.

  34. Hi @Jan – Thanks for asking.

    The URL rewrite project is planned to be part of a much larger project I’m working on and that part, which I wish were first is still waiting for some client funding.

    Elaborating, I’m working on a framework for WordPress that addresses more advanced content management use-cases and the needs of professional web developers. I’m working with clients that need components of that framework and developing them has me pretty stretched.

    I’m still looking for a client to fund that component and once found will either work on it myself or collaborate with some other developers I know if I don’t have the bandwidth. Once done though, I’ll release it as GPL.

    Wish I could say it was done now, but not yet.

  35. Hi Mike,

    Thank you for your time replying and answering my question. Gosh .. has it been a week since already? Excuse my late reply please. Ive been totally caught up in WordPress code cellar the past week. :p

    I totally understand what you are saying. Your answer makes perfect sense to me. So that leaves me to say I wish you all the best with your endeavors, both finding funding and coding itself. And if the time is there, I do sincerely thank you in advance for planning on releasing your work under GPL.
    Take care, Jan

  36. @Jan – Thanks for coming back to reply. BTW, one of my clients discussed wanting this just yesterday although we’ve not yet scheduled it for actual development.

  37. Thank you very much for this post. I am a long-time pro designer for static sites who started with Drupal when CMS became necessary for client sites. I’ve since moved to WordPress, mainly because the company I often sub-contract with went that way. I loved aspects of both, and pulled my hair out with each at times. Your post really helped me to understand the differences between the two (coming from design, believe me, not all are as obvious they may be coming from a programming background).

  38. This post would have had a lot more value if MikeSchinkel was as well acquainted with Drupal as he is with WP. A lot of the statements made are either factually false or extremely subjective.

    Somewhere down the line, WP won’t serve you as well as Drupal and you’ll be managing a mess of a site with WP doesn’t even support JavaScript aggregation (speaking of performance!) and loads of custom spaghetti code.

  39. @JP – I would say “Thanks for commenting” but given the ad-hominem attack I can’t say that I appreciate it. If the statements I made are “either factually false or extremely subjective” then please delineate what those are rather than rely on character assassination.

    “Somewhere down the line…
    Your prediction would hold a lot more weight if you could give specific examples of issues I’d face as I did in my post rather than generic fear mongering.

    As for lack of Javascript aggregation in WordPress: “W3 Total Cache.” Problem solved.

    Loads of spaghetti code? Spaghetti code only occurs if you write it that way; WordPress doesn’t do anything to require one to write spaghetti; did it force you to for some reason?

    For the record I was “managing a mess of a site” from the moment I started working with Drupal and not “somewhere down the line.” As for WordPress I’d say I am already pretty far down that line and the farther I go the more I’m sold on it.

  40. My partner and I are working on a new client project that requires a CMS. The client wants something off-the-shelf, so we recommended Drupal.

    While my partner, who is fairly comfortable with Drupal, suggested it due to the ease with which he could build the back and front ends, we found that the markup it generated was less than desirable (you might even call it spaghetti code). Both of us being a proponents of web standards, and producers of clean semantic code, we ultimately dumped Drupal because it spews out just the opposite.

    Though we are unsure about using WP because our perception is that it primarily a blogging engine–which is not what our client needs–we are open to looking at it as an option. Mike, maybe you can lead us to green pastures!

  41. Hey @Brion, thanks for the comment. Amazing, you gave me reason #18! I may well have to revise my post. :)

    Anyway, I’ll contact you directly about your needs; maybe we can discuss it over lunch or coffee?

  42. Dear Mike,

    Interesting blog. I came to your post through my search for a description of WordPress architecture but it leaves me hungry for more.

    Do you know of any documentation which could provide some good insights at WordPress and Drupal’s architectures.

    Best regards

    Christian

  43. Hello Mike, congratulations for your great post. Some points are too technical for me, but it’s been very helpful.

    All the sites I’ve developed are 100% Flash. But now I have in mind a project and I’m looking for a CMS. But which one? The eternal question. I’ve installed Drupal and WordPress, played a bit and I found WP much more “easy”, at least for a person like me that is more a designer than a programmer. I wonder if you could tell me if with WP I can achieve it.

    All the content will be posted by registered users (better from the front-end or from the back-end?). Posts have to be categorize by country, city and different city places. Upload photos, maybe video. And if it’s possible the users would have to have a profile with their posts and favorites.

    The anonymous visitor of the site should be able to drill down through all the posts and find, for instance, all the pots referred to restaurants from Paris/France, or one in particular if the user knows its name.

    With your experience, do you think that this can be done with WordPress?

    Thanks in advance!

  44. Dear Mike,

    Your comparison was one of the most comprehensive I’ve seen in the last 2 years (ever since I came across Drupal). I’m a business owner (non-tech) who owns a humble food site. I have mega plans now to convert that into a dynamic, user-generated food community. Like I mentioned before I came across Drupal and was impressed by its flexibility which was useful for tech-noobs like me.

    My original plan of migrating to Drupal (for a full powered social community of food content) has stayed in the drawing board. Only about a month back did I meet a entry level Drupal designer / developer and am having him customize a Drupal theme. My biggest fear is maintenance (without strong tech support) and a upgrades.

    I wrote a lengthier post at StackEchange after I read through your post and comments – http://wordpress.stackexchange.com/questions/11182/community-and-user-generated-content-website-have-been-thinking-about-drupal-but

    I’ve used WordPress as a user since 2005 and for a blog, it does its job. I see displaying content (Panels and Views), custom content types and access control (some users cannot see certain aspects of the Drupal when compared to WP, especially the clunky admin area of WordPress). Would you suggest WP for the community website?

  45. WordPress is a better CMS because it’s “easier to find skilled designers” and because “there are more ‘professionals’ available”, really ? That’s what makes a great CMS ? Thank you for the eye opener … not.

  46. Hi @Christian Lehmann,

    Thanks for the question. Unfortunately I don’t know of an obvious architecture document for either; doesn’t me there isn’t, just I don’t know about them.

    What specifically are you looking for?

    -Mike

  47. Hi @Mario Gran,

    Thanks for the comment.

    Glad to hear you are moving away from 100% Flash sites. While pretty, there are many reasons why Flash for entire websites are a bad idea, not the least of which are findability via SEO and lack of ability to bookmark and share links to specifics parts of a site.

    But yes, WordPress is much more designer friendly than Drupal. In Drupal you have to learn how to be a decent PHP coder; in WordPress not so much.

    And yes, WordPress can do what you ask brilliantly. For any specific how-to questions ask at http://wordpress.stackexchange.com.

    Hope this helps.

    -Mike

  48. Hi @RK:

    Thanks for the comment.

    It depends. When I hear people talk about creating a community site I’m often concerned they might be building a ghost town. A websites with community features does not a website make.

    In your case it sounds like you have lots of users and lots of traffic? I would build out the website if I were you and then slowly add key features, testing each one to see if people will use it. You can do this very effectively with WordPress.

    I do worry about your desire to add “friending”; every time I see a new site that wants me to friend people I think really carefully about whether or not I really need to use the site because with so many other sites with friends I don’t want yet another site to keep track of that. But maybe that’s just me.

    Lastly, I read your StackExchange post and while I unfortunately am at a phase where I can’t devote the time to answer it in depth like I have many questions in the past I’m concerned you may be trying to “boil the ocean”, especially since you are non-technical. I’d highly recommend researching the “Lean Startup” approach and deciding on what will be your “Minimum Viable Product”, and then adding things littel-by-little and doing A/B testing to determine what will really work for your community.

    Hope this helps.

    -Mike

  49. Hi @Cristian:

    Thanks for your comment.

    So, you disqualify the validity of 15 of my 17 points because 2 of my points are less than compelling in your eyes? Well I disqualify your input as worthy of consideration because you ignore the other 15 points.

    That said, in the real world the availability of talent is one of the more important selection criteria; just ask any manager who has to hire and maintain a staff. But I’m guessing you’ve never actually had to hire people, managed a staff budget, or needed to worry about retaining talent? Yeah, I thought so.

    -Mike

  50. Dear Mr. Schinkel,

    thank you very much for your patience in writing your post and replying to comments. I even learned a lot of how to deal with ad hominem attacks and general rhetoric. I’m a freelancing physicist who has to take jobs as they come and right now I’m trying to set up a website which is supposed to have a document repository and a blog announcing the latest entries in the document repository. This website shall pose as a showcase for an organization which hopefully will give me a contract for their new website, which will be quite a challenge.) Being a non-PHP coder (I usually do small to medium sized software projects which I handle with C#, VBA and AutoIt, but I’m learning…) I was a little uneasy in starting with WordPress for this website. That’s why I was looking for alternatives for WordPress. The only real contenders are Drupal, Joomla! and Textpattern. The latter one is already in decline, I’m afraid. Drupal’s reputation as flagship has been dismantled by your post. Which leaves me with the decision Joomla! or WordPress. Having done some first steps in WordPress and having read your post and the amount of responses, I’m swayed to stay with WordPress and leaving Joomla! aside. Or am I making a mistake here in disregarding Joomla!?)

    Now I make so bold as to ask you these questions:

    1) I need a database for the documents. The documents are not supposed to be “posts” but “pages”. What kind of plugin is needed to retrieve the documents with respect to their contents: “Flutter” or “Pods”? Do I need a plugin at all or can WordPress and “Custom Post Types” do the job on their own? I don’t want to let these pages (documents) “disappear into the archives”, they should easily be found by some search function (better than the one built into WordPress). Any suggestions (“WP Search 2.0.3.0”, “Search 1.0.1”, “Relevanssi – A Better Search 2.7.4”, “Search Everything 6.6”, “Search filters”, “Search Unleashed 1.0.6”, “Super Search 1.1.3”, “WP Custom Fields Search 0.3.16” or …?)

    2) In terms of customizability and code structure what is in your opinion the best Theme: “Atahualpa” (free) , “Suffusion” (free) or “Thesis” (paid)?

    3) You seem to be a very outspoken person with a no-nonsense approach. What would you charge for counseling me in a WordPress project if need arises? (Your hourly rate or per ticket or whatever. Payment can be arranged via PayPal.)

    Thank you for your patience reading this,
    Georg Huber

  51. I’ve been struggling for weeks between Drupal Commons and WP/Buddypress and I think I’m going with the later because of this. Thank you Mike!

  52. @Georg: Thanks for your comment. My opinion after looking at Joomla was it was too complicated with very little extra benefit over WordPress. However I’ve not actually used Joomla to the extent I’ve used WordPress or Drupal so I really can’t say for sure. The one thing I can say is that WordPress has at least an order of magnitude more users and sites than Joomla albeit many are “just” blogs.

    As for you documents, it sounds like you might just need a Custom Post Type of “document” and then a search plugin that would support finding them. I don’t have specific experience with those plugins so I’m not sure which you need there.

    As for a theme, I think the concept of a theme might be oversold. Most of the type I work with custom themes in part because of the clients desire for a unique branded design. But for those sites were an off the shelf theme is a good solution I’ve been leaning more to WooThemes because I like their designs and they seem to have good admin functionality too. But I’ve seen that themes are really a religious issue so you’ll have to decide what works for you.

    Thanks for the compliment and I’ve emailed you about my hourly rate to help out, if wanted.

  53. I totally agree. I start with joomla, then drupal since 4,5,6,7. , really pain. I’ve made one e-commerce website with ubercart. I want to jump to the river. Drupal is not ready in the box. What I like about Drupal is cck, and views module? I want to go for wordpress. As a beginner, pls suggest what is an equivalent views module in wordpress? I just know that pods is like cck. Thank you.

  54. Hi @ten – Thanks for the comment. The Drupal and WordPress approaches are bit different; Drupal lets the user configure via the admin, WordPress let’s the themer configure via simple PHP. So WordPress’ Views is WP_Query, but they really are apples and oranges. For client projects I like the WordPress way a lot better. That said, Pods is like CCK, and I expect at some point someone will write a Views equivalent. Are you an end-user or a themer?

  55. Thanks Mike for the advice for WP_Query. I’m an end-user and just start learning WordPress. The first time I’ve tried WordPress, I feel different. Easier, more fun, great UI. Anyway, I need to spend time to get used to how WordPress works compared to Drupal. It won’t be long. And will replace all drupal with WordPress for sure. Would you kindly ask AngryDonut to write a Views equivalent? :) I really like views.

  56. Hi Mike,

    Thanks for this post and discussion, which is one of the very few on the topic where the information is based on intimate knowledge of both platforms rather than out-of-date characterizations and generalities.

    I’m currently re-evaluating our platform of choice – we use Drupal 6 and the debate is whether to move to Drupal 7 or WordPress (we’re a small design shop, so ideally I’d like to have only one platform).

    What I’m trying to wrap my head around is where are the actual limitations (if any) of WordPress vs Drupal. Then we can decide whether we are better off going for 100% WP, 100% Drupal or a mix. So far I’ve come up with the following:

    – This comment here claims that WordPress custom post types do not do relationships (nodes / users): http://www.chapterthree.com/blog/jennifer-lampton/wordpress-vs-drupal-saga-continues#comment-24924 . Is that the case? In generally do custom post types support the same amount of fields as Drupal CCK (files, images, relationships, HTML etc etc)?

    – This comment claims that more applicative functionality is better on Drupal, in particular workflow: http://zenofnptech.org/2011/02/wordpress-vs-drupal-fight.html#comment-8614

    – This comment describes a particular case which involves a specific workflow which requires a custom admin interface which he claims “would be impossible on WordPress”: http://zenofnptech.org/2011/02/wordpress-vs-drupal-fight.html#comment-8527.

    I’ve personally had the following experiences, but it’s difficult to know if these are platform limitations or lack of expertise on the part of people I’m dealing with:

    – A WordPress consultant we’re discussing a job with wishes to completely wipe the client’s current WordPress installation, including the 140 pages of content, and start from fresh, because she claims “plugins always leave junk lying around”. I find it hard to conceive that a plugin would pollute an installation in a way where uninstalling it would leave enough of a mess that it would interfere with further work, and therefore nuking everything it the recommended course of action with each major site revamp. Is this true?

    – A partner agency, after telling me that clients find WordPress easy to use, gave me a login to a couple of their installations. It seemed to me that as soon as there was a modicum of complexity, the pages would be hardcoded in one way or another (usually as HTML handcoded in the WYSIWIG editor, but in one case the content of the homepage was in the .php template). Arguably this is a good approach – letting the client maintain only the easy pages – but it also seems like a bit of a cop-out. Is there an equivalent to Panels on WordPress?

    Finally: Organic Groups. I’m aware of pressbuddy, but it seems a little overkill for the case where you simply want a closed section of the site where people with the right permissions can post certain kinds of content. Also, this is a case where Drupal’s “there is no backend” actually comes in handy (though it can be a major headache in other situations) – being able to create a couple of links to the front end, eg to add new content and edit it means that intranet users don’t need to be “backend trained”. Can you achieve a similar effect on WordPress?

    Best,

    Ben

  57. Ah, and another one: Draggable views. The typical situation is the “team” page, where there is a pic on the left and name and some text on the right (no wrapping). Occasionally you’ll have extra stuff such as job title and a video link.

    This is generally too much of a pain for the editors to maintain in the WYSIWIG editor (you need to insert divs and make sure the images are all the right size, and you can be pretty sure the formatting will not be done consistently), so the typical solution we deploy is to have a custom content type for “team” and a view to list them. However the view needs to be manually ordered (the janitor will not be above the CEO, regardless of whose name starts with ‘A’), which is where draggable views is a lifesaver.

    How would one approach this problem in WordPress? Is there a way for editors to manually set the order of a list of posts?

  58. Hi @Ben O’Hear:

    Thanks for asking. That’s probably one of the best and most thoughtful comment and set of questions I’ve ever gotten on this blog! It’s really fodder for another blog post which I unfortunately don’t the time for this minute.

    I’m currently re-evaluating our platform of choice – we use Drupal 6 and the debate is whether to move to Drupal 7 or WordPress (we’re a small design shop, so ideally I’d like to have only one platform).

    Good idea! But from my post, of course I think so. :)

    but it’s difficult to know if these are platform limitations or lack of expertise on the part of people I’m dealing with:

    I definitely understand. I don’t have 100% knowledge of the current state of Drupal but I am pretty close to having that expertise on WordPress so I’ll help how I can.

    But first let me say that there is a philisophical difference between WordPress and Drupal. In WordPress you do a lot of things in PHP whereas Drupal pushes as much as possible to be done within the admin. And that’s where I think WordPress is better for the professional site builder who is not afraid of occassionally using PHP or the power end user who doesn’t mind researching plugins whereas Drupal is better when writing code is 100% not an option.

    Often Drupal seems easier because of being able to, for example, define fields via CCK in the admin, but that approach makes deployment and ongoing site upgrades a lot harder and it makes it extremely hard to “get around Drupal” when client requirements don’t match how Drupal thinks. It’s much easier to write a short snippet of PHP code to call WP_Query and then hard code a loop than it is to find the hooks within Drupal that are need to modify the behavior of Views, for example.

    If I’m building a plugin then “yes” I do want to use hooks; if I’m building a theme for a client’s site then, not so much; I just want to make the thing work, not have to do software engineering.

    This comment here claims that WordPress custom post types do not do relationships (nodes / users): http://www.chapterthree.com/blog/jennifer-lampton/wordpress-vs-drupal-saga-continues#comment-24924 . Is that the case? In generally do custom post types support the same amount of fields as Drupal CCK (files, images, relationships, HTML etc etc)?

    In part she has a point. There are several options for relationships WordPress, one being Pods CMS Framework that basically duplicate the functionality of Drupal CCK and another being the Posts2Posts plugin. And there are several others.

    That said, I’m working on a plugin that will be part of a family of plugins (all to be called “Sunrise” plugins) that are designed to meet the needs of the professional site builder (PSB) and to ensure that WordPress is (almost?) always the better option for the PSB than Drupal. IOW, for those areas where we currently have to say “Well, she has a point”, Sunrise’s vision is to make it so that “No, she doesn’t really have a point anymore.” :)

    The first plugin will be called Sunrise Fields and it will address the relationships issue and the issue related to being able to provide data entry fields for custom post types as well as for other objects like users, categories, etc. If you are interested I can add you to our closed beta. BTW, our goal for these will be that every single professional site builder who chooses WordPress will be using the Sunrise toolset; IOW we are hoping to set a standard.

    – This comment claims that more applicative functionality is better on Drupal, in particular workflow: http://zenofnptech.org/2011/02/wordpress-vs-drupal-fight.html#comment-8614

    Yes, Drupal has modules for admin defined workflows whereas WordPress (for the most part) currently does not.

    That said, I’m curious what workflows are actually needed? I believe most can be addressed with existing plugins or some simple PHP code in the theme. But then again I’m actually very interested in real-world business use-cases where a workflow system is actually needed because frankly we’d love to build a WordPress plugin for workflow (to be able to include as a Sunrise module), assuming we can figure out what is actually needed.

    – This comment describes a particular case which involves a specific workflow which requires a custom admin interface which he claims “would be impossible on WordPress”: http://zenofnptech.org/2011/02/wordpress-vs-drupal-fight.html#comment-8527.

    Here, she is just wrong; it’s her lack of knowledge regarding the WordPress ecosystem speaking. All of these things can be done very well using existing plugins, especially the e-commerce and membership parts. If there are more specifics that interest you, just ask.

    – A WordPress consultant we’re discussing a job with wishes to completely wipe the client’s current WordPress installation, including the 140 pages of content, and start from fresh, because she claims “plugins always leave junk lying around”. I find it hard to conceive that a plugin would pollute an installation in a way where uninstalling it would leave enough of a mess that it would interfere with further work, and therefore nuking everything it the recommended course of action with each major site revamp. Is this true?

    She is not very good; I definitely would not hire her (or maybe you misunderstood her?) While she is correct when if comes to starting with a fresh site to get rid of old plugins and other code, she is wrong in saying that you need to start from scratch with the content. You can install a new copy of WordPress, export ALL of the old content from the old site and then import back into the new install. There is no reason this require re-entering content.

    One caveat, that would apply equally to Drupal as well as WordPress is that if a 3rd party plugin stores data but does not support export/import you may need to do something custom there, but it is just a MySQL database and files on the server so there is little reason why this should be a showstopper. (We are planning to address these concerns in part via Sunrise by setting a best practice for how plugins will integrate with import/export.)

    – A partner agency, after telling me that clients find WordPress easy to use, gave me a login to a couple of their installations. It seemed to me that as soon as there was a modicum of complexity, the pages would be hardcoded in one way or another (usually as HTML handcoded in the WYSIWIG editor, but in one case the content of the homepage was in the .php template). Arguably this is a good approach – letting the client maintain only the easy pages – but it also seems like a bit of a cop-out. Is there an equivalent to Panels on WordPress?

    In most cases I don’t think this is a cop-out at all, I think this is the easier way to maintain a site. It may not seem like it at first but if it takes 1 day to make changes with WordPress but it takes 3 days to figure out how to get Drupal Panels to behave how the client wants (the 1-to-3 time comparison has been my experience) then aren’t you better off with hard coding?

    That said, I think Widgets and Widget Areas are somewhat the equivalent of Panels. You hardcode the HTML and then configure sections in the HTML to have widget areas, and then you use drag-and-drop in the admin to assign Widgets to the areas.

    In my experience professionally delivered sites don’t constantly have someone changing page layouts so the interactivity of Panels just adds overhead on every page load that you typically don’t need. Of course Panels is great for an end-user who constantly wants to fiddle with their own site and who doesn’t want to modify theme files but not so great when the process is to prepare wireframes and then comps and get clients to sign off for approval before building. So there you use Balsamiq or similar to create wireframes instead of needing Drupal Panels.

    That said, there are numerous theme vendors that are attempting to provide something that is probably even better than Drupal Panels. Check out PageLines Platform Pro, Headway and Carrington Build.

    Finally: Organic Groups. I’m aware of pressbuddy, but it seems a little overkill for the case where you simply want a closed section of the site where people with the right permissions can post certain kinds of content. Also, this is a case where Drupal’s “there is no backend” actually comes in handy (though it can be a major headache in other situations) – being able to create a couple of links to the front end, eg to add new content and edit it means that intranet users don’t need to be “backend trained”. Can you achieve a similar effect on WordPress?

    Frankly I’ve never really been able to understand the value of Organic Groups. It always seemed like so much overkill to me.

    “Can WordPress achieve a similar effect?” The answer to that question is (almost?) always “Yes, of course!” WordPress is PHP based, as it Drupal, and it can get out of the way more easily than Drupal and it’s lower level functionality is not coupled to the admin workflow like Drupal’s is (used to be?) For example, I can easily call wp_insert_post( $post_array ); to add a new post but I remember in Drupal I couldn’t do that easily because the code to add a new node expected values to be in $_POST vs. an array that was passed in.

    The first thing you probably want to look at is Gravity Forms which can let you do 90% of what you’ve asked if not 100% (you can do the additional 10% in your theme code.) Yes it’s a commercial product but for only US$35 you get support with it so typically it’s a no-brainer for a site.

    Or if you want open source only then wait for Sunrise Fields; it won’t have the admin UI that Gravity Forms does but will allow you to let people post content however you would like once you’ve configured the forms in PHP using sr_register_form( 'form_name', array( ... ) ) and sr_register_field( 'field_name', array( ... ) ) calls in your themes’ functions.php file.

    Ah, and another one: Draggable views

    How would one approach this problem in WordPress? Is there a way for editors to manually set the order of a list of posts?

    This is trivially easy to implement in a plugin using jQuery UI Draggable. That said, I expect that there are probably plugins that already do this like maybe Post Types Order.

    P.S. Also thanks, you have provided some great resources that will let me talk about Sunrise when we release. :)

    Sure thing. Hope this helped.

  59. Hi Mike,

    Thanks a ton for taking the time to provide these really useful answers. I have a “friends and family” project at hand, so I’ll give WordPress a go on that.

    I’d love acccess to your Beta of Sunrise. If I may: Make sure each plugin of your suite has a descriptive name other than “Sunrise”. If searching for a plugin to fulfill a particular function, the name is the primary source of recognition, and something like “post types order” has much more information scent.

    To follow up on a couple of points:

    – I fully agree that views being in the database is a PITA – it would actually make life a lot easier if it stored it’s stuff in the filesystem. That said, in my opinion the main attraction of views isn’t the bit of SQL it writes, but all the nitty gritty it does for you (imagecache / lightbox integration, clean truncation of text, paging, caching, linking etc). I do think that saves a fair amount of coding and debugging. Whether it makes up for the times when you are stuck and need to wade through the whole system to find the correct hook is another matter.

    – Organic groups: To give an example of where I’ve found that handy: A kindergarten site where there is (Group #1) an area for all parents where they are allowed to post pictures, recipes, documents, todos, things to sell etc and (Group #2) a similar area for the parents council. The key thing is that group members can create content as well as read it (but only for their group). If there is an easier way to achieve this than using Organic Groups, I’m all ears :-) , but that module does solve this problem comprehensively and cleanly (including protection of all attached files).

    – Workflow: I agree this is overrated. I have one example on our own site, where one person does the text and the other the images for portfolio pieces. So we have a workflow in place to make it easy to know which items each person still needs to work on. But at the end of the day, this is just a status with lists for each status. A second example was an ecommerce site where the payment was processed by the London office and product shipped by the Australian one. Again, a simple “Status/desk” situation. I have seen much more complex examples, but they were not done within a CMS (ERP or custom developments), so I don’t think that they are relevant.

    As a general rule, a system to prevent people from overwriting each others work and one which allows for the revision of a live node without having to publish the new version straight away is very useful, and should feature out of the box (AFAIK that’s not the case either on Drupal or WP).

    Incidentally, I’ve found the Bricolage CMS to have a really good workflow system for journalists, if you’re looking for inspiration.

    Thanks again!

    Ben

  60. Thanks for the follow up @Ben

    “I’d love access to your Beta of Sunrise.”

    Contact me via http://about.me/mikeschinkel

    “If I may: Make sure each plugin of your suite has a descriptive name other than “Sunrise”. If searching for a plugin to fulfill a particular function, the name is the primary source of recognition, and something like “post types order” has much more information scent.”

    Do you mean something other than “Sunrise” or something more than “Sunrise Fields?” If the former then yes, look at the latter. If the latter, then I appreciate your suggestion but it goes against our strategy to create a well-known trusted brand with simple names. We’ll instead work to get our brand known and if we are successful with that we’ll get a little more mind-share than the average 1 of 15,000+ plugins. :) Yes it will take longer to get people to find us initially but I’m confident that it’s the right marketing strategy.

    “in my opinion the main attraction of views isn’t the bit of SQL it writes, but all the nitty gritty it does for you (imagecache / lightbox integration, clean truncation of text, paging, caching, linking etc). “

    As we work on Sunrise we’ll be looking for real-world needs like these, so after looking at parts of Sunrise please do bring these issues up specifically on discussions about modules related to areas.

    “If there is an easier way to achieve this than using Organic Groups, I’m all ears :-) , but that module does solve this problem comprehensively and cleanly (including protection of all attached files).”

    To be honest when I used Drupal I never understood the value of Organic Groups; i.e. I didn’t see why they needed to create such a large module. “Allow people to create content”: I see that need; I think of that as forms that allow you to create posts on the front-end. “Allow people to discuss things”: I see that need too; I think of them as forums. But what I really struggle with is the combination of the two. I don’t understand use-cases where posts need to be made on the front end in a discussion format that isn’t, well, a forum. For the use-case you mention I would just give them all admin access albeit with a specific user role that gives them only the rights they should have. OTOH if you can help me see what’s needed maybe I’ll be of more help with a WordPress-specific solution. Or do I misunderstand and the discussion portion is not an important part of your use-case?

    Workflow: I agree this is overrated. I have one example on our own site, where one person does the text and the other the images for portfolio pieces. So we have a workflow in place to make it easy to know which items each person still needs to work on. But at the end of the day, this is just a status with lists for each status. A second example was an ecommerce site where the payment was processed by the London office and product shipped by the Australian one. Again, a simple “Status/desk” situation. I have seen much more complex examples, but they were not done within a CMS (ERP or custom developments), so I don’t think that they are relevant.

    Okay, I actually see that. And yes, it’s something I’ve been wanting to address (I need it for something.) But I almost see a workflow driven by a wizard and specialized UI for each step. IOW if you need to process payment there should be a UI specifically for processing payment and it shouldn’t just be a generic edit screen. The good news is that the Sunrise Fields module I’m working on should support that kind of thing brilliantly.

    As a general rule, a system to prevent people from overwriting each others work and one which allows for the revision of a live node without having to publish the new version straight away is very useful, and should feature out of the box (AFAIK that’s not the case either on Drupal or WP).

    Incidentally, I’ve found the Bricolage CMS to have a really good workflow system for journalists, if you’re looking for inspiration.

    Good to know, thanks. I’ll be sure to check it out.

  61. Hi Mike

    What a great post! I agree with everything you say. And I admire your patience and collect with what seems to me to be a rather hostile series of replies bordering on attacks by some of the Drupal advocates here. All rather unnecessary…. reminds me of ugly Apple fanboyism.

    I’ve been trying to build a business directory for some time now. Partly as a learning project and also to try and sell advertising space inside the directory.

    I started of with WordPress and got along with it quite well. I then came across the Genesis framework and that was nice too. Along the way, they, Studiopress, developed a sidebar plugin that enabled contextual display of certain widgets depending on what pages you were on. Due to my lack of programing skills, it had one limitation for me in that it could not be “tied in” to any particular “tags”. That was a deal breaker for me and I started looking at other things.

    And so came along Drupal 7. The way in which sidebars or rather “blocks” worked was great! And so I began to get really into it! But as your article quite correctly illustrates, there are all sorts of other things one has to learn to deal with.

    Some random observations…

    I’m no developer but a fairly competent webmaster and am pretty handy with html and css. I’ve spent more time then I would have liked to on having to continuously upgrade modules. Like every single week! I’ve had to learn and wrestle with version control. For someone who is not doing this everyday it’s somewhat stressful worrying if your doing it right or wrong when its time to update core Drupal across your staging and live sites that the good webhosts employ (as you indicated i.e premium hosting is required) Error messages are a regular occurrence when one upgrades and then there is the issue of having to apply patches…. not so easy on a windows machine. One needs to spend a lot of time maintaining this beast. Of course if you have many sites to look after, do one and the rest take very little longer. But for a single site maintainer owner…. its a time sink. And where I am, our currency is worth so little, so it’s not as easy as just hiring a European or American Drupal shop whose currency is worth 5 times ours!

    One surprising omission I see is that there is no easy way to add various meta descriptions for content in D7. There are some modules underway to do this… but that part is not too matured yet. I have found thou that their RDF framework works really well!

    The Drupal also community ain’t the most friendly. I’ve been unfairly told off when trying to help once. Moral to the story… if your a newbie there…keep your mouth shut.

    Its hard to find just D7 modules in Drupal.org as the filters don’t isolate D7 modules from the other Dx’s.

    So Mike…. After 1.5 years…. I have created a great site in D7. I love D7. I’m almost ready to now go and try and look for some people to get on the directory. But I have started looking at this beast I have created. And it’s still not finished. I have like close to 200 tables in the database already. I’m beginning to worry…. can I actually look after this beast? Will it chug to a grinding halt one day?

    And so before taking my first customers, I thought..maybe I should just checkout WordPress again. I remembered that one weakness before was the URL routing system. I read a lot about it before. Thats what led me to your article here!

    One thing that came to mind Mike and strikes a chord reading your article is that a lot of my love for Drupal comes from the fact that I don’t need to know PHP! Drupal nearly always provide a GUI for this. But at what cost?

    One thing not mentioned here, which is Drupals great strength is it’s Taxonomy. But I’m glad to see that WordPress has some interesting plugins here!

    It’s late here and it’s time to leave this cafe! Hopefully Mike I can also try your Beta Sunrise plugin? I’d be so grateful!

    And so Mike… I love Drupal immensely…. But I can see exactly where your coming from and agree with just about every one of your comments here entirely mate!

    Cheers

    mark

  62. Hi @Mark:

    Thanks for commenting, and for the great synopsis.

    I’d say the #1 reason when Drupal can be a better selection than WordPress is if you absolutely can’t learn simple PHP and/or you don’t have access to modify code on the server. Yours may be a better scenario for Drupal (though it pains me to say it…)

    That said, what you wanted to do with sidebars and pages is very doable either with plugins like WidgetLogic[1] or Dynamic Widgets[2], or with some very simply theme modifications[3]. Ironically though, with theme frameworks like StudioPress I think you’ll find that while they provide more features out-of-the-box they are harder for non-programmers to enhance than a basic WordPress theme.

    The other thing to consider is that you can get most simple questions answers on WordPress Answers, so it’s very easy to learn enough basic PHP to get done what most things want to do to their sites.

    And 200 tables scares me pretty badly. WordPress’ Custom Post Types typically don’t require new tables and because of caching the WordPress meta data architecture performs on par with Drupal or better in most cases.

    You’ve got a lot of time invested so I wouldn’t say you definitely should switch, but there’s a pretty good chance it would benefit you. I dunno, your call.

    -Mike

    P.S. BTW, what country are you from since you mention it indirectly?

    [1] http://wordpress.org/extend/plugins/widget-logic/
    [2] http://wordpress.org/extend/plugins/dynamic-widgets/
    [3] http://codex.wordpress.org/Customizing_Your_Sidebar

  63. Hi Mike!

    Thanks a lot for those links and suggestions. I will have a good look at them!

    I agree with what you say about WordPress Frameworks…. one could almost say that conceptually they’re taking you down the Drupal path :P ! Lol!

    After lots of looking, I’ve come across this great theme that is HTML 5, responsive, well coded, has micro formats and looks great from the get go!
    http://kitmacallister.com/about/

    Well, so far after a couple of days Mike, I have managed to incorporate one easily created Drupal nicety into my current template with no framework or plugin. This is where in your content types, you can have a listing of post excerpts with thumbnail images. Click on the read more link or the thumbnail, and it takes you to the full page post.

    WordPress can have a similar sort of feature. You have this Featured Image “panel” that can allow all this teaser image management to happen easily in the admin section, yet strangely the PHP code that’s needed to insert it into the posts is missing on many themes, or if it’s there it doesn’t show due to seemingly strange conditional logic.

    Despite Drupal’s great flexibility in this area Mike, of a “Teaser view” and a “full or Default view”, one issue I have is that the teaser view’s title is “hard coded”. What you can’t do is display the teaser image (or anything else) before the “title”.

    I find this rather frustrating as you end up with much taller “listing” pages. Your forced to have each title above each teaser images. It’s more efficient if the image comes before the title in the html as you can make all your listing pages “shorter” in height by getting the title on the side of each teaser image and not above it.

    But to do this in Drupal, you need to really dig deep into the core and construct your own arrays, if you even know how that is! I’d say few people do, and the few that have even mentioned it don’t show how. Emailing them resulted in no replies either sadly. Complex stuff.

    The alternative is you use views to create your own teaser view. But then we have the problem that we don’t have perfectly optimized h3 tags and end up with a multitude of divs all over the place. Enter template suggestions to try and solve this. Lots of time and lots of learning needs to be committed to achieve the ideal solution here.

    So, proving your point Mike, in just one day, with some industrious effort on my part, I have managed to figure out how to do this “teaser image with excerpts” linking to “full view image with post” that has really clean code and can be “semantically coded” for SEO goodness with the greatest of ease.

    Moral to the story is that WordPress has lots of goodness about it. But to really get it to sing and dance a really awesome Bossa Nova, you just HAVE to learn some PHP logic. Simple as that…

    As to which way to go Mike, I want to now see how far I can go with custom content types and taxonomy. If I can get a reasonable WP solution here, I will definitely switch from Drupal!

    It has to be said Mike, that I think my time spent with Drupal was a truly fantastic investment. It makes you look at things in a different way and gives you a much broader perspective on things. Armed with all the experiences from Drupal land, it becomes a lot easier going back to WordPress, because you know just what’s possible, what you need and exactly how you want things to work. Then it just becomes an issue of coding it into WordPress.

    Anyways… thanks Mike for pointing me back to WordPress.

    Regards

    P.S. Malaysia!

  64. why do the Drupal brigade get so hung up on “Views” being web development’s holy grail? Maybe I’m missing something but surely this is just using a point-and-click GUI to bypass any actual development??

  65. Hi Mike

    I stumbled across this page and not sure if you still check for new posts. I was looking for some pointers. I am not a PHP Programmer although could prob put together bits and pieces from other peoples posts when required.

    I used to use Joomla but moved to Drupal. I like Drupal as it does make things easier for me as a non php programmer but I love the WordPress admin.

    I have a project where the client wants a recruitment website setup. They want their staff to be able to login and post new jobs, administer cv’s and new users etc but without having full control over other elements of site.

    Additionally we need people to be able to register and complete a form along with uploading their CV. Their cv is not for others to view except admin.

    Once registered they will also be able to search for jobs.

    A lot of this functionality seems easy done in Drupal with views and custom content types etc but I feel WordPress looks more polished and professional but not sure how I can go about setting this up in WordPress.

    Any pointers would be great.

    ps. Client also needs their staff to be able to search for specific skills that a user has ticked when registering so that cv’s and profiles will show up based on the skills selected. The staff can then download the cv and email to the employer.

    Cheers
    Paul

  66. Honestly MikeSchinkel, have you ever used Drupal? Your 17 points, are at best ridiculous and at worst directly lying…

    I’m going to be brutally honest, W.P is great, I use it all the time for my “budget” clients and as you state…most often the upgrades is just a click a way! But “most of my clients” have specific needs demanding Drupal. I don’t have the time nor the energy to get in depth regarding this question, but saying that W.P has the same (or perhaps even better) core/framework and can handle the same complex functionality IS TO LIE!!!

  67. Hi, you’re probably trash this one as it is a simple “Thank you” comment. I wanted you to know that I am a using WP for very big business sites (lagazette.fr is around 35 000 posts) and I totally agree with your analysis (also I am not so familiar with Drupal but I’ve made my living on CMS since 99). Again Thx from France :)

  68. Well though I just emerged from drupal hell thanks to a couple PHP tricks, I still would like to keep going with drupal.

    The only reason I’m on this article is that 1) google kills knol 2) knol goes to annotum 3) annotum is wp 4) annotum tweet has interesting link to this blog

    So I gotta parse this article, having just been through a little drupal hell myself.

    Also if annotum source were not downloadable and watchable in github it’s likely I never would’ve bothered to follow the trail here… those r the facts man.

    Regards,
    Rich

  69. I m sorry I cannot just come to an idea with your post with pos+ and neg- comments whether to go for WordPress or Drupal bcoz I am just a beginner and still want to research more with a little bit encouragement from your post

  70. Honestly, drupal has his problems, but Organic group vs Buddypr
    ess is no match.

    Just spent hours trying to adapt a theme to buddypress. Are we serious? Is a sort of treasure hunt trying to find the correct Div.. seriously must be a joke.

  71. Hi,
    sorry if i say that, but this post tells me that you cant be a serious php-developer. Drupal is not just a CMS, it is a PHP-Framework for building CMS which fits all of your needs.
    Yeah, its not an ready-to-go-solution and its API has a bluff lerning-curve, but this is, because IT HAS AN API.
    It has great tools like the features-module or drush, which helps architects and developers to maintain and deploy their development in a realy proffesional way.
    It thinks in entities, not just Content- or Posttypes which is great to build intelligible webapplications in a agile way.
    Dont misunterstand me. WordPress is a great software, especially for people who arent deep enough in proffesional webdevelopment or for projects which have no special needs in its features.
    Men, you tell me its a realy reason that wordpress has an built-in wysiwig?? For drupal there is an whole api for wysiwig…
    Wordpresscode is better to manage?? Its just PHP like Drupal is. And Drupals code is very very organized. I know where to search when i search something. I am using version-control-systems to manage the code and have great drupal-specific tools like drush.
    Drupal is inflexible to desing? Dont know what you mean… in drupal i can decide which template-engine, i can controll the html-output of every module without touching the module itself and have all functions to add JS or CSS in a flexible way even if this CSS will be aggregatet for performance-reasons.

  72. @Siggi:

    So, you lead with the ad-hominem attack? So you question my abilities as a PHP developer? Returning the attack, what makes you think you are even 1/2 as good as me?

    I started programming in 1985 in Fortran, then Pascal, then I programmed taught Clipper professionally as well as I wrote a book on it from 1987-1994. I also taught database design and object oriented programming during those same years. From 1994-2006 I was a VBScript/ASP/IIS/SQL Server developer and I built one of the very first ecommerce shopping carts on the web. And I’ve been programming in PHP/MySQL/jQuery with either Drupal or WordPress since 2007. I gave a presentation to the Atlanta Drupal called “IN-DEPTH DRUPAL: ARCHITECTURE AND DEBUGGING” meetup group in 2008. I’ve reported 82 issues on the PhpStorm issue tracker and I have a top 3 reputation on WordPress Answers where most of my 350+ answers have been PHP level answers. I’ve submitted almost 100 tickets on WordPress track and over 20 patches. And most recently I gave an advanced PHP talk at two WordCamps entitled Mastering Custom Post Types.

    So now I’ll ad-hominem you; what qualifies you to attack me by questioning my abilities with PHP? How many years programming experience do you have? How many different languages besides PHP have you programming professionally using? Let me guess; you’ve been a programmer less than 10 years and Drupal was your first love and you’ve made no posts and contributed no commits on Drupal.org?

    In summary let your arguments attempt to discredit mine, don’t try to attack me by saying “You can’t be a serious PHP developer” (as if there were a real definition of serious PHP developer. Hmmph.)

    Now on to your points:

    • WordPress is also a PHP-Framework for building CMS which fits all of your needs. I know, I’ve been doing exactly that as a PHP developer for over 1.5 years.
    • WordPress HAS AN API, and it’s a rather damn large one, thankyouverymuch.
    • WordPress doesn’t have “Features” per se because as implemented it’s a bad idea (storing most everything in the database) and WordPress has wp-cli.
    • Maybe you’ve heard the old saw about Regular Expressions? Well I’ll paraphrase The Drupal community realized they had a problem with organizing content because everything wasn’t a Node, so they created Entities. Now they have two problems.” But I do get your point; that’s why Sunrise will be releasing “Objects” as a first class concept and hopefully the WordPress community will follow Sunrise’s lead.
    • If you think that WordPress is not for professional web development or that it can’t handle special needs then you’ve simply not been paying any attention to the WordPress space.
    • Drupal’s WYSIWYG editor options is like the man with many watches; he never really knows what time it is. There needs to be one primary so that it can become standardized for end users, and plugin and theme developers can just assume it is there; WordPress has it, Drupal does not.
    • Drupal’s code is well organized, but architected in a highly inflexible way. It’s like saying “He worked really hard every and then he was fired. Why? Because he worked hard doing the wrong things.”
    • I know where to search for code in WordPress; your point?
    • I am using version-control to work with WordPress and have great tools like wp-cli as well as PhpStorm. No real difference there.
    • Drupal is highly inflexible to design; Drupal forces a designer to write hooks and those hooks must run where Drupal wants them to; Drupal places content where it wants, not where the designer wants. Unless you want to bypass most of Drupal, which is kinda against the whole point of a CMS.

    Listen, I get it. You have fun programming PHP in Drupal for whatever reason. But just because you like programming it in PHP does not make it a better CMS than WordPress.

  73. I like this example, http://www.themarthablog.com/ http://www.marthastewart.com/ both communities have to pick their battles. The real question is where to place value for development on projects. Which battles have been won before not between each other but against the technical problems themselves. That is the point of a procurement strategy and many people think that can copy others but its just not that straight forward.

  74. @Marcus – Thanks for the comment. Your point isn’t completely clear to me but I think you are saying that we should work together to solve technical problems, that Drupal should be used for CMS and WordPress should be relegated to blog use? Did I get that correct? If yes then I do see how as a Drupal person you might feel that way.

    OTOH I’ve got a strong opinion that Drupal’s current architecture makes it a less optimal solution vs. WordPress in most CMS use-cases. Sure, we can all put on our technical hats and sing kumbaya but frankly that doesn’t help situations when companies are pouring huge sums of money into Drupal solutions when they could be getting a less-expensive and better solution with WordPress.

    I chose WordPress because I believe its a better platform for most CMS use-cases than Drupal. I could have stayed with Drupal, and if I had there would be lots of income opportunities here for me because lots of the local Fortune 500 companies are using it (we have 11 in Atlanta.) But watching this happen pains me greatly when I know that many of those companies could be paying 1/2 the cost to build WordPress apps and would end up with solutions that would be easier for designers to theme, easier for the developers to program, easier for systems people to deploy and manage, and most important they would have solutions that end-users would not hate.

    So this is not about technical, this is about politics, and by that I mean money. I wrote this post because far too much money is being poured into Drupal when those spending the money would get a better all-round solution if they were to work with WordPress instead.

  75. If I had to mention one thing that really has frustrated me with WordPress in all the years we’ve worked with it, it would have to be lack of consistency across plug-ins. Countless plug-ins have left cruft in their own custom tables and/or the common settings table, even after those plug-ins were uninstalled or upgraded.

    As for deployment, we have had considerable difficulty finding all the little places in the database where each plug-in decides to store the site path. A lot hard-code the filesystem path to things, making for some painful search-and-replace during deployments.

    I can also say that the “one-click upgrade” has left many a site broken, due to the lack of a consistent API or convention for each plug-in to follow for how to handle it.

    It disturbs me that, even though you say WordPress is worried about “backward compatibility”, there’s nothing in the core to prevent you from installing a plug-in that’s not compatible. In the worst case, you get a WSOD, and you have to go into the database and disable it. At best, it is up to the developer to read what version of WordPress (including the *minor version*) each plug-in is compatible with, and to only pick those compatible.

    I also do not like how WordPress encourages developers to modify site code through the UI, including plug-ins. That’s a recipe for a difficult upgrade path down the road.

    None of these issues have come up with any of the countless Drupal sites we’ve created in the past few years. Why?

    – Drupal has a well-defined API for modules to perform installation and uninstallation, and lets you know when modules have not been uninstalled. There is occasional cruft left behind by modules that don’t implement it properly, but the Drupal community process makes it easy for people to catch these types of things, especially now with automated testing built-in to Drupal.org. In addition, the well-structured design of the Drupal database makes it easy to catch.

    – Standard tools, like Drush and Aegir, automate deployment of Drupal sites and automatically correct site paths in the database. It has been quite some time since I’ve had to go fishing through the database to manually correct old paths.

    – Modules explicitly declare what version of Drupal core they work with. You can’t accidentally install an old module for, say, Drupal 6 on Drupal 7. In addition, the core API is stable across an entire major version, so there’s no need to pay attention to the minor version when picking a module. If a module does require a specific minor version because of a bugfix that went in for that version, it says so, but this is quite rare.

    For us, at the end of the day, it’s how Drupal handles these scenarios and, as Richard Schulte pointed out, the fact that plug-ins build off of one another that has set us on a Drupal path. WordPress, for us, does not provide enough structure or power, and feels too much like the archaic days of using Dreamweaver and HTML to construct basic sites. Today’s sites demand dynamism and flexibility — “hard coding” the site or rolling your own code to tell the CMS how to be a CMS is simply not suited to roll with the web in the long term.

    My question to you: with all that hard coding you say is standard and acceptable practice with WordPress, how easy do *you* find it to create a mobile version of a WordPress site? Does it require a separate theme? Can you give users a mobile version of the admin UI on WordPress? Can you slim that admin UI down to just what users will need to do from the mobile device, specific to the use case, or is it just the generic “content editing” UI that all WordPress sites use?

    That’s the stuff that makes me satisfied at the end of the day to be running Drupal.

  76. Hi @Guy Paddock,

    Good points all, and thanks for commenting.

    I agree that WordPress has lots of poorly written plugins, but I don’t think that makes WordPress itself bad; it just means that WordPress is easy. Most WordPress pros quickly learn how to identify plugins that are likely to be problematic and then they avoid those, or they take them to learn how and they build their own that they can control.

    I also agree that the hardcode paths are an issue, but again we avoid those plugins and/or know how to handle them.

    Most plugins just work with prior versions so if WordPress were to disable them from being able to be installed then it would optimize for the rare cases instead of the common case. But if you’d prefer to disable plugins that are not compatible (i.e. the ones where the developer has not yet stated they are compatible) then it would not be hard to write a plugin to make it so. And for those who can’t write such a plugin, they shouldn’t point the loaded gun at their feet and pull the trigger.

    WordPress does NOT encourage developers to modify site code through the UI; the edit feature is there for those who have zero access to uploading files via FTP, which is many users. Again, if you dislike that you can easily remove the Edit feature (we do for our clients.)

    I’d say you had none of those issues with Drupal because you specialize in Drupal, you don’t specialize in WordPress. Your site is Drupal and your company provides Drupal hosting (there, I gave you an SEO link. You are welcome.) If you specialized in WordPress you’d know its best practices like you evidently know best practices for Drupal. I can speak better English than I can Spanish; why is that a surprise?

    Drupal has Drush and Aegir, WordPress has wp-cli and Migrate Webhosts.

    Drupal modules declare Drupal versions because Drupal breaks compatibility with each version. With WordPress that’s not needed like it is with Drupal.

    Mobile versions: Responsive Web Design. There are literally hundreds of how-to links via Google. I assume I don’t need to provide those links here.

    As for the “feel” of Drupal vs. WordPress, “To each his own” as my dad would say. After 2 years of working with Drupal doing a WordPress project felt like a breath of fresh air to me. FWIW.

    Again, thanks for the comment.

    -Mike

  77. I’m a firm believer in using the best tool for the project at hand.

    I would be very interested if you could take a look at the latest version of Drupal Commons and tell us how you might duplicate/improve the majority of features using WordPress instead.

  78. Hi @Leon,

    Thanks for the comment.

    I appreciate the challenge but I don’t have time (nor interest) in developing expertise on Drupal Commons. OTOH if you can list the top 3 to 5 aspects of Drupal Commons that you believe are key then I can more easily answer the challenge.

    P.S. Regarding the “right tool for the job” meme, I’m a strong believer that one should not evaluate tools in a vacuum. To me the fact that WordPress has 8 times the market share of Drupal for CMS and the fact that 3rd party services are much more likely to invest in developing plugins for WordPress before they do for Drupal, if at all is a factor that ranks extremely high on my list. Given that criteria alone Drupal is rarely the right tool for the job, IMO anyway.

  79. Mike,

    I wanted to thank you for your great article.

    I was for years locked into Drupal because I did not think that WordPress had an equivalent to CCK in Drupal 6 or Fields in Drupal 7, nor had an equivalent to Views.

    I HATE being tied into Drupal because of the many reasons you mention, for me one of the most frustrating things about Drupal in the update process.

    Your article motivated me to research things further.

    I was able in less than a day:

    Create custom fields, using Advanced Custom Fields plugin
    Create custom content/post types, using hard code in function.php
    Create an exposed search form and use user input to search in multiple custom fields

    So I was very happy.

    However, where I ran into a wall is trying to search using a multiple value select list.

    In Drupal, if you create a custom field that is a select list and allows multiple values, then if you use that field in Views, views automatically creates an exposed select list which allows multiple values.

    I find that VERY hard to do in WP and if you have any suggestions that would be very much appreciated.

  80. Hi @Mike,

    Thanks for the comments.

    What’s the context for your Multiple Value Select list? Is it in the admin? Is it basically that Advanced Custom Fields does not offer such a multiple value select list?

  81. Hi Mike,

    I appreciate you asking me more about the issue with the Multiple Value Select list – especially because I realize I did not explain the issue very clearly. That is because it is a complicated thing to describe.

    I am going to work on finding some other solutions and if I still have trouble I will pass it by you…..

  82. You make some good points but I still would not consider WordPress for anything beyond a basic site.. yet.
    I am happy to hear about custom post types. Its a start.
    I design and develop custom themes for Drupal but I have built and themed some WordPress sites as well. WordPress can be more forgiving in some ways (especially to theme) but there so many things in Drupal the WordPress doesn’t have yet.
    The big one is Drupal Views. Also Context, Panels and Rules.
    One of the things that WordPress is lacking in that plugins don’t leverage eachother the way that Drupal modules do.
    As you mentioned there is more code duplication in WordPress. It is always easier to just write it yourself than to collaborate with others.
    I build WordPress sites when a client asks for it. If they need anything beyond a blog, some pages a more complex system like Drupal just makes sense.
    I say the best tool for the job.

    Currently I work for a company that is replacing WordPress, Buddypress, Magento and a custom PHP CMS and with Drupal.

  83. Hi @Taiger;

    Thanks for the comment.

    You make some good points, especially about how plugins don’t leverage each other. That is unfortunate. But I think it is changing.

    Regarding Drupal Views, Context, Panels and (I think) Rules, that is a preference you have that I don’t. There are easy ways to achieve similar in WordPress using PHP code, and I’d much rather have site architecture in PHP code vs. data in the database. Plus, coding it can result in better performance; Drupal’s abstractions have abstractions and all the abstractions require a heavy server and drain performance.

    When I mentioned code duplication I wasn’t implying that people don’t collaborate, I was referring to duplication in the theme only.

    I agree “Best tool for the job.” To me, however, a critical component is “How many people use and support the tool?” Hands down it’s WordPress over Drupal on that one.

    And my company no longer does Drupal, only WordPress. We feel like doing both would just be splitting our focus, minimizing our expertise and wasting our time.

  84. Hi Mike,

    Mike here, I am the OP of post #91 above: http://mikeschinkel.com/blog/17-reasons-wordpress-is-a-better-cms-than-drupal/#comment-110573

    In this post I indicated that I was excited about moving away from Drupal, main reason being that I hate the update process.

    Well I have now spent a month evaluating WP and comparing it to D7.

    I have created an extensive comparison list of all major features, programming, etc.

    And I have decided to go back to Drupal for many reasons.

    I also would take issue with a number of the 17 points you make above.

  85. Hi Mike,

    Re my post #91 and you asking me to publish my list of comparisons..

    I think it is important to take into account the requirements of various developers or builders of a website. In other words, your requirements, priorities, etc may be different than mine. Hence different features and issues of Drupal and WordPress will have different importance to each of us, and the other readers and posters on this post.

    In that case there is no absolute best, only relative bests, that depend on the paradigm of each person.

    I am more of a developer of websites for myself – typically membership based websites. It sounds like you are more developing sites for others. This alone will affect how we see WP and D7.

    So I don’t think it is wise of me to say “D7 is better than WP for these reasons” – I could only say “D7 is better than WP for me for these reasons”

    Therefore I am not sure if it is productive for me to list my comparisons….

  86. Hi Mike,

    I find your post and start to read, but from the text and from your comment #4 I see you want fight vs Drupal YES or YES!

    @Mike “With WordPress it is often a “Click to Upgrade” and you done. Can you say the same for Drupal?”
    You said that you prefer WP because with one click you can make a upgrade and because will be more friendly for ‘normal user’, and I’m agree. But just in the same text you attack the flexibility of Drupal with a crazy argument:
    @Mike “WordPress is infinitely customizable using PHP, jQuery, et. al. And I personally find it much easier to build plugins for than I found to build modules for Drupal.”

    So finaly, you want do things ‘with one click’ or develop the solution with PHP, Jq, et.?? ;)

    I’m a Drupal developer, but I don’t have nothing vs WP, even, I think is the best options for a simple project, maybe a blog or something similar. Are diferents tools for diferent projects and for diferent users and both are great!

  87. Hi @Hedmon,

    Thanks for the comments.

    I think you misunderstand the context of my comments. One click to upgrade makes it easier for the user admin; architecture makes it easier for the site implementor. On more implementations, you need both.

    FWIW, the latter comment came from my experience where it’s much easier to add functionality via plugins and themes with WordPress vs. modules and themes with Drupal. My experience, my opinion.

    -Mike

  88. This article is $hit. wordpress is better for simple sites. i have designed a site for a business and it–like most businesses–wanted wordpress because any fool can use it. It took my a few hours to learn wordpress.

    I am developing a more complex site on Drupal now. You can’t do this site on wordpress, becasue wordpress can’t handle complex tasks. Drupal is the one for complex tasks, probably better than a framework for most things.

    You are talking nonsense.

  89. @Luke

    Thanks for taking the time to comments.

    However your criticisms are too non-specific to be worth considering, especially with ludicrous claims to have learned such a large codebase “in a few hours.”

    Plus I can’t take anyone serious who can’t be bothered to (or may not be educated enough to know that you should) spell correctly and use proper English correctly, nor especially to capitalize the proper noun “I.”

    -Mike

  90. i wanted to emphasize some errors / misinformations in your original posts, but seeing how blindly you defend your “ideas” i will refrain.
    btw, i use both platforms, as a developer, and when i have read the post+replies, didn’t know weather to laugh or cry.
    you obviously lie when you are saying you know drupal.
    you act like a typical newbie programmer who choked on drupal before even beginning to understand it.

    and another thing: why do you convert this into a war between 2 open source tools? is there something you gain from this? maybe if you successfully bash the “competition” you will gain more possible clients for you?

    or are you just too lazy to master and use more than one framework, and are trying to advocate your decision? beats me.

    i will go back programming in both these platforms, because both are very fine, and very easy to work with. yes, both have + and -, but these differences help me decide which one should be used ina certain situation. there are cases when both are overkill/under-performers, and then i use custom coding from scratch, or using zend/codeigniter/both, depending on situation.

    the key is flexibility and adaptability, not gathering “believers” to support a person’s low self esteem.

    PS: when someone characterizes himself az an “idealist” or “perfectionist” it usually raises a red flag, because that person is not worth reasoning with. he fanatically believes something, like religion and any naysayers are heretics worthy of holy purging by fire.
    and your replies reflected exactly this.

  91. Hi @serena,

    Normally I thank people for their comments, but in this case I won’t because all you did was offer a personal attack. And because you chose personal attack I won’t address any of the points you addressed; why lower myself to the level of responding to personal attacks?

    -Mike

  92. I would like to thank Mike for this post. If I had found this earlier I might have been able to convince my bosses to use WordPress instead of Drupal for our corporate social site.

    I am using Drupal Commons and it is really bloated. To give an example it has a dozen different types of posts that people can add to groups (discussions, wikis, documents, blog posts, etc). Theses are directly visible in the user interface, so using it as such imposes that complexity onto the end-user.

    Getting to understand what is going on when you start from scratch with Drupal Commons is very uphill going, as there are so many layers of modules stacked one on top of the other. Does that content come from a template file? From a View? From a Context? Which one?

    I thought Drush was really dandy to start with, but it’s been reporting cryptic error messages lately. Features looks like a good idea but getting it to work is another matter.

    One big difference I see between WP and Drupal is that in WP people get to give their ratings on plugins. In Drupal such an idea would be considered as sacrilege: how can a mere user pass judgement on the glorious work of fully fledged member of the Drupal community? Maybe that’s the reason why documentation on Drupal modules is often simply not there, or else hiding in some readme.txt file inside the delivery, or given in the form of answers to issues.

  93. definitely wordpress is much better!! and also joomla!! these 2 are far more powerful than drupal, i have worked recently with drupal and it almost killed me! thanks for your beautiful ideas ;) they are facts

  94. First I’m a designer first, so every time I’ve seen a response that had the word “code” in it my head goes “not what I’m looking for”. I’ve been developing sites for ugh, almost 16 years and finally researched and made the switch to developing CMS-based sites in 2009 rather than hand-coding everything and then handing it off to a programmer when I couldn’t do it myself (I try).

    When I researched CMSs in 2009 I was really turned off by the plugin community in WordPress since so many that had the features you wanted cost money. As I’ve paid for Photoshop filters and CyberStudio/Dreamweaver plug-ins for sooo many years, that just didn’t feel right to me. I looked over quite a few others and found Drupal to have the most “tools” in free modules that would allow me to build-out sites I needed. While other CMSs like WordPress offered lots of modules, many, as stated over and over again in other comments were basically sandboxed into their own functionality and didn’t work with other plugins/modules/systems to bridge the gap when needed.

    I’m in no way saying there’s not a way to make it happen by hand coding, but to me, using a CMS should be more about building using a UI, not hand coding. If you want to code, use a more lightweight framework and slim everything down. Me, I was trying to move away from coding and found almost everything I could imagine in the right Drupal modules.

    But I think that’s a catch there as well and isn’t tied to any one CMS. The time it takes to find, research, implement and test all these plug-ins/modules is really one of the two major drawbacks and hinderances when it comes to development time for your own sites or for clients. I’ve spent at least 4 months solid on that for Drupal 6 and have just done the same for Drupal 7 within about 2 months (albeit a lot of those are still in dev versions and have their bugs).

    Drupal does have a seriously steep learning curve and I can’t imagine anyone putting together a complex site in under a few months. Simple stuff, yeah. I went through waves of “I’ve got this”, to then hit the valley of “oh $hit, what the hell is this” or “how do I get this there”. Once you’ve gone through that and actually understand how these modules work together you can put together something in far less time than when you were first learning but Drupal and the massive options it and primarily the contributed modules offer are time consuming but make it flexible.

    I do however feel the direction of Drupal 7 and how different modules are now taking the place of D6 modules to form a better future is of great importance in any comparison. Drupal 6 was more limited, D7 with modules and themes offers more modern necessities like adaptive/responsive design and HTML5/semantic coding which was one of my primary reasons for updating my library to Drupal 7.

    I’m not really offering a comparison of WordPress in it’s current state and plug-ins versus Drupal 7 in it’s current state and it’s modules, but just wanted to add some experiences on here about Drupal as many discussions seemed one-sided and I disagreed with many of the points as they have been overcome in many ways between D6 to D7 migration (honestly don’t have the will to go into all that and have been reading this for what 2 hours now, so need to get back to work).

    I do not like dealing with so many updates and dead ends with modules in Drupal but feel that once you spend the time to test through and find what actually works as stated, you have a pretty solid and comprehensive toolbox to work with.

    I do have mixed feelings on how end-of-life of modules happens in modules in Drupal, but realize it’s generally necessary in order to move on to the next evolution of development and user experience. This does strand data in the database at times when upgrading to newer major versions, but at that point it’s probably a good idea to clean the slate anyway from a corporate brand and message perspective but sucks when dealing with massive amounts of user contributed data on more social sharing sites. One of those where timing and choosing the right version when initially developing is of great importance, but with what I’m seeing as a far too rapid turnover of major versions and dropping of older versions support in Drupal, I’m feeling like Drupal does indeed require commitment and additional time 6 or so years later to redevelop a new version of the site when the “switchover” happens again for the next great version.

    I appreciate everyone’s views on the VS. It’s needed, open source or not to keep all CMSs up to modern expectations. I do wish Drupal would somehow completely overhaul it’s admin section/content managment where settings are more contextual when viewing the site/content so you don’t have to go digging into various multiple pages to make changes to content and interface, but I’m not sure that’s going to happen in Drupal 8.

    If I were to contribute my opinion on the VS, it would be that if you have time and more time to develop and redevelop, Drupal might provide a wider toolbox for people that need to user a User Interface and not hand code the whole thing. But it sounds like if time is limited, WordPress sites might have longer shelf lifes but not have quite as much admin UI for complex functionality.

    I do see wisdom though in using modules/plug-ins instead of coding in order to take advantage of others’ testing and debugging as well as feature add-ins without having to recode (though some new features do require redevelopment but I can’t see that being more complex than hunting down coding across hundreds of thousands of files and multiple databases).

    Onward and upward! Pick your poison.

  95. First I’m a designer first, so every time I’ve seen a response that had the word “code” in it my head goes “not what I’m looking for”. I’ve been developing sites for ugh, almost 16 years and finally researched and made the switch to developing CMS-based sites in 2009 rather than hand-coding everything and then handing it off to a programmer when I couldn’t do it myself (I try).

    When I researched CMSs in 2009 I was really turned off by the plugin community in WordPress since so many that had the features you wanted cost money. As I’ve paid for Photoshop filters and CyberStudio/Dreamweaver plug-ins for sooo many years, that just didn’t feel right to me. I looked over quite a few others and found Drupal to have the most “tools” in free modules that would allow me to build-out sites I needed. While other CMSs like WordPress offered lots of modules, many, as stated over and over again in other comments were basically sandboxed into their own functionality and didn’t work with other plugins/modules/systems to bridge the gap when needed.

    I’m in no way saying there’s not a way to make it happen by hand coding, but to me, using a CMS should be more about building using a UI, not hand coding. If you want to code, use a more lightweight framework and slim everything down. Me, I was trying to move away from coding and found almost everything I could imagine in the right Drupal modules.

    But I think that’s a catch there as well and isn’t tied to any one CMS. The time it takes to find, research, implement and test all these plug-ins/modules is really one of the two major drawbacks and hinderances when it comes to development time for your own sites or for clients. I’ve spent at least 4 months solid on that for Drupal 6 and have just done the same for Drupal 7 within about 2 months (albeit a lot of those are still in dev versions and have their bugs).

    Drupal does have a seriously steep learning curve and I can’t imagine anyone putting together a complex site in under a few months. Simple stuff, yeah. I went through waves of “I’ve got this”, to then hit the valley of “oh $hit, what the hell is this” or “how do I get this there”. Once you’ve gone through that and actually understand how these modules work together you can put together something in far less time than when you were first learning but Drupal and the massive options it and primarily the contributed modules offer are time consuming but make it flexible.

    I do however feel the direction of Drupal 7 and how different modules are now taking the place of D6 modules to form a better future is of great importance in any comparison. Drupal 6 was more limited, D7 with modules and themes offers more modern necessities like adaptive/responsive design and HTML5/semantic coding which was one of my primary reasons for updating my library to Drupal 7.

    I’m not really offering a comparison of WordPress in it’s current state and plug-ins versus Drupal 7 in it’s current state and it’s modules, but just wanted to add some experiences on here about Drupal as many discussions seemed one-sided and I disagreed with many of the points as they have been overcome in many ways between D6 to D7 migration (honestly don’t have the will to go into all that and have been reading this for what 2 hours now, so need to get back to work).

    I do not like dealing with so many updates and dead ends with modules in Drupal but feel that once you spend the time to test through and find what actually works as stated, you have a pretty solid and comprehensive toolbox to work with.

    I do have mixed feelings on how end-of-life of modules happens in modules in Drupal, but realize it’s generally necessary in order to move on to the next evolution of development and user experience. This does strand data in the database at times when upgrading to newer major versions, but at that point it’s probably a good idea to clean the slate anyway from a corporate brand and message perspective but sucks when dealing with massive amounts of user contributed data on more social sharing sites. One of those where timing and choosing the right version when initially developing is of great importance, but with what I’m seeing as a far too rapid turnover of major versions and dropping of older versions support in Drupal, I’m feeling like Drupal does indeed require commitment and additional time 6 or so years later to redevelop a new version of the site when the “switchover” happens again for the next great version.

    I appreciate everyone’s views on the VS. It’s needed, open source or not to keep all CMSs up to modern expectations. I do wish Drupal would somehow completely overhaul it’s admin section/content managment where settings are more contextual when viewing the site/content so you don’t have to go digging into various multiple pages to make changes to content and interface, but I’m not sure that’s going to happen in Drupal 8.

    If I were to contribute my opinion on the VS, it would be that if you have time and more time to develop and redevelop, Drupal might provide a wider toolbox for people that need to user a User Interface and not hand code the whole thing. But it sounds like if time is limited, WordPress sites might have longer shelf lifes but not have quite as much admin UI for complex functionality.

    I do see wisdom though in using modules/plug-ins instead of coding in order to take advantage of others’ testing and debugging as well as feature add-ins without having to recode (though some new features do require redevelopment but I can’t see that being more complex than hunting down coding across hundreds of thousands of files and multiple databases).

    Onward and upward! Pick your poison.

    (also when submitting this the first time on this WordPress site I got a White Screen of Death with errors, sooooo……..)

  96. First I’m a designer first, so every time I’ve seen a response that had the word “code” in it my head goes “not what I’m looking for”. I’ve been developing sites for ugh, almost 16 years and finally researched and made the switch to developing CMS-based sites in 2009 rather than hand-coding everything and then handing it off to a programmer when I couldn’t do it myself (I try).

    When I researched CMSs in 2009 I was really turned off by the plugin community in WordPress since so many that had the features you wanted cost money. As I’ve paid for Photoshop filters and CyberStudio/Dreamweaver plug-ins for sooo many years, that just didn’t feel right to me. I looked over quite a few others and found Drupal to have the most “tools” in free modules that would allow me to build-out sites I needed. While other CMSs like WordPress offered lots of modules, many, as stated over and over again in other comments were basically sandboxed into their own functionality and didn’t work with other plugins/modules/systems to bridge the gap when needed.

    I’m in no way saying there’s not a way to make it happen by hand coding, but to me, using a CMS should be more about building using a UI, not hand coding. If you want to code, use a more lightweight framework and slim everything down. Me, I was trying to move away from coding and found almost everything I could imagine in the right Drupal modules.

    But I think that’s a catch there as well and isn’t tied to any one CMS. The time it takes to find, research, implement and test all these plug-ins/modules is really one of the two major drawbacks and hinderances when it comes to development time for your own sites or for clients. I’ve spent at least 4 months solid on that for Drupal 6 and have just done the same for Drupal 7 within about 2 months (albeit a lot of those are still in dev versions and have their bugs).

    Drupal does have a seriously steep learning curve and I can’t imagine anyone putting together a complex site in under a few months. Simple stuff, yeah. I went through waves of “I’ve got this”, to then hit the valley of “oh $hit, what the hell is this” or “how do I get this there”. Once you’ve gone through that and actually understand how these modules work together you can put together something in far less time than when you were first learning but Drupal and the massive options it and primarily the contributed modules offer are time consuming but make it flexible.

    I do however feel the direction of Drupal 7 and how different modules are now taking the place of D6 modules to form a better future is of great importance in any comparison. Drupal 6 was more limited, D7 with modules and themes offers more modern necessities like adaptive/responsive design and HTML5/semantic coding which was one of my primary reasons for updating my library to Drupal 7.

  97. First I’m a designer first, so every time I’ve seen a response that had the word “code” in it my head goes “not what I’m looking for”. I’ve been developing sites for ugh, almost 16 years and finally researched and made the switch to developing CMS-based sites in 2009 rather than hand-coding everything and then handing it off to a programmer when I couldn’t do it myself (I try).

    When I researched CMSs in 2009 I was really turned off by the plugin community in WordPress since so many that had the features you wanted cost money. As I’ve paid for Photoshop filters and CyberStudio/Dreamweaver plug-ins for sooo many years, that just didn’t feel right to me. I looked over quite a few others and found Drupal to have the most “tools” in free modules that would allow me to build-out sites I needed. While other CMSs like WordPress offered lots of modules, many, as stated over and over again in other comments were basically sandboxed into their own functionality and didn’t work with other plugins/modules/systems to bridge the gap when needed.

    I’m in no way saying there’s not a way to make it happen by hand coding, but to me, using a CMS should be more about building using a UI, not hand coding. If you want to code, use a more lightweight framework and slim everything down. Me, I was trying to move away from coding and found almost everything I could imagine in the right Drupal modules.

    But I think that’s a catch there as well and isn’t tied to any one CMS. The time it takes to find, research, implement and test all these plug-ins/modules is really one of the two major drawbacks and hinderances when it comes to development time for your own sites or for clients. I’ve spent at least 4 months solid on that for Drupal 6 and have just done the same for Drupal 7 within about 2 months (albeit a lot of those are still in dev versions and have their bugs).

  98. First I’m a designer first, so every time I’ve seen a response that had the word “code” in it my head goes “not what I’m looking for”. I’ve been developing sites for ugh, almost 16 years and finally researched and made the switch to developing CMS-based sites in 2009 rather than hand-coding everything and then handing it off to a programmer when I couldn’t do it myself (I try).

    When I researched CMSs in 2009 I was really turned off by the plugin community in WordPress since so many that had the features you wanted cost money. As I’ve paid for Photoshop filters and CyberStudio or Dreamweaver plug-ins for sooo many years, that just didn’t feel right to me. I looked over quite a few others and found Drupal to have the most “tools” in free modules that would allow me to build-out sites I needed. While other CMSs like WordPress offered lots of modules, many, as stated over and over again in other comments were basically sandboxed into their own functionality and didn’t work with other plugins or modules or systems to bridge the gap when needed.

    I’m in no way saying there’s not a way to make it happen by hand coding, but to me, using a CMS should be more about building using a UI, not hand coding. If you want to code, use a more lightweight framework and slim everything down. Me, I was trying to move away from coding and found almost everything I could imagine in the right Drupal modules.

    But I think that’s a catch there as well and isn’t tied to any one CMS. The time it takes to find, research, implement and test all these plug-ins or modules is really one of the two major drawbacks and hinderances when it comes to development time for your own sites or for clients. I’ve spent at least 4 months solid on that for Drupal 6 and have just done the same for Drupal 7 within about 2 months (albeit a lot of those are still in dev versions and have their bugs).

    Drupal does have a seriously steep learning curve and I can’t imagine anyone putting together a complex site in under a few months. Simple stuff, yeah. I went through waves of “I’ve got this”, to then hit the valley of “oh $hit, what the hell is this” or “how do I get this there”. Once you’ve gone through that and actually understand how these modules work together you can put together something in far less time than when you were first learning but Drupal and the massive options it and primarily the contributed modules offer are time consuming but make it flexible.

    I do however feel the direction of Drupal 7 and how different modules are now taking the place of D6 modules to form a better future is of great importance in any comparison. Drupal 6 was more limited, D7 with modules and themes offers more modern necessities like adaptive or responsive design and HTML5 or semantic coding which was one of my primary reasons for updating my library to Drupal 7.

    I’m not really offering a comparison of WordPress in it’s current state and plug-ins versus Drupal 7 in it’s current state and it’s modules, but just wanted to add some experiences on here about Drupal as many discussions seemed one-sided and I disagreed with many of the points as they have been overcome in many ways between D6 to D7 migration (honestly don’t have the will to go into all that and have been reading this for what 2 hours now, so need to get back to work).

    I do not like dealing with so many updates and dead ends with modules in Drupal but feel that once you spend the time to test through and find what actually works as stated, you have a pretty solid and comprehensive toolbox to work with.

    I do have mixed feelings on how end-of-life of modules happens in modules in Drupal, but realize it’s generally necessary in order to move on to the next evolution of development and user experience. This does strand data in the database at times when upgrading to newer major versions, but at that point it’s probably a good idea to clean the slate anyway from a corporate brand and message perspective but sucks when dealing with massive amounts of user contributed data on more social sharing sites. One of those where timing and choosing the right version when initially developing is of great importance, but with what I’m seeing as a far too rapid turnover of major versions and dropping of older versions support in Drupal, I’m feeling like Drupal does indeed require commitment and additional time 6 or so years later to redevelop a new version of the site when the “switchover” happens again for the next great version.

    I appreciate everyone’s views on the VS. It’s needed, open source or not to keep all CMSs up to modern expectations. I do wish Drupal would somehow completely overhaul it’s admin section or content managment where settings are more contextual when viewing the site or content so you don’t have to go digging into various multiple pages to make changes to content and interface, but I’m not sure that’s going to happen in Drupal 8.

    If I were to contribute my opinion on the VS, it would be that if you have time and more time to develop and redevelop, Drupal might provide a wider toolbox for people that need to user a User Interface and not hand code the whole thing. But it sounds like if time is limited, WordPress sites might have longer shelf lifes but not have quite as much admin UI for complex functionality.

    I do see wisdom though in using modules or plug-ins instead of coding in order to take advantage of others’ testing and debugging as well as feature add-ins without having to recode (though some new features do require redevelopment but I can’t see that being more complex than hunting down coding across hundreds of thousands of files and multiple databases).

    Onward and upward! Pick your poison.

    (also when submitting this the first time on this WordPress site I got a White Screen of Death with errors, sooooo……..finding that slashes create an error in comment submissions, hmmmmmmm? So they were all changed to ” or ” above as I’m not going to rewrite but find & replace since there doesn’t seem to be Transliteration for WordPress.)

  99. (when submitting this the first time on this WordPress site I got a White Screen of Death with errors, sooooo……..finding that slashes or something create an error in comment submissions, hmmmmmmm? So they were all changed to ” or ” above as I’m not going to rewrite but find & replace since there doesn’t seem to be Transliteration for WordPress. and that didn’t work either so my real comment isn’t to be submitted, this is a test to see if comments work at all here)

  100. I read practically all your comments and seeing that this was written a while back, a lot has changed. I am researching content for a presentaion I have to do later for a CMS Lightning talk and you have given me a WHOLE lot of points to present.I was at a disadvantage because I had never used another CMS more than my 1 week stint with Mambo. It has been Drupal ever since. But reasons to switch were never compelling, so I have not even ever installed WordPress, even though I hear its amazingly simple to do. (Not simpler than my drupal command line 1 command script). So I approach your list, point for point from a very biased, yet blissfully so perspective. I am yet to see greener grass so until then, until I’m proven wrong, here is my rebuttal.

    1. WordPress Allows Infinite Design Flexibility:
    There is ABSOLUTELY no design I have never been able to implement using Drupal themeing and I develop from psd from designers who are CMS agnostic

    2. Usability has been “Baked-in” to WordPress:
    So I’ve heard, with Drupal, all you need to acheive this is setting proper permissions to hide irrelevant stuff and installing modules like admin and adminmenu

    3. WordPress has a WYSIWYG Content Editor in Core
    This was by design for a number of reasons, WHICH ONE!! or build a substandard WYSIWYG editor? Infact my practice is to avoid them where possible to prevent horrible user formatting that ends up in Myspace looking sites. I instead force typography with CSS and teaching basic formatting rules like h1 h2 h3 em etc.

    4. WordPress Strives to Maintain Backward Compatibility
    Nowadays I upgrade my drupal sites like this: drush up or drush site-upgrade

    5. A WordPress-based Website’s Source Code is Easier to Manage
    Drupal does a lot of config in the DB, so its easier for normal people to config, but if you are technical enough to need code, then install features, strongarm etc. In Drupal 7 – Almost everything is exportable to code. Most forward thinking Drupal shops use Git or some other VCS to maintain their config

    6. Collaborative Development is Easier with WordPress

    Answered by #5

    7. Revisions of WordPress-based Websites are Easier to Deploy

    Looking for Query management in code, enter drupal Entity Field Queries which is part of Drupal core, did I mention it was database agnostic?
    By the way it integrates with every other drupal module

    8. Easier to Find Skilled Designers for WordPress
    I think you just have been looking in the wrong place. I look for jobs at groups.drupal.org/jobs and it is VERY COMPETITIVE. I am usually one of MANY applicants for jobs, especially if telecommute is allowed. The fallacy of which you speak about knowing code is incorrect. In a typical Drupal theme, the most complex code you will see on a typical design is IF constructs and PRINT statements. 1 hour tutorial fixes that.

    9. There are More WordPress Professionals Available
    This is probably true, there are also more Mechanics for Toyotas than BMWs. That statistic by itself means nothing. In fact that that should encourage you to do Drupal dev.

    10. WordPress Professionals Charge Lower Rates
    So do Toyota mechanics… One would argue that a technical tool needs more skilled higher paid professionals but I have no statistics for that, it could just be marketing because I hear Sharepoint devs make a killing. Yet another useless statistic because so do prolog, OS kernel and lisp devs

    11. WordPress’ Code is Much Easier to Debug
    This can be considered a feature, depends on how you look on it. Drupal’s module are TIGHTLY INTEGRATED with the core API, this allows for seamless interoperability with all its contrib and core modules. So you may need to be forced to understand what you are doing before writing “slap-on, patchy” code. Which I “hear” WordPress is Nototrious for – then again I have never used WordPress, so that just hear say

    12. WordPress Sites Load Much Faster than Drupal Sites
    Admittedly, its slower, but not SEO damaging slower. Plus if you are REALLY concerned about speed then do the default caching drupal offers, or use memcached, APC etc. Or do away with the sql queries alltogehter by simply installing the BOOST module for Drupal, that converts all your pages into static html files

    13. WordPress Requires Less Expensive Hosting
    This is True yet false. False for the typical user who just runs his regular brochureware site, Drupal is hosted on practically ALL shared hosting $4/month servers. For the slashdot effect or big sites see measures in #12

    14. WordPress has the Most Integrations
    This is a biased view, I am YET to find a third party tool that I needed that Drupal never had some sort of integration with. You have to bet his one with actual examples

    15. WordPress has More Robust Extensibility
    This is by design and if you admit it, you would need to access the same hook twice in one module, just pop in a simple IF statement for the various paramenters of that hook. And I would think its obvious that if one module disables a hook, you could either go there to modify the “disabling” or re-enable it in a simple 5 liner module.

    16. WordPress has Far More High-Quality Attractive Themes
    This is also a function of the purpose Drupal sites are used for. Most people with websites have blogs, which usually mean they have wordpress. Because it was designed for that and does that pretty well. Well… Drupal was not designed to be a blog…only. It was designed to actually do much more than blogging, infact blogging is considered a low hanging fruit. Most drupal sites require custom branding – For blogs, thats not always the case. To prove this, check the top downloaded themes on drupal.org – The VAST majority are “Base themes” so I doubt its as esoteric as you claim. These base themes when installed are plain white pages, with tonnes of “customizability”. Stuff like HTML5, responsiveness, mobile and SEO capapble out of the box.
    With this the possibilities of design are literally limitless.

    17. Lastly (for my list, at least) there is a WordPress Answers but not one for Drupal
    Drupal Answers have been up and running for some time now, but I forgive that statement since this was written some time ago. This was also a function of the greater number of “bloggers” who used wordpress, it says nothing about the quality of the product.

    ALSO to address your potential #18
    18. reasons why WordPress is a better CMS than Drupal
    If you want a “CMS” and not Drupal the CMF then install one of the many “Drupal Distributions” available. You will get a specialised CMS + the extensibility of a CMF – top that ;-)

    Since I see you giving out SEO priveleges. I will take this opportunity to present myself as an available Drupal freelancer: (I do wordpress to Drupal conversions too) http://drupal.org/user/34622

  101. I read practically all your comments and seeing that this was written a while back, a lot has changed. I am researching content for a presentaion I have to do later for a CMS Lightning talk and you have given me a WHOLE lot of points to present.I was at a disadvantage because I had never used another CMS more than my 1 week stint with Mambo. It has been Drupal ever since. But reasons to switch were never compelling, so I have not even ever installed WordPress, even though I hear its amazingly simple to do. (Not simpler than my drupal command line 1 command script). So I approach your list, point for point from a very biased, yet blissfully so perspective. I am yet to see greener grass so until then, until I’m proven wrong, here is my rebuttal.

    1. WordPress Allows Infinite Design Flexibility:
    There is ABSOLUTELY no design I have never been able to implement using Drupal themeing and I develop from psd from designers who are CMS agnostic

    2. Usability has been “Baked-in” to WordPress:
    So I’ve heard, with Drupal, all you need to acheive this is setting proper permissions to hide irrelevant stuff and installing modules like admin and adminmenu

    3. WordPress has a WYSIWYG Content Editor in Core
    This was by design for a number of reasons, WHICH ONE!! or build a substandard WYSIWYG editor? Infact my practice is to avoid them where possible to prevent horrible user formatting that ends up in Myspace looking sites. I instead force typography with CSS and teaching basic formatting rules like h1 h2 h3 em etc.

    4. WordPress Strives to Maintain Backward Compatibility
    Nowadays I upgrade my drupal sites like this: drush up or drush site-upgrade

    5. A WordPress-based Website’s Source Code is Easier to Manage
    Drupal does a lot of config in the DB, so its easier for normal people to config, but if you are technical enough to need code, then install features, strongarm etc. In Drupal 7 – Almost everything is exportable to code. Most forward thinking Drupal shops use Git or some other VCS to maintain their config

    6. Collaborative Development is Easier with WordPress
    Answered by #5

    7. Revisions of WordPress-based Websites are Easier to Deploy

    Looking for Query management in code, enter drupal Entity Field Queries which is part of Drupal core, did I mention it was database agnostic?
    By the way it integrates with every other drupal module

    8. Easier to Find Skilled Designers for WordPress
    I think you just have been looking in the wrong place. I look for jobs at groups.drupal.org/jobs and it is VERY COMPETITIVE. I am usually one of MANY applicants for jobs, especially if telecommute is allowed. The fallacy of which you speak about knowing code is incorrect. In a typical Drupal theme, the most complex code you will see on a typical design is IF constructs and PRINT statements. 1 hour tutorial fixes that.

    9. There are More WordPress Professionals Available
    This is probably true, there are also more Mechanics for Toyotas than BMWs. That statistic by itself means nothing. In fact that that should encourage you to do Drupal dev.

    10. WordPress Professionals Charge Lower Rates
    So do Toyota mechanics… One would argue that a technical tool needs more skilled higher paid professionals but I have no statistics for that, it could just be marketing because I hear Sharepoint devs make a killing. Yet another useless statistic because so do prolog, OS kernel and lisp devs

    11. WordPress’ Code is Much Easier to Debug
    This can be considered a feature, depends on how you look on it. Drupal’s module are TIGHTLY INTEGRATED with the core API, this allows for seamless interoperability with all its contrib and core modules. So you may need to be forced to understand what you are doing before writing “slap-on, patchy” code. Which I “hear” WordPress is Nototrious for – then again I have never used WordPress, so that just hear say

    12. WordPress Sites Load Much Faster than Drupal Sites
    Admittedly, its slower, but not SEO damaging slower. Plus if you are REALLY concerned about speed then do the default caching drupal offers, or use memcached, APC etc. Or do away with the sql queries alltogehter by simply installing the BOOST module for Drupal, that converts all your pages into static html files

    13. WordPress Requires Less Expensive Hosting
    This is True yet false. False for the typical user who just runs his regular brochureware site, Drupal is hosted on practically ALL shared hosting $4/month servers. For the slashdot effect or big sites see measures in #12

    14. WordPress has the Most Integrations
    This is a biased view, I am YET to find a third party tool that I needed that Drupal never had some sort of integration with. You have to bet his one with actual examples

    15. WordPress has More Robust Extensibility
    This is by design and if you admit it, you would need to access the same hook twice in one module, just pop in a simple IF statement for the various paramenters of that hook. And I would think its obvious that if one module disables a hook, you could either go there to modify the “disabling” or re-enable it in a simple 5 liner module.

    16. WordPress has Far More High-Quality Attractive Themes
    This is also a function of the purpose Drupal sites are used for. Most people with websites have blogs, which usually mean they have wordpress. Because it was designed for that and does that pretty well. Well… Drupal was not designed to be a blog…only. It was designed to actually do much more than blogging, infact blogging is considered a low hanging fruit. Most drupal sites require custom branding – For blogs, thats not always the case. To prove this, check the top downloaded themes on drupal.org – The VAST majority are “Base themes” so I doubt its as esoteric as you claim. These base themes when installed are plain white pages, with tonnes of “customizability”. Stuff like HTML5, responsiveness, mobile and SEO capapble out of the box.
    With this the possibilities of design are literally limitless.

    17. Lastly (for my list, at least) there is a WordPress Answers but not one for Drupal
    Drupal Answers have been up and running for some time now, but I forgive that statement since this was written some time ago. This was also a function of the greater number of “bloggers” who used wordpress, it says nothing about the quality of the product.

    ALSO to address your potential #18
    18. reasons why WordPress is a better CMS than Drupal
    If you want a “CMS” and not Drupal the CMF then install one of the many “Drupal Distributions” available. You will get a specialised CMS + the extensibility of a CMF – top that ;-)

    Since I see you giving out SEO priveleges. I will take this opportunity to present myself as an available Drupal freelancer: (I do wordpress to Drupal conversions too) http://drupal.org/user/34622

  102. Hi,

    Good read, I have worked in both but mostly in Drupal and that too in Drupal 6. I liked it until and unless i ran into some trouble which were usually related to architecture. I haven’t done that much in wordpress to compare both but I have a question here:

    – With Drupal 7 focusing on usability (and get it right somewhat) but what about database structure, they are saving every custom field in its own table, seriously? I mean I have Drupal 6 sites with content types having more than 30 fields, so now I will have 30 more tables for them and even 30 more for revision control? What about my custom queries where I need to get/filter few of those fields against a node? 30 Joins?

    So you are thinking same what I am or is it only me?

    Let me know if you have time.

    Thanks

  103. I don’t know about Drupal or WordPress, but I drive a Porsche and a Chrysler MiniVan. I can give you 17 reasons why my MiniVan is a much better car than my Porsche, as long as all the reasons involve moving a lot of large cargo.

    ps-I don’t actually own a car, but I will consider my point driven home.

  104. Hi @Issa

    Thanks for commenting. I’m glad to see that you’ve helped those people having a mid-life crisis to see reality and instead have them spend their money on the things their families need.

    -Mike
    P.S. I see your point, and I raise you mine. :)

  105. Very good post.

    I am a Drupal user and I git freaked when I realised that all the sites im building in v6 (which I was trained in when i was a web developer) are going to be obsolete when 8 comes out and their security will lessen and lessen as Drupal no longer supports.

    I think this is bad practice from Drupal given that you only have a couple of years or so between each major release…

    However I would like a video or something that shows upgrading wordpress between major versions…it cant be THAT simple can it?

    Even in the digital agency i worked in when we upgraded from D5 to D6, we just created the site from scratch and imported the content using CSVs (took a lot of excel work)

  106. I agree with some of these; however, as it was written in 2010 it is sorely out of date. Even in 2010 it was incorrect on many points. I think any Drupalista who knows anything about Drupal would agree with the following:

    1. Drupal allows for **infinite** design and flexibility, if you know what you are doing. If you want to stick to pre-made themes and only contrib modules out-of-the-box then you’re missing out big-time.

    2. This is true, less so today, except that I have been able to create my own user-friendly interfaces using Drupal’s framework that blow the doors off of anything WordPress. This seems to be a very common theme amongst these 17 points — out-of-the-box vs. what-you-can-actually-do.

    3. Drupal uses the same WYSIWYG editors as other CMSes, including WordPress. tinyMCE and (F)CKEditor are just two of the more popular ones. Also, please note that Drupal’s core is NOT meant to be all-inclusive, and the WYSIWYG was left out purposefully. It is a core, not the whole apple. That’s why there are modules and hooks.

    4. If implemented correctly, Drupal is just as upgradeable. This may refer to Drupal 5?

    5. Not relevant, and not correct. Not even remotely correct. There are many ways to use your VCS of choice with Drupal, including having “all in code.” This is the approach we use. DTAP, remote developers, and Drupal get a long just fine.

    6. This is also not correct. We develop locally (MAMP) and push/deploy using git. No conflicts.

    7. Look up “Aegir.” One click deployment is one of Drupal’s specialties if using drush (the DRUpal SHell). There are many approaches to this, to maintain DTAP, versioning, accountability, etc. If you’re developing and deploying and you have to continually update the database manually, it’s being done wrong.

    8. Only the title of this item is true. Although it helps to know PHP, it is not required unless you want to do any of the cool stuff — some of which you just can’t do in WordPress.

    9. This is true, however.

    10. Not all of us are expensive, but I do see your point. One big thing I’ve seen over and over is that WordPress devs (not all, of course) don’t know enough about application development to do things properly. I typically see the house of cards issue in WP sites, not Drupal ones. Just my experience.

    11. Blanket statement, and incorrect. Breakpoints, dpm(), kpr(), the Devel module, integration with IDEs, even a Firebug plugin — Drupal is just as easy to debug as WP.

    12. Absolutely incorrect. Every Drupal site I manage (and had a hand in creating) is actually *faster* than every other WordPress site I manage. Every single one. And that’s a lot of them. I tune both Drupal and WordPress sites as one of my main responsibilities. The only time I see a WP site run faster than a Drupal site is if the WP site was created by a superstar and is relatively simple, and the Drupal site was done poorly by somebody, usually somebody with less than 3-4 years of experience.

    13. Yes, this one is probably correct. However, WordPress can definitely benefit from good hosting. Too many people try to run WP (and Drupal) on what we call the “GoDaddy $5 Special” and fail miserably. Again, I tune. Using subpar servers is like buying a Toyota Tercel and expecting it to run like a BMW. You get what you pay for. Again, this is my experience, not theory. I see it day in, day out.

    14. No, it doesn’t. You’re using Google’s “estimated” searches to determine this? That’s not going to give an accurate depiction at all. Plus, if you add the Services module into the mix, the integrations become infinite. Really, integrating with new external services is a breeze (now?)

    15. How much experience do you have with Drupal’s architecture? This statement suggests that you do not have much, or what you have is very outdated. I DON’T mean that as a dig at you, I just don’t like seeing incorrect information being disseminated by someone not qualified to do so. Again, nothing personal — I mention this because many people try Drupal and fail because they don’t properly understand the big picture. I’ve seen people with the big “Drupal Sucks” sign around their necks when it turns out they’ve only been using it for 1-2 years, or less, and still don’t know what check_plain() does, or t() and l(), or how to write a test.

    16. This is way out of date at best, or at worst, just wrong. Drupal themes these days are built on frameworks. Zen, Omega, Fusion, 960gs, … the list goes on. Off-the-shelf themes should not even be a thought for a real business. There are plenty of marketplaces where designers sell their themes. And they’re a lot better than the free ones. There aren’t many professionals who start a theme from scratch, and the ones who do are probably being forced by a small gremlin under the desk.

    17. It’s nice that WP has a message board where you can post questions, and get answers relatively quickly, in a matter of hours or days. There’s a really nice one for Drupal which has been around since the beginning. Go to IRC. Join any one of the Drupal rooms that is relevant to your question. Ask the question. Get immediate answers from experts in the Drupal community. In real time. 24/7. For free.

    Don’t get me wrong, WordPress rocks. I love it. I love what’s good about it, and I even kind of like the stuff that’s bad about it. But an article like this with so much misinformation should be either taken down, or updated to reflect what is correct. Maybe you posted this to start a Drupal-vs-WordPress, Mac-vs-PC, Diet-vs-Regular, Yankees-or-Red Sox flame war. ;)

    Thanks for reading!

    Mike

  107. As someone who has used both, I disagree vehemently. With all due respect, going through your list, nearly everything is a matter of you not knowing how to properly use Drupal.

    Drupal is far superior to WordPress. It has a lot better modules, better development community, and contrary to this article, is FAR more flexible.

    Looking at your reasons I have to wonder if you’ve actually even used Drupal. Most of your comparisons show clearly that you are heavily biased toward WordPress and are not reviewing this objectively or being intellectually honest. I know because I’ve been in that same boat. I used to love WP and was resistant to learn Drupal. Once you learn it, Drupal beats WP. I know so many people who have been in this same exact boat and come to the same conclusion.

    1. Drupal allows infinite design flexibility too. As I said, I’ve used both. If you can’t do something in Drupal it’s because you don’t know how, not because Drupal is inflexible. Personally I find I save time overall. Some things are easier, some harder, but in general most is quicker to set up in Drupal once you get the hang of it.

    2. WordPress comes a lot more “user-friendly” out of the box. That is, it’s friendly to the guy who wants to post a blog. It is NOT friendly to the developer. Moreover, a decent Drupal install bypasses this. Drupal is infinitely customizable and it is fully possible to create a MUCH better experience than what WordPress offers out of the box. WordPress is ok for standardized things, but when you get to custom work it becomes a complete pain and not user friendly at all.

    3. WYSIWYG is easy to add to Drupal, and if you don’t need it you shouldn’t have it, this is not a sound point in the slightest.

    4. The backward-compatibility comes at the cost of feature improvements. It takes them longer to do less and in a less extensible way because they are trying to support something that was built 10 years ago. This can be either a pro or a con, depending on the project, it certainly doesn’t help to prove that WP > Drupal.

    5. No, Drupal has better source code. This is an extremely minor point IMO, but still you are wrong. I have no idea where you got the idea that WP beats Drupal on this. Maybe you’re using Drupal wrong.

    6. That’s a laugh. I’m sorry but that’s just absurd. I guess it would depend on the project but for a large majority of basic websites, shopping carts, or really most projects, I’ve found it a lot easier to collaborate on Drupal.

    7. Ah, finally a point you’re actually right about. I will give this to WordPress, it is easier, but once you have a good process down to do it in Drupal it really isn’t a huge deal.

    8. Design is not relative to the CMS! You talk of finding “skilled designers” but if these designers only do WordPress they aren’t “skilled” at all. They are clueless! HTML and CSS do not change between CM systems! lol. And the idea that you need to know PHP to theme Drupal, is preposterous.

    9. Yes there are more of them. There are also more cheap PCs out there than expensive ones, but the expensive ones are obviously still better. Your point is moot yet again.

    10. Yes, they charge lower rates because they provide inferior products.

    11. I don’t know what gives you that idea. Drupal has good debugging tools, so does WordPress. It’s just a matter of what you’re more familiar with, and how tricky the bug you’re trying to squash is. I completely disagree that this is a function of CMS, since both have very good tools available.

    12. No, Drupal is definitely faster than WordPress. This is a benchmarked fact, plenty of research out there to prove this one totally and utterly wrong. Drupal sites are near instantaneous. The caching in Drupal is absolutely superior to WP, anyone who knows the first thing about caching can tell you that! Drupal has an amazing system! Yes it is a bit of a resource hog, on the back end, but the insanely good caching makes up for this and easily causes Drupal to surpass every other CMS out there for raw page load time. If you’re getting slow load in Drupal, your install and/or your server are improperly configured.

    13. Pure silliness. You can host either system on $5/month bargain bin if you really want to. When you get to high-traffic sites, there are gains and losses. Ultimately though, page load time is faster in Drupal, and I think that’s far more important to most than the expense of hosting when you’re talking about high-traffic.

    14. You can integrate just about anything with Drupal too. Yeah, more companies support WordPress out of the box, but this just doesn’t even show up as a blip on the radar when I am considering between CMSs.

    15. This is a pretty vague problem you’re describing. I guarantee, whatever specific thing you are trying to do that can be done in WP, can be done in Drupal. I will give you that it could turn out to be a bit harder, but all the gains are worth this in my opinion. Again your point is so vague that it’s hard to counter, if you have a specific instance though I guarantee Drupal can handle it.

    16. Oh lord. Not only is it completely subjective, it’s totally untrue. It is not harder to create a Drupal theme, that idea is nuts and just flat out wrong. Drupal is easier to theme, by far. As I said, I’ve done both. So I have no idea where you’re getting your theory, but it’s totally wrong. TOTALLY wrong. There are a lot of great themes for Drupal. Other CMSs are scrambling to copy what Drupal theme developers are doing, for example, with Omega. It is on the forefront of responsive web design. It is the best theme I’ve ever worked with for any CMS. There are plenty to choose from for both systems, if you can’t find decent Drupal templates you’re not looking hard enough.

    17. This isn’t true any more. Nor was it ever, frankly. Just because there wasn’t a stack exchange for Drupal before WordPress does not mean WordPress is better! It means it’s more popular, which is something we all already know and something that is irrelevant if you’re seeking the best tool for a given job.

    I used to have the same attitude as you, before I actually knew how to use Drupal. Learn Drupal, you will find it is better for most projects, but more importantly you will find that it is stupid to speak in absolutes like this. Saying WordPress is a better CMS than Drupal is EXACTLY THE SAME as saying an Apple is a better fruit than an Orange. They are both fruits and they both serve their purpose well.

  108. Hi @Jt,

    Thanks for commenting.

    As someone who has used both, I disagree vehemently.

    Where I live it’s a free country, so you are entitled.

    With all due respect, going through your list, nearly everything is a matter of you not knowing how to properly use Drupal.

    You make one of my points; Drupal requires a lot more expertise.

    Drupal is far superior to WordPress. It has a lot better modules, better development community, and contrary to this article, is FAR more flexible.

    That’s your opinion. I disagree.

    Looking at your reasons I have to wonder if you’ve actually even used Drupal. Most of your comparisons show clearly that you are heavily biased toward WordPress and are not reviewing this objectively or being intellectually honest. I know because I’ve been in that same boat. I used to love WP and was resistant to learn Drupal. Once you learn it, Drupal beats WP. I know so many people who have been in this same exact boat and come to the same conclusion.

    I used Drupal professionally 2 years before I ever wrote a line of code for WordPress professionally (I think I did some hacking on my own blog once before that.) I gave this presentation entitled IN-DEPTH DRUPAL: ARCHITECTURE AND DEBUGGING to the Atlanta Drupal meetup group back in 2008, a year before I started working with WordPress.

    1. Drupal allows infinite design flexibility too.

    You are right if you don’t mind duplicating lots of Drupal code. But practically speaking, you are wrong. Drupal is more of a framework and WordPress more of a library. Frameworks are less flexible by nature. The Drupal Node/Block structure is the prime example.

    2. WordPress comes a lot more “user-friendly” out of the box. That is, it’s friendly to the guy who wants to post a blog. It is NOT friendly to the developer.

    Your opinion, not mine. I’m a developer, have been since 1987. Wrote a book on programming in 1990. After 2 years of Drupal and 6 weeks of WordPress I
    hated developing for Drupal and really enjoyed developing for WordPress. And I’ve been developing plugins for WordPress for 3 years now continue to enjoy it even more.

    Drupal is infinitely customizable and it is fully possible to create a MUCH better experience than what WordPress offers out of the box.

    Much better for the Drupal true believer, maybe, but IMO not for the average user.

    3. WYSIWYG is easy to add to Drupal

    Too many options make Drupal’s WYSIWYG a mess.

    and if you don’t need it you shouldn’t have it, this is not a sound point in the slightest.

    Huh? Seriously? (It’s easy to remove WYSIWYG in WordPress if you really need to.)

    4. The backward-compatibility comes at the cost of feature improvements.

    Theoretically, but that hasn’t stopped major improvements in WordPress over many versions. I’d say both have improved but WordPress hasn’t forced the painful and expensive “forklift upgrade” like Drupal has.

    Constraints can be beneficial, you should try them.

    5. No, Drupal has better source code. This is an extremely minor point IMO, but still you are wrong. I have no idea where you got the idea that WP beats Drupal on this. Maybe you’re using Drupal wrong.

    This is probably the #1 most important point, funny you say its minor. And I love how you limit validating your opinion to more opinion. Give better reasons other than you think it’s better. In my case, the tangible reason Drupal is such a pain compared to WordPress is that Drupal embeds a lot more logic in its MySQL tables.

    6. That’s a laugh. I’m sorry but that’s just absurd. I guess it would depend on the project but for a large majority of basic websites, shopping carts, or really most projects, I’ve found it a lot easier to collaborate on Drupal.

    Saying it’s absurd doesn’t not make you correct. You must has just scanned #5 and #6 because it’s clear to me you didn’t understand what I wrote. tl;dr?

    Please reread and you’ll see that code is easier to manage than data in version control. For example Drupal store node configuration in MySQL, WordPress stores custom post type registration in PHP.

    I can deploy a new custom post type to a live WordPress site by committing the code change to version control; you can deploy a new custom content type to a live Drupal site as easily?

    7. Ah, finally a point you’re actually right about. I will give this to WordPress, it is easier, but once you have a good process down to do it in Drupal it really isn’t a huge deal.

    Funny, you agree with #7 and disagree with #6 and #5 yet the former is because of the latter two.

    8. Design is not relative to the CMS! You talk of finding “skilled designers” but if these designers only do WordPress they aren’t “skilled” at all. They are clueless! HTML and CSS do not change between CM systems! lol. And the idea that you need to know PHP to theme Drupal, is preposterous.

    Okay, I’ll give you that I should not have said “Designer”, I should have said “Themer.” OTOH, when I worked with Drupal I had designers create designs that simply couldn’t be duplicated in Drupal w/o duplicating and then hacking lots of Drupal’s core code.

    9. Yes there are more of them. There are also more cheap PCs out there than expensive ones, but the expensive ones are obviously still better. Your point is moot yet again.

    Better how? Drupal is better is some ways. Just not better in most ways, which I have outlined on this page ad nauseum.

    10. Yes, they charge lower rates because they provide inferior products.

    Inferior products? Whatever.

    11. I don’t know what gives you that idea. Drupal has good debugging tools, so does WordPress. It’s just a matter of what you’re more familiar with, and how tricky the bug you’re trying to squash is. I completely disagree that this is a function of CMS, since both have very good tools available.

    What gives me that idea is experience. Drupal uses a lot more shared code than WordPress so it’s much harder to set a breakpoint that you don’t have to revisit many times than with WordPress. And WordPress code organization, which looks less DRY at first is actually much easier to find the proper code to debug. Again, that’s just from my experience. You might be such a Drupal guru that your experience differs.

    BTW, what exactly is your WordPress experience? Did you spend two+ years developing WordPress plugins before you found Drupal so you too can speak authoratively on this subject?

    12. No, Drupal is definitely faster than WordPress. This is a benchmarked fact, plenty of research out there to prove this one totally and utterly wrong. Drupal sites are near instantaneous.

    Are you on crack? What benchmarks do you want to present? If so, why not link to one? How about >this one?

    Benchmarks are like statisticians; you know “Liars, Damn Liars, and then Statisticians.” :) Let’s look at the underlying architecture. Drupal can run hundreds of MySQL queries to load a single page. Default WordPress? Less than 5.

    The caching in Drupal is absolutely superior to WP, anyone who knows the first thing about caching can tell you that! Drupal has an amazing system!

    What evidence do you have that Drupal cache is absolutely superior to WP Total Cache?

    And this much vaunted caching doesn’t help Drupal users at all when using the admin, which is one of the things I found most painful about Drupal.

    Yes it is a bit of a resource hog, on the back end, but the insanely good caching makes up for this and easily causes Drupal to surpass every other CMS out there for raw page load time. If you’re getting slow load in Drupal, your install and/or your server are improperly configured.

    Either Drupal or WordPress can be made to load insanely fast if the server architecture has been set up by seasoned professionals. We’re talking about performance for the rest of us.

    13. Pure silliness. You can host either system on $5/month bargain bin if you really want to.

    Who’s being silly now? Low traffic sites don’t really matter here, other than the poor speed of the admin.

    When you get to high-traffic sites, there are gains and losses. Ultimately though, page load time is faster in Drupal, and I think that’s far more important to most than the expense of hosting when you’re talking about high-traffic.

    So, you are saying that it’s silly to worry about how many simultaneous users can be served by a given server? Funny, I bet your CFO doesn’t agree. Drupal is a pig for server resources when compared to WordPress. To run Drupal on a high traffic site requires more money be spent on servers. Period.

    Even this guy doesn’t claim Drupal is a performance champion: http://drupal.stackexchange.com/a/37279

    I spoke with the people at Akiban Server and much of their business is fixing Drupal performance problems because of all the MySQL joins. I tried to get them interested in WordPress but we couldn’t find anyone who really needed it. WordPress simple scales much better given their fewer MySQL joins.

    14. You can integrate just about anything with Drupal too. Yeah, more companies support WordPress out of the box, but this just doesn’t even show up as a blip on the radar when I am considering between CMSs.

    May not be a consideration for you, but it’s a HUGE consideration for me and a lot of business people. Why should we have to write our own integrations (which can be very costly and time consuming) if someone else is going to do it for us?

    15. This is a pretty vague problem you’re describing. I guarantee, whatever specific thing you are trying to do that can be done in WP, can be done in Drupal. I will give you that it could turn out to be a bit harder, but all the gains are worth this in my opinion. Again your point is so vague that it’s hard to counter, if you have a specific instance though I guarantee Drupal can handle it.

    It’s not vague at all. Hooks in WordPress uses add_action( $hook_name, $function_name ) and add_filter( $hook_name, $function_name ) to register hooks. Drupal uses function naming conventions, i.e. “{$module_name}_cron()” for example. In WordPress I can hook cron as many times as I want, and any other plugin can remove those hooks if needed.

    Drupal doesn’t allow one that one hook per module nor does it allow hooks to be added by one module or to be removed or reordered by another.

    Is this difference really that hard for you to grasp?

    16. Oh lord. Not only is it completely subjective, it’s totally untrue.

    Numbers are not subjective. Here’s a simple metric. List Ten (10) commercial theme vendors that specialize in Drupal. If you can I’ll list twenty five (25) that specialize in WordPress (and that will be the tip of the iceberg.)

    It is not harder to create a Drupal theme, that idea is nuts and just flat out wrong. Drupal is easier to theme, by far.

    Why do you make statements w/o any justification to back them up? The reason Drupal is harder to theme is you have to use hooks to theme which means the designer has to provide a design that can be sliced that way and/or they need to be minimally competent in PHP.

    WordPress theming only requires function calls by the themer and/or it’s easy for a designer to provide any HTML+CSS that a PHP dev can turn into a WordPress theme.

    Drupal REQUIRES the HTML+CSS to be structured to fit Drupal, which HTML+CSS designers who don’t have Drupal experience will almost always fail to create compatibly. Most designers just don’t think that way, in my experience.

    As I said, I’ve done both. So I have no idea where you’re getting your theory, but it’s totally wrong. TOTALLY wrong.

    The fact you know how to theme Drupal does not make my prior statement wrong, it just means you haven’t had the experience with designers creating Drupal incompatible designs that I’ve had.

    There are a lot of great themes for Drupal.

    Name five (5).

    Other CMSs are scrambling to copy what Drupal theme developers are doing, for example, with Omega.

    Show me ONE (1) reference on WordPress.org where someone active in the WordPress community has even mentioned Omega let alone is “scrambling” to copy it.

    Omega is one theme whereas WordPress has hundreds. Here are just five (5) vendors to look at, all with their own spin on the features of Omega:

    It is on the forefront of responsive web design. It is the best theme I’ve ever worked with for any CMS. There are plenty to choose from for both systems, if you can’t find decent Drupal templates you’re not looking hard enough.

    The forefront? Srsly? You are a true believer, aren’t you?

    Lots of responsive design in the WordPress world:

    17. This isn’t true any more.

    You got me. Yes, I wrote the post over 18 months ago, so yes one thing is no longer true.

    Nor was it ever, frankly. Just because there wasn’t a stack exchange for Drupal before WordPress does not mean WordPress is better!

    You don’t stop do you? You’ll spin anything.

    If I have a fully electric car it might be “better” but effectively isn’t not as usable if it sits dead on the roadside because there’s no charging station within range. Even though it doesn’t matter to you 3rd party support is a critical factor when evaluating a CMS for most people.

    the best tool for a given job.

    Don’t get me started on “the best tool for the job” meme. It’s one of the most overvalued tropes on the technical Internet because it evaluates tools in a vacuum instead of the real world, but I’ve got too much of a headache after responding to all your comments to elaborate today.

    I used to have the same attitude as you,

    This isn’t attitude, this is opinion based on experience.

    …before I actually knew how to use Drupal. Learn Drupal, you will find it is better for most projects, but more importantly you will find that it is stupid to speak in absolutes like this.

    And there you go making another of my points; Drupal requires a lot more learning than WordPress. And this learning is unique to Drupal but isn’t necessary if someone picks WordPress instead. Why work harder than you have to?

    Saying WordPress is a better CMS than Drupal is EXACTLY THE SAME as saying an Apple is a better fruit than an Orange. They are both fruits and they both serve their purpose well.

    I won’t agrue that because my post title was not nuanced. It’s hard to make a nuanced title.

    So here’s how I’ll clarify: “WordPress is a better CMS for most use-cases than Drupal, and where it’s not Drupal is almost always much more expensive to build with, deploy and manage.”

    Here’s one way Drupal is “better”. Drupal developers make a lot more money than WordPress developers, at least that’s what recruiters tell me here in Atlanta. So I guess if you are a mercenary developer you’d want to protect that at all costs.

    Yes, to the one making the bigger buck Drupal is the best CMS! :-)

    BTW, seems this article on Smashing Magazine agrees with me:

    -Mike

  109. your article was related with Drupal 6 and WordPress 3. well, Drupal 7 is ready (more than a year ago), then there is no changes to the article? or a new article?

  110. Hi Mike,
    As someone stuck with Drupal and sometimes very frustrated, I come back to your page regularly to regain my morale and return with the conviction that indeed it’s not just my incompetence, but that other people have the same fundamental issues as myself and that the problems I am experiencing are inherent to Drupal itself. (Right now I am trying to upgrade from Drupal Commons 2.6 to 2.9, with a custom theme on top, and it’s taking days and days, and I still can’t see the end of it). Keep up the good work! Although I think you won’t have many more arguments to debunk, as Drupalists will more and more give up on trying to contradict the obvious, and return to their attitude of effortless superiority on drupal.org.

  111. @ Mike Schinkel : You are sick ya. Do you have something against Byert?? It seems you do.
    Perhaps you are trying to get your site ranked or sell ads huh? For your information, your SITE is not very attractive, perhaps because it is built by you with your wordpress huh? If you can’t do something big like drupal than why criticize????

    Backward or reverse compatibility is not the developers concern. Developers will keep developing and bringing more and more features in terms of security, beauty, design etc etc but if someone wishes to use an outdated version than its upto them to maintain. Its opensource man!!!! There always is an upgrade path…

    WordPress is a blogging software not Content Management system actually. You will debate it is and can do everything everything a CMS can do but sorry, ” A mobile phone or a tablet can be used to do most of the office works such as reading, writting, drafting, browsing Net, downloading, and almost anything else but it doesn’t makes it a Computer. It can never compete with Computers!!!”

    Try listing 5 best websites built with WordPress and 5 with Drupal, compare them. Compare thier design and sophistication.

    Take a poll to see how much percentage of wordpress users use it for Blogging and Website. It may be around 85% blogs and 15% websites.

    Check which software does great brand names uses such as Hi5, Yahoo, Whitehouse, Ferrari and goto drupal to see the list……..

  112. I Always love these discussions! I can waste a lot of time just reading the comments on this type of articles.

    Anyway, my view on this is that WordPress as well as Drupal have their weaknesses. In most cases I think WordPress would be the best choice for it’s superior usability and easy update / upgrade path. But it’s not a swiss army knife (thats whats makes it so simple for developers and users alike) If you need anything more than a brochure or blog site, or something that requires the input of multiple users with different access right, I would advise against WordPress and go with Drupal or god forbid Joomla. A developer or business man should be cautious to worship a CMS. Keep your cool and understand there is no silver bullet.

  113. These are a Premium plug-in, & theme, but anyone looking for a solution might find these useful.

    People looking for “Views” for WordPress might want to check this out:
    http://wp-types.com/
    They have a free demo that they will set up for you too.
    I am about to pay for it so I can test it on my own, but it looks very promising.

    I also use a custom theme that is absolutely fantastic.
    Check out Catalyst for WordPress:
    http://catalysttheme.com/
    This I am using currently and Love it!

    Hopefully folks find this useful, and thanks for the Post Mike.
    …. I can’t believe that I read through almost all the comments. I almost never do that. Needless to say it was very stimulating. Well done.

  114. When ever your solution is to write code and hard code html, you have failed as a cms, might as well just stick to dreamweaver.

  115. When ever your solution is to write code and hard code html, you have failed as a cms, might as well just stick to dreamweaver.

    BTW, received php errors when trying to post on your site. So, tell me again why wordpress is better?

  116. Mike, have you ever tried Drupal 7 with Omega theme and Context module?
    I’m speaking from designer point of view not developer’s.
    I have created many heavily customized sub themes without writing single line of php code. I’m focused only on CSS. I don’t even need to create tpl files for content types! How it compares to WordPress?

    I’m really interested how can you create a WordPress site “only by copy and paste template tags”? None of the usable WordPress themes are that simple. In fact to build decent WordPress theme you will need to hire skilled WordPress developer. Even Twentyten’s function.php file have 513 lines of php code. As a designer I’m not dare to make WordPress site. Of course I can always buy a theme and again pay a developer to customize it.

    As I said in the beginning, I don’t need developer to make great Drupal 7 site. If I could do this in WordPress I will switch immediately!

  117. My company uses Drupal. I got this article in my mailbox. It deserves a reply. Here’s what I sent my coworker. Its tone might be derogatory or curt, but it is nothing personal. It may contain errors. Feel free to fix.

    I think this by Mike Schinkel article is flawed. Let me count the main ways:

    1) In Mike’s first paragraph, he admits that writing the article “has me going against my better judgment”. Moreover, “it won’t be the first time” he’s gone against his own judgment. That kind of inner conflict between desire and prudence is the first strike against his argument. He is admitting up-front that even he doesn’t trust his own judgment.

    2) He admits that WordPress has an architecture which is “less sophisticated and with more code duplication” than Drupal, yet somehow Mike sees this as an advantage? Sounds to me like Mike can’t handle sophistication, rather than that sophistication is bad.

    3) He likes backward compatibility. WordPress, if it is ever to go beyond a blogging+ platform, needs to ditch its legacy (and duplicative) code for something a little more . . . sophisticated. Mike admits that WordPress is “confusing, I know, but that’s for legacy reasons”.

    To address his points one-by-one:

    1) Design Flexibility. Apparently Drupal has “an architecture that an engineer can truly love.” I am confused. Is he trying to convince developers not to use Drupal by telling us that we will love it? His actual point is nonsense, in that a developer has total control over what HTML Drupal outputs to the screen. He just doesn’t know how to do so. There’s a difference between a CMS missing a feature and a developer not knowing how to implement a CMS’s feature.

    2) User Interface. Apparently WordPress passes the Mom test. That’s fine for a blog+. Not so fine for a professional organization that needs to do a little more than mention how great its cookie-baking went.

    3) WYSIWYG in core. He almost makes a point, but then mentions that WordPress uses TinyMCE — the most used editor in Drupal. I’ve had headaches using CKEditor, but I never had any problem using TinyMCE in my other Drupal projects. WordPress forces you to use TinyMCE. Drupal assumes that if you are a developer, you are smart enough to make your own choice.

    4) Backward… see #3 above.

    5) Easier Code to Manage. Mike seems to get confused here. He says that Drupal makes it easier for power users, and that a CMS’s target audience isn’t “a housewife”. And yet he just spent three pages convincing us that Drupal was too complex for moms. He can’t have it both ways. Either the CMS is for technical and/or power users, or it is for less advanced users. Moreover, it the CMS is for advanced functionality, then it will contain complex code that is inherently harder to manage. He wants it both ways.

    6) Collaborative development. “Without a good version control strategy” marks the beginning and end of his argument. Yes, without a good version control strategy, collaboration will be nigh-near impossible, no matter what CMS you use.

    7-11) His complains about how hard or costly Drupal is to use. One solution is to use the easier and less sophisticated CMS. The other is to learn Drupal.

    12) Load times. Evidently Mike doesn’t know how to optimize Drupal, which is often a requirement because of all the fun stuff it does.

    13) Less expensive hosting. Again, you get what you pay for. We’re seeing a trend here.

    Skip ahead to 17 to nail the coffin shut

    17) A little-used Drupal stack exchange forum. Here Mike displays a glaring lack of understanding about the Drupal community, and reveals why he doesn’t know how to use Drupal. Drupal.org contains a huge and vibrant community with a massive amount of documentation, including the hugely important ‘issue queue’ for each and every module. You don’t go to stack exchange for an answer. You go to the module page.

    “Full disclosure, I’ve been making my living as a WordPress specialist for almost two years”

    Exactly. This guy doesn’t know what he is talking about because he doesn’t know Drupal.

  118. nice fallacy you got there, Captain Fallacypants. 17 reasons why WordPress is better than Drupal – but, in all “fairness”, three reasons why it isn’t – signed by a WordPress user?

    it’s ironic that you criticise people’s inclination to post “inflammatory comments” when you didn’t even get those slanderous accusations straight. mind you, even before Drupal 7 was released, most of that stuff you wrote didn’t stick.

    it kinda gets pretty obvious that you just wrote this post to draw attention to your then-started WordPress business. I mean, grow up a little, kid. there’s work for everybody.

    even for people who use a “CMS” that sets structure configurations up in the theming layer.

  119. also, I tried to comment on this post but got an error from akismet. you should get that fixed.

  120. Im not super familiar with wordpress, but I work at a company that uses it on our public website (as our application is on a different server), and I see its shortcomings.

    I really don’t get how you are suppose to build with wordpress, there is no “open source” block or views systems available. If your a OPEN SOURCE developer, and your not wanting to PAY for code, and or plugins, that you can’t modify, that sorta makes the decision for me.

    And with the current version of Drupal, I can simply paste link to a plugin from the drupal website, and downloads, and installs it without using any ftp and or file transfer like before, im super sold on Drupal now.

    Im sure there is a sort of Hatfields & McCoys love hate relationship between developers of Drupal and WordPress. And Being more familiar with the structure of Drupal, im falling on that side of the fence. Possibly because the author is “more familiar” with wordpress, he sees only the benefits of wordpress… Just a thought.

  121. Hi @Will – Thanks for the comments.

    Yes WordPress has shortcomings. The point of this post (written ~2.5 years ago) was that Drupal had worse shortcomings than WordPress and that the shortcomings of Drupal were mostly architectural in nature; i.e. they can’t really be “fixed” without making Drupal something very different than what it is.

    You are correct, WordPress doesn’t have a blocks of views system per se but then those are Drupal concepts so it would be like saying Windows doesn’t support the Mac OS X “.app” file; of course it doesn’t!

    On the other hand there are many, many solutions in the OPEN SOURCE plugin repository that address the same site builder needs. They are just a different flavor then you are used to, that’s all.

    WordPress has had the ability “to paste a URL and download a plugin” for longer than I can remember. But that prior limitation of Drupal is not one of my 17 reasons so I don’t really know what your point is.

    I don’t think this post was based on a love-hate relationship, that wasn’t my intention. This post was written for those people who blindly buy into the (possibly Drupal-promoted) branding of Drupal=CMS and WordPress=Blog and therefore dismiss WordPress as a CMS.

    I never expected for Drupal fans to switch because of this post, I only expected for people who are doing research into a CMS to hopefully see this post so they are able to form their own opinions instead of buying into the errant “conventional wisdom” that Drupal = CMS and WordPress != CMS.

    As for me being “more familiar” with WordPress it is true that today I am more familiar with WordPress, ~2.5 years after writing this post. But it seems you did not read the post in full before commenting because I worked professionally in Drupal for 2 years before switching to WordPress so when I wrote this post I was about equally familiar with the two.

    And yes, a lot can happen in 2.5 years so you might ask “Isn’t Drupal better now?” to which I’ll answer “Unless Drupal radically changed its architecture, I highly doubt that most of the issues I mentioned have been addressed.”

  122. I’ve been a Drupal developer for more than 5 years, and some of my sites have grown enough to show some of the drawbacks you point here, especially when it comes to pageload times, since Drupal is just too slow. Theming is the other major drawback I have faced, there very few themes available out there. That said, I think it might be time for me to switch to WordPress, so I will give it a try. Thanks a lot for the post!

  123. a year ago that I first saw this post, at the time already had a couple of years working with drupal.
    Just wanted to let you know that by this post I began to learn WordPress, now I love both platforms.

    I believe that I do not quit working in Drupal, there are things that I feel more confident with DP, but also WP has great things, the number of templates is huge. not to mention the plug-in.

    the point that I would like to share is that professionalism is required in both, time, knowledge and experience.

    I do not think one is better than the other, both are good and do their job, it all ends up with which you feel more comfortable to do certain tasks. not because they are designed for this or that, but by knowledge of the tool you possess. both are written on php at the end.

    Thanks for this post and for keeping it so many time.

  124. Hi @Gerardo,

    Thanks for the thoughtful comments, especially a year later.

    I’m glad that both work for you. I wrote the post for people who made the default assumption that Drupal was a better CMS without ever evaluating WordPres. Kudos that you evaluated both and have come to your own conclusions what works best for you.

  125. Interesting post and some very interesting responses. Personally, I find it quite bemusing that we only see posts like this bigging up wordpress, from people who make a living from wordpress.

    Why is this? Is this some form of marketing? Well, I am not sure, but it does sound like some form of platform promotion ..

    Again, typically, market leaders seat smug acting ‘professionally’ condescending to the less powerful competitors. BUT in this case, the ‘market leader’ has reversed that trend and is eager to big hersel up and constantly tell the world why it provides a better platform. Why is this? A case of inferiority complex? I suspect very much so.

    I am no drupal expert, more like an intermediate developer, and I agree it does take some focus and effort to get into drupal and understand its architecture. But that is for a great reason. Drupal is without doubt the most flexible platform I have ever used, that can be adapted to all sorts of great needs .. all without writing code. For those who tout coding, perhaps this demostrates a lack of full understanding into all the awesomeness of views, contexts, panels, etc .. and the fact that one can easily clone various functions (via features) for use in other projects or sites.

    I do have some decent wordpress experience, but each time I set out trying to do something significant in wordpress (thinking it will be quicker), I end up going back to drupal because the wordpress codeset and ways of doing things just seems so much more amateurish and unstructured when compared to drupal.

    I am by no means dismissing wordpress by any means, but comparing it with drupal is like comparing apples with oranges. They are two very very different systems, which would be suitable for various scales and complexities in projects. I am a systems integrator, and the best platforms I have found are drupal, django and web2py. I just cannot seem to find a fit in my projects for wordpress .. it just seems so much of a blog and brochure website system.

  126. Training is the biggest factor for me. I can train a client how to use WordPress in a few hours and they tend to actually enjoy it. Training clients to use Drupal is like running an insurance seminar. From a usability perspective, Drupal is a major fail. Also, I cannot stand the Drupal culture. It is downright creepy.

  127. Here’s one for Drupal: like joomla, wordpress has a not-free plugin aftermarket. Drupal is all free. For things like CCK and Views, you find half a dozen or more competitors in WP some free, some partially free (pay for extras), some pay-for “suites”. Why Suites? Because you won’t be getting integration between plugin initiatives in a pay-for aftermarket. Drupal has chosen CCK implementation in core and Views implementation in core–and they get modules like Rules that integrates with these any most other modules. It’s doubtful you’d see a module like Rules emerge in the WP marketplace– in a pay-for plugin aftermarket, why would a) anyone write a Rules module to integrate with a competitor, and b) why would a competitor permit you to integrate with their module? Rules across plugins is just not gonna happen in WP. The kinds of integrations between intiatives drupal is achieving is unheard of. Java could accomplish sort of integration of disparate parties through interface definition, what drupal is doing is actual functional integration between initiatives, this seems unheard of.

  128. Do you think there may be a problem with you analyzing Drupal 6 with the new WordPress. Drupal 7 it’s miles ahead of Drupal 6, and also most of your points were solvable by popular modules.

    I also didn’t understand why you had troubles making your Drupal sites look good. If you make your own theme, it’s exactly like any other template system. Or you could just edit the tpl’s that were causing you problems.

  129. @Peter Drinnan Thanks for the comment. Definitely agree, all.

    @Rich K. Thanks for the comment too. The fact WordPress has a thriving commercial aftermarket is a HUGE plus in WordPress’ favor, IMO. And integration with other systems? I’ve always thought that puts WordPress in the “win” column.

    @Miguel Drupal position on version compatibility, in other words “not” makes the discussion of one version’s features over another moot in my opinion. As for theming, if like me you don’t have graphic design skill you have to learn on designs via either off the shelf designs or other designers and in my experience there are somewhere between 10 times and 100 times more designers who are experiences and comfortable with WordPress.

    That said, if you think Drupal’s and WordPress’ template systems are “exactly the same” you’ve clearly never themed a WordPress site. As previously said/implied, it’s much easier to separate concerns between designer and developer on a WordPress site than on a Drupal site.

  130. Enjoyed the article, and agree with most all of your points. Havent touched Drupal in awhile, but considering how good WordPress continues to get each and every week/month/year, I doubt they have caught up.

  131. I’ve enjoyed reading the nearly three years of back-and-forth. I have years and years developing in the .NET world on the DotNetNuke CMS, and have amassed a good deal of savvy on that platform. However, I want to move away from it for various reasons, and tried WordPress. For some reason, I hit some walls doing some seemingly simply things, so tried Drupal. Oddly, I found it easier to use than WordPress–I know that I shouldn’t have, I guess.

    Reading your article carefully, and then the entire thread, I am strongly considering giving WordPress another try for rebuilding a large community site that’s currently in DotNetNuke, as well as expanding the site currently built in Drupal. My guess is that on the second go-around with WordPress, things will click.

    It would be great to have a trusted consultant available to help me as needed. (I don’t code in PHP, and don’t have time to learn it, unfortunately.) If you are willing, would you email me your rates?

  132. Hi Stephen,

    Thanks for reaching out. Interestingly, I toyed with DotNetNuke a long time ago when I was in the .NET space. Around 2004-2005, I think.

    At the moment I’m at capacity and trying to pull back from more obligations of my time but nonetheless I’ll reach out to you via email and see if I can help you somehow.

    -Mike

  133. Yo vengo de Drupal, y me ha llamado bastante la atención WordPress, tengo un proyecto ya empezado en Drupal, donde puedo comprar membresías, a los compradores se les asigna un rol y pueden escribir su propio post, y terminada la membresía dicho post es eliminado, cosa que no se cómo hacer con WordPress, se me está haciendo un infierno buscar y buscar y no encontrar lo que necesito

  134. I have created a portfolio and blog site with WordPress earlier.
    I am feeling proud after reading this article that i did a great job choosing wordpress.
    BTW thanks for the share.

  135. WordPress is bar far easier to use. In fact web designers might be obsolete if it continues to improve. But the way wordpress is now, it’s for insta websites, with basic features. Yes some addons are available and this works for most designs. But the business and corps that need features and flexibility with drupal.

    Drupal is tough to use, so it’s not something anyone can pick up like wordpress. Drupal is heavy and slow so it’s not something anyone with shared hosting would want to use.

  136. Hi.

    For 7 years I’m doing both WordPress and Drupal development, sites from zero up to web applications.

    I enjoy working with both and I know what to choose proper for a project. Sometimes a website is better to be done in WordPress, other times it’s really better in Drupal.

    If you’re fixed on WordPress is better then Drupal or any other system, then I’m sugesting, start to learn PHP at a higher level and soon you’ll find that there are even better platforms then WordPress or Drupal.

    On the side that WordPress is cheaper, yes I agree, same quality is directly proportional with the price…

  137. I know this post is old but even back then you had about half of these points wrong.

    I think your negativity towards Drupal came from a lack of understanding.

  138. Hi @Scott – Thanks for the comment. Couldn’t agree more.

    Hi anonymous @Drupal Defender.

    “..you had about half of these points wrong.”

    You might say that without explaining your reasoning, but saying so doesn’t make it true.

    “I think your negativity towards Drupal came from a lack of understanding.”

    Maybe so. But I highly doubt it.

  139. “Maybe so. But I highly doubt it.”

    I don’t doubt it, you describe you experience with Drupal where you leave websites unfinished because you couldn’t get them looking good and it was pure hell to complete. This just proves a lack of understanding, if you couldn’t get a site looking good in Drupal and struggled with the last 15% of every project then you clearly didn’t know what you were doing.

    “You might say that without explaining your reasoning, but saying so doesn’t make it true.”

    Writing this article doesn’t make it true either. Reasoning:

    1. WordPress Allows Infinite Design Flexibility

    False. Drupal is just as flexible when it comes to design. I’ve designed and developed sites that look nothing like a standard Drupal website. Since Drupal 5.

    2. Usability has been “Baked-in” to WordPress

    True for Drupal 6 however their were modules available back then to rectify this situation. In Drupal 7 this issue has been addressed.

    3. WordPress has a WYSIWYG Content Editor in Core

    Why is this an issue? Unless you’re building your own site then a decent Drupal developer will install a WYSIWYG for you. If you are building your own site then it a very simple process to select and install a WYSIWYG that suits your needs. That is flexibility, rather than lumping you with an editor that you may not like.

    4. WordPress Strives to Maintain Backward Compatibility

    False. Upgrading major versions of Drupal does not mean an expensive rewrite. You can upgrade from each major version easily. The main issue is contributed modules not having support ready for the new realise. This is the same with WordPress plugins.

    5. A WordPress-based Website’s Source Code is Easier to Manage

    The title of this point and the argument within it don’t match. Just because Drupal stores data in a database it doesn’t make WordPress source code easier to manage. You also complain about Drupal’s handling of this yet promote a WordPress plugin that provides the same functionality as if it’s an added bonus for WordPress. This invalidates your argument.

    6. Collaborative Development is Easier with WordPress

    False. Drupal can be run as a local copy just like WordPress. You can also version control Drupal code using GIT.

    8. Easier to Find Skilled Designers for WordPress

    False. The majority of designers I work with don’t care what the CMS is and definitely do not take the CMS into consideration when designing a website. This also knocks out point one again as I can take a design designed for WordPress and build it into a Drupal site.

    9. There are More WordPress Professionals Available

    False. More does not mean better.

    10. WordPress Professionals Charge Lower Rates

    I wouldn’t say this is a positive for WordPress over Drupal. I charge the same for both Drupal and WordPress which is a fixed price based on functionality. You may charge more for Drupal sites because you need to compensate for the extra time spent figuring everything out.

    11. WordPress’ Code is Much Easier to Debug

    False. You only spend most of your time looping through functions if you don’t know what you’re doing. Your personal inexperience should not be used as a con for Drupal.

    13. WordPress Requires Less Expensive Hosting

    False. Drupal can run on most of the basic hosting packages available without issues.

    16. WordPress has Far More High-Quality Attractive Themes

    Just because WordPress may have more themes available than Drupal does not mean that WordPress developers can develop higher quality themes.

    17. Lastly (for my list, at least) there is a WordPress Answers but not one for Drupal

    False. There is one and not only that Drupal’s large developer community is nothing but helpful and the majority of questions I’ve ever posted have been answered in a very timely manner.

  140. Hi Drupal Defender,

    I didn't expect you back, but it seems you couldn't resist. Bummer you didn't have the nerve to post your comments using your real name. But alas.

    Before I address your points one-by-one I will say it's a shame you can't determine truth without confusing it with your agenda and your opinion. Best example is your claim that my statement "There are More WordPress Professionals Available" is false with your justification being "More does not mean better." Your justification implies that my statement is correct, but you just prefer your own spin on things.

    …This just proves a lack of understanding, if you couldn’t get a site looking good in Drupal and struggled with the last 15% of every project then you clearly didn’t know what you were doing.

    Not it all. It proves I'm not a designer. Which I never say otherwise.

    Writing this article doesn’t make it true either. Reasoning:

    Srsly? As above and I'll show below, you certainly haven't mastered reasoning yourself.

    1.) "WordPress Allows Infinite Design Flexibility"

    False.

    No, it is true. Just because you think that Drupal allows flexibility does not mean that WordPress does not.

    Drupal is just as flexible when it comes to design.

    Saying it does not make it so. I've spelled out exactly why Drupal is less flexible above, because it is a roach motel for URLs; Drupal parses the URL and always calls back into the theme or plugins so Drupal is always in control. Hence: less flexibility. If that has changed in Drupal 8 (has it?), then nevermind, but I wrote this post a long time ago.

    WordPress, on the other hand performs it's processing and then turns over control to the theme. Unless Drupal 8 is doing that then sorry, WordPress is more flexible.

    I’ve designed and developed sites that look nothing like a standard Drupal website. Since Drupal 5.

    Your experience is not relevant to the question of whether or not Drupal is a good choice for CMS. Sure some people with a lot of expertise can make things work, but that does not translate into Drupal being a better CMS; we need a lot more websites that just the ones you've built to prove the rule. And yes there are many, but not nearly as many as WordPress.

    Speaking of, just take a look at the trends for Drupal; Drupal interest is in decline:

    Drupal Interest in Decline

    Compare with interest is growing for WordPress:

    WordPress Interest is Growing

    Clearly some people have developed the same opinions about Drupal and WordPress as the one's I've shared here.

    2.) Usability has been “Baked-in” to WordPress

    True for Drupal 6 however their were modules available back then to rectify this situation. In Drupal 7 this issue has been addressed.

    Another of your reasoning errors. Usability can't be baked-in to v7.0 if it wasn't based into v6.0, unless it was a complete rewrite. And I've not heard from any non-Drupal devotees that Drupal is usable but I hear the contrary all the time.

    3.) WordPress has a WYSIWYG Content Editor in Core

    Why is this an issue?

    Because standardized interface is extremely important for many reasons, user training and quality of features being one. 3rd party modules/plugins are never as well maintained nor as a user designed as core features thus something that really needs to be core feature is a bad idea to have as a user-module. Sure, speciality WYSIWYG editors to override the built in ones are a fine idea, but core needs to be a built-in WYSIWYG editor, and I'm pretty sure at least 90% of end users would agree with me on this.

    Unless you’re building your own site then a decent Drupal developer will install a WYSIWYG for you.

    Sure, but then you end of with companies who have end users who are familiar with Drupal can't be sure that their users will be familiar with/comfortable with the editor chosen. Editors are too important for a C.M.S. for them to be an afterthought.

    If you are building your own site then it a very simple process to select and install a WYSIWYG that suits your needs.

    Except that requires the end-user to spend quite a bit of time doing research and trial and error that could easily consume 5, 10 or even 20 hours, and that's assuming they run into no problems with the ones they pick. If the user chose WordPress instead they wouldn't have to worry about this thing they'd prefer the core team worry about for them.

    That is flexibility, rather than lumping you with an editor that you may not like.

    Yes, it is flexibility. But not in the area of website design that matters to most CMS end-users but instead flexibility in configuration, which is an area where most end-users just want someone to handle for them.

    4.) WordPress Strives to Maintain Backward Compatibility

    False.

    Once again, you claim false only because you don't like the point, not because it's not true.

    Upgrading major versions of Drupal does not mean an expensive rewrite. You can upgrade from each major version easily.

    Not nearly as easily as you can with WordPress. With WordPress more than 99% of upgrades take no more than 1 click. So please don't insult me again and say upgrading Drupal is comparatively easy. It's not.

    The main issue is contributed modules not having support ready for the new realise. This is the same with WordPress plugins.

    Yes, but it's not the only issue. Drupal core makes backward INcompatible changes, by design; Dries himself says it is so. Alternatively WordPress does their best to insure backward compatibility. Again, don't insult me on this one, take a look at what just a few Drupal users are saying:

    5.) A WordPress-based Website’s Source Code is Easier to Manage

    The title of this point and the argument within it don’t match. Just because Drupal stores data in a database it doesn’t make WordPress source code easier to manage.

    I take it you are not familiar with using version control such as Git or Mercurial then? Because if you were you'd know that you can version control a database dump in the same manner you can source code. It. Just. Does. Not. Work. That. Way.

    Period.

    You also complain about Drupal’s handling of this yet promote a WordPress plugin that provides the same functionality as if it’s an added bonus for WordPress. This invalidates your argument.

    Sorry, you didn't provide any reasoning to validate my argument about storing logic in the database.

    6.) Collaborative Development is Easier with WordPress

    False. Drupal can be run as a local copy just like WordPress. You can also version control Drupal code using GIT.

    Then I'll let you try to explain how for example 4 different people (a module developer, 2 theme developers and a programming PM) can all be working with local copies of the same application and when one makes a change, such as adding a new content type or CCK fields the others are able to check-out those changes within seconds, if using Drupal?

    BTW, the example of the 4 people and their roles I gave above it example the makeup of a team I'm working on building an intranet using WordPress for a Fortune 100 company (yes I did say "intranet.")

    8.) Easier to Find Skilled Designers for WordPress

    False. The majority of designers I work with don’t care what the CMS is and definitely do not take the CMS into consideration when designing a website.

    Since I wrote this post this is one area where I might start to agree. The problem is that most WordPress people are not as skilled in PHP development as the average Drupal developer. On the other hand, there are far fewer Drupal developers and they are very hard to find. I know, people in Atlanta are occasionally asking me if I know anyone and the few I know are working on projects, and most of them are at Turner Broadcasting.

    As an aside, I keep awaiting the day that Turner Broadcasting finally gives up on Drupal as several other local companies have.

    This also knocks out point one again as I can take a design designed for WordPress and build it into a Drupal site.

    Any design? Any? Are you willing to make that bet? (and if so, what/how much are you willing to actually bet?) Because that's a bet I would take.

    9.) There are More WordPress Professionals Available

    False. More does not mean better.

    Already commented on this one, above.

    10.) WordPress Professionals Charge Lower Rates

    I wouldn’t say this is a positive for WordPress over Drupal.

    So it's clear you are arguing for what puts money in your own pocket and not what is actually the best choice for CMS for your end-users.

    I charge the same for both Drupal and WordPress which is a fixed price based on functionality.

    Again, as I've said, your specific are not relevant to which is a better CMS. I personally charge a lot more than most WordPress people I know, but that's beside the point of the post.

    You may charge more for Drupal sites because you need to compensate for the extra time spent figuring everything out.

    I'll channel my inner 17 year old on that one: "Whatever."

    11.) WordPress’ Code is Much Easier to Debug

    False. You only spend most of your time looping through functions if you don’t know what you’re doing. Your personal inexperience should not be used as a con for Drupal.

    So, you know have to know what you are doing to use Drupal effectively?!? LOL!

    You are really making my points for me. The better CMS for most users is the one that requires less expertise to master it.

    13.) WordPress Requires Less Expensive Hosting

    False. Drupal can run on most of the basic hosting packages available without issues.

    You are correct, but only for low traffic sites. However most companies who are evaluating CMSes are concerned about scalability and higher traffic sites, even if only for risk management.

    Because Drupal stores so much of it's configuration in the database it has to load and process that information each time it loads a page, and this is especially problematic on high traffic sites. Caching can

    Simply put to scaling Drupal requires more machines than WordPress requires for the same traffic.

    16.) WordPress has Far More High-Quality Attractive Themes

    Just because WordPress may have more themes available than Drupal does not mean that WordPress developers can develop higher quality themes.

    Okay, so what? Let me say it a different way:

    • They are orders of magnitude more quality themes for WordPress than for Drupal.

    And don't insult my by trying to say otherwise (unless you are willing to create a list of all the Drupal theme vendors that you know of and the number of themes each offers, so I can rebut you with the same list for WordPress.)

    17.) Lastly (for my list, at least) there is a WordPress Answers but not one for Drupal

    False. There is one and not only that Drupal’s large developer community is nothing but helpful and the majority of questions I’ve ever posted have been answered in a very timely manner.

    LOL! You are correct. TODAY. But you were NOT correct about the state Drupal Answers when I wrote this post.

    So, because of the passage of time I'll give you two where one was my realization that it's hard to find PHP developers who know WordPress. The rest you are unfortunately just wrong about and as the Google trends show, the world is coming to understand the truth of what I posted almost 3 years ago.

    But not because of me, I'm sure. Instead I'm almost certain they are learning that Drupal is a nightmare because by now many of them have actually tried Drupal, and found it to be wanting. Otherwise, why would the trends show so much loss of interest in Drupal at the same time WordPress is

  141. Your so smug and stubborn aren’t you?

    Where you claim that I am wrong in my reasoning in regards to my statements you clearly don’t read. My responses were in response to your reasoning rather than the actual statement. For example, where I say “False”, may not be to your headlining statement but rather to the actual reasoning you are providing to back it up.

    I find it funny that you say less expertise is needed to use Worpress and then in your comments promote a negative article about Drupal that goes on about Drupal developers being “Click Monkeys”. Contradict yourself a lot don’t you.

    Anyway, maybe I got on the attack too quickly and it was the wrong way to go about it. I guess the main reason I left a comment in the first place is because… well Drupal definitely isn’t as bad as you say it is and you have some of your facts wrong and a lot of your reasoning is your opinion or made up deductions rather than hard facts.

    It’s all well and good that you don’t like Drupal but to publicly put down Drupal developers and put their livelihoods at stake because of it isn’t really professional.

    Anyway, for the record I was never against WordPress. I like it and use it a lot, I just finished a WordPress site last night. As much as you think it’s a cop-out, yes each CMS has it’s own use and I think a responsible developer should pick the correct CMS for the client’s needs rather than a petty ‘I don’t like that CMS’ reasoning.

    FYI… Yes I would bet that I can put any design into Drupal, some of the layouts designers have sent me I’ve thought it would be hard to build into Drupal (no harder than WordPress) but once I get started it all works out. Sure I’ve had a headache or two trying to get some things to work but from my many years in the industry I have found that all CMSs give you that same headache every now and again.

    Your comment about not being a designer is a bit of a turn around, you said you had hell completing the last 15% of websites, usually the last 15% is part of the development stage of a project. I’ve never worked on a project where the site was built and then designed afterwards.

    In response to the interest over time, WordPress will always have more interest because it is a platform for newbies and non-developer types as well. This clearly would boost it’s user stats but it does not discount Drupal as an awesome CMS.

    In terms of usability, you haven’t heard of D7 being user friendly. My question to you is, have you used it? You mention in your article that you were willing to write a CCK plugin for WordPress (which actually contradicts your point about storing this data in the database, a plugin for WordPress would do the same thing right?), then WordPress upgraded to version three and you thought how good it was. Have you used Drupal since version 6 because your reaction to WordPress 3 was the same reaction I had to Drupal 7. In terms of usability they hired usability experts to help fix Drupal’s issues and Drupal 8 has even more advancements in this area which includes adding popular functionality to core.

    Anyway, that’s all.

  142. PS. I’m not a coward for staying anonymous, if I was a coward I wouldn’t say anything at all. I’m not a random troll swearing and being abusive for fun so my identity has nothing to do with the statements I’m making and having a name attached wouldn’t give it anymore credibility than a John Smith making a comment. Who’s John Smith? No one cares do they? You’re simply trying to discredit my argument within your first paragraph to push readers towards your line of reasoning.

  143. Hi @Drupal Defender,

    Your so smug and stubborn aren’t you?

    So you are the Pot who is calling the Kettle (me) black? I think you have more than enough to match me. After all, I didn’t track you or your blog down; you commented here on my almost 3 year old post telling me how wrong I was, and then you replied and replied.

    But your tone did get slightly better before you attacked me about asking who you were, so I’ll give you that in the middle. At this point let’s just agree to disagree. For me, I’m no longer frustrated as I was when I wrote this post.

    3 years ago Drupal still appeared to be on a upward trend and I wrote this post because I was seeing non-technical people blindly choosing it because of the “CMS” brand positioning Drupal had built. Fast forward to today and the trend I’m seeing is that many enterprises are finally realizing what a pain Drupal is work with and are thus giving up on it and moving to WordPress. At least the ones that are paying me are.

    Speaking of which, I’ve got paying work to do. Later.

  144. Boom! You forfeit, I win!!

    Seriously though, I don’t know why I even bothered commenting. I see it was a complete waste of time for both of us so I apologise.

  145. Wow. Seriously… Wow.
    Mike you are just mean.

    If you spent half as much time actually trying to understand the dissenting view as you do writing these monolithic diatribes this would be a much more fruitful, albeit less entertaining discussion.

    As you can tell by my name (and yes that is my real name) I’m a big fan of Drupal. While I may have not invented Linux with Linus Stallman at Bell Labs I have been programming php for five, count em, five years. I’m a competent programmer. But just because I know how to program doesn’t mean I want to define custom post types in code. That’s what a CMS IS FOR. So you DON’T HAVE TO write code. Being able to define content types through simple and straight forward admin interface is both easy and extremely powerful.

    I also don’t really understand your argument with respect to deployment. When I need to deploy a Drupal site I put all the files and data in a tarball, upload it to the server, import the database and I’m done. Maybe I’ll have to change the db credentials in the settings file, big deal. The last time I deployed a WordPress site to a production server I had to do a search and replace on the dump file to change the site url from the dev url to the prod url. What the hell is that?

    User management is a huge thing that has only been touched on briefly here but I think is a real deal-breaker when thinking about using WordPress. Drupal gives you such fine grained control over what a user has access to. I don’t know about you but a lot of my clients can’t even tell me what browser they’re using. I certainly don’t want them to have access to any configuration or system settings. With Drupal I can even define their level of access within specific content types.

    And about your 17 “reasons” WordPress is better than Drupal – c’mon man. Most of those reasons are either untrue or just your opinion. I’m not going to go into great detail about them because others have already done so above – and done a fine job I might add.

    If you respond to this post I’m sure you’re going to try to out-logic me, going line by line explaining why each one of my points is wrong. You’re probably going to put “out-logic” in quotes as part of some snide remark. But whatever. I can’t really respect the opinion of someone who refuses to listen.

  146. Wow. Seriously… Wow.
    Mike you are just mean.

    Well, you may be right. I just don't happen to share your opinion on this matter.

    Since I believe you are referring to my replies to comments on this post I will say I respond with fewer pleasantries to those who choose ad-hominem attacks rather than to debate the merits of my post. But in that respect I'm simply giving what I get.

    If you spent half as much time actually trying to understand the dissenting view as you do writing these monolithic diatribes this would be a much more fruitful, albeit less entertaining discussion.

    If you respond to this post I’m sure you’re going to try to out-logic me, going line by line explaining why each one of my points is wrong. You’re probably going to put “out-logic” in quotes as part of some snide remark. But whatever. I can’t really respect the opinion of someone who refuses to listen.

    So I'm confused. Am I supposed to write a post and then when people challenge my position — with what to me is flawed logic — I should agree with them and wish them a nice day? Are you saying that I should not be using logic in my replies? Or is it that just you wish that I would have agreed more often with the points of the commentors even though I don't believe them to be correct?

    BTW, my style of reply was derived from trying not to be what I've always hated; when people take a position, get challenged, and then simply ignore the points that are hard to defend (I call that the "Sean Hannity Style of Defense.") So I reply point-by-point (when I have the time) because I think that's the most intellectually honest approach and what I'd like to see from others.

    While I may have not invented Linux with Linus Stallman at Bell Labs. . .

    "Linus Stallman?" LOL! :) And I'm not trying to be mean, I just think that your inadvertent portmanteau is genuinely humorous. But again, not at your expense; I just mean in general.

    BTW, if you don't know what I mean you can look them up as Linus Torvalds and Richard Stallman. And if you really want to see mean, you should hang out on the same mailing lists as Linus.

    I have been programming php for five, count em, five years. I’m a competent programmer.

    So, are you saying that 5 years is a lot of experience and your opinion related to programming topics is thus validated, or that you believe you are competent is spite of having only 5 years experience? Seriously, is length of experience a valid metric for you?

    I typically shy away from mentioning how many years I've been programming during debates because doing so is a form of a dishonest debate tactic called "Appeal to Authority." But, since you brought it up, I'm been programming professionally for over 24 years (not counting my hobbyist years):

    1. 7 Years – Clipper (Database app development on DOS)
    2. 12 Years – ASP+VBScript+IIS+SQL Server (Web/database development)
    3. 2 Years – Drupal
    4. 3.5 Years – WordPress

    However, now that I've quoted my years experience I will say I know many people with 10 years experience who are far better programmers than I. Said more directly, length of programming experience is not a proof of someone's programming ability so let's stick to debating the specifics, not our relative authorities. As a side note, however, significant lack of experience (i.e. < 1 year) is almost certainly proof of inability although that doesn't apply to either of us.

    But just because I know how to program doesn’t mean I want to define custom post types in code.

    If you read through all my comments you'll see that I acknowledge that there are aspects of Drupal that are superior to the equivalent of WordPress. However, in my opinion the sum total benefit vs. downsides of all that is WordPress far outweighs all that is Drupal, for CMS, except in selected use-cases which I'll mention later.

    Being able to define content types through simple and straight forward admin interface is both easy and extremely powerful.

    Agreed that it is easy and powerful. But I also believe it's usually not the best overall solution. "Easy at First Use" often does not translate into "Robust and Maintainable Long-term Use."

    However there are several post type plugins for WordPress for defining post types in an admin UI without code; some free, some commercial. So if you want to challenge WordPress here then I will definitely agree with you; this feature should be in core to avoid having 10+ different yet incompatible ways to do it (which is the same issue I have with not including a standard WYSIWYG editor in Drupal.)

    But for site building professionals (vs. power end-users) the use-cases are rare in practice where I would condone storing post types definitions in the database because doing so makes version control and ongoing deployment very difficult. If you are setting up a website for your Aunt Ginny to publish here recipe database, then sure use one of these plugins. But if you are build a site for a client you are doing them a disservice.

    Besides, with websites like GenerateWP how can you in good conscious not code post types for your client projects? You are using version control for your client sites, right?

    That’s what a CMS IS FOR. So you DON’T HAVE TO write code.

    Sigh. Here's where you are going to be upset at me for using logic, but that's just who I am.

    Let's see if Wikipedia says anything about Web CMSes being defined as needing to allow configuration via an end-user interface?:

    A web content management system5 is a bundled or stand-alone application to create, manage, store and deploy content on Web pages. Web content includes text and embedded graphics, photos, video, audio, and code (e.g., for applications) that displays content or interacts with the user. A web CMS may catalog and index content, select or assemble content at runtime, or deliver content to specific visitors in a requested way, such as other languages. Web CMSs usually allow client control over HTML-based content, files, documents, and web hosting plans based on the system depth and the niche it serves.

    Hmm, as I expected; nothing in the definition about a CMS required to be configurable via from within the admin console.

    So is end-user admin configurability a bad thing? Assuming that the CMS provides the tools for deployment and maintainability, no. But AFAIK Drupal still does not, although maybe some day it will. Currently WordPress is much better in this respect because I can easily define most things in code, version control them and then deploy them much more easily than if I were using Drupal.

    I also don’t really understand your argument with respect to deployment. When I need to deploy a Drupal site I put all the files and data in a tarball, upload it to the server, import the database and I’m done. Maybe I’ll have to change the db credentials in the settings file, big deal.

    Understandable that this might not be clear. You are correct, the first time you deploy a Drupal site it's relatively easy, maybe even easier than a WordPress first time deploy. But first time deploys are always an order of magnitude easier.

    The last time I deployed a WordPress site to a production server I had to do a search and replace on the dump file to change the site url from the dev url to the prod url. What the hell is that?

    Agreed, having to change URLs in a WorPress database prior to deploy is sub-optimal. But it's easily fixed with a bit of write-once reusable code. However deploying Drupal updates to an existing site where you cannot just copy the over the database with the updated configuration is where the real challenge emerges. You have to extract the features you added and apply them to your client site's database, and hope like hell you get it right.

    Honest question: Have you never had to update an existing site, or has all your experience been in deploying newly developed sites? If the latter then you'll understand the pain I write about when you finally have to apply a significant update to a production site where you can't just blow away all the content and comments added since you first deployed the site. Believe me, it can be a painfully rude awakening.

    But if you won't believe me on this, just see what the developers at StackOverflow and Drupal Answers have to say on the issue (be sure to search for the part where they talk about database deployments):

    In summary, to deploy Drupal you usually have to write a SQL script to deploy an second release of a database.

    FUNNY, since I wrote this post it seems Drupal has learned from WordPress is the creation of the Features module is any evidence:

    2012 March: One current trend in Drupal development is to move site configuration out of the database and into code using the Features module. Nuvole made an excellent presentation on this (although it regards making Drupal distributions, the concerns for large-scale sites are similar. By moving site configuration to code, many errors can be eliminated as you can just use your existing version control system to manage deployment.

    On to User Management:

    User management is a huge thing that has only been touched on briefly here but I think is a real deal-breaker when thinking about using WordPress. Drupal gives you such fine grained control over what a user has access to.

    I agree with you completely. (See, I do listen to and understand dissenting views…)

    WordPress has user management built into their API but they do not bring it to the surface quite like Drupal does. It is definitely something else I'd like to see in WordPress core, but in the mean time I just use the Members plugin.

    Members is not on par with Drupal's built-in but instead just exposes WordPress' user Roles and Capability API via an admin UI. If you write custom code with custom logic you still have to write your own code to control access however that code is super easy to write and I question if a data-driven CMS could allow the flexibility most sites need without adding outrageous complexity that most people would never need.

    So yes, Drupal is generally better here than WordPress. But again, when all things are weighed out the improve ease of deploying WordPress sites outweighs what you have to do to enable it's user management functionality compared to Drupal's much more complex deployment picture.

    I don’t know about you but a lot of my clients can’t even tell me what browser they’re using. I certainly don’t want them to have access to any configuration or system settings. With Drupal I can even define their level of access within specific content types.

    Funny, with WordPress the access is controlled by code so I know that users won't have access vs. with Drupal if I misconfigure I can accidentally give then access to the wrong settings. But I digress, this is not a distinction worth debating IMO.

    And about your 17 “reasons” WordPress is better than Drupal – c’mon man. Most of those reasons are either untrue or just your opinion.

    Untrue? That's a rather pointed accusation that comes without specific proof. The house wins given that level of evidence.

    And as far as the latter – my opinion – well it is my blog. One where I write my thoughts when the mood strikes, and not one that I pimp for traffic in a bid to be Internet famous.

    I didn't reach out to ask you or any of the others here to comment so in essence you are walking up to my front door and telling me you don't like the color my house is painted. Well, fortunately, I don't care if you don't like that color; it's mine and I'll paint it the color I like.

    And another thing; this post is almost 3 years old, so even if some things are now untrue they were not when I wrote them.

    Now, I've said above and I'll say again; there are use-cases where Drupal is a better fit than WordPress. WordPress requires either a highly motivated end-user or a site building professional to develop, install and configure it.

    OTOH Drupal works best where:

    • Professional-level graphic and user-interface design is not critical,
    • The project sponsor is not picky about how things need to be done,
    • There is no budget for any PHP code development, and
    • The end users are not highly motivated to learn and configure the system.

    Perfect examples of these kind of use-cases are in:

    • Academic administrations,
    • Local governments,
    • Low-budget associations

    And I'm sure there exist others although none come to mind.

    But for everything else, there's WordPress.

    I’m not going to go into great detail about them because others have already done so above – and done a fine job I might add.

    My response, specifically related to that one comment, is:

    "Whateves dude."

    …as someone I work with likes to say.

    Anywho…, you seem like a reasonably person who is just miffed that I called your baby ugly (that's just a well-known metaphor, I'm not being condescending or sarcastic.) You've had to work hard to develop expertise on Drupal and so if someone describes it as a bad solution you naturally get defensive and lash out; it's just human nature.

    But I stand by my opinions, even if me expressing my opinions can be viewed as me being "mean." OTOH I do respect your right to have your opinion; we all should have that right. But my belief that you have a right to your opinion doesn't require that I have to agree with it.

    Hopefully you can see that I debate the points when the debater is civil (as you pretty much have been) and that you now agree that when I get attacked ad-hominem as you saw above that I have the right to be less-than-civil in my responses.

    The last thing I'll say is this; in 3 more years many things will likely have changed, especially both our perceptions as our experiences continue to grow. 3 years from now WordPress may nothing more than a painful legacy technology or it may be thriving even more than today.

    But once thing I'm confident of is that Drupal will will continue its slow decline and that 3 years from now it will be a shell of it's former self. So I'd love to invite you back to visit in 3 years and see if you still have the same opinion of Drupal then that you have of it today. Either way, if I return in 3 years I'll be gracious.

  147. Such a nice blog post!

    I work on both drupal and wordpress and am a civiCRM developer..

    just wanted to add : using wordpress we can build cool as well as application oriented sites without comprimising on any aspect .. for various reasons mentioned in this post… and comments ..

  148. I only agree in two issues, some code decencies plus slow in the browser compared to wordpress, however from a development point of view, the views module alone does out smart the whole wordpress concept.

    Drupal is very flexible in terms of writing your own custom module to the extent it allows you to alter and hook.

    You don’t have to write a function theme, use the templates directly if you want to play with html code. Also With drupal 7 entities, the flexibility is extended to beyond content type.

    With a bit of cheats you can write complex database schemas. Beside php can be written through the filter in the page for quick editing.

    Drupal basically wins in both sides, UI for developers and flexible architecture for programmers. It is either drupal framework or upgrade to MVC for a serious business.

    Don’t waste your time with wordpress. I used to be one of those who are rejecting change and the future of php is in fact object orientated, therefore drupal is a framework compared to YII MVC even though drupal is not yet fully object orientated.

    You have to understand that complex projects require complex planning hence all cms solutions are not suitable for complex development including drupal. Do you want a fully custom solution then use MVC or do with drupal.

  149. While I admire your logic, and sometimes wrestle with my commitment to Drupal as the CMS/CMF (whichever may be your preferred nomenclature), I definitely have to take issue with the statement below. I humbly request the data upon which you base the assertion that Drupal is in decline? …and, more specifically, what is the nature of this decline?

    The contributors involved in creating Drupal 7 was double that involved in Drupal 6… and this increase is matched in the contributors to Drupal 8. So, no decline in commitment from the open source community.

    The adoption of the MVC framework Symphony, responsive design in core, WYSIWYG in core, Views in core, etc. greatly increase the power and flexibility of Drupal core (without extra modules) to new levels of developer, designer, and administrator friendliness. So, no decline in the technological advancement of Drupal.

    Drupal’s adoption in corporate America is blossoming, in no small way thanks to Acquia. Corporations such as GE, NBC/Universal, Pfizer, and Time Warner are standardizing their new site development in Drupal – even creating dedicated distributions for various business units. This is independent of Drupal’s continued growth in the demographics you somewhat disparagingly identify in your discussion above. So, no decline in the adoption and deployment of Drupal across various business sectors.

    I agree with most of the points of pain you identify, particularly in terms of Drupal migration/upgrades – though these are by no means insurmountable, and improvements in Drupal, associated modules, third-party tools, and general knowledge regarding best practices in handling this process since D6 have made the process fairly manageable. I do not agree; however, that Drupal is in decline.

    The WordPress-vs-Drupal debate won’t be settled as long as either remains available, at least not beyond the personal level :) Having not tried developing for WP I certainly can’t chime in, as that would be pointless… one cannot judge without using in earnest. Just not Ok with you complaining about hearsay arguments only to employ them yourself – wrist slapped.

    But once thing I’m confident of is that Drupal will will continue its slow decline and that 3 years from now it will be a shell of it’s former self. So I’d love to invite you back to visit in 3 years and see if you still have the same opinion of Drupal then that you have of it today. Either way, if I return in 3 years I’ll be gracious.

  150. Hi @AnotherTodd,

    Thanks for your comments, and your respectful tone.

    Your points are well taken, it’s possible that Drupal is not in decline. I posted that it was based on the following indicators:

    1. Anecdotal evidence in Atlanta where it feels like once a month I hear about yet another company leaving Drupal for WordPress,
    2. Google Trends showing a decline in search interest for Drupal (see above), and
    3. The W3Techs site showing a decline in Drupal use compare with growth of WordPress, as a percent of hosts on the web.

    However, I’ll openly admit that taken together these indicators still might not be statistically valid. I’d be happy to see any additional data that might provide a more accurate picture. Thankfully, unlike opinions over which is the better CMS the rate of growth or decline is an actual fact, assuming we can measure it correctly.

  151. This is a great review of the capabilities of both CMS platform. I am seeing a pattern evolve, older Drupal sites that I have passed along for others to maintain/upgrade have been abandoned and re-launched in WordPress. This is because those to continue to maintain the sites do not have the skills to do the Drupal work, but with WordPress there are many more people who can step in. I enjoy working with Drupal but for smaller schools, colleges and businesses I certainly see that they would want to move in the WordPress direction.

  152. Hi @geoff,

    Thanks for stopping by.

    While you do have a point, or should I say an apostrophe, I’ve always believed its better to cover a topic with that right words and in enough depth that a reader can understand it’s fine points rather than obsessing over punctuation within superficial content. (its/it’s misused here for posterity.)

    FWIW.

    -Mike

  153. Hi @SiePlake,

    Sorry for the very late reply, your comment went direct to spam and I just now found it.

    Honestly MikeSchinkel, have you ever used Drupal?

    For 2.5 years professionally and exclusively.

    Your 17 points, are at best ridiculous and at worst directly lying…

    Saying they are ridiculous doesn’t make it so. Let’s talk details not blanket admonitions.

    But “most of my clients” have specific needs demanding Drupal.

    I would argue that when you see clients “whose specific needs demand Drupal” it’s because you prefer to promote Drupal to them, not because of any actual “demands.”

    I don’t have the time nor the energy to get in depth regarding this question, but saying that W.P has the same (or perhaps even better) core/framework and can handle the same complex functionality IS TO LIE!!!

    Well it’s nice <sic> to be called a liar when I’ve only stated my opinion, and when the name caller won’t even take the time to explain what they think that I’ve said wrong.

  154. This article is absolute Bunkum.

    Maybe for the sites you build WordPress is a good choice, that’s great, it has it’s use cases.

    I enjoyed your summary where you say one of the best parts of WP is the custom page types, guess where they got that idea :)

    If you wanna build a blog, use WordPress, if you wanna build WordPress, use Drupal. Actually if you wanna build a blog, use Ghost.

  155. Hi @Matt,

    Thanks for taking the time to comment. Wish you’d given more justification for your opinion that just calling mine “Bunkum.”

    Here’s the irony; when I wrote this post over 3 years ago I was frustrated because many people were making the assumption that WordPress was just a blog, like you say, and that they assumed that Drupal was the better choice. Fast forward to today and the many agencies I know around town — and Atlanta with ~10 Fortune 500 has LOTS of agencies — are doing most of their projects in WordPress and are viewing Drupal as the past mistake that it was.

    But don’t take my word for it, just ask Google Trends what it thinks.

  156. Google Trends does not say much here. WordPress is also a service like Blogspot: http://www.google.com/trends/explore#q=blogspot%2C%20wordpress&cmpt=q

    More people searching for WordPress does not necessarily mean it’s better.

    WordPress has its strengths, sure, but I don’t see it as a solution for hosting huge sites such as The Economist or the White House.

    And the communities can’t be compared. Most Drupal modules are open source.

  157. but I don’t see it as a solution for hosting huge sites such as The Economist or the White House.

    I can see it for them; our opinions just differ.

    And the communities can’t be compared. Most Drupal modules are open source.

    I don’t see any reason they can’t be compared. Most WordPress plugins are open source too, and there are a lot more available WordPress plugins than there are Drupal modules.

  158. Hi Mike, I love this article (and have been using WordPress for about 90% of my projects), but since it was written so long ago, and since WordPress has evolved so much (for the better) in the past few years, could you comment on (or better yet make a brand new post on) the reasons WP is better (or how it compares) today to Drupal? In any event, thanks for the article, it has been very useful to me.

  159. Hi @Stephen,

    Thanks for the comment. If I have integrity and am intellectually honest, which I think both are true, I’d have to say that although I’ve had lots of experience with WordPress I’ve had no additional experience with Drupal since writing this post and thus it might be unfair of me to compare their current states.

    What I do know of Drupal is they seem to be moving more into the framework direction as Drupal are adopting much of Symfony. That tells me Drupal is becoming more complex architecturally but also very different than the Drupal I knew. If my understandings are correct that also means Drupal is moving away from being an empowering CMS and becoming more of a CMS toolkit for professional developers.

    Compare that with WordPress and I think WordPress continues to strive to be as approachable as possible to a wider cross-section of people. And yet still be able to scale to whatever level of complexity is generally needed in a CMS.

    Of course all of this is conjecture about current Drupal because, as you mention, I wrote the post we are commenting on a long time ago and I haven’t used Drupal since. Hope this helps?

  160. While came to this blog, somewhat!!! i h’ve seen both CMS platforms and patterns have evolved in other drupal websites and it have been abandoned and re-launched in wordpress. can you tell me that this will be helpful in future business?

  161. Hi @Zaria,

    Thanks for the comment. However, I’m not sure what you are asking. I see you run a consulting firm offering Drupal development; are you asking if you should start offering WordPress development?

    -Mike

  162. I’m here reading this because of the Backdrop fork of Drupal8.

    I’m not sure Drupal is just fragmenting at this point. Drupal8 constitutes a “fork” by engineers which is accepted as mainline by the establishment, Backdrop is an official fork done by major other figures in the community, modules there being decided to be incompatible with Drupal7. And drupal7 is the abandoned legacy version. nice… And they imagine that backdrop will pick up the non-technical and small business users, instead of relanching in WordPress??? Why on earth don’t they just continue to support Drupal7?

    Things like shortcodes in core make WordPress very attractive.

  163. My answer to this post and debate is one base on observation. When time does not afford me the ability to thoroughly analyze, well I just look at results. A good place to start is just for this is asking yourself, what do enterprise level businesses use for sophisticated and powerful sites. In my experience when the choice is WordPress or Drupal – WordPress is a joke and Drupal wins. Professionals with money on the line could care less about reviews rather only what works, what is reliable and scalable. Thats Drupal. Personally in my years of development, I have never been boxed in by this CMS.

  164. While I’ve always preferred WordPress, I have been testing the Drupal waters the past few weeks. Gotta say it’s like comparing a son to a daughter – too different to compare.

  165. @Wordpress Soon,

    Thanks for the comments and great points. Drupal should have launched a new project rather than create Drupal 8. It’s much like how Microsoft launched Visual Basic.NET after which Visual Basic became a footnote although it was once the most used programming language in the world. Maybe Drupal will see the same fate?

  166. @Lion,

    My answer to this post and debate is one base on observation. When time does not afford me the ability to thoroughly analyze, well I just look at results. A good place to start is just for this is asking yourself, what do enterprise level businesses use for sophisticated and powerful sites.

    Funny, I’m in Atlanta, Georgia USA home to many Fortune 500 companies and in my experience I am seeing more and more of them switch to WordPress instead of Drupal. What’s driving a lot of this is that the IT departments installed Drupal and the Marketing departments are finding it unusable and demanding the Drupal implementations to be replaced with WordPress. I bid one such project just last week.

    When the choice is WordPress or Drupal – WordPress is a joke and Drupal wins. Professionals with money on the line could care less about reviews rather only what works, what is reliable and scalable. Thats Drupal.

    Saying it doesn’t make it so. Responsible professionals look for what fits the needs the best and not cater to their own biases. In that case, many are finding WordPress to fit the bill better than Drupal for the reasons I outlined about.

    But don’t take my word for it, take a look a the Google trend lines for “Enterprise WordPress” vs. “Enterprise Drupal”, as one data point. The former is trending up and the latter is trending down. And if you are going to assert otherwise, please provide some objective data to compare with, not just mindless assertions.

    Personally in my years of development, I have never been boxed in by this CMS.

    I’m happy that it works for you; more power too you. OTOH, in my personal years of development Drupal is too tight a box to work within and it seems many others who are not Drupal evangelists are coming to same conclusion.

  167. Hi @DPP,

    Thanks for the comments. Yes, they are different animals but when they are selected it usually means the other is not; few people build a web presence that uses both Drupal and WordPress. IOW they are typically mutually-exclusive choices.

    So from that perspective, people need them compared.

  168. Ignorant animal Ride!

    LOL! Although that makes no sense I’ll give you as pass as Spanish is your first language.

    You have no idea of the stupid things you say.

    Are you sure that it’s not your difficulty with English that causes you to misunderstand what I say? Clearly if I were reading something in Spanish I would struggle to understand it too.

  169. WordPress is for people who are satisfied with things how they work out of the box.
    If you want flexibility you go for Drupal, and its learning curve.

    WordPress customization is a real pain, most of plugins don’t work except if you pay for them. And at that moment, let’s compare it as like if you want to make a house :

    WordPress provides the rooms, Drupal provides what you need to build the rooms.

    Saying one is better than the other one, is a total non-sense, it depends on what you want to do. If you are happy with WP plugins for how they work out of the box, and your WP theme, go for WP.

    If you want to customize everything go for Drupal. For original theming, Drupal provides theming frameworks like Omega 4.x or Zen which are pure gems in term of flexibility to build responsive layouts. WP has more themes ? Who cares when you want you want to build a corporate identity ? To buy a theme is the last thing you want to do anyway.

    When you build a site which is a business application, with customized workflows, and really personalized content for your users, WP is out of the game, because it is not a framework.

    Beside of this, WP and Drupal are 2 different dev models. Because Drupal modules are all free, and most of good WP modules must be paid, without guarantee theat they won’t interfere each other.

  170. Hi Mike,

    I just want to share my opinion on both CMS’s as a non developer who is a marketer/web designer. I can say that Drupal is an absolute nightmare to use. I am not sure why developers who love Drupal say it is better than WordPress.
    Drupal is supposed to be a CMS, which in turn means easy to use and deploy pages etc. by people who are non developers.

    As I am writing this post, we had to call in a so called Drupal expert for the charity I work for in the UK, as a booking module just stopped working and needed to be totally re-coded. We have lost at least £2000-£3000 worth of
    business this week for our training courses. We were also not able to find a suitable booking module as it is so scarce for Drupal
    or didn’t meet the requirement.

    I pointed out at least 3 or 4 in WordPress that we could have deployed in less than 24 hours and transferred the
    training course info/booking across if something like this would have happened in WP.

    True Drupal has better security and you can assign things to different useres, but WP does that now as well. Security has also been improving, and I used to work for an Info security firm (hackers) and we even switched across
    to WP at that company. The core is a lot more stable than people give WP credit for. I asked the guys at this hacker house, and they
    said, WP’s core would score around 8 to 9 out of ten for security. They rated it the same as Drupal’s.
    It’s the plugins which cause the problems of course due to poor coding.

    Anyway, at this new place I was stunned three months ago that they were using Drupal. Almost no-one knew how to use it.
    So, we are going through a re-brand and I have already come up with a plan to move across to WordPress.

    All our content, blog, a new shop, and members area will be easily deployed on a WordPress platform. Drupal, I have hardly found any decent modules for it, and don’t get me started on Uber cart. It seems to be the only shop as a module for Drupal. WordPress has at least 5 or 6 very good one’s.

    Uber cart!!?? gees can’t even use it out of the box properly.

    I am just about to write a CMS comparison in terms of plugins and functionalities for my business manager, so that we can move to a new website,
    and it already looks like WP is leaving Drupal dead in it’s tracks. Also, I am doing my evaluation from an unbiased perspective as there would be a lot of work to move this Drupal site due to the sheer amount of content we produce as we tackle and influence the
    British government on Child poverty and welfare.

    The person who made the recommendation on Drupal had left the organisation about 2 years ago, and these poor folks who many
    even find sending emails a task, are stuck with Drupal for content management or the lack of managing it. Only about 5 people out
    of 30 know how to use it for blogging etc.

    I showed them wordpress/gave them a demo with some tasks as test. Only about 6 or 7 out of 30 couldn’t complete it. Drupal, no point of
    testing as I already knew before hand that they were not able to use it.

    Again for the WordPress sceptics and Drupal lovers, it is supposed to be a CMS not something that is developer friendly only.

    So, WP wins hands down.

  171. Hi @Norbert,

    Thanks for taking the time to write such a great comment! Of course, it agrees with the premise of my article so I would like it. :)

    And yes, I’m running into more and more cases where Drupal fans selected Drupal for an organization and then the users found it to be unusable, and many are now taking control of the decision away from IT people (many of whom has bought into the “Drupal is the best CMS propaganda”) and the users are forcing moves to WordPress.

    Working with one such organization right now that is a professional membership organization. The Drupal developers delivered a public site and then promised a private membership site yet 2 years have passed and they still have not been able to complete. The client finally got fed up and has bid out a WordPress public and private site and I’m hoping our team will get the project.

  172. Hello,

    I was a php-html-css illiterate who entered web development community by trying to build a website on Drupal (OMG!). In the beginning I was amazed at the flexibilty. I tried Joomla and WordPress, but they did not offer the amount of Flexibility I got from Drupal, from the front end. Even though part of what you said is true, It still holds that Drupal is a more flexible CMS than anything I had ever seen. With D8 coming up, I am sure the difference in number of users between Drupal and WordPress will come down.

    Regards,
    Prathap

  173. Hi Rana prathap,

    Thanks for the comment.

    I will agree with you that Drupal is more flexible in some ways than WordPress, but in many others ways it is less flexible, most importantly theming. And what I’ve found is the latter flexibility is more important than the former.

    In the cases where WordPress is less flexible than Drupal there are plugins available to address almost all the differences if not all, and there are many plugins to address lack of flexibility in Drupal for which there are not modules.

    So lack of flexibility has never been a problem for me with WordPress. YMMV, of course.

    As for Drupal 8, let me be clear that I wrote this when Drupal 8 was at best an internal discussion on the Drupal inner circle, and Drupal 8 is evidently very different from Drupal 7 and before.

    But will Drupal 8 grow the Drupal user base and encourage WordPress users to choose Drupal?

    I highly doubt it, and I think there is strong evidence in the history of software platforms that would support my view. So I decided to explain in another blog post. I even decided to write a bit of advice on what Drupal/Acquia/Dries could do differently.

    I hope I wrote clearly enough so that you can follow my thought process.

    -Mike

  174. I know it’s a old post and i am not going to argue with this.

    I a Drupal user since three years and i also maintain some modules on Drupal.org

    I am not familiar with WordPress enough to make a comparaison. Anyway i think your article is still very interesting, even if I am pro Drupal. I still see WP as a blog generator, which has been “extended” to websites.

    I would certainly agree that Drupal API can be a pain in the ass (pardon my expression) at the beginning but the main strengh is that you can build a website without writting a single line of code (or few) and you have a strong community which develop modules which extend the possibilities of Drupal. Modules like Views, Panel, Rules, Commerce or even Pathauto, which are very powerful and completely free. There’s not duplicate module, you have one module for one need, which is nice i think, what about WP ?

    Anyway, there’s one thing i didn’t see in your article, it’s the translation management. For Drupal, i would say it’s quite difficult because there is not a united interface to manage the translation. It seems better in D8.

    Same for DB management, Drupal is compatible with MySQL, PostgreSQL and SQlite. Drupal 8 will allows the use of other database type like document database (MongoDB), what about WP ?

  175. Hi @Jibus,

    Thanks for taking the time to leave a comment.

    I still see WP as a blog generator, which has been “extended” to websites.

    Given that you stated that you are not familiar with WordPress, is that classification really fair? WordPress started as a blog 10+ years ago, but in that time it has become so much more.

    …but the main strength (of Drupal) is that you can build a website without writing a single line of code (or few)…

    Are you not aware that is now also true with WordPress, when plugins and themes are used, most of which are open source?

    …and you have a strong community which develop modules which extend the possibilities of Drupal. Modules like Views, Panel, Rules, Commerce or even Pathauto, which are very powerful and completely free.

    I’m not sure how this is a benefit of Drupal over WordPress, unless you just really prefer the name “module” over “plugin.” WordPress has a much larger number of very powerful and completely free plugins when compared to Drupal’s module count. At the time of this writing there were 15,574 modules for Drupal vs. 33,072 plugins for WordPress.

    And add the fact that most maintained Drupal modules are version specific and most maintained WordPress plugins will work with the latest version then the ratio of applicable Drupal Modules to applicable WordPress plugins becomes much smaller indeed.

    …There’s not duplicate module, you have one module for one need, which is nice i think, what about WP ?

    I will give you that point related to WordPress, for selected functionality. Sometimes there are just too many plugins doing the same thing, not working together, and none with all the features you want. But I don’t think that problem is unique to WordPress; I think Drupal also has this problem.

    One of the issues I had with Drupal when I used it was that there was no single standard WYSIWYG editor nor was there a standard way to attach and use images; both of those issues were addressed in WordPress core well before I wrote this post ~4 years ago (kudos that Drupal finally integrated an Image module into core.)

    So it seems there are still other areas where Drupal does not have just one module:

    …Anyway, there’s one thing i didn’t see in your article, it’s the translation management. For Drupal, i would say it’s quite difficult because there is not a united interface to manage the translation. It seems better in D8.

    There is no built-in translation management admin UI in WordPress although there are several plugins that provide UI for managing multiple languages but adding support at the code level for a plugin is rather easy is you also use PoEdit.

    Same for DB management, Drupal is compatible with MySQL, PostgreSQL and SQlite.

    In my experience with Drupal I’d say that Drupal’s support of those different databases is less of blessing and more of a curse. The modules you reference as a benefit are rarely written for and/or tested with more than MySQL so the upshot is that choosing one of the other databases leaves you with a less capable site that cannot use many of the available modules. And when you do choose modules without explicit support for your database you really should to rigorous testing to ensure they work, and even then future updates may not.

    What this means to me is that I don’t think an organization would be making a prudent choice to use Drupal with any other database besides MySQL.

    And assuming I’m right about the database choice that leaves Drupal with the burden of maintaining least-common-denominator support for all those databases when they could be spending time on other more useful development even those it’s rare for people to use anything other than MySQL.

    Drupal 8 will allows the use of other database type like document database (MongoDB), what about WP?

    Similar comments to MongoDB assuming it’s used as a replacement for MySQL. If instead used in conjunction with MySQL and for data that MySQL does not handle well then that’s great.

    BTW, I’m personally currently working on a future planned addition to WordPress core that addresses the same needs as CCK, and one of it’s goals it to allow alternate storage providers to enable use of MongoDB and other data storage such as Amazon S3 for when those are needed.

  176. The real deciding factor comes down to what you really need your site to do in the end and how much effort and time you are willing to put into it. Being an experienced IT specialist – I left robust and powerful Drupal in favor of more popular WordPress and don’t regret about that. I consider WordPress to be one-fits-all solution – hardly any other CMS comes close to it in terms of multifunctionality and flexibility. By the way, I managed to switch from Drupal to WordPress within my coffee break (found an online converter which performs migration with minimal human involvement – CMS2CMS)

  177. Drupal and WordPress both are good! They both could meet most customer’s requirement! It’s very hard to say which is better because the visitors don’t care who they are!

  178. Hi Mike, thanks for starting an interesting discussion, I’ve learnt a lot from it. While I appreciate that a lot of the responses have been aggressive in tone (and I respect you for publishing these), I feel you have been somewhat dogmatic in conceding some of the very valid points in Drupal’s defence. Fair enough, it is your blog after all and you are entitled to your opinion.

    In my five years’ experience of developing for WordPress and Drupal, I have found the most frustrating aspect of WP to be the plethora of similar plugins, making it difficult to choose the best solution. And each developer takes their own path with coding architecture and even diverging admin UI. The Drupal world seems to encourage collaboration between modules, and common standards for UI.

    I take your point that for those fluent in PHP, with WP it’s a bit easier to hack an existing plugin into something you need. But I feel that once you have taken the trouble to learn the Drupal API – a fairly painful learning curve – you’ll be able to create sites in a much more elegant way. And non-coders out there are able to create very sophisticated functionality in Drupal without having to find the exact plugin for their use case.

    I can’t help feeling that there is space for both of these great Open Source frameworks, and a developer that knows both can make a good decision as to which is most suitable for the job at hand.

  179. Hi Robin,

    Thanks for the comments and you make excellent points all around. I do wish that the WordPress community were more collaborative with plugins, but what is missing is leadership in that area from Matt or the core development team.

    That said, I still don’t think the downsides of Drupal are outweighed by the downsides of WordPress, at least not IMO as you so graciously acknowledged. :)

    And here’s a great blog post by Ben Ostrower of Wide Eye Creative — who build high-profile political websites — about how they previously used Drupal but then moved to WordPress and how much better it has been for their clients.

  180. Though I haven’t worked with Drupal, but I worked in WordPress and its slow. It lacks flexibility compared to frameworks.

    Lots of free plugins and themes??? Most of them are unusable and amount of time it requires to customize them equals to building from scratch.

    Inexpensive programmers and designer? From when cost equals to talent? Talented people will always be expensive and will give output 2x times faster than the novice guys.
    Any entry level junior guys claim that they know wordpress while they only know copy/pasting the old code and its very hard to differentiate a good programmer from a novice one in case of wordpress.

    How many big sites are there in wordpress? Most of them are newspaper style sites or the company websites or portfolio websites. Building a yellow page or classified kind of sites in wordpress with 100,000 of data????

    For small sites wordpress is great and 50-60% of sites are small or company websites. Thats why wordpress has more popularity than any other cms.

    Yes, its UI is great.

  181. Hi @Sudip,

    Thanks for your comment.

    Though I haven’t worked with Drupal, but I worked in WordPress and its slow.

    Slow is relative. Depending on configuration which would typically include Nginx, Varnish and Memcached/Redis, WordPress can be extremely performant.

    It lacks flexibility compared to frameworks.

    ABSOLUTELY. But this post was a comparison of two leading source open-source CMSes, not a comparison of a CMS vs. a Framework (such as Symfony, Laravel, etc.) Comparing them is like comparing a Ford F-Series truck with a Ferrari Enzo, and criticizing the Ford for not being fast enough nor handling corners as well.

    Lots of free plugins and themes??? Most of them are unusable…

    Certainly, many of them might be “unusable” (though not sure what your definition of that is), but the more free ones there are the more that a small subset of them will be extremely usable; it’s the long tail theory applied.

    …and amount of time it requires to customize them equals to building from scratch.

    Not exactly. Most of the implementations that my team does are mostly custom code, but we frequently review plugins to learn how they accomplish their core functionality we don’t have to do discovery R&D to figure it out, and that saves us tons of time.

    Inexpensive programmers and designer?

    Can I assume you are someone who gets hired and not someone who hires? Maybe it you were the latter you could have a broader view of this.

    To hire developers of the skill level capable to work with a framework is significantly beyond the reach of many businesses. Yet those same businesses can afford to have a WordPress site build because there is so much pre-made functionality available.

    From when cost equals to talent? Talented people will always be expensive and will give output 2x times faster than the novice guys.

    Of course. My billing rates are much higher than the average WordPress site builder, but that’s because I specialize in an area that most WordPress professional don’t have expertise in. And I can architect and build systems that would stump many WordPress site builders.

    But it’s not because I’m somehow “special”, it’s because I have more developer experience than most in WordPress; I was programming professionally before many of them were born, when the founder of WordPress was in primary school.

    Any entry level junior guys claim that they know wordpress while they only know copy/pasting the old code…

    This is very true. I have come in to projects after the client hired people like that only to find out they couldn’t handle PHP or MySQL beyond cutting and pasting.

    But that does not mean those same people cannot provide great value to a large segment of clients. And they do on an ongoing basis. Now my title didn’t say “WordPress is the best CMS for every single use-case”; there are some use-cases it’s just not cut out for, although those use-cases are becoming fewer and fewer.

    …and its very hard to differentiate a good programmer from a novice one in case of wordpress.

    True, but it’s also very hard to differentiate a good programmer from a novice one in case of a framework. So this is really a moot point.

    How many big sites are there in wordpress? Most of them are newspaper style sites or the company websites or portfolio websites.

    Depends on what you call a big site? Of course neither Yahoo nor Facebook are built on WordPress; they are beyond what WordPress can handle. But there are many other use-cases that WordPress handles brilliantly.

    Building a yellow page or classified kind of sites in wordpress with 100,000 of data????

    100,000 “what” of data? 100,000 phone entries or 100,000 listings? Sure, no problem.

    Examples of complex sites that run on WordPress that are more than just newspaper, company or portfolio sites, including a store that has 100k+ products:

    http://www.transpacific-software.com/blog/integrating-woocommerce-with-diamond-data-from-rapnet-or-idex/
    http://www.bbcamerica.com/
    http://ualr.edu/
    http://martaguide.com/
    http://shop.spectator.co.uk/
    http://www.soulbrother.com/
    http://www.quora.com/Large-e-commerce-site-on-WooCommerce

    ~23% of the web runs on WordPress now. A good many of those sites are going to be large.

    For small sites wordpress is great and 50-60% of sites are small or company websites. Thats why wordpress has more popularity than any other cms….Yes, its UI is great.

    Also agreed.

    Where WordPress is not the best is for insanely high traffic sites (like Twitter or Facebook) or for highly complex software-as-a-service type applications. For most everything else, it rocks!

  182. Mike, you wrote, “Any design? Any? Are you willing to make that bet? (and if so, what/how much are you willing to actually bet?) Because that’s a bet I would take.”

    Drupal is design agnostic. My company begins with a clean slate and designs whatever the client desires, then we integrate that design with Drupal.

    We’ve put together a distribution that creates an incredibly user-friendly expeirence utilizing various Drupal core and contrib modules, and when we incorporate the design, the client is able to manage his/her website with great ease.

    I’ve had a number of clients come to me from WordPress, and after switching the over to Drupal (7.x), they have been extremely pleased, and they rarely contact me for assistance because it’s so easy to use/administrate.

    See http://carsonw.com/portfolio and the various designs, including, but not limited to

    http://amazingparish.org
    http://team-ride.com
    http://catholicveritas.com
    http://thestingwisher.com
    http://saclife.org

  183. Hi Carson,

    Thanks for commenting.

    Looking at your website it seems you are a one-man shop, who does the design yourself? Then of course you can make sure your design fits Drupal. Try working on a team in an agency where the person doing the design only knows Photoshop and the person building the theme only knows HTML+CSS and then come back and tell me you can get any design to work in Drupal.

    Speaking of Core and Contrib Modules, are you aware how much overhead they can take and how they can slow down a site and cause Google to shun them? Let’s take a look at a few of your sites using Pingdom:

    http://tools.pingdom.com/fpt/#!/cLkRTc/http://thestingwisher.com
    164 HTTP Requests and 2.10 second page load. Ugh. You’ve got to get your HTTP requests down, and using Drupal I think that’s difficult.

    Here’s a WordPress site I was just involved in launching that is twice as fast and almost 1/4th as many HTTP requests:
    http://tools.pingdom.com/fpt/#!/1N8KZ/http://techpageone.dell.com

    Moving on this one only(?) took 130 HTTP requests but took 9.97 seconds to load! Seriously?!?
    http://tools.pingdom.com/fpt/#!/iseTj/http://catholicveritas.com

    Sorry, but I still think that by using Drupal you are doing a disservice to your clients. I know you’ll disagree, but we’ll just have to agree on that.

  184. Mike,

    Because Drupal is design agnostic, my company can take any design and implement it on Drupal. It doesn’t matter who creates the design and the markup. It’s fairly easy to implement.

    Yes, I am aware that code – regardless of the CMS – can be written in ways that lead to poor performance and in ways that lead to great performance. I am also aware that as you add plugins and modules to a CMS, you risk a loss in performance.

    I am also aware that with various Drupal module configurations, you can greatly decrease the number of HTTP Requests, as I demonstrate below.

    Finally, I’m aware that page load time can have little to do with the number of HTTP requests and can have everything to do with the hosting environment and network latency.

    Take http://tools.pingdom.com/fpt/#!/cLkRTc/http://thestingwisher.com for example.

    You mentioned that it involves 164 HTTP Requests and a 2.10 second page load time.

    (All of the stats below are taken from Pingdom.)

    1. 50 of those requests were due to the Facebook and Twitter Widgets. Remove those and you’re down to 114 Requests with a page load time of 1.15s. (http://www.screencast.com/t/dX4sQXH1SxK3)

    2. Then, with the quick and easy implementation of the “Advanced CSS/JS Aggregation” Drupal module, I was able to decrease those requests to 32 with a Load Time of 731ms (http://www.screencast.com/t/lIkQv5TrT)

    So… perhaps your observations should be revised?

  185. Hi @Carson,

    Thanks again for taking the time to comment.

    Because Drupal is design agnostic,…

    You say it is design-agnostics, and I say because of the architecture it is not. We’ll have to agree to disagree.

    …my company can take any design and implement it on Drupal.

    Sure, because you are highly motivated to do so, and probably more skilled than the average themer. But you didn’t address working on a team where the people doing the theming are junior HTML+CSS coders, which is often the case in a larger agency project.

    It doesn’t matter who creates the design and the markup.

    Actually it does. If the HTML is not fully modular, i.e. if the HTML coder implemented their HTML such that the HTML does not fit neatly into blocks they you either have to toss most of what Drupal does for you or redo the HTML. I’ve been there, please don’t tell me that’s not true.

    I am also aware that as you add plugins and modules to a CMS, you risk a loss in performance.

    Some risk greater performance degradation than others. My point was WordPress often bundles CSS and JS as part of core and it appears Drupal does not.

    I’m aware that page load time can have little to do with the number of HTTP requests

    Sorry. that is simply not true. The #1 most useful performance best practice is to Minimize HTTP Requests. Period.

    Then, with the quick and easy implementation of the “Advanced CSS/JS Aggregation” Drupal module, I was able to decrease those requests to 32 with a Load Time of 731ms…

    If it is so easy, why would you ever deliver a client’s site without it?

    Listen, I wrote this post almost 4 years ago but have left comments open because I hate when people close comments. Still, it’s 4 years old and AFAICT it has been proven correct by the number of clients we are seeing either leaving Drupal for WordPress or choosing WordPress instead of Drupal. That was not the case 4 years ago.

    Yes, I know you believe strongly in Drupal. But I believe just as strongly against Drupal. So let’s just leave it at that and agree to disagree.

  186. Mike,
    Your assessment of Drupal is not correct IMHO. I have built several big sites on Drupal and a couple on WordPress. The rest were hundreds of “design based” sites with standard functionality. I have to tell you that when the chips are down, you can get Drupal to do things that WordPress would struggle to do ( or rather the developer would struggle to make happen ). I look at Drupal as military grade.

    I love WordPress as well, but there are certain types of sites that lend themselves to the complexity of the Drupal architecture. Of course if you are only talking about implementing a “design” based site with stock functionality, why would you not use WordPress.

    Drupal shines in the hands of serious developers and coders who need to really create architecture and build functions that never existed, yet fit perfectly into the framework of Drupal. Can you do that with WordPress, sure but you would be a real trailblazer and I doubt anyone would try.

    Many complex site concepts fall victim to the .net / aspx world, where sites are super expensive and require a team of “engineers” to maintain them. The companies that require enterprise performance do fine with Drupal, but they don’t often use WordPress, and I think that is because the WP talent pool is really not capable of building a $50k site.

    You will find that more enterprise level web apps are built on Drupal and that many large firms use WordPress for their social sites.

    WordPress is a great CMS, but Drupal is also great and although it is misunderstood by many, it has proven to be very friendly once you understand the design work flow.

  187. Thanks again for taking the time to comment.

    Thank you for taking the time to dialogue.

    Try working on a team in an agency where the person doing the design only knows Photoshop and the person building the theme only knows HTML+CSS and then come back and tell me you can get any design to work in Drupal.

    It’s fairly easy to implement any theme into Drupal. It doesn’t require an expensive, specialized skillset for the elite, esoteric few. Take it from someone who only knew basic HTML + CSS and didn’t have any familiarity with PHP and was asked to implement that into the Drupal theme layer.

    Do you have to learn ‘how’ to do it? Yeah, of course… and to be honest, I’ve discovered that it’s a whole lot easier than WordPress, but I’m not here to diss WordPress (I recommend WordPress when I feel it is appropriate to meet my clients’ goals). I’m commenting here to share my experience of Drupal, which is very different than your experience.

    If the HTML is not fully modular, i.e. if the HTML coder implemented their HTML such that the HTML does not fit neatly into blocks they you either have to toss most of what Drupal does for you or redo the HTML. I’ve been there, please don’t tell me that’s not true.

    That’s not true. *smile*

    Drupal is extremely flexible. It’s like a toolbox, and you can choose whichever tools you would like to accomplish the goal you have in mind.

    In Drupal 8, Drupal is getting even more flexible with an even easier, more awesome theming system, by utilizing Twig.

    Some [plugins and modules] risk greater performance degradation than others. My point was WordPress often bundles CSS and JS as part of core and it appears Drupal does not.

    Yes, Drupal does bundle CSS and JS as part of core. It’s under admin/config/development/performance.

    And just like W3 Total Cache, WP Super Cache, etc. for WordPress, you can extend Drupal with contributed modules to go even further when aggregating and minifying CSS and JS.

    The #1 most useful performance best practice is to Minimize HTTP Requests. Period.

    Actually, that’s not true if, all other things being equal:

    • Site A requires 30 HTTP requests and is on a Hostgator cPanel WHM VPS with 20 busy sites and 500 email accounts, and if it is being accessed from Australia, and

    • Site B requires 200 HTTP requests and is on its own Digital Ocean SSD Droplet in San Francisco and is being accessed from Texas.

    In that case, it doesn’t matter how many HTTP requests your site requires, Site B will always outperform Site A.

    That is why I said, “I’m aware that page load time can have little to do with the number of HTTP requests and can have everything to do with the hosting environment and network latency.

    “Then, with the quick and easy implementation of the “Advanced CSS/JS Aggregation” Drupal module, I was able to decrease those requests to 32 with a Load Time of 731ms…”

    If it is so easy, why would you ever deliver a client’s site without it?

    I just didn’t. There’s no good reason other than that it was my own fault. Don’t blame Drupal. Blame me.

    So… yes, it really is so easy. I’m not lying to you.

    I do have to admit, it was a little fun doing that optimization, to prove that your conclusion as incorrect. And it took all of 5 minutes? =)

    Listen, I wrote this post almost 4 years ago but have left comments open because I hate when people close comments. Still, it’s 4 years old and AFAICT it has been proven correct by the number of clients we are seeing either leaving Drupal for WordPress or choosing WordPress instead of Drupal. That was not the case 4 years ago.

    Well, in my experience, clients who have migrated from WordPress to Drupal have experienced extreme satisfaction, due to its great usability, which I demonstrate in these two videos:

    https://www.youtube.com/watch?v=sKsR7B47lG4
    https://www.youtube.com/watch?v=66l32Xk7Hc8

  188. Hi Carson,

    It’s fairly easy to implement any theme into Drupal. It doesn’t require an expensive, specialized skillset for the elite, esoteric few. Take it from someone who only knew basic HTML + CSS and didn’t have any familiarity with PHP and was asked to implement that into the Drupal theme layer.

    That's your opinion and one in which my experience disagrees. And your’s is an opinion colored by your willingness to learn the arcanity of Drupal theming. My experience with HTML + CSS people who don't want to learn how to modify their process to accomdate Drupal is different from yours. Again probably because you are a one-man shop and I work with teams of people.

    I’ve discovered that it’s a whole lot easier than WordPress, but I’m not here to diss WordPress (I recommend WordPress when I feel it is appropriate to meet my clients’ goals). I’m commenting here to share my experience of Drupal, which is very different from your experience.

    Again, your opinion and experience is colored by your desire to promote Drupal. Note my opinion is colored by my past use of Drupal even though previously I had a desire to promote Drupal (for example) until I came to learn how much easier WordPress was to work with.

    If the HTML is not fully modular, i.e. if the HTML coder implemented their HTML such that the HTML does not fit neatly into blocks they you either have to toss most of what Drupal does for you or redo the HTML. I’ve been there, please don’t tell me that’s not true.

    That’s not true. smile

    Drupal is extremely flexible. It’s like a toolbox, and you can choose whichever tools you would like to accomplish the goal you have in mind.

    Saying it does not make it so. But then as I've said, we should just agree to disagree.

    In Drupal 8, Drupal is getting even more flexible with an even easier, more awesome theming system, by utilizing Twig.

    Ah Drupal 8. The savior. I have already written about why, in time Drupal 8 will be looked back on as a failure.

    Yes, Drupal does bundle CSS and JS as part of core. It’s under admin/config/development/performance.

    Fair point.

    The #1 most useful performance best practice is to Minimize HTTP Requests. Period.

    Actually, that’s not true if, all other things being equal:

    Yes, you can cherry pick the worst hosting scenarios and the best hosting scenarios and find a case where industry best practice does not excel, but doing so is really disingenuous when we are discussing best practices.

    I could provide best practices for retirement planning and you could reply that they are not best practices for African Bushmen but that would only be you being petulant and would not discredit retirement planning best practices. Same goes for HTTP Requests.

    I just didn’t. There’s no good reason other than that it was my own fault. Don’t blame Drupal. Blame me.

    But nonetheless we should trust that your experience is sufficient to prove Drupal is the superior CMS?

    So… yes, it really is so easy. I’m not lying to you.

    I was not implying that you'd be lying. What motivation would you have for that?

    Instead I believe your preference for Drupal colors your opinion and the fact you run a one-man shop and do not work with numerous agencies and lots of different team members with lots of different skill sets means you don't have the valid experience to truly evaluate your assertions.

    Well, in my experience, clients who have migrated from WordPress to Drupal have experienced extreme satisfaction,

    Your Logical Fallacy is "Anecdotal".

    due to its great usability, which I demonstrate in these two videos:

    You have a funny view of usability. I daresay most of the commenters on this post (and there have been many) would disagree with the statement: “Drupal has great usability.”

    And matching your logical fallacy, I know that the people I've spoken with who have unfortunately had Drupal implemented for them by a group advocating Drupal have all found it quite unpleasant to work with, especially the ones that have since converted to WordPress, for example the Stanford Law School website (you have heard of them, right?) and PrimeGlobal, the latter whom we are converting to WordPress in 2015.

    Finally, you are not going to convince me that Drupal is okay and I'm not going to convince you that it has problems, so let's just stop this debate of mere assertions and unvalidated anecdotes and allow our prior written words to be our proxy.

  189. Great Article.I came across your article while being extremely happy with wordpress but wondering if drupal 8 could be better than wordpress now i am sure it’s not.
    Even though I am reading it 4 years later I agree with all of your points and I think most of them are still true to this day.

    A few pro wordpress thing’s I think you missed:
    for those who want absolute customization capability I recommend formidable pro (forms with views like gravity forms but better and cheaper) great help to build anything you can imagine for user’s who don’t need access to back end. Use cases : directory listing, booking, I even created a full CRM with it.

    Advanced custom fields if using just the back end is fine. If custom post types are needed Combine that with generatewp.com (I prefer that to pods).
    With those you can handle relationships and you also get any kind of fields you need you can also add your own if it’s not available. This way anything that needs to be customized by users can easily and quickly be added to the respected page/post/post-type.

    The above is for those who won’t mind a bit of php and like to build advanced websites with custom relations and extra functionality but for end user’s and designers with no php skills who want to still design their own website and not pay a wp developer. Try one of the top themes from themeforest that comes with visual composer. They are not just themes they are WYSIWYG site builders for those who don’t like php.

    That being said i have couple problems with wordpress too. one is acl that took me awhile to figure out. I can do it by coding and do it faster by plugin’s like members(1 year no update (WPFront User Role Editor (new one i like) ) But I think acl should be core for any fully functional cms.

    Second is e-commerce for that i’d go with prestashop because there are some basic functionalities you need and can do them with prestashop for free which would cost you over $2000 a YEAR worth of woocommerce plugins (and only 25 sites not unlimited license) for example product attributes and customer groups- product bundling etc.

    Anyways i am kinda new to wordpress about 8 month and you obviously know way more than me. so any correction in my choice of plugins and suggestion for plugins that could make my life easier in wordpress is highly appreciated .

    Oh and excuse me for my bad english it’s not my first language

  190. Hi @Daniel,

    Thanks for the great comments.

    Not a big fan of Advanced Custom Fields, but then there’s not a significantly better solution at the moment.

    Speaking of Drupal 8, have you read this later post I wrote?

    -Mike
    P.S. Your English is very good, no worries!

  191. Thanks for your reply. yes I did. Actually that’s what came up in google and i got here from there. good article as well although from what you described i doubt it can be fixed even if they did those things !

    oh and no comment on acl in wp ? I’m curious what savvy wordpress devs do ?
    do you code everything yourself ? created your own plugin ? use a third party free/premium plugin ?

    Would love to hear from you and Thanks again for your quick reply and amazing articles.

  192. Hi @Daniel,

    I didn’t mention issues with ACL because of time, but I don’t like how they store two meta fields for each value, and especially don’t like how how it is to change field names as an architecture evolves.

    In the past we’ve rolled our own in a variety of ways and I am working on an alternate to hopefully include in WP core, but didn’t want to talk about it too much until I actually have something to release.

    -Mike

  193. Care to share your Joomla story, Mike? I ran across this post and saw you had some experience with Joomla but saved that story for another day.

  194. I’m a themer for both, WP and Drupal. As a frontend dev, I pledge for better felxibility regarding both.
    A clean theme, from scratch takes 5 minutes in Drupal and 20 seconds in WP (using underscores for example).
    Everything is slower working in Drupal, but this is not the issue.
    The issue is I really can’t find free options regarding complex functionality in WP. For Drupal it gets easier, once you have Views and Entities. There’s no complicated code I have to write to achieve such performances. As a front end, this is THE absolute mind-blowing advantage.
    Drupal without Views is really a PITA.
    WP without Views is really a PITA.
    We’re not talking about blogging or presentations websites. For that, we know WP is king. Really complex websites are not supposed to be easy or cheap to build, regardless platform. SO, are we talking about performances or lazy ass developers or cheap clients?

  195. Yes the facts say it all
    wordpress is all about innovation, an evolutionary process. It takes time, profound body of knowledge and continuous passionate efforts to build technology and process breakthroughs.
    Regards – marketplace scripts

  196. I always enjoy a heap, reading posts from frustrated Drupal’s beginners! It’s not your job! You did well to move to WordPress!

  197. respectfully, i think this post http://websitesetup.org/cms-comparison-wordpress-vs-joomla-drupal/ is less parcialized and a bit more updated for the people who really wants to know wich CMS to use without have “Fanatic Arguments” it shows the scenario of the 3 major CMS and not only “the ones i’ve tried” and really can help you to make a idea according to each developer skills vs client needs, less subjective and definitively less “Fanatical” (i think “Devoted” is a better word) than this post and answers…

  198. Hi @Reynerth,

    Thanks for the comment.

    You say “Fanatic”, but I say “Frustrated.”

    I picked WordPress over Drupal because Drupal frustrated me on so many different levels, and not because I first choose WordPress and as such became a fan in a vacuum. I knew Drupal well before I left it in disgust.

    -Mike

  199. Hi Mike,

    This is a great debate and I’m loving it. I don’t have time to read all but (read 50%), I was very impressed to see how you have changed from Drupal to WordPress and the way you were able to answer back those tricky questions and comments with solutions were amazing.

    I’m just a freelance web designer for non-profit organisations to help them out free of charge and for small business etc. I started off with Joomla and Drupal and used to criticise WordPress a lot but now I’m 100% WordPress user and when I looked back to those days, I was in the wilderness and depending and waiting and waiting on someone to find solution or search through forums after forums to see anyone has done something to fix the issue.

    Now with WP, I don’t have to search too far as the main WordPress site offer most solutions and fixes are there already. Tons of plugins and endless beautiful Themes that are far superior than Drupal or Joomla. And like you said, if you want something done (customise larger scale) out of ordinary to your theme, you can buy the professional themes and their support never let me down yet with little money to pay for. I know basic PHP which helps me to do most of minors stuff.

    I’m now much more relaxed than ever with WP.

    Take care and long live the WP! :-)

  200. Your article is nonsense.

    Why should an apple be better than a rabbit? a horse better than a cow
    You are comparing two different platforms.

    I use both depending on the needs

  201. @remi

    If people frequently make a decision to use EITHER Drupal OR WordPress and NOT BOTH — which many do — then a comparison is not nonsense. Instead, your comment is nonsense.

    -Mike

  202. pls just use what you know to do what you need…

    and dont compare two look alike platforms that have diferent porpuses…

  203. Hi @pls,

    Please don’t be so rude as to tell me what I can’t write on my own blog…

    That said, WordPress and Drupal may have different “porpuses” in your eyes, but in my experience they are often the two (2) platforms people consider using and then pick one. Given that experience then it makes perfect sense to compare them.

    Of course, since I wrote this over four (4) years ago I’m finding many fewer cases where Drupal is making it to the shortlist.

  204. I think that we must not look just at technical aspects to compare WordPress and Drupal.

    My opinion is that WordPress’s creators has clear in mind what WordPress is and what is the purpose for which they develop it.
    Drupal’s creators don’t.

    I mean, WordPress is a platform for editors, very user-friendly, where you can find everything you need to write your editorial contents.

    For which kind of users Drupal is built for?
    Drupal 6 and 7, was built to help “NON-developer” users to do things that usually developers do. For example: views, content types, sophisticated taxonomies.
    But I think that from Drupal 7 to Drupal 8, Drupal loses its way.
    So, who can use Drupal? a “NON-developers”? not really, because a “NON-developers” can find Drupal very difficult, so he prefers WordPress.
    A developers? But if I am a developer, I prefer to use a framework and build from myself things like views and content type.

    This is the reason why I prefer WordPress.

  205. Hi @Alex,

    Great comment, and thanks for taking the time to communicate it.

    I had not considered that perspective but it does make a lot of sense.

    However, I did write a follow up post that comes to a similar conclusion.

    -Mike

  206. Hi Mike, you only managed to find 17? Is that it? No seriously this is a really great post and really well researched. I think the growing flexibility of WordPress is one reason why it seems to be growing in popularity. Sure there are some vulnerabilities with security but tell me a platform that doesn’t? Plugins like Wordfence can help with this.

  207. Blablabla… I recently tried to update WP via command line, since I am using Nginx the core update doesn’t work from my WP backend.

    Drupal has a command line tool called drush. Simply type the command ‘drush update core’, core is updated.

    I tried to find a similar solution for WP, and found the WP-CLI tool. Unfortunately, it doesn’t work that simple. In fact, it doesn’t work at all.

    So, talking about reasons to use WP, here is ONE to better stay with Drupal, when using Nginx as your webserver.

  208. Hi @Robert,

    Thanks for the comment. I can’t speak to that because we managed hosting and they manage NGINX. Locally we use Apache because it’s easier.

    Now if WP-CLI does not work with NGINX, that needs to be addressed. Thanks for pointing it out.

    -MIke

  209. Dear Mike,

    Thank you very much for your post. It was very helpful for us in making a difficult business decision: as a small website develpoment, SEO and online marketing agency we decided to forget Drupal in the future and work in WordPress only.
    A few months ago a client asked for a webshop, selling files (of designs). We were struggling with Drupal Licence module for at least a week, listening to all tutorial videos, trying the process at least 60 times to get it working. (We are not native English speakers, so you can imagine…)
    A few weeks later another client was planning to sell e-books, and insisted on WordPress. I found 2 solutions for that: Selling Media and Woocommerce. I installed the function in 1 hour… and went crazy.
    Many years ago, in 2007 we put our vote to Drupal, because it was W3C standard. (Previously our HTML websites were W3C valid sites.) It is history, our Drupal sites are not valid anymore.
    On top that we swallowed that we work slowly due to the lack of our knowledge – but net net after so many websites and solved things we are not quicker at all! And it is not our fault – this is the over-complexity of Drupal.
    Costumers are not interested in the type of CMS (at least in our country, yet) – they need a working website and a website designer who is confident, and telling them that “It’s OK, I can answer your request.” They are not interested in how hardly you work with a stupid Licence module…

    Of course there are things what cannot be done easily with WP, but it is the same as Drupal! The more complicated the site is, the bigger the chance that the next update would put bugs into your system. It happened to us a few times!

    Net net, we look forward to our WordPress adventure in the future, and hopefully we can increase our own turnover just by being much more quicker!

    Maria

  210. Very long time drupal user. I just switched to WP because I’m not rewriting everything again for Drupal 7, then 8, then 9. For custom code. Drupal is a nightmare. WP seems to stay backward compatible. I don’t have time for Drupal any longer.

  211. After doing Joomla! and WordPress in past and now doing Drupal for living, it all boils down to one simple thing. Skills.

    Drupal takes more skills to build and maintain and in MY opinion it can flex much wider, be customised to do pretty much anything wherein WordPress feels bit limited.

    WordPress is a good platform if you are starting on CMS-sites and want an easy&fast solution for website. After you stop trying to force your WordPress or Joomla! thinking in Drupal and figure out how it actually behaves, going back into either one seems like changing a Lambo into an old Toyota. :)

    Of course this is an old article and many things have changed, but it was a good read anyways.

  212. Oh and I have to add this: I’m a graphic designer AND I’m doing Drupal sites. I must be a rare gem! I should probably ask for a raise. :D

  213. Personally, I both love and am frustrated by both.

    WordPress is very flexible in its design and looks, but only if you pick a great theme that already does what you want, or you are able to PHP code you own theme. There are some plugins that try to fix that, but they usually require a learning curve and again rarely do exactly what you want it to do.

    Drupal is the same way, but Drupal’s block system is a lot easier to use and customize than WordPress’ widgets, especially when talking about visibility settings. It is much easier to manage content that only shows up in certain pages or sections, like context sensitive navigation, for example.

    Right now I prefer WordPress too, but for some projects, I just need the flexibility of Drupal. I am hoping Drupal 8 fixes many of the frustrations we currently have with Drupal.

  214. I use Drupal more than 5 years and it is very easy to make Custom Design in Drupal. In WP very difficult.

    When a client as me to make Inventory Control with Inv Out and Inv In, so we can see the Balance, I can create ini directly in front of my client.

    Also generating reports very2 easy. WP? Nop.

    The author of this article only use Blog and Profile Website that’s why he doesn’t know Drupal for such Web Based ERP.

  215. I have used both of them on extreme level. Both are good to build a Web. According to me as Web chef, I use wordpress for Cakes or Bakes and use Drupal to serve complete food meal for big numbers of guests. :)

  216. Wow. I must say this is definitely the most commented on post of it’s kind I’ve ever seen. This is incredible! Lots of value in the conversation, though it would’ve helped if the commenters would have tempered the heated tone; but not quite as entertaining probably. :)

  217. WOW you have created a solid argument for using a CMS with less features that is slower to develop with on the basis that if a developer is smart enough he should be writing his own code anyway…

    I like it…kind of

  218. This guy just doesn’t get the way Drupal has been heading. WordPress, a structurally cursed, corrupted, and in other words, anti-structural CMS is good just for blogging tool. The only absolute superiority of WordPress over Drupal is its Admin UI (and its technically awful large community) which is going to be challenged since Drupal has taken it into account.
    Next, Drupal is for engineers (as already mentioned), hence it appears more to be a CMF than a CMS, making it appropriate for heavy websites and applications.
    Regarding security, well, are you kidding me?
    Performance, enabling caching and installing proper modules (community proven) WordPress is beaten by birth.
    A person who knows something about programming tends to compare Joomla with Drupal, since WordPress is a toy tool, and this is the reason behind its popularity.
    In our company, we have dissected WP from the very first line to the last, tons of problems and issues, the way modules are loaded (read code-snippets). Drupal is built with modularity in mind, WordPress is built with nothing in mind, but later brough something called “Admin-UI” into its wretched mind.
    Drupal’s conditional blocks (code-level) are even meticulously written, delegating performance-devouring operations as late as possible.

    :)

  219. I feel one of the largest issues with WordPress is its backward compatibility. In a world where everything on the web is going dependency based with tools such as composer in the PHP world and npm for node.js I fail to see how WordPress can keep up and remain backward compatible at the same time. Symfony is quickly becoming the building blocks of the web and WordPress will not be able to utilise these components without a MAJOR re-write resulting in the loss of backward compatibility. WordPress is over the hill whilst Drupal is climbing to new higher heights by leaning on the implementation of great tools such as : Symfony 2, Doctrine, Twig etc.

  220. I have worked with both and if you use Drupal correctly there is nothing you cant do. If you are lazy and dont want to learn how to theme then such modules as panels and panels everywhere can help out. Sure there is a learning curve involved but this is true for anything.

    My experiences of WordPress have been poor security, issues where it has tried to update itself and caused site crashes at the host as well as poor performance and these are not all sites I have worked on/developed. I think as others have said its horses for courses so pick what fits your clients needs but I dont think anyone who truly understands Drupal could say it was bad.

    Oh and here is another issue.. I just tried to submit my comment without completing the name field. Instead of validating with an error and returning me to this page with the field highlighted it directed me to a WordPress error page and I had to click back. Another thing which wouldn’t happen in the Drupal world ;-)

  221. A lot of your arguments against Drupal no longer stand, These are the ones that I know of the top of my head:

    WYSIWYG is in core since Drupal 8.

    CIDM, the new configuration management and the features module in Drupal 7 let you manage content types and other configuration as code
    That means collaborative development is not harder in Drupal.

    Drupal 8 is now built on top of Symfony, as a result more Symfony developers are now also developing Drupal.

    As of Drupal 8.1, Drupal comes with an amazing default caching layer, big pipe and Refreshless (preloading of linked content, similar to Turbolinks).

    Drupal 8 uses Twig for templates, this makes it compatible with the Twig template ecosystem.

    Drupal now also has it’s Drupal answers: http://drupal.stackexchange.com/, not sure though if that is such a big deal. The best place for support is still the issue queue on Drupal.org, definitely not the mailing list. While Drupal is not as big as WordPress, Drupal.org has 1M active users, definitely big enough for community support.

  222. Hi Kristof,

    Thanks for the comment.

    Definitely. Yes, my six year old post is finally less relevant.

    Of course WordPress has improved by leaps and bounds since then, and then of course there is this from almost 2 years ago.

    The more things change, the more they stay the same.

    -Mike

  223. Hi Mike,

    I do like to see old posts having consistently maintained threads over years.

    Another thing that I enjoyed reading this list was that perhaps the founder of OnTheGoSystems, Amir Helzer, was inspired by your post or their was some sort of synchronicity.

    5 years ago he queried you about views, then he goes and creates Toolset for wordpress, with Types and Views, for creating and displaying custom post types via the admin interface without php.

  224. In my view a mature framework should be used instead of WordPress or Drupal. In PHP Laravel is getting more and more popular, and a nice CMS has appeared called OctoberCMS. The added value of this system is that the underlying code is much better structured, it does not follow standards, but even after using a large number of plugins the code won’t become such a “mass” due to the underlying Laravel framework. User notice only an increase in performance, and a slightly better SEO.

  225. @Andor Szamos

    Thanks for the comment.

    In my view a mature framework should be used instead of WordPress or Drupal.

    I really like Laravel. We are using it to build a console for a virtual machine solution for WordPress that we are building. But using a “mature framework” will not provide any benefit to end-users of CMS when you compare with all the functionality they will end up loosing by not going with WordPress — in the form of plugins and themes and — and the available expertise in the market they would be loosing, even when compared with Drupal.

    Sure, it is great that such a CMS exists — it may result in innovation that pushes these other CMS to improve — but CMS end-users gain no tangible benefits from “well structured code that follows standards”, only developers do. And only innovators and early adopters even care about it. Those in the early majority do not care about well structured code that follows standards, they are in the majority and they are the people who pay the lion’s share of compensation to those who implement CMSes.

    No Laravel-based CMS will ever come close to the market share attained by WordPress because there so many more people who have the skill to develop for WordPress vs. in Laravel. And market share is what the early majority cares most about.

  226. I really wanted to be sold into WordPress as it does seem better maintained and easier than Drupal but most of the stuff I’m using in Drupal, as hard as they are to understand, either have no equivalent in WP or only have a premium equivalent with a price tag so ridiculous that makes me want to run as fast and as far away as possible from WP

  227. WordPress is a pile of shit. You’ve got to be kidding me!

    I’ve been fucking around with this nightmare because a client wants to “update their site in the furture”. Nevermind the fact that half of the plugins are bugged the fuckout, or that all the themes look like a fucking blog. Some of the most asthetically displeasing work I’ve ever done. I’m ashamed to present this project to the client… Because it looks like a WordPress blog.

    I’m sorry, but WordPress is 2006 Web 2.0 blogging bullshit, and CMS is retarded.

    Build a site and hardcode new content. It’s really that simple. Pissing around with WYSIWG ‘drag & drop’ nonsense is a bascially crawling back into the dark ages of Netscape Navigator 3.0 and table-based layouts.

    If your looking to post a few pictures of your cat, and maybe blog about the mac & cheese you made at Grandma’s, then WP is fucking stellar! Other than that, it’s a bloated, steamy cyberturd with the masses buzzing around it.

    Fuck WordPress.

  228. @dude –

    I’m ashamed to present this project to the client… Because it looks like a WordPress blog.

    Based on your ranting comments and your expletives it would seem your difficulties with WordPress and your inability to deliver a site that does not look like a blog point more to your insufficiencies than any tangible negative related to WordPress. #juststaying

    -Mike
    p.s. What a name. Original.

  229. Hi @K –

    Thanks for the comment.

    …but most of the stuff I’m using in Drupal, as hard as they are to understand, either have no equivalent in WP or only have a premium equivalent with a price tag so ridiculous that makes me want to run as fast and as far away as possible from WP

    I would be curious to know what things you cannot find a free, open-source equivalent for? I’d love a chance to propose some solutions for you.

    Not saying there are equivalents for everything but I have found few needs for which I can’t find something for WordPress that works as well as what is in Drupal.

    …either have no equivalent in WP or only have a premium equivalent with a price tag so ridiculous…

    As for premium plugins, what do you consider ridiculous? Honest question.

    “Ridiculous” of course depends on what value the add-ons provide for your specific use-case, as in it is all relative.

    1. If you are in a country where the average wage is closer to the bottom of this list absolutely I agree that most premium plugins pricing are ridiculous for you.
    2. If you are using the CMS for learning, local volunteering or hobby use where there really is no budget and no revenue associated then agreed, anything more than a few dollars is ridiculous.
    3. OTOH if you are using WordPress or Drupal for a business in a 1st world country that has employees and thus a monthly budget of at least many hundreds of times what the most expensive premium add-on costs then I would say that the fact that the premium add-on exists is a benefit as that strongly implies that the add-on will be supported and continue to exist. And that is much better than a free but poorly supported add-on that ends up being abandoned when the developer not longer has time to invest their free time in providing for the needs of others who do not provide them any return on their time investment.

    BTW, my post here was really for businesses in a 1st world country, not for the two former mentioned collections of groups although I never explicitly stated that until not.

  230. As you mention this is now a six year old post but I’d like to point something out that I haven’t seen in the comments as far as I can see. The problem with the premise of the post and with most people that get into this discussion is that WordPress and Drupal (particularly now, but even 6 years ago) have significant differences and are aimed at different audiences/uses. They therefore have a multitude of different reasons for being used.

    My background is 10 years using Drupal, I’ve never used WordPress. I have however always respected the impact it has had on the internet. There is no denying that WP has changed the way people develop code, and particularly content on the web and in most cases thats great.

    However meanwhile Drupal has been keeping its line as an enterprise CMS framework. We rarely use Drupal to build content managed websites anymore, but to build complex applications that when I’ve discussed them with my WordPress friends they agree it’d take huge amounts of custom code to develop and would generally just not be done. They’d use a framework and code from that instead.

    I’m not saying as crassly as others that WordPress is just for blogs and Drupal for anything more, but as you’ve recognised in terms of user management and community tools Drupal makes much more sense – therefore anything that requires user login is in most cases going to make much more sense to be developed in Drupal.

    I guess what I’m saying is that it shouldn’t be about one being better than the other – its a question of choosing the best for what you need to do. WordPress outshines Drupal in a number of areas, as does Drupal in others. You’ve focussed on all the positives of WordPress in your post and not focussed on any of the positives of Drupal. Lets not suggest that “WordPress is better for your website than Drupal”. This is just nonsense as there are WAY too many possibilities, strengths, weaknesses and strategic reasons as to why you would choose one over the other. In the last ten years the WP community has learned a huge amount from Drupal, as has the Drupal community from WP – neither is better or worse overall, they’re just better or worse at certain things.

    It depends on what you know, how you can solve a clients problems and the choices you make. There is not, in my opinion, an out and out winner for every CMS based decision – thats the joy of both competition and most importantly, choice.

  231. Using drupal at first was the worst decision of my whole life.
    You can now easily migrate from Drupal Ubercart to WordPress Woocommerce, there is a simple WordPress plugin to use called FG DRUPAL TO UBERCART MIGRATION, you should use it now before it is too late !!!

  232. In the last 16 years, I have created 200+ websites with Joomla, 40+ with WordPress and 60+ with Drupal.
    I can confirm that the points written on this article are not fair to either Drupal or WordPress. The author obviously has no experience with Drupal and very little with WordPress.
    Although WordPress has come a long way since this article was posted, but so has Drupal.

    Drupal is much more flexible than any other CMS solution and has very powerful tools that are not available in WordPress, those tools make a whole lot of difference (like Views, Drush, CCK, Composer and more).
    When I have a request for a simple website, I use WordPress, it is fast and straightforward.
    However, when I get a request for a sophisticated and secure website, that is also easier to update by anyone, then the only available solution is Drupal.
    I stopped using Joomla and other CMS for numerous reasons and it’s not the place to discuss them here.

    If you want to comment about any technology, 1st gain ample experience in it then you are qualified to do so, otherwise you are biased and unfair.

    It all comes down to what your website requirements are and then you can choose between Drupal or WordPress.

    enjoy! ;)

    1. @Alex Bellig — So you comment on a post that is 10 YEARS OLD and claim the author (me) has “no experience with Drupal and very little with WordPress” and imply your opinion of that is because “WordPress has come a long way since this article was posted, but so has Drupal.”. Give me a break.

      You are correct I do not have current experience with Drupal, but this article was written 10 YEARS AGO!. As of today I have about 12 years of significant experience on WordPress — and 30+ years of development experience overall — and I am in the top 1% of reputation on WordPress StackExchange.

      So just what is your validated reputation online related to WordPress, sir?

      1. Mike, I am not challenging you. The truth even after 10 years stays as follows:
        – Drupal is for professional and sophisticated sites and should be used by somewhat advanced developers
        – WordPress is for people who are not necessarily developers and want to create quick and nice-looking websites that provide basic features.

        The above statements can be easily proven, with examples.

        As for my credentials, I have two major university degrees. Since 1991 have worked in three Fortune 500 companies as IT Director and VP of acquisitions. During that period I have acquired multiple certifications in different IT and web development fields.
        Currently I have my own IT company with offices in 5 different countries, 65 employees (and growing). One of the devisions is web development with 12 developers, 3 QAs and 5 contractors. We do website development for major companies that have extremely complex requirements that currently WordPress cannot handle, that’s why we rely heavily on Drupal and custom development. Our developers have committed a lot of modules and codes to the Open Source environment (github and cvs).
        That said, our developers also rely on WordPress for the quick and easy websites. Personally I love WordPress but we need to be fair in the difference of the two. You cannot really compare a sophisticated system like Drupal with WordPress, they should be in different categories.

        Thanks!

        1. Hi @Alex,

          You stated:

          “The author obviously has no experience with Drupal and very little with WordPress.”

          That is what passes for a “challenge” in my book.

          Further, your statements are opinion, and as such not “provable.”.

          You’ll note I am happily publishing youropinion here on my own personal blog even though your opinions conflict with my own. Many people would not.

          And you can certainly provide anecdotes that might support your claim, but I can just as easily find anecdotes that challenge them, including many of the WordPress projects I have worked on including an intranet for Coca-Cola’s global marketing.

          As for your claim:

          “extremely complex requirements that currently WordPress cannot handle”

          That is a decision you made based on you and your team’s opinion, not a statement of absolute fact. There is no limit in complexity that a Drupal app can handle that a WordPress app cannot. And that is a fact because they are both implemented with and extended by PHP, MySQL, Javascript, CSS, etc.

          Sure, some things are likely easier done in Drupal, but then other things are easier done in WordPress. I feel confident my team can match with WordPress anything your team could do with Drupal, and likely for a lower budget. But I will admit, that is just my opinion, so we’ll likely never know (unless someone wants to hire us both and put us to the test. Like money will ever get spent to make that happen!)

          Frankly, if you had written “I disagree with what you wrote even 10 years ago — though it might have arguably been true back then — but it is not true today with Drupal” I would have reacted very differently because I have no experience with Drupal since the re-architecture. (However I have a sense that Drupal continues to be over-architected as it was 10 years ago — just as is Symfony — but I cannot claim to have any experience to validate that gut feeling.)

          I would have even reacted differently if you had stated all the same (sans the personal attack) if you had made it clear you were only offering your opinion instead of claiming it to be fact.

          But for you to claim “fact” as if you were somehow anointed to be an arbiter in matters of technical opinion means you are behaving no better than a garden rate troll. And — if you really believe your opinions are so valuable as to be indisputable “facts” — I would advise any potential clients of yours to steer clear of any decisions you might make on their behalf, especially ones where you are likely to confuse opinion with fact..

          Any I being harsh? Sorry. Not sorry.

  233. Of course wordpress is better. Why do you write this article? You can easy check how much site on wordpress in the internet. That is all

  234. Great article. I went with a wordpress website and it really does give me the ability to completely manage my content without needing a web developer.

Leave a Reply

Your email address will not be published. Required fields are marked *