Happy New Year! 2020 was… well… let’s just talk about 2021. There’s a lot of exciting things on the horizon already for this year and I hope that there’s even more to come!
I think the biggest thing in the Drupal community to highlight is that Drupal 8 will be going end of life in November 2021 when Symfony 3 goes end of life. What does that mean for you? Well… we’ll talk about that more in a future post. But for the short term it means you have some planning to do for 2021 (getting to D9 is top priority). And depending on where you (and your team) are in terms of Drupal 9 skills, you may have some things to focus on. Thankfully, you’ve got months before you are “forced” to move to Drupal 9 so this is a great time to have a look at what you know (and what you don’t).
What follows is my list of recommended skills for optimal use of Drupal 9. You do NOT have to be an expert in any of these to get by! But you definitely want some level of proficiency and if at all possible, you should work to standardize a workflow within your team(s) so that you all have a common approach to each and a well-documented understanding of how (and why) you will integrate each item into your workflow.
Let’s jump right into the list!
1. Configuration Management
The configuration management system remains one of the most significant departures from “the way things used to be” in previous versions of Drupal. More, the vastly different approaches taken between organizations, teams, and even projects regarding a configuration management strategy make this topic even more challenging. Why? There isn’t necessarily a one-size fits all methodology.
Having said that, there’s a lot of basics you can (and should) focus on to understand. Specifically, you’ll want to ensure that the site building being done on a site (including basic configuration, entity development [e.g. new content types, etc.], view configuration, roles and and permissions, etc. can all be built out locally and then deployed into your upstream environments.
I’ve written about configuration in many parts on this blog, so there’s a lot of material there to dig into if you need it!
TLDR: if you are going to successfully build AND maintain a Drupal 8+ site, you need an understanding of how your site uses configuration (regardless of how how do it).
2. Dependency Management
Drupal 8 introduced composer as its dependency manager. This is a massive step forward for the Drupal community (especially given that dependency management only existed on prior versions of Drupal if a team went to the trouble of implementing it themselves).
While composer itself is “pretty easy” to use (no, seriously, it is!) it can be incredibly challenging to integrate into a devops workflow (especially if you, in fact, don’t use a devops workflow or continuous integration tooling). Fun fact, composer was one of the biggest blockers for me when I was originally trying to learn about Drupal 8!
So if you’re still using Drupal 7 OR if you’re using D8/D9 by installing from tars/zips this is a skill for you! Composer is particularly useful in ensuring that you have “the same version of the thing you’re using everywhere.” It also drastically reduces your repository size (to the tune of tens of thousands of files, in most cases).
Also remember that many Drupal 8+ modules have dependencies that are not bundled up with them! My most common example here is the Search API Solr module. This module will cause your site to fatal error if you don’t have the Solarium PHP plugin. The module does not come with this plugin. The composer.json file for the module does require it though.
TLDR: the community has moved in this direction and if you’re a holdout (or you’re new to D8/D9) this is a very high priority indeed because not using composer will make your life increasingly difficult.
3. Code Standards
(including Deprecated Code Analysis)
For my regular readers, you shouldn’t be surprised to see code standards on this list. I talk about them a lot. But! Drupal 9 actually represents a time when not following coding standards could actually bring down your entire platform. Why? Deprecated code.
The primary differences between Drupal 8.9.0 and Drupal 9.0.0 are:
updated dependencies (especially Symfony version 4.x)
removal of deprecated code
Obviously if you have written code that functions for Drupal 8.x that uses deprecated methods / classes / services / etc. it will continue to work fine in Drupal 8.x but the instant you update to Drupal 9.x you’re going to have a pretty significant problem. Why? Well, your code is going to try and execute something that no longer exists (which will cause a pretty spectacular PHP fatal error).
Getting in the habit of following coding standards is critical for a lot of reasons. If you don’t subscribe to that statement, let me try another one. Getting in the habit of keeping your code up to current standards (including deprecations) will help future proof your codebase.
There are many tools out there to help automate this process. On the deprecation front, check out the Upgrade Status module and Drupal Check. On the coding standards front, check out PHP Code Sniffer (PHPCS) and the Drupal coder module.
TLDR: with the heavy reliance on object oriented PHP AND the regular update cadence of Drupal core things shift around every few months. If you don’t stay current, you may be blocked from the next major version of Drupal (which also includes any contributed projects you’re using).
4. Virtual Environments / Containerization
Some of the most structurally unsound projects I’ve worked on in recent memory came about because of horribly disorganized development processes. Much like the importance for using a dependency manager to lock in particular versions of dependencies, using standardized environments for local development, continuous integration, and hosting environments is also quite important to ensure that we have consistent behaviors.
Look, there’s a LOT of smart folks out there that are building things for you to use explicitly for this purpose. If you haven’t, check out Drupal VM, Lando, DDev, Docksal, etc. You do not have to be a genius / expert at managing servers and VMs especially when you’re using one of these tools which do the lion’s share for you! Basically, you’re just on the hook for configuring them and they do all the rest.
TLDR: adopt a VM solution for your team and everyone should use that same solution and the same configuration for development.
5. Automated Testing
Last, but certainly not least, is to invest some effort into one of the many automated testing frameworks commonly used for Drupal platforms. Some examples might be:
PHPUnit (Unit and Behavioral testing)
Behat (Behavioral testing)
Nightwatch (Behavior and JS testing)
Pa11y (Accessibility testing)
Wraith / Backstop (Visual Regression testing)
While you certainly do not need to adopt “all” of these, I would suggest that you pick ONE and start working to integrate it into your devops processes, training your team on how to write tests in the framework, and integrate a testing plan into your project.
Testing is a critical component of not just development but also updates. Remember, as discussed previously, Drupal is constantly releasing new features and functionality AND you are more or less guaranteed that every two years moving forward you will have to do a major version upgrade (a la Drupal 8 to Drupal 9). So, by implementing automated testing you are essentially helping to future proof your platform against these future updates.
TLDR: even if you aren’t actively doing development on your platform you’re going to have ongoing updates from the community. Investing in testing is well worth the money (unless you’re a fan of broken things and downtime).
Bonus: Continuous Integration
The final thing I want to chat about today is continuous integration. You may have noticed it come up several times already on this list! But things like configuration management, dependency management, automated testing, etc. are all heavily reliant on a continuous integration (CI) and continuous deployment (CD) process. If you aren’t using one, you should be. Again, you don’t have to be an expert here! But you should do something that can be integrated into your development processes so that you can take advantage.
In Conclusion
One of the things I love about working with Drupal and open source technologies is that I am constantly expanding my skillset and broadening my horizons. This can be quite overwhelming if you try to wrap your arms around everything all the time. BUT! If you take ONE item from this list and focus on that, I think you’ll have success. Take time to evaluate where you are and what you need for your project and be laser focused on just that. Do you want to be the next Kubernetes expert? SO COOL! You can do it! Do you need to be a Kubernetes expert to start your team using Lando? Absolutely not. So focus your time and efforts accordingly.
Good luck and happy training!
Related Content
Get ready for all the exciting changes in the Drupal-verse in 2022! D7 EOL, PHP 7.4 EOL, and D10 release on deck!