Recently we began a project with the Royal Society of Queensland to make a new web application and online resource. As it’s still getting ready for go-live I’ll need to be a little elusive about the project and its audience, but what I can share is the process we went about to give them as much bang for their buck as we could, and reduce costs during development.

Without going into the requirements (or more importantly the implementation) too much, there was a heavy need for: publishing and publications management; groups and moderation workflows; distributed authorship; content taxonomy and classification management; consumption by multiple devices; and most importantly, low cost of development and ongoing management.

Sounds like heaven?

At Gaia, we’re technically agnostic. While we have certain preferences, we implement what’s best for the client. In the two years I’ve worked here, I’ve worked on Drupal, WordPress, Magento, CollectiveAccess, Artefactual Atom, Archivematica, Angular Single Page Apps (SPA), Knockout SPA, and investigated a range of other technologies, like Static Site Generators (SSG), before making our recommendations. The point is, we make an analysis, and choose what we think is best and can support in an ongoing fashion.

This blog will go into why I recommended Drupal 8 and the factors we considered to come to that decision.

Firstly, we deal in Open Source and the client did not have a licensing budget. So goodbye Adobe Experience Manager, SiteCore and other admittedly very good, but expensive publishing platforms and web content management systems.  Realistically, we still needed a Content Management System (CMS) at the core of the project, but a CMS that could publish to multiple consumers. That included quality open source CMS’s like Drupal and WordPress, as well as SSG’s like Jekyll combined with search-as-a-service, like Algolia.

Looking at the publishing requirements, I believed relying on markdown or similar would make SSG a bit hard to manage for the client, but more importantly, they probably didn’t have the ecosystem of plugins / modules required to keep the build costs down.  Similarly, building a nice Javascript SPA site or Javascript powered CMS site like React Static, certainly sounds exciting, but I think the decoupled approach (at least in the short-term) was probably overkill.  In short, I believed that a traditional CMS with lots of modules and plugins was the best fit, ideally one that could progressively be decoupled if needed in the future.

So, next came weighing up the best-fit CMS. I am familiar with both Drupal and WordPress, but no so much Joomla!, Type3 or the multitude of other free CMS platforms that do a good job at managing content. To minimise development costs, sticking with my familiar platforms made a lot of sense. But even more important than that familiarity, WordPress and Drupal are the world’s 1 and 3 most used Content Management Systems, and there are sufficiently massive ecosystems of plugins and modules to ensure we could keep development costs down.

At this junction it became a choice of WordPress vs Drupal 8.

So why did Drupal 8 win out? The short answer was the site requirements were sufficiently complicated in terms of publishing content that it lent itself to the more powerful, albeit somewhat more complicated Drupal 8 platform. WordPress could do it (and we know it well as it powers our own site), but I thought Drupal could do it better.

Let’s look at a few of the aspects I considered, and a caveat, this was a lens specifically about this project: these observations are not necessarily generalisable to other projects:

• Security: much as been made of the recent Drupal vulnerabilities, however, the security team is proactive, and assuming you stick to supported modules and follow the security advisories, you have excellent security. WordPress has automatic security updates to core, but there’s no control over what contributed module authors do. If you stick to core, WordPress is a clear winner, but Drupal 8 is certainly a safer bet (the devil you know) when it comes to the module ecosystem. In this case, I’m personally going to say Drupal is slightly ahead.
• Workflows: this is something managed well in both platforms, moderation, approval queues etc. can be supported easily. No real winner in either camp here.
• Theming: WordPress has an amazing and beautiful ecosystem of themes out there that require only minor theming. This is an important requirement when you are trying to reduce costs as a lot of time can be spent theming. Drupal has some good themes, but usually more time is required. This factor was a consideration strongly in favour of WordPress.
• Maintainability: WordPress is easier. You can generally update from within the admin interface, and as long as you have a good backup procedure, it’s an easy process. Drupal really requires use of Drush and increasingly Composer, which really requires a developer. In terms of developer community and agency support, although Drupal has a big community, WordPress is much larger. This is another one in favour of WordPress.
• Groups and community pages: the “default” community pages in both WordPress (Buddypress) and Drupal (Organic Groups), didn’t really fit the requirements. With further investigation, the requirements were probably simpler than what either of these modules offered. So really, some simple modules and permissions managed what was needed here. No real winner in either camp here.
• Content classification and data modelling: in my opinion, there’s no comparison here and this is what pushed Drupal into the winning position. Building managed taxonomies of content, creating content types, sharing elements between content, and using tools like Drupal Views to expose data, has no comparison. Combined with the ease of creating these custom content models, easily publishing content types APIs for reuse, how you can use search index weighting for aspects within the content types, all combined to push Drupal 8 to the winning position. This was the most important requirement of the project, and thus was the winning factor that overrode WordPress’ other aspects.
• API first: though not required yet, important to be ready for the future. Both platforms support API and progressively decoupled systems. No real winner in either camp here.

This was a bit of a summary of the process I went through to decide on Drupal 8. We’re now in build, and I look forward to sharing the results of the build process in coming months.  If you want to know more about Drupal, our processes, or any of the techs that I mentioned, send an email to morgan.strong@archive.gaiaresources.com.au, or start a conversation with us via our social media channels – Facebook, Twitter or LinkedIn.

Morgan