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 Compatibility - Drupal 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 Manage - Drupal 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 Themes - Drupal 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:

 

 

165 comments ↓

#1 Nick Ali on 12.01.10 at 8:27am

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 MikeSchinkel on 12.01.10 at 8:40am

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 John Locke on 12.01.10 at 7:55pm

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 MikeSchinkel on 12.01.10 at 9:30pm

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 John Locke on 12.02.10 at 3:46am

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 Richard Schulte on 12.12.10 at 11:53am

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 Richard Schulte on 12.12.10 at 11:56am

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 Alastair on 12.13.10 at 1:17pm

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 Chris Chris on 12.14.10 at 9:50am

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 Tammy Hart on 12.17.10 at 2:23pm

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 Wyck on 12.17.10 at 2:36pm

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 joop on 12.17.10 at 5:54pm

does wordpress has drush??

#13 ปฐมบทแห่ง My Blog on 12.22.10 at 11:50am

[…] 17 Reasons WordPress is a Better CMS than Drupal (ไปอ่านเองนะ เขียนมายาวเหนื่อยละ) […]

#14 Amir Helzer on 12.24.10 at 7:35am

Hi Mike,

Do you still miss Views in WordPress or did you get used to coding this yourself in PHP?

#15 MikeSchinkel on 12.24.10 at 8:02am

@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

#16 Amir Helzer on 12.25.10 at 2:27pm

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.

#17 MikeSchinkel on 12.25.10 at 3:31pm

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/

#18 Elizabeth Quintanilla on 12.27.10 at 1:20pm

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

#19 MikeSchinkel on 12.27.10 at 1:45pm

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.

#20 Kevin T on 12.27.10 at 6:06pm

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…

#21 Stuart Kushner on 01.06.11 at 4:38pm

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.

#22 Thompson on 01.10.11 at 3:51pm

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.

#23 Julian on 01.14.11 at 2:43am

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?

#24 MikeSchinkel on 01.14.11 at 4:23am

@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

#25 Jafar on 01.19.11 at 5:03am

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.

#26 MikeSchinkel on 01.19.11 at 5:24am

@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

#27 Jafar on 01.20.11 at 4:29am

Mike I disagree but thank you for the links and your commitment to open source.

#28 MikeSchinkel on 01.20.11 at 4:41am

@Jafar - Thanks again for your comment.

#29 Charlie on 01.20.11 at 9:22am

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

#30 mori on 01.24.11 at 7:52am

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.

#31 mori on 01.24.11 at 7:57am

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.

#32 Banago on 01.27.11 at 8:42am

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!

#33 jharvey on 02.03.11 at 9:57am

“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

#34 MikeSchinkel on 02.03.11 at 10:21am

@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?

#35 Todd on 02.03.11 at 10:55pm

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.

#36 MikeSchinkel on 02.04.11 at 1:18am

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.

#37 Todd on 02.04.11 at 3:08am

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.

#38 MikeSchinkel on 02.04.11 at 4:28am

“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.

#39 Jan on 02.04.11 at 6:53pm

Hi Mike

You wrote you have a URL management / rewrite plugin on the drawing board whose goal is to remove this limitation from WordPress.

I have also read these tickets, and have seen your posts on this subject:
http://core.trac.wordpress.org/ticket/8958
http://core.trac.wordpress.org/ticket/12935

Actually I am eagerly awaiting for this to be handled in wordpress.
Is there any timeschedule? How far are you from releasing such plugin?

#40 MikeSchinkel on 02.05.11 at 11:03am

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.

#41 Jan on 02.12.11 at 7:03am

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

#42 MikeSchinkel on 02.12.11 at 12:29pm

@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.

#43 Wendy Peck on 02.17.11 at 1:05pm

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).

#44 MikeSchinkel on 02.17.11 at 1:27pm

@Wendy - Thanks for your comments!

#45 JP on 02.17.11 at 1:58pm

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.

#46 MikeSchinkel on 02.17.11 at 2:06pm

@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.

#47 Brion Mills on 02.20.11 at 12:27am

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!

#48 MikeSchinkel on 02.22.11 at 12:13am

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?

#49 Christian Lehmann on 02.28.11 at 4:20am

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

#50 Mario Gran on 03.03.11 at 4:33pm

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!

#51 RK on 03.04.11 at 2:46pm

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?

#52 17 Reasons WordPress is a Better CMS than Drupal http://mikeschinkel.com/blog/17-reasons-wordpress-is-a-better-cms-than-drupal/ | scribu on twitter on 03.04.11 at 3:29pm

[…] 17 Reasons WordPress is a Better CMS than Drupal http://mikeschinkel.com/blog/17-reasons-wordpress-is-a-better-cms-than-drupal/ […]

#53 Cristian on 03.07.11 at 3:47pm

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.

#54 MikeSchinkel on 03.07.11 at 6:25pm

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

#55 MikeSchinkel on 03.07.11 at 6:30pm

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

#56 MikeSchinkel on 03.07.11 at 6:41pm

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

#57 MikeSchinkel on 03.07.11 at 6:47pm

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

#58 Georg Huber on 03.23.11 at 11:24am

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

