Drupal Dork - Tips & Tricks

Responsive Design Test Bookmarklet

Brock — Fri, 17 Feb 2012 22:54:51 +0000

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.

Local Settings for Development Sites

Brock — Sat, 19 Nov 2011 17:44:17 +0000

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:

@include('local.settings.php');

The @ at the beginning of the line ensures that PHP will not throw an error if the file does exist (details). This way, we can include it in the settings.php file that's committed to git—and used on the server—without it causing any errors, despite the fact that no local.settings.php file will be found on the production server.

Our git repositories are alwyas set to ignore the local.settings.php file. That way, each of us has our own copy with our own database credentials and other settings, and no one accidentally commits it.

There are a few other settings that I always include in mine. This is what a typical local.settings.php looks like on my machine:

$db_url = 'mysqli://root:rootpass@localhost/client_db_name';

// Make sure I can always run update.php
$update_free_access = true;

// Some sites use memcache, which overrides the cache include file from the core
// Since I don't have memcache running on my machine, I override it back to the
// default, and test caching on the staging server
$conf['cache_inc'] = './includes/cache.inc';

// Make sure I see all the errors I want to
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED);
ini_set('display_errors', TRUE);
ini_set('display_startup_errors', TRUE);

I've found this technique so handy that I regularly add the local settings include on freelance clients as well.

Insanely Useful Tips for Git on the Command Line

Brock — Fri, 13 May 2011 00:52:07 +0000

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.

Once you find it, include it in your .bash_profile, replacing the path specified here with the location you found:

# Use git auto-completion source /usr/local/Cellar/git/1.7.3.4/etc/bash_completion.d/git-completion.bash

Tab completion works for git commands (reset, status, commit, etc) as well as branch names.

Branch name in prompt

This one would not have even occurred to me, but I came across it in a comment on a Lullabot blog post about git. You can show the current branch in the prompt when in a git repo directory, like this:

brockbookpro:multi_smtp (6.x-1.x) $

Again, modify your .bash_profile to add this:

function parse_git_branch { git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* $.*$/(\1) /' } export PS1="\h:\W \$(parse_git_branch)\$ "

If you're working on a project with a lot of branches, this will make life easier.

Search Indexing: Published vs. Unpublished

Brock — Fri, 22 Apr 2011 15:08:08 +0000

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.

Now, the reported percentage in the admin doesn't really matter that much. I would like for it to give the client accurate information, but it was more important that a user's search would return all available results. If there are published nodes that have not been indexed, then search results will not be accurate.

My quick solution was to make sure that published nodes would be indexed during every cron run, instead of just indexing all willy-nilly. I implemented hook_update_index() by replicating node_update_index(), with an extra WHERE condition to restrict it to published nodes:

function mymodule_update_index() {
  $limit = (int)variable_get('search_cron_limit', 100);

  // Store the maximum possible comments per thread (used for ranking by reply count)
  variable_set('node_cron_comments_scale', 1.0 / max(1, db_result(db_query('SELECT MAX(comment_count) FROM {node_comment_statistics}'))));
  variable_set('node_cron_views_scale', 1.0 / max(1, db_result(db_query('SELECT MAX(totalcount) FROM {node_counter}'))));

  $sql = "SELECT n.nid FROM {node} n 
    LEFT JOIN {search_dataset} d ON d.type = 'node' AND d.sid = n.nid 
    WHERE (d.sid IS NULL OR d.reindex <> 0) AND n.status=1 
    ORDER BY d.reindex ASC, n.nid ASC";
  $result = db_query_range($sql, 0, $limit);

  while ($node = db_fetch_object($result)) {
    _node_index_node($node);
  }
}

With the indexing batch limit set to 100, the site will index up to 200 nodes per cron run: the node module does a hundred nodes without concern for status, and my module takes care of 100 that are published.

Note: the site in question is running Drupal 6.20. It looks like this was fixed in D7: the reported percentage accounts for all nodes.

Display Suite in Drupal 7

Brock — Tue, 19 Apr 2011 01:18:42 +0000

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, var_dump, and nested arrays

Brock — Thu, 23 Dec 2010 16:25:36 +0000

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