The 15 Things Your AEM Team Says Drupal Can't Do, But Can

We’re tired of companies being misinformed about Drupal’s capabilities. Time to clear the air.

Over the last several years, Acquia Drupal has quickly built inroads into enterprise clients that would traditionally gravitate towards either Sitecore and Adobe Experience Manager (AEM). This rapid growth has created a fair amount of out-of-date information that AEM proponents tend to lean on when advocating for the Adobe platform but the reasoning is not substantiated in many cases.

The top 15 misconceptions about Drupal:

#1: Drupal doesn’t offer an intuitive inline editing experience.

#2: Drupal cannot track several published versions of the same components for A/B tests.

#3: Assets are not revisioned and revertable.

#4: Drupal Workflows do not support annotations.

#5: Images cannot be reused in multiple components.

#6: Drupal cannot store assets in a hierarchy.

#7: You cannot compile Less files into CSS with Drupal.

#8: You cannot move a page in Drupal from one folder to another.

#9: Drupal does not support a collection of individual fields into a single multi-field type.

#10: Drupal can’t inherit page properties from parent pages.

#11: Digital asset management integration is not as seamless as it is in AEM.

#12: The marketing team can’t update page layouts without involving an engineer.

#13: Drupal is free… like a puppy.

#14: Drupal’s lack of support for multiple master database backends means Drupal can’t be made highly available (HA).

#15: PHP is inferior to Java.

#1: Drupal doesn’t offer an intuitive inline editing experience.

This claim was actually true about Drupal—until recently. One of AEM’s key differentiators is its slick editorial experience. Just take a look at this example page building interface, inline with all of the site content and design:

Adobe

Drupal has long lagged behind AEM’s superior page building editor and content experience. However, in the last year, Drupal has invested a tremendous amount of engineering hours to bring this experience to parity with AEM.

Drupal 8 has long had all the components necessary for a slick page-building experience—media handling, a block API, complex custom fields, entities, etc.—which the Layouts module, now part of Drupal 8 core, brings together into a cohesive and compelling user experience that is (at last) similar to AEM’s capabilities.

Drupal

By configuring and installing the right modules (extensions, plugins, etc.) you can achieve a seamless editorial page building experience, for the rare marketing teams that actually want to do more than just edit content and refine SEO attributes.

#2: Drupal cannot track several published versions of the same components for A/B tests.

AEM teams will often point to their platform’s ability to track multiple published versions of individual site components (widgets) in order to perform A/B tests.

While Drupal’s content and field module is flexible enough to support tracking two different published versions of even the most complex component or widget, support for this use case is not as well executed as AEM. However, from our perspective the larger issue is not about the capabilities, but whether a CMS is the right tool for an A/B test.

WordPress is the most popular content management system in the world. Back when it was first released, in 2003, if you wanted to add a lead generation form to your site, you built it in WordPress. Marketo, one of the leading marketing automation platforms, wasn’t founded until 2006. Fast forward a decade and now you have dozens (if not more) of third-party services for embedding a lead generation form in a WordPress site. Building a lead generation form into a CMS today is considered a bad practice because these third-party tools can invest tremendous amounts of engineering time on solving one problem, whereas the CMS has to spend limited engineering time solving many. A CMS simply can’t compete, and hasn’t, for years.

Over the last decade, third-party services have repeatedly become a better option than using engineering time to modify a CMS, and that’s finally happening for A/B testing as well. It’s true that AEM has better support for doing an A/B test in the CMS, but the broader question is, shouldn’t you be using one of the leading A/B testing tools—Google’s is free!—rather than doing it right in the CMS?

#3: Assets are not revisioned and revertable.

AEM has robust support for the revisioning of assets; every time an asset is changed by a content author, the previous version (or difference) is stored in the system so that a user can later revert to the original.

AEM teams often get confused by Drupal’s revision system, but rest assured that Drupal tracks every change to content and assets and allows users to see the history, compare the differences, and revert back as needed.

Drupal

#4: Drupal Workflows do not support annotations.

