<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1114119085333160&amp;ev=PageView&amp;noscript=1">

13thingsilearnedfromdrupalcampnorthwest2013.jpg

My first Drupal Event as a full-time developer was Drupal Camp Northwest 2013, organised by the Northwest Drupal User Group (NWDUG). I've been working for a few years as a small organisation's Drupal all-rounder and ad-hoc designer, but coming to CTI Digital means stepping up a gear: suddenly I'm spending every day elbow deep in the Drupal API and custom modules, and I rarely shut down my computer without having learnt something new. Drupal Camp is the next step on the path to becoming a fully-fledged Drupal Developer, my first tentative steps into the wider Drupal community and the new things they want to share with me.

These are the things I learned over the weekend.

A room full of Drupal devs and front-enders, and a picture of a footballer appears on a screen. Not one of us can identify Robin van Persie by sight.

Drupal is powerful and flexible, and however you want to do something, there's a module for that. But its performance isn't one of its strengths, and it can run slow when faced with heavy traffic. There's lots of things you can do, but there's more you can do if you can get direct access to your server. Drupal has caching in its core that you definitely should use, but if you can install things like APC Op Caching and Varnish then you're in a much better position. Memcached can also help, but it works best when its working across multiple servers in a Cloud.

There's no international standard on which bits of a name go where. You can't assume the first bit of a user's name is their given name. As personalisation becomes more important and websites start talking to you as an individual, it's going to be more important to call people what they expect to be called. So make sure you only ask the user to give you the bit of their name you really need, and only break it into pieces if you absolutely have to: if nothing else, only collecting a username if you don't need someone's full name will keep you on the right side of the Data Protection Act. Let the user tell you their name in a single field, and give you the name they want to be addressed by separately. Trust them to know their own name – don't change it or validate it against what you think a name should be, because you'll invariably meet a culture that do things differently.

They just do. Fact.

If you're using Drupal 8 straight out of the box, you're going to get a powerful CMS with responsive layouts and a decent UX. If you only every use it through the UI, you will probably never find out how much has changed under the hood. But if you do delve into the code, you're going to find a lot of things are easier: everything is an entity and everything is a field, so no matter what you want to fiddle with, there's only one way to learn. But then …

There's going to be a lot of new things to learn with Drupal 8. If it's you're first exposure to Drupal coding, then that's fine – you'd have stuff to learn whatever version you went with. But if you've already learned “the Drupal Way” you've got some stuff to unlearn: Field API has been completely refactored, Variables are gone, settings aren't in the database any more and you can't give up and hack PHP straight into the body of a node. Plus you'll have to learn Object Orientated Programming, Twig, YAML, Composer and a number of Symfony components. But you know what? If you learn that stuff, you're going to be a better developer. You'll have a wider range of skills that could take you anywhere using PHP. I know it hurts, but this is for your own good.

The thing that makes Drupal strong is its community. The community use Drupal, update Drupal, fix its bugs and its performance issues, but they do more than that. They organise things like Drupal Camp, or sprint days. They help each other out. One of the big discussions of the weekend was how to grow the Drupal community and teach others how to do what we're already doing. We're all trying to make a living from Drupal, but instead of trying to keep what we know to ourselves so we can increase our personal value, we're happy to share it and bring everybody up to the same level. In the end, that makes the whole community stronger.

But Git is amazing, and even if you're just a one-man band it's going to make it easier for you to keep track of your Drupal code and roll it back if something suddenly dies. You probably want to be learning Git anyway.

Or maybe it doesn't. No-one could really agree.

Vim comes as standard with any Ubuntu or IOS computer, and – whilst no-one is denying its got a steep learning curve – it can do a lot more than you might give it credit for: splits, auto-completes, code inspections, tabs. You can even link it to PHP CodeSniffer.

If you're writing your own Drupal Modules, this Pear package is going to save you a lot of time: it can check for bad coding and standard compliance, and it will tell you very quickly that your website has crashed because you typed :q in the middle of your module when you were in the wrong Vim mode.

Do some quick Google research on Jenkins, Dreditor, Drush, Apache Bench, Composer, Bower, Grunt and Phing and you might find that any number of them could make your life a lot easier. Open Source is ace.

At Drupal Camp, you always learn something new.

  1. Drupal people are my people.
  2. If you're not caching your site, your site is slow
  3. Names are important
  4. Foxes look better in glasses and a hat.
  5. Drupal 8 is going to be so easy.
  6. Drupal 8 is going to be so hard.
  7. The water's lovely.
  8. If you want to contribute to Drupal Core, you're going to have to use Git.
  9. Nginx runs faster than Apache
  10. You don't need a fancy IDE to edit code
  11. Oh, and you want to find out more about PHP CodeSniffer
  12. And some other stuff too.
  13. Not all tennis players can do the splits.

About the author

Paul Smith
Paul Smith
Paul has several years experience as a site builder and systems administrator for a number of Drupal 6 and 7 websites. A key member of the Drupal Support Team, he provides day-to-day support for the British Council (5 sites) and British Land (40 sites) and Great Ormond Street Hospital (2 sites), resolving errors and issues to a fixed SLA deadline, and also suggesting, developing and deploying new features and improvements to the sites. This role involves strong problem solving and debugging skills, and well as face-to-face and remote client management responsibilities.

Get the latest content directly to your inbox

SUBSCRIBE

Recent posts