Open Collective
Open Collective
Loading
A bump in the Webform module's road to Drupal 9
Published on September 16, 2019 by Jacob Rockowitz

The things that make me most excited about the pending release of Drupal 9 in June 2020 is that as a community we have the opportunity to look back at what we have accomplished, let go of some old deprecated code, and can now start thinking about what is next for Drupal 10.

Accomplishing

To my mind, the biggest accomplishments with Drupal 8’s release was shifting it’s entire code base and community to be more object-oriented. The adoption of Symfony into Drupal core allowed us to build a more robust and flexible Content Management Framework. The Webform module for Drupal 8 is a testament to how healthy Drupal has become as a framework. Its robustness is a combination of Drupal's Plugin API and Form API with object-oriented concepts, including dependency injection. A straightforward and personal statement is.

Drupal 8 made me a better programmer and software architect.

Looking at the code and concepts behind core and contributed modules, it is immediately apparent that everyone stepped back and reapproached a lot of technical challenges - our collective hard work and contributions resulted in great solutions and better code. Core improvements are documented as initiatives on Drupal.org. Contributed projects generally don't have initiatives. When you look at the flexibility behind a "simple" module like Metatag, maintained by Damien McKenna (DamienMcKenna) or something potentially as "complex" as Domain Access, maintained by Ken Rickard (agentrickard), it’s impressive to witness what is being built and maintained by the Drupal community.

I think it’s safe to say that everyone is ready to keep improving our software and let go of some of the technical baggage, aka deprecated code.

Deprecating

While Drupal 8 has evolved, some code has become deprecated and replaced by better code and design patterns, allowing us to improve the software. In Dries Buytaert's post, Plan for Drupal 9, he states…

"Instead of working on Drupal 9 in a separate codebase, we are building Drupal 9 in Drupal 8. This means that we are adding new functionality as backward-compatible code and experimental features. Once the code becomes stable, we deprecate any old functionality."

Regarding deprecation, what isn’t said but is worth mentioning is that some code is deprecated to improve the underlying software architecture and fix mistakes like bad naming conventions or unneeded complexity. When the Drupal community adopted Symfony, we entered uncharted waters and mistakes are going to be made. 

Recently, I started sketching with my ten-year-old daughter. An important lesson I’m trying to teach her is that it is okay to make mistakes, especially because you can always fix them later. Making mistakes is part of the process in wanting to improve something. Within art, the term 'mistake' is open to interpretation. In software development however, we know when code smells bad and have a process in place to refactor bad code.

Smelling

"Bad smelling code" is an extreme statement which frankly I would only use to describe my code. 

Fixing bad smelling code is going to cause a bump in the Webform module's road to Drupal 9.

Before I explain the specific issue in the Webform module for Drupal 8, I want to emphasize that the Drupal community is in good shape with a plan to move on to Drupal 9. 

Planning

Since Dries' published the plan for Drupal 9, people have been busy coordinating the Drupal 9 initiative. Matt Glaman (mglaman) created Drupal Check, a tool which helps everyone find and remove deprecated code. Now, everyone needs to start removing deprecated code from their module.

Sharing

Several contributors have been helping me remove deprecated code from the Webform module. Removing a deprecated service from a class constructor that which relies on dependency injection seemed impossible, but then Shawn Duncan (FatherShawn) demonstrated to the NYC Drupal Meetup an implementation pattern, which properly extends a class and safely injects dependencies.

The simplest explanation I can give for non-technical users is the Webform module failed to make it easy to extend the Webform module without having hardcoded tightly coupled dependencies. In other words, some things are going to break when the Webform is installed via Drupal 9. On top of making it easier to extend, applying this new implementation pattern reduced code complexity. This change record on Drupal.org provides a more technical explanation with a code example of the improvements.

It’s also important to acknowledge that Shawn learned this pattern while attending Alex Pott's presentation, Drupal 9 is coming: Getting your code ready. Alex credits Lee Rowlands (larowlan) and Thomas Seidl (drunken monkey) for documenting how to safely extending Drupal 8 plugin classes without fear of constructor changes

In Alex's presentation, he recommends.

"Be very very careful with sub-classes and overriding constructors"

Sadly, I wasn't aware of how to properly sub-classes and override constructors while building the Webform module, and now we have some technical debt that needs fixing.

Fixing

We must fix the sub-classing and overridden constructor problem because it paves the Webform module's road to Drupal 9. Fixing this issue is a massive patch that is going to break any Webform add-on or custom code that implements a Webform element or handler and overrides the constructor. Breaking backward compatibility in Drupal core or contributed module requires tagging a new version. Therefore, we are going to have bump the Webform module's version from 5.x to 6.x to get ready for Drupal 9. 

I think everyone is starting to understand the bad news, which is that Webform 6.x is going to break some code. This change will result in fatal show-stopping errors, which are easy to fix. Developers need to apply the implementation pattern documented in the change record. Because most patches and changes to the Webform module do not alter a class' constructor, there is some good news: We should be able to maintain a Webform 8.x-5.x and Webform 9.x-6.x branch at the same time.

Planning

Following the tradition established over the last three years, any significant bump to the Webform module's release status has been tied to the New Year. 

Along with preparing for Drupal 9, the 9.x-6.x branch of the Webform module will include any significant API changes or improvements. For example, I would like to fix how conditional logic handles a disabled element's value

Funding

Another significant and thankless task that needs to be accomplished is migrating all the Webform module's SimpleTests to PHPUnit. Fortunately, many people have thanked me by backing the Webform module's Open Collective. Now there are funds available to pay for the monotonous task of migrating dozens of tests.

Understanding

Last year's stable release of Webform 8.x-5.x was a Christmas present, and I hope everyone understands that this year's upcoming tagging of Webform 9.x-6.x is not a lump of coal but a big step in the Webform module's road to Drupal 9 and beyond.

Thanking

I rarely get to commit a patch that makes my code easier to maintain. I am thankful for Shawn Duncan (FatherShawn), recognizing how cool and important this implementation pattern was during Alex's presentation and then sharing it with the NYC Drupal community. This is how the hive mind that is Open Source works to build Drupal. The Drupal community should thank everyone involved who helped transitioned our code and community to Drupal 8. In a few months, we can thank them once again for continuously improving and refactoring Drupal core and contributed projects and paving our road to Drupal 9 - collectively and collaboratively, we’ll get there...it’s what we do.