Contributing to Drupal, especially core, can be a little daunting at first. But it is actually very simple to get started. If you are anything like me, an introvert with a certain reservation against even online forums, you might view Drupal Contribution as thoroughly impossible. I did, and this is the story of how I got over that and a guide on where I started.

History

I have been using Drupal since a few years now. In the beginning it was only to try it out. That was the time I was still skeptical of using CMS’s in general. I just had a brief look at Drupal 5 and gave it up – no particular reason: I just thought that I could do all that with native PHP “as per requirement”.

Down the line, reality hit me and I started using Drupal for a content site. It was at the time when Drupal 6 was quite mature. The site was a little clunky per my taste but I did the best I could. It was a volunteer project and I couldn’t really spend more time researching into all bits and pieces then. But the project was a success and I delved deeper and deeper into Drupal world and considered it professionally. But contributing back to Drupal seemed daunting. I mostly preferred lurking and finding any solution to the problem rather than participating in the issue queue, forums, or IRC.

Here is my story on how I started, or just jump straight to What you need to know to begin contributing.

Drupal Contribution

Due to a variety of situations, I finally started looking into contributing to Drupal a couple months back. I got bored of hanging around StackOverflow and Drupal StackExchange site and jumped in on drupal.org. I went to my dashboard and spotted something called as “Novice Issues.” You can see it in the screenshot below.

I checked it out and found some issues that I could do, not just technically, but without worrying too much about community standards, conventions, decorum, etc… Those issues were things like changing function calls, patch re-rolls, some manual testing, etc… Such simple issues had clear guides on how to go about doing stuff in form of [meta] issues. For example, the earliest kind of issues I participated in were to do with changing theme system to use twig and converting theme() calls to drupal_render(). Simple straight-forward tasks – and clearly documented in their respective meta issues. See the meta issues for Convert core theme functions to Twig templates and Don’t call theme() directly anywhere outside drupal_render(). These meta issues are conveniently linked from the individual issues itself.

What is great about this is that such simple tasks can quickly (and easily) acquaint you with the upcoming changes in Drupal 8. Invariably, some of these issues turn more complex, and you learn more. Soon, you start looking into bigger and more complex issues. This is much better than learning by, say, reading the documentation or change records. Both of those are great sources of information, no doubt, but nothing beats getting your hands dirty.

As of today, 15 of the patches I have worked on are committed to the Drupal 8.x branch. This places me in top 10% of about 1547 users (the link shows 14 right now, it just needs refreshing) who have contributed patches to Drupal 8.x. I guess it is not so bad for someone barely 2 months into Drupal contribution.

What I gained

More importantly, I have learned a lot more about Drupal 8 than I could have hoped to if I were to go through documentation and changelogs. And I have not just learned, but actually used the new system – namespaces, twig, dependency injection, plugin architecture, integration testing, routing, configuration, and a lot more.

What you need to know

Here are a few things you will need to know and get comfortable with to productively contribute to Drupal.

GIT

You don’t need to be an expert at git, but you have to be comfortable enough to clone from Drupal repository, apply patches, create patches, etc… Get comfortable with cloning Drupal. The Version Control page on Drupal project gives the exact command, and here it is:

git clone --branch 8.x http://git.drupal.org/project/drupal.git
cd drupal


I found myself cloning so often (and it takes time to download the 30MB+ repository) that I now clone locally, which is nearly instant. This is something I do:

git clone --branch 8.x http://git.drupal.org/project/drupal.git drupal8


Now my local repository is setup in drupal8. I don’t touch this anymore, but I regularly pull updates into it.

cd drupal8
git pull origin 8.x


To work on a new patch, I simply clone from this directory:

git clone drupal8/ d8form


Other staple commands you would use regularly are:

# Add all changes to index.
git add .
# Get a diff of all unstaged changes and save it in patch file.
git diff > filename-issue-comment.patch
# Get a diff of all staged changes and save it in a patch file
git diff --cached . > filename-issue-comment.patch
# View the status.
git status
# View the status in current directory.
git status .


There is a whole section for git in Drupal documentation too.

Patches

You don’t have rights to push changes to the Drupal repository, so all your changes will go in as patches. The section above lists a few commands to create patches. To understand them more, I would recommend you to read the excellent git documentation. You can also read Making a Drupal patch for more specific instructions.

At times, your patch might become invalid due to other changes to the same file that get committed before your patch can. When this happens, you need to re-roll the patch against the latest changes. There is a step-by-step guide which explains the entire process clearly.

Testing

When you upload the patch to an issue queue and set the status to “needs review”, the Drupal test-bot picks up the patch, applies it to the latest clone of Drupal repository and starts all automated testing. In my experience, it takes about 60 – 90 minutes for a test run at the end of which, the patch is marked as passed or failed.

There are times when failures may not be caught by the test-bot. In that case, it is very important to write tests to handle that scenarios. That might be a subject of a different blog post.

Drupal Coding Convention

To keep things clean and sane for such a massive community driven project, coding and naming conventions are pretty important. This page lists the various coding standards you need to keep in mind. Reviewers are pretty good at catching problems with conventions and suggesting changes but you can save a lot of time if you fix these minor issues yourself in first place, and leave the reviews to only worry about the code.

Other

A few other things you might want to read about are listed here. I guess there are a lot more things you need, but start with Novice issues and you should be acquainted with most of them pretty soon. The community is quite courteous and great and you should feel right at home. In time, not only will you have the satisfaction of contributing to Drupal, but experience with handling any complex task with it.

I hope this guide has been useful. Please suggest improvements or let me know if I have missed anything. Do share.