Built into the core of AEM is a powerful workflow system, where you can define the creation lifecycle of a piece of content through an editorial experience and across a team. Not only does the AEM  system support a custom workflow of writing, editing, reviewing, approving, and publishing, it also allows users to annotate custom messages that describe an overall change to the content. You may have heard this described as a change log.

This is an area where Drupal’s module ecosystem causes a fragmented documentation situation—where a certain feature is supported, but only when additional Drupal modules (extensions, plugins, apps) are installed. In fact, Drupal fully supports a changelog and has a workflow system as robust as AEM’s, though achieving this functionality does require the installation and configuration (in the GUI, not code) of several modules like Content Moderation and Workflow.

#5: Images cannot be reused in multiple components.

AEM teams often point out that AEM offers an excellent media handling system, specifically when it comes to reusing the same image in multiple components. Media handling is now built into Drupal core, but to achieve feature parity with AEM, users need to employ a variety of media handling modules (like Content Browser), specifically the Inline Entity Form module to achieve a similar content reusability experience.

#6: Drupal cannot store assets in a hierarchy.

Building on AEM’s native content hierarchy model, the Adobe platform supports organizing assets in folders to enhance the user experience. AEM teams often look at the default media support in Drupal and think that assets cannot be organized in a hierarchy and are just maintained as a long list.

Drupal takes a different approach to this problem. Instead of a file folder browser experience where the author organizes content themselves, Drupal site builders configure the folder paths that media should use on each individual file field added to the system. This allows content from different fields—think a logo image field and an icon field—to be organized into different folders. To enhance SEO and make the experience even better,  you can use the File (Field) Paths module to have the media file name and folder structure dynamically built from various attributes of the uploaded content on-the-fly, automagically.

#7: You cannot compile Less files into CSS with Drupal.

Less is a stylesheet language that allows developers to write CSS, the visual theming language of websites, faster and better, with less technical debt over time. Sass is a competitive approach to Less.

Web browsers don’t support Less or Sass. When you make a change using Less or Sass, a program translates that change into CSS, which browsers do understand. AEM has built-in support for this translations process. Drupal doesn’t support it.

However, Drupal’s perspective is not that this is a missing feature but that this is not something a CMS should do. In computing, there is a concept called  Separation of Concerns (SoC)—solving discrete problems with discrete solutions. CMS is a big problem and requires a big platform to solve it, which is why you have popular platforms like Drupal, WordPress, Sitecore, and AEM.

But compiling Less and Sass into CSS is an entirely different problem than managing content for editors and building marketing sites, so Drupal’s perspective is that you should compile your Less and Sass in an outside system (which is easy with tools like Gulp). This is the industry best practice and the best solution when you ’re using Less or Sass with Drupal.

AEM teams may similarly push back on Drupal’s ability to compile JavaScript ES6 (the latest and greatest version of JavaScript) to ES5, the previous version, to ensure wide visitor browser support. Compiling JavaScript, like dealing with stylesheet languages, is something best done outside of the CMS.

#8: You cannot move a page in Drupal from one folder to another.

A major difference between AEM and Drupal that often causes confusion is how each system approaches the organization of content in the backend. AEM uses a hierarchical content model, organizing content into a tree whose structure mirrors your site information architecture (IA). Drupal takes a different approach and maintains a flat content structure in the backend, and users rely on menus, taxonomy, and URLs to build their site IA.

This difference causes confusion when AEM developers look into Drupal and think that pages can’t be moved between folders to appear in two places. Drupal fully supports organizing content into any kind of hierarchy, you just do this outside of the main content list in the Drupal author backend. Individual pieces of content in Drupal can have multiple taxonomies (tags, categories, any number of custom categorizations, etc.), appear in multiple menus (main nav, footer nav, etc.), and use multiple URL aliases. (Drupal ensures strong SEO support by redirecting all other URL aliases to a primary URL alias in a search-engine and user-friendly way.) That means you can achieve the same kind of flexibility in content hierarchy in Drupal or AEM.

#9: Drupal does not support a collection of individual fields into a single multi-field type.

