Drupal 7 vs. Drupal 8 : What difference does it make?

Introduction

Drupal is one of the popular CMS platforms and remains one of the top picks for government websites. Analyzing the difference between Drupal 7 and 8, two different versions can give insights about where they each stand in the typical considerations of a project manager like staffing, the flexibility of content management, website performance, maintenance and build speed. Read further to know the differences between Drupal 7 and 8 in detail.

Drupal 8 has been an architectural sea-change from Drupal 7 and had been five years in the making. Comparatively, Drupal 9 is a much more incremental change over Drupal 8. In this article, we explore the question “What difference does it make to a project manager, if the site is built in Drupal 7 vs. Drupal 8?”

The Typical Considerations of a Project Manager

When evaluating a website build project on Drupal 7 vs. Drupal 8, a project manager or a business owner (more generally) would be concerned with a few key things:

• How easy is it to staff for a project? Is the skill set very niche or more broadly available? When the team members leave the project or the company, how easy is it to hire and bring on new talent quickly? How easy is it to ramp them up so that the customer doesn’t see a deterioration in quality?
• Does it take any longer to build in Drupal 7 vs. Drupal 8?
• A key component of client satisfaction is the ability to add and update content on the website easily. Is there a difference in this regard?
• Finally, how easy and cost-effective is it to maintain the site for the long-term? Will it be easy to upgrade and address security vulnerabilities?

Staffing the Project Team

When looking for people to build up your team, if you planned on creating a Drupal 7 team, you had to go and look for Drupal 7 specialists, for either front-end, back-end or full-stack. The Drupal web developers were a breed of people that specialized solely in the peculiarities and idiosyncrasies of the Drupal platform. However, building a team around Drupal 8 is a more flexible task. Consider the following:

• Since Drupal 8 runs Symphony under the hood, it opens the possibilities of hiring from an entire marketplace of PHP developers
• Since the front end also inherits from well-established technologies like Twig and new concepts like decoupled CMS, Drupal 8 development teams can be composed of members from different backgrounds.
• The entry-level is not anymore some niche concepts and technologies, but rather a well-rounded set of industry-standard technologies.

If you look at the Drupal 8 tech stack below, you will see that very few of them are Drupal specific.

Front-End developers:

• SASS and LESS for CSS and media queries
• HTML5
• Twig templating engine
• Theming experience
• Client-side state and event-driven programming for decoupled interfaces
• Javascript, jQuery, Drupal Behaviours

For Back-end developers:

• PHP OOP concepts like dependency injection among others Symphony experience
• MVC, decoupled interface, REST and CRUD API models
• Knowledge of Composer dependency management
• DRUSH and Drupal Console
• MySQL or MariaDB

Finally, the learning curve has been flattened by Drupal 8’s architectural standardization which makes it easier to replace any team position with minimal training overhead.

Ease and Flexibility of Content Management

WYSIWYG editor: The ability to add images into the body of articles, or change the fonts and distribution of the paragraphs, even simple tasks such as inserting links or tables — all of these require a WYSIWYG editor. Installing and configuring this was quite a daunting task in Drupal 7. In Drupal 8, this comes pre-installed. Also, the new WYSIWYG implementation has several bug fixes that make it more stable.

Media formats and file handling: Drupal 7 needed you to install a group of unrelated modules to individually create and manage things like images, videos, aggregation, and social media feed, In Drupal 8, the concept of “media types” centralizes everything related to those tasks. In one fell swoop, the media types core module allows us to implement any of the above, and control their behaviour from a single place. To achieve this, it uses plugins for each type, so setting it up is just a matter of pick and choose.

In-place editing: Was simply not possible with Drupal 7 until very late in its life cycle. Also, its implementation ended up causing many conflicts in the UI and adhoc bugs. In Drupal 8, the functionality to go to any part of the site and edit its content “in-situ” comes pre-installed out of the box. Content managers no longer have to do cumbersome searches in the admin panels to find the content they need. They simply go to the URL while logged in, and the edit icons will appear.

Internationalization: Has long been a complicated business to handle in Drupal 7. With Drupal 8, however, many translations are available for Core and admin with the initial install. Multilingual content is now a given, as all the functionality is included in Core. You can see this article for more on the subject.

In summary, Drupal 8 is far better and easier for content managers.

Website Performance

