Customizable Header Images for Your Drupal Theme
The dark days of Drupal theming are history. Today, it's pretty easy to find a slick design for your site, and if you need to build one from scratch there are great training tools to make the process painless. (Shameless plug: Lullabot's Theming Basics and Advanced Theming DVDs are a great resource!)
What's still relatively uncommon, though, is support for user-friendly customization by non-designers. Drupal 5 shipped with the re-colorable Garland theme, and a handful of themes support the same feature via Color module. The Nitobe theme offers a choice of header images; Development Seed's Singular theme lets administrators upload a custom background image for a site; and TopNotchThemes' Fusion theme allows administrators to choose fonts and switch from fixed-width to liquid layout using a settings screen.
Adding these kinds of customization options to a theme can make a huge difference in usability for end users and administrators. In this article, we'll learn how to add a "header image" setting to a theme, allowing a site manager to change the site's header from the administration screen!
read more »Single Sign-on across Sub-Domains in Drupal with No Extra Modules
With the multitude of single sign-on modules out there for Drupal, it's easy to miss the fact that Drupal has a built-in single sign on mechanism already. No modules, no configuration, just 20 easy lines of PHP in your site's settings.php file. This solution works for a lot of clients, but the set of requirements is pretty specific as to when you can use this approach. This includes:
- The sites sharing a single log-in must be on the same domain. For example:
www.example.comforums.example.comsubsite.example.com- You must be using MySQL.
- Your sites must be on the same hardware cluster to be able to query each other's databases.
If your site fits within those requirements, you're on your way to simple, efficient, and easy Single Sign-on!
The concept for this single sign-on approach is based around Drupal's ability to prefix database tables. As you may know, you can run multiple Drupal sites on the same MySQL database. However, most sites are not configured this way, each site is given it's own dedicated database. Drupal's table prefixing can be combined with MySQL's ability to query across databases to make a simple "shared table" across multiple sites. Then you just need to set a cookie domain so that the two sites share session information and you're done!
read more »Analyze This! Using the Google Analytics API
Google Analytics is a great way to monitor site usage and traffic. You add Google Analytics to your site using the Google Analytics module, which is super simple to set up. After it's in place, you can go to the Google Analytics site and dig into a ton of data, create custom reports, etc.
But you can also use the Google Analytics API to pull Google statistics into your own site and display them there. There is a Drupal module, Google Analytics API that was created by Joel Kitching as a Google Summer of Code project. It provides a wrapper you can use to create tailored queries of your analytic data. You can turn on the included 'Google Analytics API Reports' module to display Google statistics in blocks or pages right on your site, and/or create custom code to suck in specific statistical data and do any Drupally thing you like with the results.
read more »User Management for Real World Groups
Drupal's default methods of handling user names, emails, and registration processing work pretty well out of the box for many web sites. Drupal assumes your users are online, have unique email addresses, and that you want to create a site that grows organically as users find it and register themselves. Drupal out of the box may not work so well for real-world groups of people where the group already exists and consists of specific people who may or may not be online, may or may not have unique email addresses, and may or may not be able or willing to register themselves on your site.
Some good examples of the problems I have run into are creating web sites for families, clubs, and churches, but the same problems exist for any other real world organization or group. They have established groups of members, some of whom may share email addresses or have no known email address. And in these cases the administrator will probably create user accounts for everyone rather than waiting for users to self-register. On top of that, we may want some control over usernames so that users can recognize each other once they do get online, by forcing the username to be FIRSTNAME LASTNAME.
This creates several problems that have to be overcome creatively. After several years of trying various approaches, here is a summary of the problems I ran into and the ways I eventually solved them. I have included links to the ones I discuss, with the number of downloads in the week of November 22 as a measure of how commonly used they are.
read more »Drupal data imports with Migrate and Table Wizard
If you haven't yet heard the buzz that's been building since Drupalcon DC in March about the fabulous Migrate and Table Wizard modules, written by the smarties at Cyrve, then here are a few questions for you:
- Does the phrase "data migration" conjure up images of being repeatedly stabbed in the knee with a rusty fork? (which would of course be a far more enjoyable experience!)
- Have you spent countless hours sifting through record after record of your clients' legacy data, pining for an easy way to catalog it all so you (and they!) can both tell what's really important to pull over?
- Do you lose years off of your life every time you attempt a bulk migration, hoping for the best that there are no horrific bugs that need to be sorted out afterwards that you didn't catch in testing?
- Have you had it up to here with having to go and find separate modules, each with totally different interfaces and levels of bugginess, for importing nodes, taxonomy, users, and so on?
If you answered yes to any of these questions, then the Migrate and Table Wizard modules are for you! Read on to learn how they work and try a "hands on" example.
(Note: This article is written against the current -dev releases of both Table Wizard and Migrate, which will eventually become Migrate 6.x-1.0 and Table Wizard 6.x-1.2. Final screen shots may vary.)
read more »Drupal Performance Tip: Block Visibility
This is something we hit a lot when doing performance analysis on very slow websites, so I figured I'd issue a public service announcement. :)
It's not uncommon in more complex themes to have many different block regions, and even dynamic regions that will only appear on certain pages or when viewing nodes of certain types. One very common use-case is to have both a page.tpl.php, and a page-front.tpl.php, each of which print out different regions, particularly for ads or promotions:
Defining block regions is super easy; simply add a couple lines in your theme's .info file:
regions[ad_top] = Ad Top
regions[ad_bottom] = Ad Bottom
regions[front_sidebar] = Front Sidebar
regions[sidebar_ad] = Sidebar Ad
regions[content] = Content
regions[feature_a] = Feature A
regions[feature_b] = Feature B
regions[feature_c] = Feature C
regions[feature_d] = Feature DAnd then in your *.tpl.php file, wherever you want the region to appear, simply print out its machine-readable name:
<?php
print $feature_a;
?>Don't want the blocks in the "Feature A" region to show up in page.tpl.php? No problem! Just don't print the region out there! Done! Right?
read more »My Aha! moments in Drupal theming
While at Drupalcamp Copenhagen I got into a few conversations about Drupal aha! moments, particularly around theming. After trying to talk in the abstract about the things that finally "clicked" for me when I was learning Drupal, I offered to write it up with some specifics. So, for my Danish buddies and any other curious Drupalers, these are my two biggest aha! moments that accelerated my Drupal theming ninja skills: "getting" the theme system and working with forms. I've already written about modifying forms and since "getting the theme system" is a big chunk, I'm going to focus just on that moment in this article.
read more »Hacking Views, Part 1: Basic Concepts
The 'Views' module is one of the mainstays of Drupal site building. It allows non-programmers to build highly customized listings of data that match certain criteria, then present that data in a variety of ways. A thumbnail gallery of photos, an alphabetized listing of site contributors, and a calendar display of upcoming events are all common applications of Views.
In this series of articles, we'll be taking a quick look at the architecture of the Views module and how its pieces work together; touring the different plug-in points that Views offers developers; and building a simple 'argument handler' for Views that demonstrates how the approach looks in the real world. A bit of knowledge about SQL will be useful for the article, as well as some understanding of object-oriented programming concepts like 'inheritance', but the code samples should be simple enough to tweak even if you're not a pro.
Under the hood, the pieces of a View can be divided into two different groups: the 'data' (stuff that affects the underlying database query that Drupal uses to retrieve the information for the View) and the 'presentation' (stuff that affects how that data is displayed to a user of the web site).
Buildin' SQL
The 'data' portions of the View are more numerous: they correspond roughly to the different pieces of a SQL 'SELECT' statement. That should come as no surprise -- at Views heart is a SQL query builder that turns all of your settings into a query against Drupal's database tables.
Creating Custom CCK Fields
You can create custom CCK fields, widgets, and formatters for any situation, but it can be hard to see how to do it. I finally found time to create an 'Example' module that creates a simple field, formatter, and widget, with lots of embedded documentation about what belongs where. You need to create three files, an .info file, an .install file, and the module itself. The code below creates a very simple textfield, but it can be used as a starting point for any custom module. I'm also attaching a .zip file with the contents of this custom module.
The .info File
; $Id$
name = Example field
description = Defines an example field type.
dependencies[] = content
package = CCK
core = 6.xThe .install File
<?php
// $Id$
// Notify CCK when this module is enabled, disabled, installed,
// and uninstalled so CCK can do any necessary preparation or cleanup.
/**
* @file
* Implementation of hook_install().
*/
function example_install() {
drupal_load('module', 'content');
content_notify('install', 'example');
}
/**
* Implementation of hook_uninstall().
*/
function example_uninstall() {
drupal_load('module', 'content');
content_notify('uninstall', 'example');
}
/**
* Implementation of hook_enable().
*
* Notify content module when this module is enabled.
*/
function example_enable() {
drupal_load('module', 'content');
content_notify('enable', 'example');
}
/**
* Implementation of hook_disable().
*
* Notify content module when this module is disabled.
*/
The Great Pretender: Making your data act like a field
These days, almost every major Drupal site is using CCK, the module that lets you add custom fields to any content type. Among other things, CCK lets administrators rearrange a node type's contents using a simple drag and drop interface. In the past, this only worked for fields that CCK itself managed. If you worked with a custom module that altered a node's content, it was up to you to manage its position in the node content.
Now, though, it's possible for any module to tie into CCK's field management page to control the positioning of custom content. The key is hook_content_extra_fields(), and in this article we'll show you how to use it.
Twitter
Mailing list
RSS Feed
