dylan's blog

Now that the Drupal community's migration to Git is in full swing, it's a great time to switch your own projects as well. Curious? Perhaps you saw the Git panel in San Francisco, or maybe you've listened to Sam Boyer campaigning passionately at your local DrupalCamp. Is there a rebel in your office who keeps going on about how much better life can be with git-svn? (How ironic that Subversion is now the establishment.)

If you're just getting started, here are some tips I've collected over the last year. Or if you're already a Git ninja, here's how you can help.

If you are using Ubercart to do ecommerce with Drupal, be sure to use one of the mainstream payment gatways: Authorize.net or Paypal.

While Ubercart does support a number of alternative payment gateways, the dangers in going with these alternatives are significant. Here's an example of a single day where two of the less well known Ubercart payment modules were exposed as having flaws that allow people to checkout without needing to pay:

A previous post described how to reposition node comments with Drupal's hook_menu_alter(), to facilitate a tabbed interface. One side effect that popped up was pagers – when a pager link was clicked, the tab state got reset. The solution was to refresh the #comments div with AJAX. As an interesting twist, it uses the ability of jQuery's $() to construct a new DOM object from HTML. This means that no new menu callback is needed in Drupal; it fetches the comments directly from the href in the pager link. While a little inefficient, this technique has the cool benefit of being able to grab any content from anywhere on your site, with merely a URL and a selector. It also degrades gracefully for non-javascript users; since without JS the tabs appear as sequential blocks the pager will function normally.

(The following code is based on the AJAX Comments project).

Here's a tiny shopping cart block for Ubercart that fits right in with the menu. Of course the standard block could be themed this way, but this is handy when the design calls for the full-sized block elsewhere in the layout.

In the discussion following my last post about cron and the cache hit rate, I promised to do some testing of the different cacherouter backends, as well as Boost. Again, these tests focus on the needs of a smallish site with 500 nodes and 1200 requests per day. Boost is the clear winner for response time (which shouldn't be a surprise given that it allows the web server to deliver HTML files directly from disk). What's interesting though is that the response times are all close enough that it doesn't really matter what caching backend you choose (An end user cannot perceive the difference between 6ms and 2ms, and throughput isn't an issue at this scale). The only factor that's really relevant is how good your system's cache expiration and regeneration logic is. I haven't yet had a chance to explore this aspect in detail, but it seems like Boost is the clear winner here as well.

By default, Ubercart sets the breadcrumb on the checkout page to simply "Home", which I personally find a bit odd. Because it calls drupal_set_breadcrumb() late in the request cycle, it's not even possible to create menu links for use by the menu_breadcrumb or menutrails modules. Stranger still, the cart settings page offers a "Custom cart breadcrumb" text and URL option, but it's hard-coded to use a single link instead of a trail of links.

Here is a small snippet that will set the breadcrumbs to mimic the URL paths, for example:

Home › Cart › Checkout

A lot of what's written about performance tuning for Drupal is focused on large sites, and benchmarking is often done by requesting the same page over and over in an attempt to maximize the number of requests per second (à la ab). Unfortunately, this differs from the real world in two key ways:

1. Most of our projects aren't regularly driving traffic at millions of hits per day.
2. Our users request a lot of different pages.

In this post I'll model a site with 500 nodes, and 1200 hits per day. That's fewer than 1 request per minute, yet for many small businesses this would be a fairly healthy traffic flow. In this case, it might at first seem that high performance doesn't matter. A clever hacker could probably manage to install Linux on the office coffee maker and get acceptable HTTP throughput. However, latency still matters a great deal, even for small sites:

User impatience is measured in units of 1 tenth of a second starting at 200 milliseconds or so.

Drupal's page cache is capable of delivering blazing fast response times, but only when the cache is warm. And the reality for most small to mid-sized sites is the page cache is being cleared out far quicker than it's regenerated.

A strange quirk in Drupal 6 hard-codes comment rendering into the node module. This makes it quite difficult to reposition comments, for instance under a set of tabs in the node template. Attempting this brings you crashing into the most dreaded rampart of Drupal theming; moving something out of it's vertical stack:

comment_render($node) can easily be placed in your node template, but how on earth can the original display be removed? comment_render() is called by node_show(), which contains this nugget:

if (function_exists('comment_render') && $node->comment) {
  $output .= comment_render($node, $cid);
}

While it's tempting to fake it with jQuery, or CSS positioning, there is a way to fix this by overriding the page callback for node rendering. Here's a quick module that implements this solution:

In my last post, a basic intro to to running cap deploy was presented. Now, let's look at some more advanced scenarios. (See Part 1 for the actual task definitions described here).

• Multistage: Deploy to different environments (such as testing vs. production).
• Drush Integration: Use the power of Drush to extend Cap's reach into Drupal's internals.
• Multisite: Run many sites from a single code base.

I'm a big fan of having an automated deployment process. It's really the web development analog to the "one step build process", as described in the Joel Test. In the past I have used various shell scripts to perform this task, but I have recently become a convert to Capistrano (or "cap" for short). With Capistrano, uploading your code to the test server is as simple as typing cap deploy. When you're ready to launch in production, it's just cap production deploy.

From capify.org:

Simply put, Capistrano is a tool for automating tasks on one or more remote servers. It executes commands in parallel on all targeted machines, and provides a mechanism for rolling back changes across multiple machines.

In detail, here are the features that got me hooked. There's a lot more that cap can do, and I'll describe some more tricks in part 2 of this post.

• Atomic deployments with error checking. Cap uses a set of symlinked directories, and the links are updated during the final step. It also won't allow a deployment to keep plowing ahead if an intermediate step fails. This makes your deployment atomic; it will either fail or succeed entirely.
• Fast rollback. If something does go wrong, getting back to the previous state is as simple as cap deploy:rollback.
• Parallel execution. If you use multiple servers in a load-balanced environment, cap can make managing them easier.
• Multistage deployments. "Stages" are different server instances of your code. You may have different servers for development, content entry, and production. With the Multistage extension, cap can share code for common tasks between these stages.