Tutorials

On most of our projects, at one point or another, someone says "I think there's a module for that", and then they rush off and start searching online. Most of the time, the module DOES exist, and most of the time, it's really easy to find. It's all in the wrist... :)

Since Drupal.org's new theme was released, the search and filtering capability has improved tenfold. If you're like us, however, you use Google for just about everything. This is just a quick little guide on some of the tricks we learned early on that made searching for Drupal themes and modules much faster.

If you're familiar with Varnish, you're well aware of its awesomeness. It can turn your site from a slowpoke into a speed demon. We recently observed a site (which we didn't build) that was, under load, taking about 800ms to respond per request. In went Varnish, and the response time for 99% of the requests dropped to just over 2ms. Kind of a "Holy crap!" moment.

Sometimes though, you might run into some issues when trying to configure Varnish. One of these instances is when you need it to provide different caches in different circumstances. For this tutorial, we'll be focusing on configuring Varnish to provide a cache per group of devices, defined by user agent. Why is this important? Well, what if you want a different theme for each of these scenarios? Without adding some mechanism to handle this, Varnish will just cache the first thing it sees and serve it out to all of the devices.

Unless you're familiar with the linux command-line, setting up file permissions can be tedious and difficult. Add a migration into the mix and it becomes very easy to have a Files directory that isn't writable by the web-server. This tutorial is meant to make this process a bit easier and leave you with a files directory that is not only writable by the webserver, but includes a "sticky" permission to ensure that all files created inside of it inherit the proper read/write access permissions.

Replacing usernames with real names sounds like it should be easy, and it is. It hasn't always been this way, though. Once upon a time you'd need to create a theme override in the theme's template.php, which is understandably scary to non-developers. We've put together this quick tutorial to help guide you through the simple process of getting this working on your Drupal environment.

Out of the box, Drupal provides the ability to create page templates for different pages/sections. However, its flexibility is relatively limited, in our opinion. This page on drupal.org shows the following page.tpl.php naming conventions and uses:

This is an interesting list. While it does accommodate for quite a bit, it misses a few seemingly obvious use-cases. Now, this of course depends on your site and its needs. It may suit your purposes just fine. On the off chance it doesn't, however, take a little trip with us down the rabbit hole and find out how to create your own page templates for literally ANYTHING you want.

Typically, regions are returned in a theme's page.tpl.php file. This works for almost everything, but as we found recently, there are situations where a region might need to be made available to the node.tpl.php file for the purpose of more specifically control a block's location within a node. A good example of this is a node that has comments enabled. The node content and its comments will appear one after the other, both being returned by the value $content in the page.tpl.php. How to add a block between them?

First, we want to prepare the theme to accept our node-based region. This will involve defining a new region, overriding the default node.tpl.php file, and creating a theme override. Then, it's just an issue of modifying the node template to print the region correctly.