#59 Kendra on 03.29.11 at 8:38pm

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!

#60 MikeSchinkel on 03.29.11 at 9:28pm

@Kendra - Thanks for the comment. Glad I could help.

#61 MikeSchinkel on 03.29.11 at 9:43pm

@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.

#62 Website Doctor on 06.08.11 at 6:50pm

Those are all very good points as to why wordpress is better than drupal. I would never use anything other than wordpress. Thanks for sharing!

#63 ten on 07.01.11 at 1:00am

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.

#64 MikeSchinkel on 07.01.11 at 1:46am

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?

#65 ten on 07.01.11 at 10:47pm

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.

#66 MikeSchinkel on 07.05.11 at 11:06pm

Hi @ten - I’ve not used any views equivalent but here is what Google indirectly found for me:

- http://wordpress.org/extend/plugins/virtual-pages/
- http://wordpress.org/extend/plugins/query-posts/

Not perfect but hey! Maybe someone will hire us to develop one?

Also see http://codex.wordpress.org/Template_Hierarchy to learn more about templates.

#67 Ben O'Hear on 07.21.11 at 3:08am

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

#68 Ben O'Hear on 07.21.11 at 6:12am

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?

#69 MikeSchinkel on 07.22.11 at 1:20pm

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.

#70 Ben O'Hear on 07.25.11 at 1:49am

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

#71 MikeSchinkel on 07.25.11 at 2:41am

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.

#72 Mark on 09.14.11 at 12:38pm

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

#73 MikeSchinkel on 09.17.11 at 9:05pm

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

#74 Mark on 09.18.11 at 3:42am

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!

#75 Oli Salisbury on 10.10.11 at 3:44pm

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??

#76 Paul Whittem on 10.13.11 at 6:00pm

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

#77 SiePlake on 10.28.11 at 11:36am

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!!!

#78 Benjamin LUPU on 11.06.11 at 8:13am

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 :)

#79 Rich on 11.23.11 at 8:56am

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

#80 WordPress vs Drupal - Jean Galea | Web Designer and Developer in Malta | WordPress Consultant on 12.10.11 at 6:06am

[…] WordPress vs Drupal On December 10, 2011 In Wordpress With No Comments http://mikeschinkel.com/blog/17-reasons-wordpress-is-a-better-cms-than-drupal/ […]

#81 Narsing Kurimilli on 01.12.12 at 11:54pm

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

#82 francesco on 01.30.12 at 1:54pm

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.

#83 Siggi on 03.04.12 at 8:02am

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.

#84 MikeSchinkel on 03.04.12 at 12:45pm

@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.

#85 MikeSchinkel on 03.04.12 at 1:07pm

@francesco - I’m not fan of BuddyPress either. It, like Drupal, is over-architected and inflexible. So you got me on that one.

#86 MikeSchinkel on 03.04.12 at 1:08pm

Hi @Rich, thanks for dropping a comment; much appreciated!

#87 Marcus on 03.25.12 at 11:33pm

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.

#88 MikeSchinkel on 03.26.12 at 12:00am

@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.

#89 Guy Paddock on 04.08.12 at 11:47pm

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.

#90 MikeSchinkel on 04.09.12 at 1:56pm

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

#91 Leon on 04.11.12 at 2:02pm

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.

#92 MikeSchinkel on 04.11.12 at 2:34pm

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.

#93 The Joomla Vs Wordpress Vs Drupal debate. on 04.14.12 at 12:48am

[…] Schinkel’s website and his personal blog on “17 Reasons WordPress is a Better CMS than Drupal” is a great read, it’s also refreshing to see that the comments made are objective and […]

#94 Mike on 04.24.12 at 3:09pm

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.

#95 MikeSchinkel on 04.24.12 at 3:20pm

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?

#96 Mike on 04.25.12 at 5:43pm

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…..

#97 Mike on 04.26.12 at 3:00am

Hi Mike,
I have also posted a similar issue using select lists here:

http://advancedcustomfields.com/support/discussion/1869/how-to-query-select-field-type-that-has-multiple-valuess

PS I am mech eng as well and did motocross racing, a little longer ago than you though :)

#98 Mike on 04.26.12 at 7:27am

Hi Mike,

I have posted my question here:
http://wordpress.stackexchange.com/questions/50299/how-to-do-a-particular-wp-query-category-search

If you would like to take a look.

#99 Taiger on 05.08.12 at 12:02pm

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.

#100 MikeSchinkel on 05.08.12 at 12:31pm

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.

#101 Mike on 05.11.12 at 8:31am

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.

#102 MikeSchinkel on 05.11.12 at 12:49pm

Hi @Mike,

Are you going to publish that list of comparisons?

-Mike

#103 Mike on 05.12.12 at 8:10pm

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….

#104 Hedmon on 05.13.12 at 7:42pm

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!

#105 MikeSchinkel on 05.13.12 at 7:52pm

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

#106 Luke on 05.21.12 at 11:28pm

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.

#107 MikeSchinkel on 05.22.12 at 12:20pm

@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

#108 serena on 05.30.12 at 7:10am

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.

#109 MikeSchinkel on 05.30.12 at 3:22pm

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

