The people I've worked with have asked me all kinds of questions about Drupal over years. Questions like "What is Drupal?", "What's Headless Drupal?", "What are Drupal Security updates?", and "What does Drupal contrib mean?", amongst other things.
This FAQ is a (growing) list of my responses to those questions, in no particular order.
Table of contents
Drupal is a free content management framework. It's written in PHP, and is used to power millions of websites worldwide.
Since 2001, Drupal has gone through eight major versions. It's current stable version is Drupal 8.6.44, as of late 2018. Drupal 9 is in active development but has not yet been released.
In 2000, Hans Snijder and Dries Buytaert created a small internal news board to keep in touch across college dorms. Later, when Dries graduated and left his dorm, they put the site online. "Dorp.org" seemed to be a good choice for the domain name because "Dorp" means "Village" in Dutch. However, when Dries was registering the name, he mistyped. So, instead of registering "dorp.org", he registered "drop.org". The word "drop" in Dutch is "druppel". Change it up a little and you have "Drupal".
Further reading:
Quite a lot of people use Drupal. Some big name websites too. Websites like...
Further reading:
Because Drupal is open-source software, no one entity creates the Drupal software. Instead, it's improved and maintained by the Drupal community.
The Drupal Community consists of over 1 million people who all bring their own set of skills to the project. Some people in the community are internet security experts. Others are front-end specialists. Some are designers. Others are strategists, trainers, and coordinators. They're diverse crowd, but together they work on the shared goal of improving and fostering the use of Drupal around the world.
Further reading:
Drupal is written in PHP. It can run on PHP versions 5.5, 5.6 and 7.0. However, these PHP versions are discouraged. The recommended versions of PHP for Drupal are 7.1, 7.2, and 7.3.
Further reading:
Well, nobody and everybody (kind of).
Drupal is "licensed under the GNU General Public License, version 2 or later. That means you are free to download, reuse, modify, and distribute any files hosted in Drupal.org's Git repositories under the terms of either the GPL version 2 or version 3..."
Dries Buytaert — the founder and project lead — owns the Drupal trademark.
Further reading:
DrupalCon is short for Drupal Conference. It's an event that brings together people who use, develop, design, and support the Drupal platform. Attendees spend the (typically) five days in educational sessions, networking events, and coding in code sprints.
Past DrupalCons:
| Year | City | Country | Attendees |
| 2018 | Nashville, Tennessee | United States | 2,899 |
| 2017 | Vienna | Austria | 1,670 |
| 2017 | Baltimore, Maryland | United States | 3,271 |
| 2016 | Dublin | Ireland | 1,787 |
| 2016 | New Orleans, Louisiana | United States | 3,102 |
| 2016 | Mumbai | India | 1,025 |
| 2015 | Barcelona | Spain | 2,039 |
| 2015 | Los Angeles, California | United States | 3,186 |
| 2015 | Bogota | Colombia | 263 |
| 2014 | Amsterdam | Netherlands | 2,300 |
| 2014 | Austin, Texas | Unites states | 3,357 |
Further reading:
According to Drupal's usage stats, there are 1.1 million Drupal 7 sites and 185,000+ Drupal 8 sites in the wild, as of December 2018.
Note: Only those Drupal websites that use the Update Status module are included so these statistics are incomplete.
Further reading:
Drupal is good. But it's not the only platform we can use to build websites and web applications. There are hundreds to chose from. However, they all have their own strengths and weaknesses. Chosing a web platform depends on the use case.
For some cases, Drupal might be a better choice than WordPress, for example. For other cases, Craft CMS might be a better choice than Drupal. It all depends on the purpose of the site, the budget, and the availability of development resource etc.
In my experience, Drupal alternatives usually come down to WordPress, Craft CMS, Shopify, and Backdrop CMS.
WordPress is a free, open-source content management. It's based on PHP and MySQL. It has a plugin architecture and a template system. It's mostly used for blog websites but can be "bent and shaped" to other uses, like online stores, single page web applications, and community sites.
Thanks to it's ease of use and it's huge community, WordPress usage across the web is staggering. Builtwith.com reports over 22 million websites running on WordPress.
WordPress is a great choice for many websites. But do be aware of it's security governance model.
WordPress security is often an issue for people who might be considering WordPress over Drupal. Why? Well, the WordPress security team looks after the security of WordPress core. The Drupal security team, on the other hand, looks after the security of Drupal core and all stable contrib modules and themes. This is one of the reasons why hackers seem to like WordPress. Securi illustrated the WordPress hacking issues very well in their 2017 hacking trends report.
Further reading:
Craft CMS (by Pixel & Tonic) is often considered a very good WordPress alternative. It's not the site builder that WordPress is, as there's not such thing as a craft CMS theme. The entire front-end — the HTML, CSS and Javascript — is all "crafted" by hand. This is one of the reasons why it's quickly becoming the favourite of a lot of development agencies and developers who build (maybe) less "enterprise-type" websites.
Further reading:
Shopify is a proprietary e-commerce platform for online stores and retail point-of-sale systems. Shopify offers online retailers of a suite of services "including payments, marketing, shipping and customer engagement tools to simplify the process of running an online store for small merchants.
Builtwith.com reports over 700,000 current sites as running on the Shopify platform.
Shopify comes with monthly fees and sales fees but is a very sold, trusted platform for sites that focus on e-commerce sales.
Shopify has a plugin marketplace but the front-end themes are generally developed by developers and agencies.
Many of the Drupal sites I've seen that attempt to do e-commerce might have been better served on Shopify.
If the focus of a site is online product sales (with maybe a blog), Shopify is a very good alternative to Drupal.
Further reading:
Some people didn't like the changes introduced with Drupal 8. So much so that two well-known people in the Drupal community — Jen Lampton and Nate Lampton — "forked" Drupal, gave it a new website, a new contrib platform, and then took this forked version of Drupal off in a completely different direction. They called it Backdrop CMS (see below).
Further reading:
Backdrop CMS is a fork of the Drupal project. It's generally considered a good option for companies who have Drupal 6 or 7 sites but don't want the cost and complexity of upgrading to Drupal 8.
Because Backdrop CMS came from Drupal, Drupal modules and themes can be converted to the Backdrop CMS platform relatively easily. It also uses many of the core concepts of Drupal — nodes, taxonomies, content types etc. — but it certainly wants to be it's own thing. (All references to drupal have been removed in the code and replaced with backdrop.)
Although Backdrop CMS markets itself to the smaller sites, it's totally capable of powering the huge sites that Drupal 7 has powered for years.
Further reading:
All software contains bugs. However, not all software bugs are visible. Some are very difficult to identify and some may only reveal themselves in very specific circumstances. Security bugs — or security vulnerabilities — are much like this.
A security vulnerability is type of software bug that a hacker might exploit to gain access to any number of resources — code, database, infrastructure etc. Think of a security vulnerability as simply a hole in a piece of software that nobody knew was there.
Once a security vulnerability is identified, it's simply fixed in code and then rolled out. The actual technical term for a security fix is a patch. Easy to remember: security patches fix security holes.
Software is being patched all the time. When you update a Windows PC, you're probably applying security patches. When you update your SmartTV, you're probably applying security patches. When you update you phone, you're probably applying security patches.
In fact, the iOS 12.1 update, released on October 30, 2018, contained a number of security patches. Here are just a few of those patched vulnerabilities.
| Component | Vulnerability |
| AppleAVD | Impact: Processing malicious video via FaceTime may lead to arbitrary code execution |
| Contacts | Impact: Processing a maliciously crafted vcf file may lead to a denial of service |
| FaceTime | Impact: A remote attacker may be able to leak memory |
| Messages | Impact: Processing a maliciously crafted text message may lead to UI spoofing |
Drupal is exactly the same.
A Drupal security update is simply a patch (or patches) that fixes a security hole. The only problem with Drupal security updates is that (generally) only a developer that can apply them. This is because a patch needs to be reviewed against your specific site to ensure it doesn't break anything. It's quite rare for a security patch to break a site but it can happen. Thorough testing in a separate environment is recommended after every security update.
Further reading:
Drupal is very secure, so long as you...
The hacked sites I've seen over the years have mostly been because security updates weren't applied. But why are out-of-date sites a target to hackers? How do people even know if your site is out-of-date?
It's usually pretty easy to see if your Drupal site can be hacked or not. If you have a few minutes, try this. Go to your homepage, add CHANGELOG.txt to the URL in the address bar and press enter.
http://yourwebsite.com/CHANGELOG.txtIf you get a page not found error, great. If you don't, you might see a file that looks like this.
Drupal 7.57, 2018-02-21
-----------------------
- Fixed security issues (multiple vulnerabilities). See SA-CORE-2018-001.
Drupal 7.56, 2017-06-21
-----------------------
- Fixed security issues (access bypass). See SA-CORE-2017-003.
The item on the first line tells anybody which version of Drupal your site is runnning.
In this example, I can that the site is running Drupal 7.57 instead of the most up-to-date version, 7.61 (as of January 2019). Because it's running on version 7.57 I know from the Drupal security advisories which security holes are present, because I can see which security patches were released for later versions.
The hacker, once she knows the version of Drupal you're running, can then simply go to http://exploit-db.com to find out ways how she might get into your site. If successful, the result is a hacked Drupal website.
Websites are also hacked because of weak CMS user passwords. If there's an account on your Drupal website whose credentials look like this...
id: admin
password: password
...it's probably only a matter of time before your website is hacked. This example may seem silly but you'd be surprised how many times I've seen this exact thing.
How to fix weak passwords? Do a review of your administrator and editor accounts. Look at the email addresses associated to those accounts and either block the accounts or remove them.
There a pretty handy module for Drupal that you can use to strengthen user passwords by enforcing password policies. See Password Policy on drupal.org for more details.
Drupal 7 will be supported until November 2021.
This doesn't mean that all the Drupal 7 sites will just stop working, or anything catastrophic like that. It simply means that the Drupal security team will stop releasing security updates for Drupal 7 after November 2021, along with some of the underlying technologies like PHP versions etc. Drupal 6 is no longer supported but there are still plenty of Drupal 6 sites knocking around.
You'll see a strange thing in the timeline image above: Drupal 8 will also hit End of life at the same time. This is because, now that Drupal 8 depends on the Symfony framework, Drupal releases are needing to fall into line with the Symfony roadmap.
So what do you do with your Drupal 7 site? Well, you have some options.
1. Stay on your Drupal 7 site but engage a paid long-term support partner after November 2021.
This is feasible and it will keep you covered, from a security update point of view. However, less and less people will be developing on Drupal 7 as time goes by. You'll find it will become quite difficult to find somebody to do the development work you may need. Not a great option, really.
2. Migrate to Drupal 8 over the next year / 18 months, and then follow the Drupal 8 to Drupal 9 upgrade path.
For companies who know that Drupal is the best platform for them, this is probably the best option.
3. Consider moving to another platform.
Here are some good Drupal alternatives.
4. Migrate to Backdrop CMS?
We just need to look at the growing collection of Backdrop CMS modules to know that it's a very strong alternative to Drupal 8 for many companies. Migrating from Drupal 7 to Backdrop CMS is likely one of the cheaper options.
Further reading:
It's important to know that there's no upgrade path from Drupal 7 to Drupal 8. So a "Drupal 8 upgrade" is not technically an upgrade. It's a rebuild, along with content and user migration. This is because Drupal 8 is essentially a different software application than Drupal 7.
The correct question to ask is really, "Should we rebuild on Drupal 8?". Not upgrade.
There are many good reasons why you would rebuild. There are also many good reasons why you wouldn't rebuild. It's a difficult question to answer, as it depends very much on your specific situation. The best thing to do is to get some advice, but not from your current agency or developer. Independent advice would likely be a bit more objective.
Further reading
In most cases, yes. And often quite easily — with caching.
A cache is a temporary, hidden storage area (cache is the French word for "hidden"). Caches are used for quick data retrieval. The "low hanging fruit" when looking to improve the speed of a Drupal site is generally always caching.
To understand caching in Drupal, let's consider a typical web page request.
Sarah visits your site homepage so Drupal needs to (at the very least):
That's quite a lot of stuff. But everything works out and Sarah get's your homepage in her browser. Nice.
Two minutes later, Bob comes along. He also wants to see your homepage. What happens? Well the whole process happens again. What? Even though nothing on the homepage changed? Yes. The server has to go through that rigmarole every time somebody goes to your homepage.
But wait. What if Drupal was intelligent enough to know that nothing changed on the homepage between Sarah's and Bob's visits? What if it could do all those slow computations just once for Sarah, remember what it gave her, and then just give Bob the exact same thing. In other words, give Bob an instant, albeit slightly "stale", homepage.
Well it can. This is Drupal caching.
Proper caching speeds up the user experience and takes the load of the server/s.
It's not only Drupal that caches data. Everything caches data, pretty much. Amazon, Twitter, FaceBook, Instagram. They all cache data. They have to. If they didn't, their sites would grind to a halt and their servers would likely explode.
There are many other things that can be done to improve performance — database indexes, code refactoring, server tuning etc. But most Drupal sites can see major performance improvements simply by setting up a good caching configuration.
Further reading:
Drupal is very good at connecting with third-party business applications. Although integrations number in the hundreds, some more common example Drupal integrations are:
This suite of modules supports integration with Salesforce by synchronizing Drupal entities (E.g., users, nodes, files) with Salesforce objects (E.g., contacts, organizations, opportunities). It supports pushing Drupal data to Salesforce as well as pulling, or importing, Salesforce data into Drupal. Changes can be made in real time or asynchronously in batches during cron run.
This module integrates Shopify with your Drupal website. Your Shopify products are synced to your Drupal site in real time as Drupal entities. These product entities are fieldable, themable, and completely Drupalized. Shopify's clean and intuitive interfaces power your store's back office and Drupal is used for product display. Customers check out using Shopify's checkout workflow.
This module provides integration with Mailchimp, a popular email delivery service. The module makes it easy for website users or visitors to control which of your email lists they want to be on (or off), lets you generate and send Mailchimp email campaigns from your site, and lets you and your users view a history of emails they have been sent from Mailchimp.
The AmazonS3 module allows the local file system to be replaced with S3. Uploads are saved into the Drupal file table using D7's file/stream wrapper system.
If you use a reasonably popular business application, there's a good chance that a stable Drupal integration exists for it.
Drupal out-of-box doesn't actually come with that much functionality. It's pretty light. Drupal 8.6.5 is only 15MB. Drupal 7.61 is only 3Mb. Why so small?
Instead of Drupal coming bundled with all of the typical things a site might need, it comes as more of a foundational platform.
This is what's known as Drupal core.
But once core is installed, it then (kind of) expects a developer to begin selecting, installing and configuring the additional modules needed for the site being developed.
These modules might be image gallery systems, date picker fields, YouTube video embed systems, Twitter feed widets. The list is huge. But it's simply these available additions that are what's known as "Drupal contrib" — all the projects that have been "contributed" to the Drupal project but that are not part of core.
Here's an example of a few of the core and contrib modules and themes that might be installed on a typical Drupal 7 site.
| Module/Theme | Description | Part of Drupal core | Added from contrib |
| Comment | Allows users to comment on and discuss published content. | ||
| Field UI | User interface for the Field API. | ||
| Update manager | Checks for available updates... | ||
| Menu | Manages the blocks in the system | ||
| Shortcut | Allows users to manage customizable lists of shortcut links. | ||
| Toolbar | Provides a toolbar that shows the top-level administration menu items... | ||
| FitVids | Query plugin for fluid width video embeds. | ||
| Metatag: Facebook | Provides support for Facebook's custom meta tags. | ||
| ShareThis | Add the ShareThis widget to nodes on your site. | ||
| Shopify eCommerce | Display your Shopify store within your Drupal site. |
Occasionally, a Drupal module might become so widely used that's it's actually incorporated into core. This happened with the Views module in Drupal 8. Views is now part of Drupal 8 core; and it's one of the reasons why there's such a difference between the filesize of the Drupal 7 and 8 downloads — 3MB and 15MB respectively.
Drupal has generally always consisted of two things: a back-end system — where content is created and managed — and a front-end theme — where that content is brought out and made available to users and search engines.
This approach has served people quite well. But it does present some issues, especially in the area of Drupal front-end theming.
A developer who wants to build Drupal sites must learn Drupal theming, so as to to build the front-end theme. However, Drupal theming can only be used with Drupal. It's not a skill that can be ported to other platforms. Some see this is a "sunken skill". In addition, Drupal theming (before Drupal 8) is difficult, and a good knowledge of PHP is essential.
Another issue is that the HTML a Drupal theme produces is actually produced by PHP; and PHP is slow. So, developers often need to install and configure various caching technologies to speed things up.
Headless Drupal attempts to solve these issues — and it solves them pretty well.
A Headless Drupal site is a Drupal back-end with all it's content types, fields, users, and content etc., but without the Drupal front-end theme. It's abstracted away from Drupal. Once the front-end is abstracted, any modern front-end technology can be used, like React, Gatsby, Vue etc. By doing this, any front-end developer could work on building up the front-end, whilst the Drupal developer works on the back-end.
For this to happen, Drupal, of course, needs to make it's content available to systems that are not itself, so to speak. This is achieved via the Drupal 8 Rest API. The REST API essentially makes Drupal content available at certain URL "endpoints" for other systems to consume.
An example of a URL endpoint might be example.com/api/news/latest/10. This would return the content for the ten most recent news articles. Another endpoint might be example.com/api/users/123/first_name. This would return the first name of user no. 123. The data that each of these endpoints return would typically be in JSON format, which the front-end system could then format and display as it needs to.
As well as the obvious front-end benefits of a Headless Drupal site, there are also other benefits.
If the Drupal site is acting merely as a data store, serving data to an abstracted system, it could also serve the same data to any number of other abstracted systems — iOS apps, Windows apps, TV apps, even spreadsheets.
The full benefits of Headless are yet to be seen, but it does appear to be the future — certainly the future of Drupal.
Further reading:
If you hav e a Drupal question that you'd like to see in this FAQ, please do feel free to ask. You can email me at peter@peterbrady.co.uk.
I'm an award winning Drupal developer and consultant, helping project managers, programme managers, and marketing managers to get the most from their Drupal sites.
"Working with Peter was an absolute pleasure — thanks to his flexibility, excellent communication skills and honesty."
— LUCA RUSSO, GIVAUDAN
"Pete's vast experience and knowledge, along with being a great communicator, made him a great mentor for the development team."
— MATT WAGG, COMIC RELIEF
"I would thoroughly recommend Peter to anyone looking for a brilliant consultant/developer who genuinely cares about what he does."
— MAT TOOR, THE BOOKSELLER
"Pete has been amazing to work with, especially as we know nothing about web developing! He took over our site and has made it into something that we can use and update ourselves really easily."
— KATIE ANGOTTI, DANONE