AEM components are made up of different kinds of field types, and AEM has this neat field type called a multi-field that is a collection of other individual fields treated as an aggregate field. A simple example: Say you want to have a component on your page that lists four products, and for each product, an author will need to set a title, image, and a URL (to the product details page). What you have here is a single multi-field, filled out four times, with three individual fields each, one for product title (text), image (file upload), and URL (link).

This one is easy: Drupal fully supports multi-fields out-of-the-box via the Paragraphs module.

#10: Drupal can’t inherit page properties from parent pages.

One of the things AEM does really well is present an intuitive tree of content to the user to editing site pages, and couples that view with the inheritance of page properties of parent pages to children. AEM teams will often have a hard time finding an intuitive content tree in Drupal and conclude that parent page property inheritance isn’t supported.

Compare the AEM content tree to the Drupal content list and it’s easy to see why this confusion exists:

Friendly Machine

However, Drupal does support the creation of pages that inherit properties from parents using the Panelizer module and the Layout API, now in Drupal core. Drupal organizes different kinds of content into user-defined content types and calls individual pieces of content nodes. Using these modules you can define a global layout for all content types, and then customize properties, layout, and theming for each content type, inheriting global properties and making as many distinct content type level refinements as you need.

#11: Digital asset management integration is not as seamless as AEM.

Drupal can integrate with most major digital asset management solutions just as well as AEM.

AEM teams will often point out the tight integration of Adobe’s Digital Asset Management (DAM) product into AEM itself as a compelling advantage over Drupal. This is a bit misleading because both Drupal and AEM integrate with a wide variety of off-the-shelf DAM solutions. In both systems, you can achieve a strong editorial experience with different solutions and workflows.

The larger issue is one of the values of tightly coupled solutions. Adobe didn’t build AEM but has been acquiring a series of businesses so that it continues to add new capabilities to its content management platform. The foundational acquisition was Day Software’s CMS, CQ, to which Adobe added analytics (by acquiring Omniture) and marketing (Efficient Frontier), and this year, commerce (Magento) and marketing automation (Marketo) to the mix. This means that today AEM is a collection of disparate tools, developed by separate companies on separate technology platforms with separate goals, hard woven into a single solution.

Curiously, while Adobe drives towards a single unified platform of (allegedly) tightly-coupled components, the world of digital marketing is splintering into literally thousands of marketing technology tools, each of which can be easily integrated into a website based on specific needs. As the sophistication of cloud services continuously improves, the ability of a digital marketing team to execute quickly using the best tools continues to get easier and easier. The appreciating currency is about speed and agility, and the ability to respond to changing capabilities, market realities, and institutional priorities, and less about a tightly coupled monolithic system.

Sure, you can make your core CMS do lots of stuff, but the real question to ask is, should you? Think about the person in your extended family (we all have one) who is very handy around the house and can tackle serious home improvement projects. What is the big difference between this person and someone who can do just handle the very basics? Tools. The serious home improvement person will have a robust set of tools they know how to use—and when.

#12: The marketing team can’t update page layouts without involving an engineer.

With the latest version of Drupal 8 and the addition of the Layout system, Drupal now offers feature parity with AEM’s most compelling feature: inline page building.

AEM is perhaps best known for providing marketing teams with a slick interface for building page layouts without the help of an engineer. Teams can create new pages, dynamically create layouts, columns, and grids, and add various content modules.

But take a moment to think about how necessary it is for marketing teams to have this capability in light of the dramatic shift to agile marketing.

There is scant evidence that this is a feature marketing teams will actually use. Most of Third & Grove client’s are mid-market and enterprise organizations, both B2B and B2C, in a variety of different sectors. Nearly all are U.S.-based. While many requested the ability to build page layouts, over the last five years, less than five of our clients have actually used this functionality once it was provided to them. Indeed, the actual usage was so low across all of our projects that we quietly stopped creating page layout builders by default unless the client asked for it. And no one ever did.

The marketing teams we encounter do not want to spend time building page layouts in the CMS. The best executing agile marketing teams we see spend their time working with writers on a content strategy, evaluating and deploying a continuous stream of various marketing technology tools (Drift anyone?), and iterating on new ways to capture informative engagement data from tagging and analyzing analytics. Building a page layout is considered a low priority task they prefer to outsource, to their development teams or an outside partner.

