10 reasons why the Royal Family should switch from Drupal to Enonic

Drupal has been in the game for a long time, with several big brands and organizations as customers—including the Royal Crown. Drupal also has a large community of developers and editors, with many people knowing the system well.

If you're running on Drupal today, you might be satisfied. But should you rest on your laurels? We think not. Here are 10 reasons why the British Royal Family, large organizations, big businesses, and everyone in between should consider switching from Drupal to Enonic.

1. Content and services

Websites and digital experiences aren't just content or "online brochures" anymore. While Drupal certainly can handle content without much ado, it stops there for the content editor.

To make it customized, you need to know PHP or someone who does. But even with developers on your team, Drupal is still not made to be a web platform, but primarily a traditional CMS. This means there are certain limitations for what your organization can do in the future.

Completely tailoring the customer journey is one such futuristic feature. Modern customer journeys don't just require content, but also services. An example is insurance companies, where content is delivered in tandem with calculators, "My page" functionality, reports, issues management, and so on—depending on where you are in your customer relationship.

Now, look on the bright side. The Enonic platform is made for solutions where you mix content and services in a seamless way. Just take a look at our customers TINE, Gjensidige, or Norway Post—or see the rich functionality you get from services like Airbnb or Uber.

For the Royal Family, a stronger link between content and services would mean better user experience and richer functionality for their sections of booking, tours, media centers, and calendar. These services are important to keep smooth, effective, and multichannel for the digital tomorrow.

2. Most dreaded platform

Clocking in just after SharePoint, Drupal is ranked as the world's most dreaded platform among developers. We believe the dependence on PHP, the performance of the platform, and the old-fashioned look and feel of the Drupal user interface might partially explain this.

Enonic, on the other hand, is based on server-side JavaScript, and we have focused on allowing developers to build CMS functionality in the same way as they build any application.

Developers, both within the Crown and elsewhere, are moving towards fullstack JavaScript, which is not supported by Drupal. Don't let the King miss out on a platform the developers will love now and in the future.

See also: Drupal vs. Enonic »

3. Slow performance

Enonic is built around the insanely fast search engine Elasticsearch, while the runtime is Java. Why is this a good thing? Java is the back-end of many large services, like Twitter and Facebook.

You expect services like this to always deliver, and so too does the Royal Family expect that their digital services always will have uptime and be fast. Adding to the fast performance in Enonic is that everything is coded in JavaScript, but optimized for speed by the Java Runtime Environment.

Drupal, on the other hand, is based on a relational database, meaning that it is slower to search than with a search engine. Ben Sinclair has explained on Quora how e.g. inconsistent caching contributes to the slow performance of the Drupal platform.

4. Confusing interface

To quote Ben Sinclair on the Drupal admin interface, it "has a pretty random UI. Some pages will update things as soon as you change them by AJAX. Some will have a "save" button at the top ... or at the bottom ... or floating ... I think this got designed by committee—in a pub."

In Drupal there is a separation between your content and your structure. Also, you can click yourself to death to manage options in the dashboard interface, like site structure and menu functionality.

You can see the Drupal user interface yourself here:

Enonic will not try to confuse the King, the Duke of Cambridge, or the Duchess of Cornwall, and offers instead a tree structure out of the box, which can mirror the site structure. Our tree structure provides a tidy and logical overview of your site, your content types, and your content pieces.

This is how Enonic looks, by comparison:

5. Ineffective search

Drupal lacks a search engine and relies on legacy database search or the use of a third-party tool at the side. The Royal Family is certainly not growing any smaller, neither in family members nor content, so featuring a fast and precise search engine is of vital importance.

Enonic has the mentioned Elasticsearch embedded. Elasticsearch can search in different sources, with scoring based on aspects of your choice.

Read more: Untangling complexity with a powerful enterprise search »

6. Dependency on third-party database

Drupal is dependent on a third-party database, which means more operations, more maintenance, and more hassle when upgrading the platform. Prince Charles doesn't need any more grey hairs, so why keep unnecessary troubles around?

In Enonic the Heir Apparent would get embedded NoSQL storage. This will be maintained by Enonic and Charles would not have to worry about any third-party installation.

7. Excessive use of modules

Just like WordPress relies on a heavy user dosage of plugins, so does Drupal rely on so-called modules. Just like it's larger CMS brother, Drupal needs several modules to get the Royal Family what they need—as the core itself is rather slim.

A fairly low number of healthy modules doesn't need to spell catastrophe, but Wikipedia cites some grave concerns about many published, yet incomplete or outdated modules among Drupal's 30,000 downloadable modules. This could at least spell a security risk.

With Enonic the Royal Family must involve professional developers from the beginning, which restricts the need for several extensions like plugins or modules to begin with. But Enonic does sport the Enonic Market, a thoroughly controlled and verified marketplace of apps, starters, and libraries that offer a ton of functionality for both developer and editor alike.

8. Loss of interest

The Royal Family has always been famous for their trendsetting ways in fashion and style, but now they may need to reconsider their digital experiences. According to Google Trends the interest for Drupal is sinking, which may indicate a flight from the community.

Enonic might not have as large a community or customer base as Drupal, but we're up and coming, with highly satisfied customers.

9. Accessibility

The Royal Family is not only trendsetters in fashion, they have always been on the forefront of speaking for people with disabilities and accessibility issues. Accessibility is important for any website or digital offering, and the Enonic customer Norwegian Welfare and Work Department has for instance a score of 100/100 in Google's Accessibility Audit.

If the Royal Family had switched to Enonic, they would have gotten easily accessible, but still powerful tools to boost their ranking and accessibility score with SEO meta fields and Siteimprove.

10. Kickstarting new developers

Developers, whether they be royal or not, love to build working systems in a flexible environment. This is what we have provided with Enonic. Setting the platform up is fairly easy for developers—just give it a few hours, then you are ready to contribute.

With Drupal it can take a day to set up the platform for a developer environment. Drupal has a lot of dependencies to third-party services, like a database and a search engine—which in turn require a lot of configuration.

Enonic makes it easier to understand concepts and is more natural for developers with the focus on fullstack JavaScript and their favorite front-end framework, like Next.js. You code and build your applications and websites through standard patterns and methods, something which a developer will find familiar.

Drupal is more like a traditional CMS: the platform is rigid and you have to teach yourself special concepts. If you know PHP and Drupal, it's probably OK, but then you have already started a long time ago.

First published 6 March 2019, updated 17 August 2022.