How Agencies Can Rock Drupal AND WordPress

There’s a tendency in our industry to think of Drupal and WordPress as opposing camps, like Xbox vs PlayStation or iOS vs Android. Agencies pick sides, defend their choice, feel slightly superior to those on the other side, and get deep into specialization.

It’s a viable strategy. There are always plenty of clients looking specifically for a WordPress or Drupal shop. The problem is, your agency can become defined by the platform it uses. That's fundamentally limiting and detracts from your unique values; it’s less about the way you approach a problem or the elegant solutions you create. Not only does this limit you to clients who have already made an explicit Drupal / WordPress decision, it also opens you up to the very real danger of commoditization. Many people can claim to be WordPress or Drupal experts. Some of them may even have decent logos to back up that claim. Some of them may charge a fraction of your desired billable rate. Not insurmountable, but this can become problematic for agencies looking to build a lasting practice.

Agencies that can rock both content management systems have an advantage. To them, asking if they do Drupal or WordPress is like asking which hand they juggle with. These agencies are better able to start with a customer problem and design the right solution rather than focusing on a problem from the perspective of a particular CMS. This flexibility means the freedom to say “yes” to a wider set of clients and projects as well as to serve a broader set of needs for existing customers.

A different way to put it: would your agency rather be known for being extremely good with a particular CMS or extremely good at solving problems? Which is more attractive to your dream clients? If it’s more about the team and less about the technology, you might want to reconsider a singular technology focus.

The good news is that this is extremely doable. Your agency can develop an ambidextrous team focused on solutions. Drupal and WordPress have many similarities. Both are open source, LAMP stack CMSs with a large ecosystem of contributed code and contributed themes, Rest APIs, and Command Line Interfaces. The basic skills that go into making a great WordPress team also make a great Drupal team and vice-versa. The communities of people involved in planning, designing, and building both Drupal and WordPress are full of amazing, creative people intent on building great things with open source tools.

Interested? Let’s start by looking at some of the differences to help guide the conversation.

What’s the Difference between Drupal and WordPress?

WordPress and Drupal have been shaped by different forces and decisions. Your agency likely knows some of this information already, but let’s fill in some blanks.

Different Missions and Philosophies

WordPress values decisions over options while Drupal focuses on flexibility and extensibility. WordPress design decisions are generally made with editors and authors in mind, per its mission to democratize publishing. Drupal, on the other hand, makes more decisions focused facilitating the work of site builders and developers. These different design decisions and intents lead to different focuses and different-feeling tools.

Different Tools

As Gene Bernier of Cheeky Monkey Media puts it, WordPress is more like a Transformer; a polished product with multiple configurations. If your client needs something that fits one of those configurations, WordPress is awesome. You’ll finish faster with a more refined product that still includes good customization opportunities.

Drupal, on the other hand, is more like a collection of Legos. You can use it to make a mansion, a mountain, or a motorcycle. The options are endless—but you won’t get a finished product without putting in the time to plan, design and build it. It may take you more time and effort to do so, but you also get to specify each and every detail to a much higher degree.

Crosstrain Your Team

In order to prepare your team to think about using another system, it’s important to change the team’s mindset from “How can we do this in WordPress/Drupal?” to “What does this project need to accomplish, by when, with what budget and what level of control?” Once the team starts thinking in terms of solutions, they will be more free to innovate with either CMS and more likely to try learning the one they’re less proficient in.

From agencies I’ve spoken with, there is likely to be some pushback as you crosstrain a team. As a broad generalization, Drupal developers often seem to have a harder time adapting to WordPress; it can feel restricting to someone used to the massive flexibility of Drupal. Encouraging everyone to focus on how quickly and completely you can get things done with WordPress helps a lot with any pushback along those lines.

On the other hand, WordPress developers often seem to have an easier time. Drupal’s developer focus probably helps with this. Learning the theming system and how to work with APIs like the Forms API can be gotchas, but WordPress developers seem to pick up Drupal significantly faster than people who don’t know either system.

