drupal

When discussing the benefits of open-source frameworks (especially Drupal), I've often heard, "But if everyone has access to the source code, how secure can it possibly be?" My standard response would be to discuss the platforms maturity and how it's been hardened by years of real world use.

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.

During the theming process for the Emmys, specifically Emmys.com and Emmys.tv, we were presented with 2 differently styled marquees. On Emmys.com, the pager uses an image, while on Emmys.tv, the pager uses number with a background image along with next/previous buttons.

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.

Lately I've been working on a project to allow drupal to intelligently manage legacy data, to display, edit, and work with all aspects of the data as securely as possible. Naturally, it's difficult to say the least but I've learned a great deal. One of the things I thought was going to be a pain but ended up easy was managing where the fields appeared on a form. Yes, I could set the weights manually through the Forms API but CCK actually gives us some really great tools to do this without sweating.

For reference, this is based on the wonderful if totally impossible to find article here: The Great Pretender.

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:

If you have ever spent any time around software development, (especially here in Portland with our amazing open-source community) you'll know that the community takes a great deal of interest in the success of others. With Drupal, I have rarely come across another technology that shares the same sense of nearly parental pride from members of the community.

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.