The site has to run fast. This is a major consideration for project managers because the clients demand it. Not only is it essential for user experience and conversion rates but it has a tremendous impact on SEO ratings as well. It is “common knowledge” that Drupal 8 runs slower and consumes more memory than Drupal 7 when benchmarked on “blank” installs. What is essential to understand is that an actual, live, customer-facing project does NOT run straight off the Drupal server. They tend to use a plethora of technologies to enhance performance: Content Delivery Networks, Cache Strategies, Aggregation, Minification, Compression and Reverse Proxies. After these typical strategies are implemented, Drupal 8 compares fairly with Drupal 7. To go beyond, Drupal 8 has few aces up its sleeve, that contribute to better performance:

• It is much easier to constantly update content and push to production in Drupal 8. This is especially important for content-intensive sites such as news sites. Drupal 7 has limitations due to its architecture – specifically how Content Delivery Networks and Reverse Proxies work and the conflicts that can occur. Drupal 7 has no direct solutions for this problem, while Drupal 8 has a mechanism specifically designed to treat these situations : “Cache Tags” — that signal what content needs to be refreshed.
• Another place where Drupal 8 gets the upper hand is dealing with logged-in users. These usage scenarios — forums, user spaces etc. –are hard to make performant because they depend on user-generated information that cannot be cached. In Drupal 7 there is no compensation for this. In Drupal 8, however, a particular type of cache works on the logged-in page, letting through to the server only those little parts that cannot be cached.

In general, website performance is a complex topic, and you might find it useful to read our 10 ways to speed up your website.

Is it faster to build in Drupal 8?

This is a complicated question. Many variables can make a project go slow or fast. There are a lot of considerations:

• How responsive is the client?
• How quick are they in approving the designs?
• How easy is it to build the designs?
• How robust is the CMS?
• How much data and content is there to upload, migrate or create?
• And many others.

The specific places where a CMS contributes to project speed are :

• How easy is it to set up?
• How easy is it for multiple developers to work on simultaneously?
• How well does it play with DevOps?
• How robust are its CI/CD capabilities?
• How easy is it to do reusable component-based design?

Drupal 8 shines in all these regards. It is much easier to set up because there are far fewer steps. Drupal 7 takes more work when placing code of modules and library resources — because it has to be either done manually or through a bootstrapped drush. On Drupal 8 it suffices to run Composer “require” commands. Also, it is important to note that Drupal 8’s command line based process allows us to automate the entirety of the DevOps processes. This, in turn, makes Drupal 8 compatible with most modern deployment methods like CI/CD and Ansible Workflows. For a deeper understanding of CI/CD and WebOps, you might find our Acquia vs. WPEngine article helpful.

Ongoing Maintenance

Consider this scenario: You have launched your Drupal 7 project, everyone on your team did a good job, and the new site is live, you celebrate! Six months down the road a huge vulnerability is discovered, many sites including yours are affected. So you scramble to get a task team of developers to work on your site. But when they try to implement the patch, they realize a library — that several modules depend on — conflicts with the changes required for this patch

To secure your system, you have to update the patch, then upgrade the modules, and re-install their configurations manually. But wait, once you did all that, now the theme of the page is looking odd! Did we just remove the gallery slider library in that last update? Or is our custom template not compatible with the new jQuery version required by the patch? This can very rapidly become a nightmare! In Drupal 8, since all dependencies are managed via composer, the entire profile of versions — for every module, theme, library and plugin — is available and controlled through a centralized JSON file. All you have to do is to request the appropriate changes to this JSON composer file. Minimal fuss!

Although the above scenario was focused on security, ongoing maintenance requires us to make constant changes to Themes, Modules and Core regularly. In Drupal 7, we need to manually keep a list of libraries and dependencies that will require to be changed. This is hugely cumbersome. In Drupal 8, we simply manage our requirements via the composer CLI (Command Line Interface). By using composer to manage our dependencies from the get-go, all the intermediate steps and considerations of updating and upgrading are handled behind the scenes.

Conclusion

Working on a Drupal 8 project has gotten a lot more flexible in terms of provisioning a team, giving content management crews what they need, implementing a distributed architecture, and managing the project after it goes live. While Drupal 7 has had a great run, everything the Drupal developers learnt from its community-powered evolution has been applied into Drupal 8 Core. If you are a seasoned project manager with Drupal 7 experience, you are in for a treat seeing how most of the pitfalls of Drupal 7 projects are neatly plastered and painted over with Drupal 8.

References

• If you are looking at migrating from Drupal 6 to 8, you might be interested in our article on migration considerations.
• If you are interested in Drupal, we did a great piece on component design in Drupal, which you should check out.

‍