In the fast-paced lives of consumers today, everyone is looking for the advantage that a viable presence on mobile devices offers. With projections of mobile web use matching or even exceeding desktop web use in the next few years, mobile applications already exceeding both, and the ever-expanding mobile device market, it’s past time to jump on this bandwagon. The question is no longer whether on not to invest in a mobile presence, the only question now is what that presence should look like, and how can you invest in it wisely.

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 web-server 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: 1. page.tpl.php (global) 2. page-front.tpl.php (front page) 3. page-node-edit.tpl.php (node edit) 4. page-node-[#].tpl.php (specific node) 5. page-node.tpl.php (nodes – global) 6. page-[internal/path].tpl.php (specific path)

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.phpfile 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?

You know that all Google/Gmail accounts are also OpenID identities, right? Well, assuming so, have you ever wondered how you can use your Google/Gmail account as an OpenID sign-in to a website? Here is one way of doing such…

Using Varnish and Pressflow together is an effective way to maximize the potential of your hosting environment, and can yield extraordinary results. The problem is, if you’re not intimately familiar with Varnish, or the Linux command-line, getting it into a functional state can be something of a challenge. Out of the box, it is adequate at caching content for anonymous users, but that’s where the fun ends. On a recently completed (large) Pressflow project, we had to make some decisions about server architecture. Varnish, under heavy load, can suck down memory pretty quickly, so we opted to use two servers. The first one housed Varnish and Memcache, while the second one acted as the application environment (LAMP with APC).