#110 Francis on 06.28.12 at 8:18am

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.

#111 Thiago F Macedo on 07.06.12 at 8:14pm

Ok, well done post.
But today there is a stackexchange for drupal: http://drupal.stackexchange.com/

cheers

#112 MikeSchinkel on 07.07.12 at 6:40pm

Hi @Thiago,

Thanks for the comment.

Finally. It’s about time.

-Mike

#113 sohrab on 07.13.12 at 10:56am

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

#114 op Friday, 20/07/2012 ergens gepost of bewaard: « test1 test1 test1 on 07.20.12 at 10:21am

[…] admin shared 17 Reasons WordPress is a Better CMS than Drupal | MikeSchinkel.com. […]

#115 Issa Diao on 08.08.12 at 6:45pm

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.

#116 MikeSchinkel on 08.09.12 at 7:55pm

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. :)

#117 Jt on 09.27.12 at 4:14pm

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.

#118 MikeSchinkel on 09.27.12 at 6:52pm

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

#119 Francis on 10.03.12 at 7:26am

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.

#120 MikeSchinkel on 10.03.12 at 1:51pm

Hi @Francis - Thanks for your comments. Yes, I must say I agree with your sentiments. Also, I just read the blog post Drupal’s Golden Handcuffs and I believe that he nails it completely, especially “The Curse” part.

#121 Greg M. on 10.24.12 at 3:11am

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.

#122 MikeSchinkel on 10.24.12 at 11:29am

Hi @Greg M.

Thanks for your comments. Yes, there are a lot of comments here!

-Mike

#123 Will on 03.12.13 at 12:44pm

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.

#124 MikeSchinkel on 03.12.13 at 4:32pm

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.”

#125 Prurito on 04.26.13 at 11:38am

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!

#126 mikeschinkel on 04.26.13 at 12:16pm

Hi @Prurito,

Thanks for your comments. Good luck!

#127 Gerardo Belot on 04.30.13 at 3:53am

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.

#128 mikeschinkel on 04.30.13 at 12:12pm

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.

#129 Peter Drinnan on 05.22.13 at 8:09pm

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.

#130 Rich K. on 05.26.13 at 1:39am

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.

#131 Miguel on 05.28.13 at 4:41pm

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.

#132 mikeschinkel on 05.28.13 at 5:49pm

@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.

#133 Mitch on 05.28.13 at 6:06pm

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.

#134 mikeschinkel on 05.28.13 at 6:09pm

@Mitch - Thanks for the comment. Yes, it does seem that WordPress has been “firing on all cylinders” for many years now.

#135 Stephen Nill on 07.06.13 at 10:04pm

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?

#136 mikeschinkel on 07.07.13 at 11:38am

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

#137 Scott on 08.08.13 at 11:24am

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.

#138 Drupal Defender on 09.27.13 at 1:28am

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.

#139 mikeschinkel on 09.27.13 at 9:57pm

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.

#140 Drupal Defender on 09.30.13 at 1:11am

“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.

#141 mikeschinkel on 09.30.13 at 2:48am

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

#142 Drupal Defender on 10.02.13 at 6:37pm

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.

#143 Drupal Defender on 10.02.13 at 6:44pm

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.

#144 mikeschinkel on 10.02.13 at 10:23pm

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.

#145 Drupal Defender on 10.03.13 at 12:37am

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.

#146 mikeschinkel on 10.03.13 at 11:58am

@Drupal Defender,

Ok, you win “anonymous coward”, you win.

#147 Drupal Lover on 10.11.13 at 6:43pm

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.

#148 mikeschinkel on 10.11.13 at 10:01pm

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.

#149 Pratik Joshi on 10.12.13 at 2:36pm

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 ..

#150 mikeschinkel on 10.12.13 at 10:11pm

Hi @Pratik,

Thanks for stopping by and for the kind comment.

-Mike

#151 safwan on 10.18.13 at 12:37pm

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.

#152 mikeschinkel on 10.18.13 at 5:59pm

Hi @safwan,

Thanks for the comment. However, we’ll just have to agree to disagree.

-Mike

#153 AnotherTodd on 10.21.13 at 3:38pm

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.

#154 mikeschinkel on 10.21.13 at 4:59pm

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.

#155 Tom Mann on 10.31.13 at 7:10pm

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.

#156 mikeschinkel on 10.31.13 at 7:15pm

Hi @Tom,

Thanks for the comment and for sharing your experience.

-Mike

#157 geoff on 01.09.14 at 11:29pm

You really need to learn to distinguish “its” and “it is”.

#158 mikeschinkel on 01.10.14 at 10:27am

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

#159 mikeschinkel on 02.16.14 at 2:36pm

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.

#160 Matt on 03.19.14 at 8:49pm

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.

#161 mikeschinkel on 03.19.14 at 9:03pm

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.

#162 Pere on 04.10.14 at 11:21am

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.

#163 mikeschinkel on 04.10.14 at 12:17pm

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.

#164 Stephen on 04.19.14 at 4:36pm

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.

#165 mikeschinkel on 04.19.14 at 11:13pm

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?

Leave a Comment