cool tech graphics

How Drupal is more welcoming than WordPress

Filed under:

I think we've all heard a few things about how Drupal and WordPress compare to each other. One thing I haven't heard much about is the "please contribute, here's how" factor to Drupal and its modules and the lack of it in the WordPress community. This can be seen in the site for Drupal modules and the site hosting WordPress modules.

Take a look at a WordPress Plugin page over on They usually give great installation information, some stats, a changelog, and screenshots of the plugin in action. However, if I'm some developer who has been using a particular plugin for a while and made some tweaks to add in a new feature, or improve performance, there is no information on how I can contribute anything at all! Even the support queue is a lacking in comparison to Drupal's. Looking at the developers tab on a project, I can get some very raw information about the project's developmental history from the development log and can check out the code, but nothing about how I can give them a patch, or to checkout the repository, or even get a simple view of the bugs that need to be fixed!

Now take a peek over at a Drupal module page. Many modules have documentation, many do not. Some have some installation details, some don't. But what they all share is a great support queue and developer-friendly instructions. These instructions guide the developer to clone the module repository, make changes, and then help them to create a patch (along with naming conventions!) as well as stating how to submit that patch to the support queue! This is a great example of how we should provide that basic information to allow new developers to contribute!

The developer documentation helped me tremendously when I decided to submit my first patch to a Drupal module. Without it, I might have never had bothered to contribute. If WordPress wants to invest further in contributions from new developers, they might want to start by giving some basic "how to contribute" information on each plugin's page.

Date posted: July 24, 2012


You bring up some excellent points in this post. Drupal does indeed have some very developer-friendly features and shines at encouraging contributions from the community. The key difference here is the target audience of each platform.

Wordpress seems largely aimed at the slightly tech-savvy end user who wants to build a decent-looking site with minimal hassle while Drupal is aimed squarely at developers who don't mind tinkering with code. To that end, Drupal is setup to make that process as frictionless as possible.

The best analogy I ever heard (thanks, Joaquin) envisioned Wordpress as a souped-up import racer, starting with a basic car and adding performance parts (read: plugins) like wheels, intake, and spoilers with some trade-offs in performance for ease-of-use and cost. Some users like this approach because it only takes a little bit of know-how to get what they (mostly) want. On the other hand, Drupal is like a kit car; for the true enthusiast (read: PHP developer), the car can be built nearly from scratch to the exact desired specifications and probably run harder/better/faster/stronger than its stock + add-ons counterpart.

With its popularity booming (16.6% of the world's websites run Wordpress vs the 2.1% using Drupal*), Wordpress certainly won't be going away any time soon, but I wholeheartedly agree that it would benefit greatly from making contributions and patches an easier, more painless process for developers.


I totally appreciate the car analogy.

Those stats hold about as much meaning to me as saying 80% of Americans prefer to eat fast-food vs. the 20% like to prepare their own meals.

I mean is a higher percentage really indicating. It's a testament to WPs ease of use, that anyone(in the world) could plop up a WP site. So quantity of quality. Is that a concern to anyone really?

When I heard that analogy, the car was a Honda. :)

Civic :-)

Drupal is developer-friendly. A well-bult Drupal site can also have good UX. Drupal is not very friendly to low skilled website makers (whether beginners or 'professionals'). Drupal is not well suited for low-budget client sites with a low or zero maintenance budget. I see litle chance of that changing. If you want a Honda get Wordpress. I have mostly low budget clients and feel I have to say to them, 'I would prefer to work on a Ferrari than a Honda. If you buy a Ferrari (Drupal) you will have more fun, but be ready for the costs and/or time and enthusiasm needed to to look after it.' You could also extend the car analogy to the cost of fuel if you think (as I do) that Drupal costs more to host adequately. That is my experience and that is why I sell WP sites even though I know Drupal better. A client with excellent taste and a budget to match will be offered Drupal.

You absolutely hit the nail on the head. The platform is often client-driven; many have little patience (much less budget) to try Drupal, and even Wordpress can be a challenge for the true technophobe. Clients I've worked with in the past just wanted a brochure site they could update themselves that "just works".

(please excude the straeam of consciousness)

Drupal's developer community also gives great benefit outside of in that there are so many articles out on the web for drupal written by people who know what they are talking about.

I feel it is because of wordpress' target audience that it is far harder to find useful solutions to problems out on the web via google.

I am a long time drupal developer and recently did my first full project with wordpress and it was quite an experience.

When I ran into problems I was almost always unable to find someone with know-how blogging about a solution.
And so many plugins go unmaintained or have unresponsive issue queues (drupal has its fair share of that though).

I also found that there generally wasn't any plugins that would exactly suit my needs (for things I would consider people would commonly use) and found it was generally faster to create my own than to spend much time looking for something already out there. On top of that there are a lot of plugins that are not free and these paid plugins I found to be sometimes very poor at doing what they were supposed to do.

There are also a lot of plugins I would consider to be very hackish in the way they are coded.

I found I pretty much had to learn the ins and out of wordpress the best I could in the time available and custom code things.

Another big thing was that it seems to be less of a whole community and more of individuals working on their own thing. A huge amount of plugins won't work in combination with other plugins.

By the end of the project I hated wordpress less as I had discovered not to expect to find help for developer type questions, or plugins to suit commen needs.
Read the core code, code things yourself and you can be happy enough in wordpress.

A great community have great developers. They don't learn "How to make a diff patch" from the modules page. I think you're a damn heart Drupal *user*. when I go to the developers tab page, I see the word "Trac". I know this is where I should go.

And I was not impressed. The killer module for Drupal is CCK, now in core. WP has custom post types, which you have to code by hand or use a junky UI plugin. There is little to no validation of fields (which WP calls taxonomy). For me, being able to create a database of different content and validate the input is what makes Drupal so great. The user interface in general for Drupal is far cleaner. Where Drupal falls short of WP is in three areas: 1) WP has a fast easy install 2) the WYSIWYG is really nice in WP 3) WP media handling is better 4) Installation of plugins is really easy, no FTP required. These seem to be things that the Drupal community could achieve. My biggest disappointment was the WP interface. I've been hearing for so long how easy WP is. Drupal's interface is pretty clean in comparison, especially if you hide most of the configurstion commands from the clients and leave them with "add content" and "content".

A lot of WP's power comes from shortcodes.

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Metal Toad is an Advanced AWS Consulting Partner. Learn more about our AWS Managed Services

Schedule a Free Consultation

Speak with our team to understand how Metal Toad can help you drive innovation, growth, and success.