Our Blog

Related Posts

Automating Plugin/Module Updates on Pantheon. We automated the process to apply plugin and module updates on Pantheon sites with a simple command.

Listen to Pixo and Four Kitchens' case studies on how we decoupled Drupal and Wordpress site architectures to separate CMS content from the front end.

How to achieve Pantheon's one-click-update functionality for Drupal and Wordpress while retaining your git history using git-graft.

Popular Tags

Recent Comments

avAssut
3.29.2017 - Drupal 8 Roadmap
Wcntoode
3.28.2017 - Drupal 8 Roadmap
Nyspathe
3.27.2017 - Drupal 8 Roadmap
AliseNMn
3.23.2017 - Drupal 8 Roadmap

Brandon Bowersox-Johnson

If you’re about to embark on a CMS website project, now is the time to consider whether you might benefit from an approach that decouples your CMS from your website. In this post, we assess the pain points of tightly-coupled Drupal that led us to adopt a decoupled approach. Traditionally, building a Drupal site goes like this:

  1. Download and install Drupal.
  2. Establish your look-and-feel with a pre-existing or custom theme.
  3. Extend functionality with modules.
  4. Create custom content types, tags, and menus, and make or import the content.

Voila! Your website is now ready for QA, training, and go-live. It is also a tightly-coupled, monolithic system, entirely controlled by Drupal. Drupal and the modules you’ve added handle the needs of every visitor to the site, whether they’re the visitors who come to your public-facing pages or the content authors logging in to manage the site. There are advantages to this traditional approach, and projects for which it is the best fit. But as an industry we’ve started to recognize significant pain points. Before you embark on your next project, let’s take an assessment of the pain points.  

Pain Points of Tightly-Coupled Drupal

Drupal Upgrades Require a Rebuild

There is no such thing as an “upgrade” from Drupal 6 to 7 to 8. Each time a new major version is released, adopting that new version requires a time-consuming rebuild. A site Pixo built in Drupal 5 in 2007 required hundreds of hours to upgrade in Drupal 6 in 2011 and hundreds more for Drupal 7 in 2013. It is a significant burden, especially for public sector or non-profit organizations, to finance a rebuild of their website every 3-4 years. Why are Drupal upgrades so hard? Drupal is modular, but unfortunately many of the add-on modules are so dependent on each other that the complete system becomes fragile. When you’re using modules that build on Drupal’s core permissions, workflow, and data structures, upgrading these modules can cause unintended results that automated tests don’t catch. Very popular add-on modules including Views, Features, ctools, Entity API, and Field Group have all had bumpy upgrades during the Drupal 7 era. The Drupal API contributes to this problem. Drupal’s API allows developers to write add-on modules that change and extend the internal workings of Drupal in huge ways. That extensibility has allowed Drupal to become a platform for many different kinds of web applications. But it also means that many add-on modules can influence each other in unexpected ways. Add to that Drupal’s philosophy of non-backwards compatibility. Each new major version is allowed to break everything that came before. To be fair, Drupal core does have a policy of providing automated upgrades of content from one version to the next. But many add-on modules change the database schema to add their own information, and those modules often do not offer support for automatic upgrades of their data. Significant effort is spent to re-build key elements of a site — examples include Views, Features, and content that uses Field Groups or Field Collections. WordPress, on the contrary, is backward compatible, so the cost of upgrading a site from WordPress 3 to 4, for example, is literally one button click. There are still other reasons to decouple WordPress, but the costly Drupal rebuild cycle is a key factor that led Pixo to look for a decoupled approach. Using a decoupled approach can solve much of this upgrade pain. It means that building a comprehensive site requires far fewer add-on modules. Drupal is employed just for its core functions, and the content you build in one version will upgrade to the next version.

Front-end Developers Have to Be Drupal Developers

In tightly-coupled Drupal development, members of the front end development team need to become Drupal developers in order to properly theme a website. The theme work has to be done in tight connection with module configuration and customization. Your entire dev team becomes tightly-coupled. For example, a calendar of events might be powered by the Views module. Putting that onto a page involves configuring the Views module (in the GUI), then dropping pieces of the front-end markup into dozens of small template override files with fun names like views-view-events–display-1-field_date_friendly-unformatted.tpl.php. Developers who do this work need to be experts in the fast-changing front-end arena while also having knowledge of complex Drupal development patterns. nested divs It’s typical to have two or three levels of nested divs for each part of a page. In the example above, most of the divs and class names are defaults, not chosen by the front-end team. On top of that, Drupal introduces dozens — sometimes hundreds — of CSS and JS files into your markup. Every module includes CSS and JS for both the admin tools and the visitor experience. With so much markup generated by Drupal core and add-on modules, your front-end work never starts with a clean slate, and you never feel like you are in control over the markup that your site visitors get. In the decoupled Drupal approach, front-end developers get to choose the best front-end tools without starting with all these CMS defaults. The front-end team can work at their own pace, with fewer hand-offs and less friction.

