Cloud Platform
5 Lessons from Working on Drupal 8
Now that Drupal 8 is production ready, and agencies are ready to expand their capabilities by building in Drupal 8, clients are asking about it, and the community's focus has shifted to developing for it.
Drupal 8's predecessor, Drupal 7, has been around since January 2011, which means that by late 2016 everyone working in Drupal was very familiar with the ins-and-outs of how Drupal 7 worked.
Writing modules, using the hook system and preprocess functions, figuring out templating and theming quirks -- it all became second nature to us. We'd mastered views and webforms, and some of us had written a couple of tricky migrations. In short, we'd all grown comfortable with Drupal 7 -- and then along came Drupal 8.
With the arrival of Drupal 8, many of those core components -- on which we'd built many sites, and a living -- have changed dramatically. We are now in unmapped territory, sailing in uncharted waters. In some respects we are explorers, surging forward into the unknown with all of our past experiences to guide us. If you're willing to embark on this journey, you will be rewarded with cutting-edge PHP and Drupal development practices on a much-evolved, much-improved platform.
Having recently launched my first Drupal 8 site, and a large one at that, I've identified five lessons I've learned that might help other developers get a grip on building sites in Drupal 8 and set themselves up for success.
It's fair to say that this is not specific to Drupal 8, but it's good advice when starting on any project. Over the years, I've found that it's the unknowns that slow a developer down, stall sprints, and steer projects into over budget territory.
I strongly recommend, on your Drupal 8 projects, to come up with a strategy to familiarize yourself with the unknowns.
In Drupal 8, those unknowns are mainly add-onsthose contributed modules you rely on in Drupal 7 and you just know they'll just work. Creating content types, building views, permissions and block positioning have all pretty much stayed the same.
The two questions I found most helpful in tackling those unknowns was: Does this add-on exist in the Drupal 8 version? If so, does it work the same as it did in Drupal 7? To get to the bottom of it, you could start with:
This might seem like an unnecessary step, but trust me: converting the unknowns into knowns will give you a jump start on your Drupal 8 project.
Again, this probably applies to any project, but I think it's especially relevant for developers moving into using Drupal 8.
I'm familiar with using core search, as well as Apache Solr in Drupal 7, and I've built a number of tools to help improve both types of search.
Well, little good did it for me when getting started with Drupal 8: Drupal's latest version deprecated Apache Solr search and essentially replaced everything with Search API. This, in my opinion, was a shift in the right direction and allows for a bit of abstraction on the actual search engine/server, providing more focus on what gets indexed and how it's sorted.
That said, there have been some changes to how indexes are created, and it's a bit of a paradigm shift from Drupal 7. In Drupal 8, creating indexes is a lot more flexible, which also means you should thoroughly think through how your search is going to work early on in your project and apply the lessons learned, starting with the unknowns first. It'll help you understand whether the desired functionality is possible using Search API in combination with your engine of choice, and it will influence your decisions with regard to what content types you're going to create. I also encourage you to pay close attention to your permissions matrix to ensure security of data, as well as filtering and faceting of your results.
At Domain7, I enjoy the benefit of having very smart people on my team. Through the process of building two large Drupal 8 sites in parallel, we were able to put our heads together and devise a solution for creating reusable components. It helped us build sites faster, maintain consistency, and improve the experience of creating content dramatically.
The concept is pretty simple, and was born out of us noticing repeating design and layout patterns in different content types used on various landing pages across the site. Normally, we'd just create the content type and duplicate the fields -- which invariably meant that this type of content and its parts could not be reused elsewhere on the site.
After initially tackling the problem using an Entity Construction Kit (ECK) and creating many modular components that could be inserted into any content type, we matured our approach using the Paragraphs module. Paragraphs allowed us to gain even more flexibility, particularly around versioning of content.
Here's how that works at a high level:
This allowed us to insert one Call to Action in various locations across the site, any content type and any layout (within some constraints). The end result was a significant improvement in the content creation experience for site administrators, because less duplication means a lot less content in your database.
If you want to create reusable components, start thinking about them early on in your project, around the time when you start wireframing. Make an effort to identify similar patterns across the site and convert them into identical repeating componentsor similar repeating components. It'll help you dramatically simplify your Drupal 8 build.
As developers we're always keen to keep data separate from presentation, and that can be achieved in various ways. Building sites in Drupal can be a lot of fun, and it's amazing to see a product come together so quickly. However, when it comes to updating the configuration stored in the database, things get tricky to say the least.
Prior to Drupal 7, it was impossible to just version your database when you had a large team working on a project. And you can't expect a client to do a content entry freeze every time you want to make some adjustments to configuration. This was somewhat resolved in Drupal 7 using the Features module. However, Features was not built to actually do config management. It was created to allow you to move a feature from one site to another, as in, "I like this blog we created, let's use that somewhere else."
In Drupal 8, this aspect has been improved and expanded upon with the introduction of configuration management. Configuration management is for moving your site from one environment to another. Almost every setting in the database can now be exported to code, versioned and then imported to the production website, without the need for a content freeze. It's an amazing and revolutionary upgrade to the deployment and maintenance processes for Drupal sites. You can now wrap up your changes in code and deploy them as needed. There is a small caveat to this: all developers working on the project have to be familiar with the system - as well as the process of working with configuration to ensure that they are always in sync with the current configuration.
Prior to Drupal 8 you could get by, and even excel, at building a Drupal site using procedural PHP and the hook() system. This has all changed in Drupal 8.
With the introduction of the Symfony framework, Drupal comes with a stable base of reusable components that don't need to be maintained as part of the main Drupal project. Because Symfony is an object-oriented framework, Drupal has changed considerably to ensure it can run on this framework. It's pretty safe to say that you'll need to be comfortable with object-oriented development patterns before you decide to write modules for Drupal 8. Some of the benefits of moving into this type of framework is that Drupal can now leverage the power of Symfony, as well as other outside Drupal contributions. It also means that Drupal is now less forgiving of poorly written code. Developers will need to adhere to standards like PSR-4, the standard for namespaces, as well as employing annotations to make their code discoverable.
Another significant change is the introduction of the Drupal plugin architecture. A plugin can be described as a discrete class that extends Drupal's functionality within the context of a given scope.
In Drupal 7, plugin functionality was somewhat achieved by implementing multiple info hooks when creating modules. Drupal's new plugin architecture does one thingand does it well. Some components that are now plugins in Drupal 8 are blocks, field types, field widgets, field formatters, and input filters. With the benefit of object-oriented programming (OOP) it's also possible to just extend existing plugins when creating your own, without the need to build them from scratch. This also means that your plugins can be reused across different projects.
It may appear daunting to jump into a Drupal 8 project for a big client project, and to some degree you will probably have to adopt a mindset of feel the fear and do it anyway. But I promise that in the end, taking the leap will be a rewarding experience. Even though module compatibility hasn't fully matured, there's enough in Drupal 8 right now to solve your biggest problems. And like I said earlier on, you'll be rewarded with a site that is using cutting edge PHP and Drupal development practices, on a platform that is in active development, experiencing huge leaps forward with each release. It's a great opportunity to improve and expand your skillset, while being part of the next group of developers on their way to becoming Drupal 8 experts.
For your monthly dose of though-provoking and useful reads about design, tech and meaning, sign up for Domain7's email.
Cloud Platform