My journey in Drupal, 4 years on

I’m approaching the 4 year mark at my agency and along with it my 4 year mark working with Drupal. It’s been an interesting journey so far and I’ve learned a fair bit, but, as with anything in technology, there’s still a great deal left to discover. This is my journey so far and a few key points I learned along the way.

Picking up a new technology to use can be a daunting task, aside from deciding if it fits your needs/requirements you need to ensure it will be something you enjoy working with as well as something you can make a living from. I never really choose to use Drupal, it just happened to be one of the CMS’ my agency use and as such I picked it up. However after working with it for the last 4 years I can say that I do enjoy projects using Drupal (though as with any technology it has it’s cons as well as pros). It also appears to be growing and going from strength to strength, so is likely to be around for a fair while yet.

Getting up to speed at first was tricky, learning how the different elements that make Drupal slot together took some time, and more than a few attempts (rather like an ikea flatpack). Helping me along the way were a few resources, such as the documentation, fantastic community and of course any question can be a quick google away from an answer.

The dev tools

As I started to get involved with Drupal I learnt about the tools of the trade. Most noteworthy of these being Drush - An awesome tool I regularly use now. A massive time saver at the start of builds for setting up core and modules when used alongside make files. Also useful during development and hugely when updating core/modules.
It can be downloaded from here: http://docs.drush.org/en/master/install
A library of drush commands is available here: http://www.drushcommands.com

Alongside this are developer modules designed to help speed up development and test the code written such as devel - a suite of modules to help module developers and themers, and coder - a module that scans your code and reports any issues available.

Re-inventing the wheel is lengthy and unneeded, it’s the same with writing code that already exists.
http://dropbucket.org provides a code snippet repo that can be searched and added to, useful for adding anything you found helpful or as a starting block/idea for your own code. Each snippet can be tagged and commented upon.

For deployments from development to production sites:

• Features - The biggest and most documented module. It places config changes into new modules that can be committed, deployed and installed. Each new module can be overridden, deleted and reverted if needed.
• Configuration Management - A backport of the D8 core module, a ‘features lite’ module it provides similar functionality but rather than creating new modules configurations are saves in tar files. An example of this process can be seen here: https://www.drupal.org/node/1872288

For modules that don’t store these settings in files you can use:

• Bundle Copy - This provides an export/import (similar to views) for Vocabs, Content Types, Users and fields. The dev version adds support for field collections, cloning content types and commerce entity bundles.
• Taxonomy CSV import/export - This allows you to import/export vocabs and terms from a csv.

The community

Outside of the CMS I began to get involved in other aspects, namely Drupal.org. Here I was able to talk to other developers, post bug reports (to which I always received a speedy response) and patches where I could. I was also able to create my own module and have it reviewed by other developers before it could be downloaded and used by others. Getting involved in this way has not only allowed me to give back to the community that has helped me, but also allows me to develop further - which can only be a good thing.

Over the last couple of years I’ve also attended DrupalCamp London and a couple of other Drupal events (such as beer and chat), which is great way to get to know other people and talk all things Drupal.