The CMS Delivers Inconsistent Functionality

As we’ve explained, in tightly-coupled Drupal it takes time and effort to customize and alter how your site looks and works. Once you build a site, it requires ongoing, repeated responsibility to re-build it and keep it working over time. Facing this challenge, it is very easy to give up and “go with the flow” of the CMS. If a project requires a calendar of events, you can just install off-the-shelf module for that. If you don’t customize it, you won’t need to fix or rebuild it over time. It’s easy to give up and use features in their off-the-shelf defaults. That can result in a website that starts to have different, inconsistent elements that give the entire site a mismatched feel. The visitor experience on your site is never tailored and polished, never consistent and delightful. In order to reduce the friction with your CMS, you lower your standards. In the decoupled approach, the front-end is a full, first-class citizen of its own. You can build and innovate the public view of your website, and there’s no relying on the defaults, for better or worse. The CMS no longer has to hold you back.

Your Content Is Trapped

In the tightly-coupled Drupal approach, your content can become trapped inside Drupal’s sprawling realm of database tables. In Drupal’s database schema, every field of content is stored in its own database table. So to reconstitute one piece of content with N fields, you need to write a SQL query to join at least N tables or write PHP code to build that query for you. That can become a barrier to sharing your content. In the modern web, it’s natural to want multiple systems, not just your website, to be consumers of your content and to present it to users. It’s natural for native mobile apps to consume content, or for content to be distributed in multiple feeds, formats, and data products. For an excellent treatise on the so-called Create-One-Publish-Everywhere (COPE) approach, check out this article about NPR’s decoupled CMS strategy . In decoupled CMS architecture, all of your content is available through the API. Any other system or device can become a consumer of that content through the same API, unlocking your content for multiple uses.  

The decoupled, content-as-a-service approach is one that Pixo and others are adopting as a way to avoid these pain points and launch better websites. Using this approach, your CMS serves up content to a separate web application that delivers your site to visitors. 

Watch our webinar with friends from Four Kitchens, hosted by Pantheon. Pixo’s portion of the recording starts at 21:00.

YouTube Preview Image

Comments

5 thoughts on “Why We’re Decoupling Drupal

  1. Is the webinar posted online anywhere?

    Great article. I develop websites in both WordPress and Drupal. I love the idea of Drupal more than the actual practice of Drupal.

    Reply
  2. I’m not convinced that a marketing website would benefit from decoupled architecture – be it on WordPress or Drupal. A SAAS application – absolutely. A site that supplies content to a mobile app – sure. But not a standard marketing site.

    I also see several inaccuracies, exaggerations, and outdated facts within your, “Pain points” which sort of undermine your authority on Drupal dev.

    Reply
  3. Jared—I’d love to hear more from you about what you feel is inaccurate. I’ve been doing Drupal since the 4.x days, I’ve been a core co-maintainer, and as a company Pixo has launched 250+ Drupal sites. In all that time, I’ve loved the Drupal community but I’ve also seen Drupal’s pain points and I believe we have to be honest about them.

    When developing a marketing/informational website, the Pixo team is loving using Decoupled Drupal and Decoupled WordPress. Our front-end team gets to work independently, use the very best front-end tools (which are evolving quickly), and build a robust visitor experience. The CMS can really be optimized to provide the best content author experience when that is its sole role. And the end result is that the CMS and the front end can each be upgraded more easily over time.

    Reply
  4. I successfully decoupled part of a Drupal site for the Tate gallery and it’s a great way to start to migrate away from a D7 system that has become overly complex and difficult to deploy. I almost think that the idea of having a lightweight framework sitting in front of Drupal is the best way to use Drupal when it becomes unwieldy.

    At the Tate we used Django (which worked really well) and I’m currently looking at using Symfony with a view that D8 uses it and so there will be some cross-over of skills.

    I agree with all of your pain-points. 🙂

    Reply

Leave a reply

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> 

required

Related Posts

Automating Plugin/Module Updates on Pantheon. We automated the process to apply plugin and module updates on Pantheon sites with a simple command.

Listen to Pixo and Four Kitchens' case studies on how we decoupled Drupal and Wordpress site architectures to separate CMS content from the front end.

How to achieve Pantheon's one-click-update functionality for Drupal and Wordpress while retaining your git history using git-graft.

Recent Comments

avAssut
3.29.2017 - Drupal 8 Roadmap
Wcntoode
3.28.2017 - Drupal 8 Roadmap
Nyspathe
3.27.2017 - Drupal 8 Roadmap
AliseNMn
3.23.2017 - Drupal 8 Roadmap

Interested in working with us?
CONTACT US