After 5 years and 8 months of hard work and joy alongside the wonderful team at Code Enigma, last March I decided it was time for me to move on to something new, stretch myself a little bit, and discover some new grounds in the Drupal world.
With parts one and two of the series covered, this 3rd (and final!) part will cover some other important aspects of Drupal development that I wanted to pay attention to while working on the Drupal 8 version of the viewport module.
Essentially, the kind of aspects that are easy to forget (or ignore on purpose) when a developer comes up with a working version or something “good enough” to be released, and thinks there’s no need to write tests for the existing codebase (we’ve all done it at some point).
This post will be a mix of links to documentation and resources that were either useful or new to me, and tips about some of the utilities and classes available when writing unit or functoinal tests.
In the last blog post, I started to talk about the process of upgrading the Viewport module from Drupal 7 to Drupal 8. While the module is now fully ported and has a stable version for Drupal 8, I didn’t cover all the steps and new things that I came across while working on it.
This time I’ll go through the notes I took while working on the settings page, the creation of a proper schema for configuration management, and the conversion of procedural code into PHP classes. Let’s get into it:
Viewport is one of the modules I maintain for Drupal 7. It’s a very small and simple module that does a very specific thing: it allows site admins to specify the values they want for the HTML meta tag that specifies the viewport settings for browsers. It also allows admins to choose the pages in which they want this custom viewport applied.
Back in the day a client required this functionality to embed some browser games that required very specific settings. Nowadays it’s not really common for a site admin to set those values, and developers don’t really require any UI to set them.