Let us now turn to the issue of whether Drupal offers as compelling an experience of page layout building. This claim was most valid when comparing AEM to Drupal 7, the previous version of Drupal. Drupal 7 did not provide a compelling parity of experience. And, when it was released two years ago, neither did Drupal 8. However, since the Layout system was added into Drupal core, it now offers a compelling, similar page-building experience.

Drupal

#13: Drupal is free… like a puppy.

Adobe likes to say that Drupal is free like a puppy is free. They mean that yes, Drupal is free and fun, but, like a puppy, it takes a lot of work (read: customization) to grow into a well-behaved dog.

The reality is that both options require a lot of work to meet your needs and mature into a valuable solution for your organization. So why pay money up front when you can get a great outcome (and feel good) rescuing a puppy from a shelter?

#14: Drupal’s lack of support for multiple master database backends means Drupal can’t be made highly available (HA).

This one is a bit technical.

Drupal works out-of-the-box with any MySQL variant (MariaDB, Amazon RDS, etc) and Postgres. Drupal can also be made to run with Microsoft SQL Server and SQL Azure. Like most database platforms, MySQL supports running as a single database, where applications read and write data to one database, running one master and multiple slaves, where applications write only to one database instance (master) but can read from any number of slaves, or master-master replication where there are multiple database instances where a change to one database cascades to all of the other master instances automatically.

Drupal fully supports a single database instance and a master slave configuration but doesn't really support master-master replication because of (among other things) its standard use of auto-increment primary keys.

This limitation is often called out by AEM teams to mean that Drupal cannot be made highly available (HA). While the limitation is technically accurate, it does not mean that Drupal can’t be highly available. Global high availability is an important requirement for any organization that relies on their site to generate leads, engage with customers, sell products, or generate brand goodwill. But it is how you go about achieving HA that matters.

Ask the AEM team a simple question: Why do you need to use master-master replication to achieve highly availability for a marketing site?

The crux of this issue is that AEM costs a lot to buy (licensing fee) and implement (budgets typically are double enterprise Drupal build budgets), and when something costs a lot, people tend to justify spending more money in other areas, like infrastructure. This is why you will often hear AEM teams talk about needing globally-distributed data centers with multiple master databases to power a marketing site.

But remember, today the main website of even large enterprise companies is no longer complex or dynamic. Why? For starters, the public doesn’t log into marketing sites. They might log into a dashboard or application or even a store, but those experiences are likely in other systems, not the marketing site. Further, the areas of a site that remain dynamic today—like a lead generation form, the investors portal, or a careers section—are now provided by third-party tools like Marketo, Pardot, Drift, and West Communications. In 2018, the burden of HA has been offloaded to the data centers of third-party providers.

Regardless of the traffic level or importance to your business, what you are often left with is a static marketing site that can be entirely fronted on a content delivery network (CDN), like Akamai, Fastly, or Cloudflare. And nothing is better at global HA than a CDN.

#15: Java is superior to PHP.

We have to nerd out again, however briefly. AEM teams will often raise concerns about PHP, the language of Drupal. AEM is written in Java.

I once chatted with an AEM team that said,  because PHP did not include certain state memory constructs that Java included on a per process level, more server overhead and complexity was required to track that data separately when they used a PHP application. They argued more complexity meant more potential for issues.

I responded that since Java was doing more per process, the memory overhead was higher and chances for fault were higher because of added complexity in a single thread. Is this technically correct? Yes. Is this really a flaw of Java? Absolutely not.

PHP and Java are both mature, robust programming languages with real strengths and real weaknesses. Neither is better. Both are great.  Both can be a headache, and both are paths to success as often as they are paths to project failure. World-class organizations run world-class applications solving problems in both PHP and Java. When used correctly, both PHP and JavaScript are secure and can be maintained. Both languages have large communities of talent from which you can hire people, here in the US and abroad.

In the context of Drupal vs AEM, programming language is no longer a valid point of consideration.

Drupal is not perfect nor right for every project but you should at least make a decision based on the straight truth of each platform.