Starting a new project is a time for change. A time to tear down your idols and re-evaluate everything. Or maybe, just, you know, have a closer look at whether you could do things a bit better this time?
As I’ve discussed on this blog before, Drupal 8 brings a lot of changes to the Drupal community and this should extend to the tools you use. Part of the problem with drastic change is that, sometimes, you don’t know what you don’t know so you can’t look for help. I will go through a few tools that, while not new themselves, are newly relevant or useful for the Drupal team now that we’re starting to work with Drupal 8.
Change records
Whether porting code from Drupal 7 or writing something fresh there will be a time when you go to use a function only for your editor of choice to tell you it doesn’t exist. What? How on earth could they remove menu_get_object() or taxonomy_select_nodes(). Well, allow me introduce you to Drupal change records.
Before a change can be committed to core, a description of the change must be written and agreed upon. Drupal change records are not a new thing. The oldest ones go back to 2011. However, the changes through the life of Drupal 7 were relatively small. The jump to Drupal 8 and the changes that will come with each new version are much bigger. Search for a missing, deprecated or modified function and chances are you’ll get a handful of results and one of them will tell you why the change happened, when it happened and most importantly, how to achieve the same result.
If, like me, you’re a fan of Twitter then I would recommend following @drupal8changes. This bot tweets every published change record as they get published. While I would never suggest that you need to read every change record, seeing them pop up occasionally can draw your attention to something for an interesting couple of minutes. If, for some reason, you do want to be notified of every change then the bot is based on the change record RSS feed.
Satis
Drupal is getting off the island. Ignoring that we created our own special phrase for not reinventing the wheel, this is a good thing. Using more object oriented programming principles, Symfony components and Composer (among other changes) means that Drupal has opened itself up to a bunch of the tools the rest of the PHP community has been developing and using for years.
The dependency manager Composer and the package repository Packagist are prime examples of this. Packagist is the most popular repository of PHP packages and Composer makes them simple to use. However, what do you do for your internal modules? Whatever your reason for not publishing the code, it doesn’t make sense to use different methods for managing internal and external dependencies. Enter Satis.
Satis is an open source tool for generating a composer repository. Essentially, it creates a static version of Packagist to host private packages. Here at CTI, we were already using it to manage custom Magento modules so it was simple to start adding Drupal projects. Thanks to the head start our Magento team had, the majority of our packages currently available through Satis are Magento modules. The Drupal team is working hard on catching up with a base theme, base build and a testing framework ready to be included in our Drupal 8 projects with Composer.
Old dogs with new tricks
While new tools are all well and good, sometimes you need to look at your old tools with fresh eyes. The problem with knowing tools like the back of your hand is that you stop looking for changes. We’re big fans of PhpStorm at CTI and it’s always worth looking at the What’s New page when a new version is released.
For example, the latest version includes:
- Smart Type code completion that only suggestions variables that match the types required by the method/function being used.
- Improved PHP7 syntax support which is essential if you’re using PHP7 (and you should be).
Xdebug on demand so that Xdebug only runs when enabled in PhpStorm and doesn’t slow down other operations. - Improved code quality analysis. Small changes that spot more potential problems with your code.
- A bunch of other stuff.
It’s also worth checking the release notes for older versions. What other useful features might you be missing out on because you were too busy and just accepted the update?
Taking this further, now that much of Drupal 8 core is object oriented it’s time to learn how your editor of choice can help you. One example is that the little icons that appear in the gutter next to method and class definitions are shortcuts to jump to classes, interfaces or methods that override or implement the current code or that the current code overrides or implements. This is particularly useful if you’re unsure what a required method should do. Jump up to the interface that requires it and, if that doesn’t explain, jump to other classes that implement it to see how they work. No more (or at least, considerably less) searching for strings to find other modules implementing the hook you’re trying to use.
Keep watching the skies
I’m sure we’ll still be finding new tools and tips when Drupal 9 is arriving so make sure you’re not bashing at a problem with a rock when a fancy screwdriver is available. Admittedly, new tools can sometimes require more effort to learn than the benefits to be gained but if you don’t look you’ll never know. It’s always worth having a look around and, with Drupal 8 opening us up to more PHP tools, there are so many more to look at.
