Clutch spoke with Chris McGrath, the Founder of Celebrate Drupal about working with Drupal – one of the most well-known website builders.
Introduce your business and what you do there.
I am the founder and managing partner of Celebrate Drupal. The company has been around since 2012, and has generally focused on enterprise-level Drupal websites which are in need of maintenance or a new build, as well as on migrations of old sites to Drupal 7 or 8.
Why do people tend to consider Drupal as a CMS?
The most common reason that I’ve seen for the consideration and adoption of Drupal, given that it is an open-source tool, is relief from proprietary technology licensing fees.
When coming to us, a lot of companies have already subscribed to the componentized nature of Drupal—a modular type of architecture, prepackaged functionalities which may already match the customer’s use case. Hopefully, they can just grab the piece of functionality they need and plug it in. At times, that will work, which can be a wonderful thing. It may not work forever, but, being one of the largest open-source communities out there, a piece of functionality will often continue to be maintained by its creator, and the user doesn’t have to do a thing other than use it. There may be an opportunity to support that creator in one way or another (either through a paid customization or a donation), but otherwise the technical debt is managed by someone else.
This follows a newer paradigm of the past 10 or so years in web application development. Previously, software and websites were built from the ground up, and the best a business could hope for was that the person being hired had done it before, and had the gained knowledge and velocity which comes from experience.
Currently with Drupal, the technology is inherently designed for reuse, and customization only needs to occur to extend baseline functionality to fill whatever gaps might exist between the desired functionality and the current. It’s certainly possible that the free software being utilized by the customer, however sophisticated it may be (we know of at least 200 companies on the Fortune 1000 list which use Drupal), will need to be extended or customized.
Drupal has answered many pains in the web development industry, based on my history of 25 years. For most of the clients we work with, and even in the case of agencies we’ve worked with, whose main focus is proprietary (or was, until fairly recently, with Microsoft’s .NET going open-source), even as of a few years ago, they were used to technology solutions being built from scratch. We appreciate the clients who come to us and want to use Drupal; they’ve done the research and know they want to leverage existing functionality. They know their solution is already there, ready to go, with much less time and money for the execution.
This is what we see as the biggest draw, and what keeps people there—we’re not going to be paying for every single component. In the SharePoint setting, which was the closest thing to a CMS which Microsoft had in the past, people often began seeing it as a good solution for a website. It is often an intranet tool similar to a website, but, if I wanted something as simple as a calendar, I would have to pay for it.
The next most common thing people are looking for is relief from their IT department. Much of the adoption of Drupal has been driven from the marketing side and the content teams, as well as by leadership wanting to see those teams be autonomous, and be able to increase their velocity of publishing. This is heavy on the decision-making side of things, and, in many cases, the publishing scenarios change significantly. Businesses can often eliminate their need for an engineer (even low-level) to deal with HTML and other technical elements of that nature, in order for information to be published to the web. Simple press releases or other documents which government agencies and corporations have to maintain on a regular basis, can easily be published by a variety of resources. Dependence on the IT department within the standard publishing workflow is removed, and the power put into the content team’s hands.
Is there anything which people should consider when choosing a platform, be it Drupal, WordPress or another CMS?
What it is they’re using the CMS for—is the language it was built on, or something they’ve had in-house expertise and history with? In some cases, we’ll see state government entities which are fully happy and have a simple use case, effectively removing the administration of the website from the IT’s hands, and putting it into a maintenance mode and content editors. However, there are others who want much more sophisticated scenarios, serving multiple countries and languages.
If possible, customers should know the tool’s capabilities out-of-the-box, and look at how they’re hoping to manage their needs in the future, whether outsourced or in-house—what the delta between the current level of comfort and what would be needed to truly carry out the vision is, and what the level of comfort with the incumbent team is, at the moment.
It’s also important to consider that since the functionality is open source, it is possible that over time, maintenance would cease or wane for specific functionality, and they may not have the support of the maintainer for free anymore. This is normally because there was a reduced need. It’s effectively crowd behavior, so, if there are a number of use cases for a bunch of customers which need such a thing, it will normally be well-maintained, while a small need will most likely fall off the radar screen of the maintainer, being eclipsed by more current ones. Therein lies the reality which people have to incorporate into their strategy.
Could you provide an overview for Drupal, and who the best client of the platform is?
Drupal has been around for 17 years now. Since then it has evolved considerably and now is aligned with other Object Oriented programming principals and is leveraging other PHP frameworks like Symfony in its latest version. As far as who the best client for the platform is, basically any entity with a volume of content to manage. We will be involved in use cases where the client seeks a more app like instantaneous experience thus employing AngularJS, React or whatever other flavor of framework. While these are great choices, it is still highly relevant to use Drupal as the CMS. As if one seeks the user friendly editing experience that along with multilingual functionality, or data storage and management or integration of 3rd party services will all need to be created by hand.
Simply put, Drupal is a tried and true workhorse of Content Management. It puts the power of organization, easy-editing and publishing, workflow, approval and other mechanisms which provide sophisticated teams with the ability to create content within their templates, and maybe even move some components around on the page, in the hands of the non-technical user.
The Drupal platform itself has a long history, multiple use cases and a huge community of people using it, with similar needs. It’s a powerful resource to rely upon for a low-cost or free solution (other than hosting and maintenance), to address a need. It covers most people’s needs, outside of more sophisticated web applications, which require more robust and flexible technologies such as Java, for making something custom from the ground up.
Are there any user or company types to which you wouldn’t recommend Drupal to?
In terms of who might want to avoid it, if the client does not have a large amount of content, and is just looking to get an agency website out there, or some sort of small, brochure site, and they have some technical skills, there are certainly better options out there. These options will provide better performance and possibly more elegance, which will incorporate more modern frameworks, providing the user with an experience they might have been used to on their phone.
Is it necessary to have a technical background, on the client’s side, in order to have a Drupal website?
No. They do have to be willing to educate themselves to a certain extent, to know their goals for the tool, and then impart those to the technologists being engaged (internal or external), in order to have their vision be carried out.
This is a problem in the Drupal world, people may be aware of some of the points I’ve made already—Drupal is a free platform, it allows for faster publishing without involving the IT team, and so on—but, there is necessary setup and configuration, at a minimum. If businesses haven’t defined their budget, if the requirements are not clearly thought through or defined, if the business does not understand what it will take to execute their vision and actually meet their requirements, or if the client is not educated enough to understand the product and its abilities, it’s possible they will not be successful. It’s important that there be some discussions in the sales process, from the technologists or in the internal development environment, and that the client asks what it will take. The developer can then understand the need and estimate the process.
There are too many cases when people don’t do these foundational steps, but expect to have their intended result in the end.
Could you talk more about the Drupal community?
Last I checked, it’s a million strong, with approximately 50,000 core developers working on the product on a regular basis, around 40,000 contributed modules for Drupal 7, and a lesser number for Drupal 8. Much of the functionality identified across Drupal 7’s lifetime is still in effect, and has been merged into the core product, which explains the difference in module numbers. This is better in the long run, but it’s certainly more challenging for the development and business communities, the latter of which being beholden to the former.
Drupal 8 has effectively gone through an entire rewrite, and shifted its architecture from procedural code, to object-oriented. It has incorporated a PHP library known as Symfony, which allows more rapid development of sophisticated features. Many of the 40,000 modules did not have a strong use case to be recreated, and, given the inertia, adoption of Drupal 8 is not as popular as it was at the start of the Drupal 7 days. There is definitely a big shift required from 7 to 8, so people are looking at the effort involved in it.
The community is certainly responsible for the product in its entirety, both the core package and the add on modules which effectively make it possible to execute most use cases. If we don’t have those contributed modules, we have to build those functionalities custom, which is something the Drupal 8 adoptee needs to be ready for.
Could you talk about some security practices for Drupal?
In terms of security, the Drupal community is diligent about keeping functionality up-to-date and free of vulnerabilities. There have been some issues, and a tendency to blame open-source technology, or the application layer (which is what we’re speaking about when we refer to Drupal); in the end, many past issues were found to be residing on the server level. It’s important to remember that the website is living in a home—the server. If it’s not up-to-date, and different patches are not in place, there will be vulnerabilities. If the application isn’t being maintained, and is out-of-date with security patches or updates, there will again be vulnerabilities.
It is imperative that website owners allow for the proper maintenance budget of the free application and server software. Normally, Drupal is run in a LAMP [Linux, Apache, MySQL and PHP] environment, which are all free technologies, but need to be maintained. Both the Linux and the Drupal communities do an excellent job of maintaining minimum security requirements; in other words, we’re keeping these applications safe. If the owner fails to update and maintain them, they are the only one responsible.
Beyond this, all websites should be developed following known best practices for web security, such as implementing the basic mechanisms to prevent intrusion and bots, and utilizing captcha technology and things of that nature to prevent unauthorized users from accessing the site. These are the first line of defense, and, from here, we can begin deploying firewalls and things of that nature, or go to a cloud provider (for Drupal, we have Acquia and Pantheon, as well as AWS, with the help of an engineer).
All of this will generally keep an application within health. I can say from experience, because I’ve worked with public entities under security requirements, which were scanned by third-parties on a regular basis, as long as those requirements were met, the audits passed.
Are there any features or aspects of Drupal which you think are impressive?
What I find worth mentioning, and should be included in this interview, is that the latest version of Drupal, D8 is friendlier to and more frequently being utilized as a headless backend, as it’s commonly referred to. This speaks to a bit of the use case I was mentioning before, where major entities such as Princess Cruise Lines and Disney are using Drupal on the backend, as a content repository, and are connecting it to the frontend of their choosing (be it AngularJS or ReactJS), to create these wonderful, modern experiences, while also having a tried-and-true workhorse on the backend for things like multilingual content editing, permissions, segregation of different content-administrator hierarchies, and so on. All of this is out-of-the-box for Drupal, therefore makes for much more minimal, custom frontend needs. Additionally, once the ability to manage content in an efficient way, and the modern frontend experience are in place, we can also integrate third-parties, such as a customer relations management platform like Salesforce, and legacy product databases from major manufacturers with thousands of records.
Are there any parts of Drupal which could be improved, to make it a better CMS?
There is always room for improvement, and it’s all about the community. This is a non-profit association managing a community of a million people donating their time. This in itself will create a situation of needing to continually evangelize and monitor, as any large organization would do, and it naturally creates a lot of challenges, since many people are donating their time, while others are seeing Drupal as the vehicle for their business. The situation is ultimately positive, since people do realize the amount of value being provided, and are finding the talent to bridge any gaps left open by the volunteers.
We have 5 additional questions. For each of these, we ask that you rate Drupal on a scale of 1 to 5, with 5 being the best score.
How would you rate Drupal for functionality and available features?
Drupal – 5
How would you rate Drupal for ease of use and ease of implementation?
Drupal – 3
People say it has a high learning curve.
How would you rate Drupal for support, as in the response of their team, and the helpfulness of available resources online?
Drupal – 4
It all depends on who can provide the needed answers. Overall, support information is constantly being updated, and the community is responsive.
How likely are you to recommend Drupal to a friend or colleague?
Drupal – 5
How would you rate Drupal for overall satisfaction?
Drupal – 5