Running a company that provides website maintenance and development services, along with having been in web development for over twenty years has given me a wide-eyed and fairly objective view of the Content Management System (CMS) landscape.
That wide-eyed understanding leads me to be very skeptical of any company or service claiming to be a panacea or some sort of “wonderful website-builder”. If our website is the beautiful house that we want to build, a CMS is more akin to the type of materials or tools we are using, than the engineer or the skilled craftsman. The tool can be beautiful, but without the skill and knowledge to use it, it’s worthless. The same goes for a CMS.
But with that warning, let’s focus on the tools, and shelve the discussion of what makes a great web development team for another day (incidentally, if you are unsure about what makes a great web development partner, check out our 10 questions to ask your development partner). I am often asked about the differences between CMSs. Usually, things like ease of use, security, and affordability are the attributes that come into the calculus of landing on a CMS (no small decision). These attributes are usually secondary characteristics or derived from the architecture of the CMS itself. So, today let’s focus on the architecture of Drupal, to understand how it may or may not be a good fit for your team.
Drupal provides out-of-the-box flexibility through the very mature and robust Drupal Core. Drupal Core has grown over the years to incorporate more of the add-on modules that nearly everyone was using anyway. By swallowing these modules into the Core, we get a more dependable, centralized, and stable foundation. Here is a list of the core components. You will see most are built for moving, storing, or displaying data for the website.
Most of our clients have websites that display a lot of content in different places. For example, a blog article may have links to it and excerpts also displayed on a structured search results page. There may also be links to the article throughout the site as ‘related content’ or on a campaign landing page. Obviously, we want that content syndicated across the site without having to rewrite anything, or store information in multiple places (this drives non-technical content editors crazy). Drupal core provides modules like Taxonomy for this purpose. Views and Views UI modules come in handy for filtering views on pages (for example, displaying all articles about ‘how to save’ in a Knowledge Center on a retail banking website).
There are also ‘collections’ of components for Drupal that may not be part of the core, but are still grouped and maintained as one cohesive project. An example of this we have used is Drupal Commerce. While not yet a fully baked end-to-end commerce solution, Drupal Commerce provides core commerce functionality like Shopping Cart and Product Listing. Most importantly, it plugs in seamlessly with the Drupal Core, avoiding a disjoint Commerce Site vs. Marketing site experience. Keeping your shopping and brochure-ware experience cohesive leads to more operational efficiency and better SEO boost, among other values.
Back to flexibility: While there are a lot of Drupal Best Practices, there is more than one way to do just about anything, giving a lot of creative control to the developer, based on the business requirements.
For example, a page can be built on Paragraphs, Drupal content types, Blocks, or custom data collections, based on how the content needs to be used and displayed. You are not shoehorned into one Drupal Way of doing things. The flip side is that the Drupal web developers must think a little more broadly and strategically. They must think critically about requirements and layout pros/cons. It’s not just about the functional requirements of the site (the ‘what’). It is also about the non-functional requirements (the ‘how’). Things like scalability, reusability, performance, and security must be considered as well. For more on non-functional requirements, check out this nice write-up on FURPS+, a way to organize product features.
Remember, the view of the CMS, warts, and all, that most of your company will see and interact with is the Admin UI. This is where most configurations will happen. More importantly, this is where all of the content editing by non-technical users will happen. Most of these folks will be on the Marketing team. In case you haven’t noticed the marketing team is not exactly twiddling their thumbs all day. They are likely overloaded by competing priorities, sub-optimal budgets, and have no patience for a clunky experience when they need to add a new campaign or update a product line on the site under a deadline.
The Drupal Admin UI got an upgrade with the release of Drupal 11, making the navigation more intuitive, responsive and customizable. It also can be ‘hooked into’ based on specific events or triggers.
Furthermore, workflows are part of Drupal Core. Let’s say you need legal approval whenever you update the Prescribing Information for a certain drug advertised on your site. A workflow can be set up so that Legal must sign off on any changes to those pages (or content blocks) before they go live. Legal team members can be alerted via email when they need to react.
Helen Keller said, “Alone we can do so little; together we can do so much.” Put another way, teamwork makes the dream work! When using the Drupal CMS, you become part of a community of thousands of Drupal Developers and Content Managers. Drupal has one of the strongest open source communities in the world meaning there is tons of code already written for a lot of custom use cases and contrib modules. Plus, this code is often regularly maintained and covered by a security policy similar to Core. All this means there is a decreased need for developers to write and maintain custom code. There are Slack Channels to stay up to date on security, email lists, forums, and the like. Your developers will not be alone in the world of Drupal.
One oft-overlooked part of the critical path to building a new website is migrating data and content from the old website. Drupal has many tools for doing this in a more automated way (beware anyone who promises complete automation here. It does not exist!). For example, Drupal 7 has node export/import. Content Migration is made easier in versions 8, 9, 10 and now 11 which has built-in support for multiple methods of accessing data programmatically. There are also third-party tools, like Gather Content which have integrations for Drupal and other CMSs.
We have many clients who need content in a central repository that must be syndicated into different contexts. For example, marketing content must be displayed in their mobile app, website, and in-store kiosks. What’s a developer to do? Using a Headless CMS strategy, you can use Drupal as that central repository, without compromising the user experience on the app or kiosk. Without having to do clunky workarounds like iFrames, you can free yourself from having to change the content in three places. Here is an example from Pantheon, our preferred Managed Platform for Drupal.
The CMS is just the start of the foundation for the Website. You will need to manage security patching, caching, logging, dev-ops, and a host of other things. Enter managed platforms. A managed platform acts like a wrapper or, well, a platform, to support the CMS, so you don’t have to worry about a lot of the management of the CMS without paying for an expensive dedicated team. You will still need a website maintenance and development team to write and manage code and respond to issues, but a lot of the other stuff is taken care of for you. For example, Pantheon allows you to deploy code through their web interface and even allows you to horizontally scale your site. Acquia also has similar functionality.
LET US HANDLE YOUR WEBSITE NEEDS
To summarize, Drupal is a mature, Enterprise-ready CMS, especially when used on a Managed Platform. If you're searching for a knowledgeable and experienced web development partner to help you with your CMS needs, please contact us today!