Development of a sponsored contrib module - Gather Content

In 2016, I had the opportunity to work on a contrib module called GatherContent.

The story began in February, when we were contacted by London-based company, GatherContent. GatherContent helps people who produce lots of content for CMS builds, usually for when you are launching a new a website. It helps take away the chaos that is involved when trying to pull content together and getting it approved for launch. It's CMS agnostic which means moving your content to and from various CMS' is easy. You also don’t need to start from scratch or educate your content editors, marketing team or anyone else responsible for the content as they are working from a single place.

An integration for Drupal existed before we were involved, but it was built by the GatherContent team, so it didn’t follow all of the Drupal UI and best practices. The goal of the project was to recreate the module for Drupal 7 using these best practices, and to create a brand new module for Drupal 8.

February

I started an analysis of the product and existing integration, based on the provided brief. I wanted to experience what a user of GatherContent would. This analysis was important to help me think like a GatherContent user based on a shared experience. My next step was to designed some mockups. These were mostly based on the UIs of the other integrations because we were trying to achieve ease of use. It was expected that the module would be used by non-Drupal people as well, such as marketing teams managing multiple CMSs. 

March

March started with the development of the new Drupal 7 version. Our internal goal was to build a Drupal 7 module in a way that would allow us to reuse a lot of code when building the Drupal 8 version. Therefore, we decided to use the Composer Manager module as one of the dependencies for the GatherContent module. This allows us to use the Guzzle library, which is incorporated in Drupal 8 core. We also decided to use entities. Not only are they the industry standard, but it also meant we didn’t have to spend too much time being careful with things solved by out-of-box entities.

April

Throughout April we focused on improving the user experience of module. We introduced our own theme components, partially fixing ones from Drupal core. We also entered the beta testing phase, so we focused on making the module run smoothly.

May

By May we were able to release the first stable version of the Drupal 7 module, and we jumped straight into the Drupal 8 development. First, we tried to automatically migrate the module using the Drupal module upgrader project. This did a nice job with some of the more obvious tasks, but most of the work had to be done manually. For that, we used Drupal Console, it was a very useful tool for scaffolding and testing some of our ideas. From an architectural point of view, we decided not to use migrate suite. The reason behind this is that Migrate is still not a stable part of Drupal core and at the time it was undergoing major architectural changes. We were also able to reuse most of our Drupal 7 code for importing and updating content.

June

We worked on cleaning up the code in the Drupal 8 module and we were fixing the first bug reports in Drupal 7. We hit problems with reporting issues on Drupal.org as some of our users aren’t active in the Drupal community. 

July

At the beginning of July, we released the first alpha version of the Drupal 8 module. Although it was quite stable, we wanted to have open options for future issues, mostly regarding backwards compatibility of the code components. During the summer, we gathered feedback and new feature requests.

September

In the first half of September we came up with several new features and approached the client to start the second phase of the module development. We decided to provide support for entity references in Drupal 8, and the ability for developers to change imported data, so they can easily provide support for other field types. We also improved the editor experience by simplifying menu creation and adding the option to import content as undefined. We understand that some users might want to automate imports, so we now support imports through drush.

October

As we reached October, development of the second phase of the project was running and we were able to fit in image field support for remote filesystems.

Current state

In November we tagged a new stable version for the Drupal 7 module and the first beta for the Drupal 8 module and we are now looking forward to gathering feedback from users.

In the end, I’m eager to say that I don’t see a big difference in working for regular clients and being paid for work on a contrib module. It is, of course, great to see the impact of your work and hear feedback from Drupal.org users.