Tips & Tricks

Benjamin Keen has created a fantastic, customizable bookmarklet that, when clicked, will show the page you're viewing in multiple screen sizes. This makes it easy to check a responsive design in multiple screen sizes as a glance. Very handy, and very simple execution.

Today I'd like to share a technique that we use on every site at Jackson River.

For most projects, we have multiple developers working on different aspects of the site, and each of us has our own local development setup and checkout of the git repository. The problem we ran into, as any Drupal shop will, is the site configuration details included in settings.php, and the way that those need to differ on our various development, staging, and production sites.

On some early sites, we used a switch statement in settings.php that would check the requested URL, and set variables like $db_url depending on that. When a new developer joined the project, they would add a new condition to the settings for whatever URL they were using (we each had our own local naming scheme, whether it was jacksonriver.com, jacksonriver.local, jr.dev, jrdev.local, and so on).

This was a terrible solution, and we stopped using it a long time ago. Instead, on every site we build, the settings file ends with an include:

I've been meaning to write something up about these for a while, because they have made my development flow so much better.

Tab completion

Arguably, the best thing about git is lightweight branches. But, I had been resisting using them, because it was a pain in the neck to keep track of them and re-type or copy-pasta the name for every checkout or merge. I rely heavily on tab completion in the command line, because I know I'll mistype things otherwise, and spend way too much time trying to figure out why something is broke later on - for example, after mistyping the target of a symlink.

As it turns out, git ships with a script to handle tab completion: you just need to find and enable it.

Since I use Homebrew to install and update packages (Mac users: you should too), my git executable is in /usr/local/Cellar/git/1.7.3.4/bin. You need to find git-completion.bash. In my case, it's in a sibling directory: /usr/local/Cellar/git/1.7.3.4/etc/bash_completion.d/git-completion.bash.

This week, I've learning a thing or two about Drupal search indexing. On the search settings page (admin/settings/search) for a client's site, the percentage of the site that had been indexed remained really low, even after running cron a few times. The search functionality still seemed to be working though, so I knew something weird was going on.

What I found was that the search_dataset table had well over a million records in it, so indexing was definitely happening. After checking the code used to calculate the percentage shown in the admin, I found that it only checks published nodes when determining how much content has been indexed - but, the node module chooses from all nodes when choosig a batch to index during a cron run. Since this site had about a thousand published nodes and over 100,000 unpublished nodes (the reason for that is a different story altogether), thousands of the unpublished nodes had been indexed, but not many of the published nodes had.

Display Suite for Drupal 7 included a lot of updates. The big ones are the inclusion of the previously-separate Node Displays and Views Displays modules, and support for more region layouts (the D6 version had a single pre-defined layout).

The feature that's making my life easy today, though, is a little thing: positioning the node post date separately from the node author. This was an option in D6 too, and I knew the module could still do it, but could not for the life of me figure out how. On the Manage Dislpay tab for my content type, my only options were the node body and taxonomy fields.

So, for your reference and mine: Display Suite fields only become available once you choose a layout under "Layout for [node type] in default" on the Manage Display tab.

I have a feeling I'll forget this step in the future, but hopefully I'll remember to look here for the solution!

Xdebug is a must-have for local development, giving you step-through debugging and nicely formatted error messages, among other things. One of the mixed blessings it brings is that it overrides var_dump(). The display is a little nicer than the default, but it also cuts off at the third level of nested arrays or objects. This cuts the legs out from under Drupal developers: everything in Drupal uses nested arrays, and if you're trying to debug a problem or figure out where some data is stored, chances are good that you'll need to go five or six levels deep into an array to find your answer. Thankfully, the Xdebug developers were kind enough to include a configuration settings for this: xdebug.var_display_max_depth. You can increase the depth limit by adding a line to your php.ini file. I bumped the limit to 10 on my machine: xdebug.var_display_max_depth = 10