For the past year, I have been working towards a stable release of Webform 6.x for Drupal 8/9. Last year, I published a blog post titled, A bump in the Webform module’s road to Drupal 9, where I stated...

That post specially focused on refactoring classes to not override constructors for service objects, plugins, and controllers. The post concluded by stating the Webform module’s version number will have to be bumped up from 5.x to 6.x. Besides refactoring constructors on the Webform module’s road to Drupal 9, I have also removed deprecated code, fixed some challenging issues, and managed to correct a few mistakes. That said, there are some issues and bad-smelling code that are not easy to fix.

Drupal provides a robust and well-thought-out API and UI for translating content and configuration. If you have a reasonably simple module that correctly defines a schema/metadata for configuration entities and uses Field API for content entities, Drupal’s translation system works as expected. The Webform module is not a simple module and using the basic schema/metadata definitions for configuration entities wasn’t always an option. Before I get into some technical details around these mistakes, there is a much simpler reason I made mistakes around translations: I only speak English and rarely use Drupal’s translation system.

As a non-disabled English speaking Drupal module developer, I made two mistakes while building the Webform module…

Fortunately, I started caring about accessibility and fixed most of the Webform module’s accessibility issues. Now, accessibility is one of the first things I consider when adding a new UI feature. I also did not think...Read More