The Process of Contributing to Drupal

Written on October 10, 2016. Posted in Blog.

Our extensive knowledge of the Drupal platform is based on about a dozen projects we successfully launched and at least half a dozen still in the making. But it wasn’t until we felt a dire need for a module with functionalities none of the existing modules covered, that we engaged in a kind of Drupal module development that involves publishing to the community.

Motivation

Every time we work on a project, the design team proposes many of the UI designs for further development. The chosen designs are then put in the development lifecycle with many of our teammates contributing feedback. What usually happens is that the pieces of the feedback information are scattered around different platforms – Skype, Slack, Email, sticky notes. Our development process needed some systematic way of feedback collection that wouldn’t clutter project management tools, e-mails and chats but would organize feedback information in a structured way. That kind of an approach should save significant time – usually spent in organizing collected feedback information from different sources.

Research

One of the core concepts of the Drupal’s community is the idea of contribution rather than competition. After a close examination of the existing modules we found three addressing feedback data organization and none accomplishing every single one of our needs on the list.

The first module we analyzed was outdated. The last stable version was built for Drupal 6 in 2011 and the development version was not as configurable as we needed it to be. Too little, too far. Strike one! Module number two had too much of what we did not need and too little of what we actually wanted. The libraries it was built upon were not to our liking. Also, the last development version dates back to 2013. Strike two! It was the last one in the selected three that seemed to be the closest. One look at the features list was good enough to get us hooked. However, after some time of trying, the third one was declared unwanted. Similar to the previous two, the last development version was done in 2013. Strike three, and you’re out! We finally decided to start working on a small yet configurable Feedback Collect module from scratch.

As beginnings go, we wanted to do everything by the book. We started exploring Drupal community guidelines and covered topics such as Obtaining Git access and Release naming conventions while browsing through the information on rules and regulations. We have to admit we wanted not only to get the job done but to make this module the model for future development, as well. This only meant that the code written had to be picture-perfect.

Development

The main point of our module is a feedback button that a site administrator can put anywhere on the site and choose between showing or hiding it on a range of pages. Clicking on a button opens the feedback form where users and contributors write their findings. Depending on the configuration, the feedback can be collected from the anonymous or registered users. One of the key areas in which the existing modules were failing was the ability to fit the feedback form in the design without ruining the harmony of the site’s elements. This is exactly in what we invested a substantial amount of time. We enabled blending of the form within the site’s design and responsiveness was followed through so that its visuals were consistent even on mobile devices.

One of the obstacles we faced along the way were the questions of third-party code use. The community was there to help us, once again. As Drupal doesn’t allow shipping custom modules with libraries not owned by the module maker we learned how to implement third-party libraries without breaking the rule.

The testing phase provided additional ideas as we learned that the module should have a backup of users’ input in the feedback form in case they forgot to click the submit feedback button or when they accidentally clicked outside of the website. All the work done by the users is saved in the browser cache, locally. By opening the site again, the users are asked whether they want to retrieve a locally saved copy or they want to enter new feedback information. Users come first, as always.

Publishing

It is when we decided to publish the module that we were introduced to the biggest challenge. In order to have a module published, it needs to be reviewed by multiple developers, followed by the patching of the problems they have found. The challenge with this method is that it takes time (and patience) until the developers start reviewing.

When the module was finally reviewed, its status was supposed to go to “Reviewed and tested by community”. Well, it didn’t. The intervention had to be initiated and we contacted Drupal’s contributors to help us speed up things. Even after this status was set, we needed more. An official staff member had to check the module in order to give our account a special permission for publishing. More time, more patience. Along the way, we had to review at least three other modules in order to get the account permissions and prepared the module presentation page with the standards in mind.

Conclusion

Going through someone else’s code seemed like a pain, but we were wrong. We discovered interesting ways some developers used Drupal in development.

We have seen quite a few good coding styles, got some fresh ideas and stumbled upon new modules that deserve the spotlight. Reviewing other modules also had a significant impact on our coding style and module testing.

The good news is that only the first module has to go through the whole process.

We did spend more time on following the standards and guidelines than we did on development, but that only made us better developers, right? 🙂

Interesting Stats

Coding was finished in 5 days.

Another 8 days were spent on testing from Drupal contributors and our team so it could get reviewed status.

We waited a month for the account permission mentioned above (for publishing modules).

After that, in the next 4 days we reviewed 3 modules and after that Feedback Collect was finally published.

Only the first time a module is published it goes through all this process. Next modules we contribute will (hopefully) take drastically less time.

It took over a year to publish this article, after only 5 days of coding. So stay tuned, in the next couple of years we will tell you a story of how we published our first Drupal 8 module.