An ExpressionEngine developer in Drupal - Part II

So I'm now a little bit further into our Drupal project. I'm still finding some frustration about how Drupal handles some things.

So I'm now a little bit further into our Drupal project. I'm still finding some frustration about how Drupal handles some things.

That said, I wanted to concentrate this on one of the things I've found to be quite cool in Drupal.

Speak to almost anyone in the ExpressionEngine community that works in a team or even works alone but with a multi-environment setup and they'll tell you that one of the biggest frustrations is database environment migrations.

This is something that Drupal does quite well (and soon to get even better I'm told). Drupal has a feature called, wait for it... Features

The scenario

So there are 3 of us working on this project and we're all running a local instance of Drupal using Vagrant/Puppet. This sprint has seen me working on the markup and styles for the page base, music player and homepage carousel.

Markup and Sass are stored in Git but I had the need to create a Drupal view to build the homepage carousel. Now a view in Drupal I'd probably best describe a little bit like a Playa based Low Variable in EE (but not as sexy). A view can use the content of other 'channels' and we can set parameters of what should return. We're altering the db schema locally and we need a way to share that alteration amongst the team.

Now I could write a short readme for them to replicate but that's cumbersome. So here's where Features comes in.

From the control panel I can go to the Features module, give my change (or Feature) a name and then hit download.

What this does is generate some PHP for my changes, updates an info file to say that my theme is dependent on having these features.

I can then commit my feature to Git and push like everything else. Then the next time the team rebase their codebase, my feature will run for their instance.

I don't think this handles content migration at this point - which I don't think matters really anyway. Development/staging environments rarely need the same content as production.

I'm told that even this is changing within Drupal and that future features will be YAML files, I guess similar to the way Statamic works if you're familiar with that tool.

When we get to content migration I'll post again.