DrupalCon Vienna - logo

5 things I learned during my first DrupalCon sprint

Brent Gees

Thanks to Dropsolid, I had the chance to attend my second DrupalCon, which took place in Vienna. While there, I participated in my first (Drupal) sprint ever. During the sprint I learned a lot of things and - luckily - also had fun at the same time. In this blog post, I’m going to share the things I’ve learned and with which hope to inspire you to participate in a Drupal sprint some time yourself.

I will be talking about the following things:

  • Drush site install
  • The Drupal Community
  • Unit testing
  • Functional testing
  • Dashboards

1. Drush site-install is lightning-quick

Because we work with a local installer that sets up everything automatically at Dropsolid, I’m not used to installing my Drupal sites from scratch. And I'm not particularly sorry.

Up until now, I used to install a website through the user interface. So far this had never posed a problem, because I don’t have to install a new site every day.  However, when testing patches, it really turned out to be a bottleneck. So I was advised to start using Drush site-install (drush si) and truth be told, it saved me quite some time already.

If you want to find out more, check it out.

2. The Drupal community is really helpful

At first, I had no clue where or what module I wanted to start helping with. So I decided to simply leave a message in the Slack group for Belgium. Kristiaan and Joris reached out to me and told me that I could help out with entity access / group or Search API related things. After some deliberation, I decided to work on Facets.

I didn't really have a preference, so my approach was to look at the ‘needs review’ section of facets and simply pick the oldest issue: "add option to hide facets with only one option". Apparently, there already was a patch. So my first task was to retest it. Of course, it failed. Would have been just a bit too easy otherwise. I couldn’t immediately find out what had gone wrong, so I checked with Joris. He gave me some tips on how he thought it should be resolved. After that, it didn’t take long for my test to turn green! Here's the proof.

3. Unit testing

After solving my first issue, I focused on other old bugs. It turned out that a couple of those had the same issue that I just patched. Hence it didn’t take me long to fix those as well and I was able to test them locally with positive results. These can be tested with the following command executed from the website root directory (for the testWithOneResult function of facets).

./vendor/bin/phpunit -c core modules/facets/  --filter testWithOneResult

When creating new functionalities for a contrib module, tests like these are easy to set up, but very handy to avoid problems in the future.

4. Functional testing is really cool and has screenshots

Sadly, the patch that had turned green earlier, wasn’t completely finished. It still required some functional tests to verify that it was working properly. During the same sprint, they helped me to set everything up for functional testing in order for me to write my own tests. And after a few tries, I finally completed the patch. In fact, it has been commited already!

If you want to do the same, follow these tips.

In order to be able to set up your local environment for testing, you first have to go to the core folder and copy the phpunit.xml.dist to a new file named phpunit.xml and fill in the simpletest_base_url, simpletest_db and browsertest_output_directory. Then to start the test, I used the following command:

./vendor/bin/phpunit -c core modules/facets/  --filter testHideOnlyOneItemProcessor --printer="\Drupal\Tests\Listeners\HtmlOutputPrinter"

This tests the ‘testHideOnlyOneItemProcessor’ function and prints screenshots of every step. Cool, right? This allowed me to check if my tests where working and what classes I should use for my selectors. I was really surprised how well this worked, and what you can do with this.


5. Dashboards are very handy, if you set them up correctly

One last thing I learned is that the dashboard is very useful. After learning from Joris how he had set up his dashboard, I went on to configure mine. This is what I came up with:


As you can see, I’ve added my posts and my issues above, so that I can see what I need to work on or if someone commented on an active issue. On the right I still had some free space, so I chose to add the ‘contributor links’ block. If I would be out of issues, I can now easily find new ones to work on.

Feel free to share your own dashboard.

Other useful tips

  • If you have not yet installed dreditor extension, it’s really useful when spending a lot of time on drupal.org
  • You can change the theme - to make it more to your taste - using Stylish. I currently prefer the ‘Bojhan's Drupal.org style’

I’m very thankful that I was able to help with the Facets' sprint, and learned a lot during one day. I’ll definitely join more sprints in the future and now that I know how everything works, I'll start helping out a little bit more on contrib.

If you want to help out as well and don’t know where to start, feel free to leave a comment. So that you can also make it to this list:


Subscribe to our newsletter

Recommended articles
Drupaljam 2020
Google analytics 4: the new generation of website traffic analysing
3 reasons to invest in your digital customer experience
Marketing automation as the driver of personalized customer experiences