The following materials can help your team start thinking in solutions instead of systems.

Explaining WordPress to Drupal Developers

If you are a Drupal developer looking to crosstrain in WordPress, there are a few common stumbling blocks to be aware of:

• There is no Views module equivalent. You may have to relearn how to write queries by hand.

• Content Types (‘Custom Post Types’) can be created directly via the API using the register_post_type command. You can also use a WP-CLI command as a helper to scaffold the necessary code. Once set up, you can add metadata to the custom post type with tools like CMB2. CMB2 keeps your configuration in code, is easily extendable and contains a number of helpful fields out of the box. You can add metadata directly via the core API or use another plugin as well.

• Paid plugins are a thing. Many popular plugins and themes have either a licensing or freemium model. Annual licensing typically covers a year of support and updates. Freemium plugins have a good free level but cost more for advanced features.

• Plugins tend to be solutions—if it’s the right plugin, installing it solves a problem quickly and efficiently. Plugins also tend to be monolithic—there’s no such thing as a “dependency” in WordPress. While some plugins do “stack” well, you typically do not chain them together to generate solutions.

• Drupal is built to be overridden. WordPress less so. WordPress can be flexible, but you may not  find the hooks you need for overriding something without digging deep in WordPress.

• The WordPress admin interface is pretty polished. You’ll probably have a relatively easy time finding your way around, and your clients and users have probably have experience using it.

Explaining Drupal to WordPress Developers

WordPress developers often seem to have a relatively easy time picking up Drupal, but there are still adjustments:

• Drupal has this great thing called Views. You can develop queries with just a few clicks. It makes compiling lists and collections of things a LOT easier.

• CMB2 is basically built into Drupal. Custom Post Types are called ‘Content Types’ in Drupal and configurable via Drupal’s admin interface. Content Types + Views are a pretty awesome combination and great data modeling tools.

• Overrides are easier in Drupal. You will find there are plenty of hooks that help you change functionality, even in the core, without breaking things.

• Unlike plugins, modules tend to be “capability” oriented, rather than complete end-user ready solutions. When you install a plugin in WordPress, your work is often almost done. When you install a Drupal module, it’s just one step on the journey..

• Drupal has more flexibility out of the box. You can do just about anything with it—if you have the knowhow and the time.

Guidelines for Choosing a CMS

The type of client and the problem they need to solve should drive the decision to use Drupal or WordPress. While you can probably build just about any given website with either system, their differing philosophies tend to make them better in different situations.

Drupal tends to be a good choice on projects that:

• Have many/complex data relationships between many different types of content

• Revolve around modeling customer business interactions

• Include multiple complex integrations with other systems

• Require a high number of specific it-must-be-just-so customizations

WordPress tends to be a good choice on projects that:

• Have relatively simple data models

• Have needs that can be met by established plugins

• Value timeline and/or budget over control of minutiae

• Are intended to improve or optimize publishing experiences

Of course there are exceptions and nuances, but the more that your project has characteristics from the Drupal list, the more likely Drupal is a good choice. Likewise, the more your project has characteristics from the WordPress list, the likelier that WordPress is a smart choice. So, for example, you can build a blog with Drupal. It probably won’t be as fast, easy or effective as one built with WordPress. Likewise, you can build a complex business application with WordPress, but it will probably require a lot more custom coding and technical debt than one built with Drupal.

Choose a Platform That Supports Drupal and WordPress

Of course, if you do head this direction, Pantheon has your back. We have best practices for both WordPress and Drupal built into the platform. We make it easy to set up workflows, manage teams, develop, and test your work. When sites go live, Pantheon provides security and reliability and our elastic hosting means that a traffic spike won’t bring down a site. We make it easy to keep software up-to-date and secure, and we provide an extra layer of defense between the black hats and your data.