At Designzillas, we've been a Drupal web agency for quite a while. For years, we’ve been developing websites in the platform, much to the delight of our development team and our clients, who both appreciate its high-performance and user-friendly back-end experience. And with Drupal 6 going end-of-life (or in other words, being discontinued), it felt like it was the right time to tackle Drupal 8.

Instead of developing in Drupal 8 for the first time for a client, we decided to try it out internally first to limit the amount of risks and have more creative freedom in regards to pushing the limits of the platform. This allowed us to become more fluent in Drupal 8 while giving us the freedom to design and develop whatever we wanted in order to test the capabilities of the platform.

With the release of Drupal 8, along came an entirely new templating engine based on Symphony components. The system uses Twig instead of PHP in templates, which encourages the developer to keep the functionality of the site where it belongs—in modules, not in the theme. More on this later. But for a long time, Drupal was in an uncertain place trying to figure out how much of the contrib (user contributed modules that extend functionality) should be brought over to the new core engine and what exactly their focus should be moving forward.

With the launch of Drupal 8, the company announced that this may be their last numbered version of Drupal—eliminating any remaining uncertainty about their future. This, along with our desire to learn more about the platform, convinced us to jump into Drupal 8 as this is likely how it will look and feel moving forward.

Drastic Differences Between Drupal 7 and Drupal 8

To be honest, Drupal 8 is completely different. But let’s explore some of the key differences between the two versions.

Out-of-the-Box Content Entry

Drupal 8 has a WYSIWYG editor built in and is ready for content entry right away, much like Wordpress. Additionally, the authoring experience is 100x better.

Here’s a screenshot of our article editor. As you can see, Drupal 8 has a robust wysiwyg editor and can support several custom fields.

Everything is Mobile First

Including admin themes. We design mobile first to ensure that the mobile user experience is perfected prior to moving to desktop, so this feature saves us quite a bit of time.

Support for More APIs

Drupal 8 supports many powerful APIs that can make the backend experience much more user friendly. In fact, you could build an entire site in Drupal 8 and never actually have to login to Drupal to make changes. But apart from back-end UX, this support will be most useful for feature-rich mobile applications.

You Can Add Fields Everywhere

You can add fields to nodes, blocks, forms, taxonomies, etc. Basically anything you have access to you can add your own custom fields. And there are way more field types to choose from that are built directly into core, so less contributed modules are needed when compared to Drupal 7, giving you many more options and much more power right out of the box.

Twig Templating Engine—More Object-Oriented

Instead of using raw PHP for templating, Drupal 8 now uses Twig—a variant of HTML—which separates all but the most basic logic and database interaction from the view. This creates a much more MVC-inspired application, where the Twig templates are just HTML output and we’re dropping variables in.

MVC (Model-View-Controller) is a design methodology that simply separates the different parts of an application (in this case, the website) into three layers.

The Model layer is where the data lives. The View layer takes the Model layer's information and presents it cleanly. The Controller layer is where input is taken, in this case where a user inputs website data. By keeping each layer separate, debugging any one layer is far simpler and updating one layer does not negatively impact any other layer. It's just cleaner than many other methods and more maintainable.

Anything more complicated than that has to be done through a module—which is a good thing! It keeps everything clean, makes the code much more accessible and the website more maintainable as you no longer have to dig through different templates to find certain architecture, you can simply look at the module.

All of this allows you to keep functionality in the module rather than the template. This is faster and in many ways much more secure, mainly because you can’t put PHP directly inside content areas.

Routing a Part of Core

No more aliases! You set up routing in the backend for every entity, node and taxonomy, and tell the system how you want to access data and what’s controlling it. It’s a very, very robust system that is more than little terrifying for first-time users. However, it has a lot of power and became incredibly useful for us when manipulating taxonomies. All of the author data on our site is taxonomies and it took some complicated routing to get the things we needed.

It’s Much Faster

Drupal 8 performs much faster than Drupal 7 and eventually we think that Drupal 8 will allow us to develop faster as we learn the ins and outs. While the platform itself is much snappier, we have yet to see any impact on website performance. But, we believe that we can create a better, more efficient Drupal web designs at the end of development. Having individual caches per block helps things move a bit more quickly as well.

Biggest Problems With Drupal 8

Webforms

Why are Webforms not in Drupal 8 core?

Unfortunately, it was decided that the contact module was the way to go for Drupal 8 core. This module works fine if your form needs are very simple and basic, and you don’t need to store the messages that are sent through the forms. But I would have preferred the much more powerful Webforms module in core—or at least the Webforms Module available for Drupal 8. Thankfully for this project, it wasn’t a huge problem, but with future builds we’re hoping that this functionality is available soon, otherwise we’ll have to address it in-house.

We’ll be eagerly refreshing this page waiting for a Drupal Webform module.

Also, views is now in core but it behaves much differently than it’s Drupal 7 predecessor. Not necessarily a problem, but an adjustment to be aware of if your team is adopting Drupal 8.

When we began, Drupal 8 wasn’t very stable and there were drastic changes in the beginning in the way you would call certain field types inside templates. However, it is much more stable now and we’re confident this won’t be an issue moving forward.

Looking Forward

Overall, we loved creating Drupal web designs in in Drupal 8 and we’re excited to use the platform for more projects in the future. There was such a big change from Drupal 7 to Drupal 8 that we hope that it eventually just becomes “Drupal,” and we’re confident that we can start using Drupal 8 for new projects moving forward.

However, if your website is currently built in Drupal 7, we highly recommended you work with a Drupal agency that has plenty of experience with the platform. While on the surface it might seem like a weekend project, it may become incredibly complex depending on the size and functionality of your site.

Conclusion

Even though there were many changes between all the different versions of Drupal (with many headaches along the way), we’re excited to kickoff a fresh round of projects with a powerful new CMS that we look forward to working with for years to come.

Hearing about growth-driven design for the first time? Learn more about the three pillars of GDD and how this methodology can help you solve your greatest marketing challenges.

Download FREE E-book