Chapter Three LLC

howto

HOWTO: Quick jQuery Usability Tip: Automatically Clear/Restore Useful Default Values

Josh Koenig

Just wanted to post this quick trick I’ve been using lately to automagically hide/show useful default text field values (e.g. “Search” in the search box) using jQuery and the ultra-handy Drupal.settings() object.

Here’s the short and sweet copy/pastable jQuery code:

$(document).ready(function(){
  Drupal.settings.inputDefaults = {}
  $("input:text").focus(function() {
    var element = $(this);
    Drupal.settings.inputDefaults[element.attr("id")] = element.val();
    element.val('');
  });
  $("input:text").blur(function() {
    var element = $(this);
    if (element.val() == '') {
      element.val(Drupal.settings.inputDefaults[element.attr("id")]);
    }
  });
});

Basically this quick snippit will add a blank array object (ahh, the joys of moving between js and PHP) to the Drupal.settings object — which is useful for all sorts of great javascript functionality, and is integral to Drupal 6.0’s extended AHAH features; if you don’t already know it, do your self a favor and study up — and automatically fill it with any textarea’s default values when a user clicks/tabs it into focus. This lets us clear the default value, but replace it quickly if the user moves on to another element.

As listed, you probably don’t want this on your site, as it will affect things like editing nodes (e.g. title inputs will go blank when you click on them… not what you necessarily want), but it’s easy to tune this to only hit elments within certain forms since every form in Drupal has a unique #id.

Thinking about this, I decided to tune it up and actually make an extended jQuery function for this so it could be more easily applied to speecific elements like so:

$(document).ready(function(){
  // handle hide/show for text field default values in only one form
  Drupal.settings.input_defaults = {};
  $("#specific-form input:text").clearDefaultText();
});

jQuery.fn.clearDefaultText = function() {
  return this.each(function(){
    var element = $(this);
    Drupal.settings.inputDefaults[element.attr("id")] = element.val();
    element.focus(function() {
      if (element.val() == Drupal.settings.input_defaults[element.attr("id")]) {
        element.val('');
      }
    });
    element.blur(function() {
      if (element.val() == '') {
        element.val(Drupal.settings.inputDefaults[element.attr("id")]);
      }
    });
  });
}

This is a pretty nice little plugin, I think, and it shows just how easy it can be to add nice/reusable UI functionality. Happy Drupaling, and go get ‘em jQuery!

(updated w/slight improvement to jQuery fn)
(updated again w/object style improvements from comments)

HOWTO: Fully Theme and Customize the Drupal User Registration Form

Matt Cheney

Just a little to the left please. Flip it around. Put that on top of this. Call it by a different name. It is the little changes, that seem trivial and small, that often end up being real headaches to make and support our clients in making. Do we really want to try to build capacity with clients by teaching them to adjust #weight in hook_form_alter?

The Drupal Theming System is pretty powerful and, when done right, can offer a good avenue for our clients and their staff to edit, modify, and change their own website content. Its a lot easier to modify HTML files than Drupal module files.

A good example of where this kind of process is needed is on the user registration page. There are a lot of little bits of language and ordering to change and add, but to do so in Drupal module code can get a little hairy. Observe our technique to abstract the user/register form into a flat template file (while maintaing most of the other good Drupal goodness).

Step One: Create a theme override in your module code for the user/register form that executes a _phptemplate_callback to use a separate template file.

<?php
function theme_user_register($form) {
 
$vars = array();
 
$output _phptemplate_callback('user_registration_form', $vars);
 
$output .= drupal_render($form);
  return
$output;
}
?>

Step Two: Expand the theme override function made in step one to remove the titles and descriptions Drupal provides for the form elements. We do this in the theme function (instead of in a hook_form_alter) to preserve the original field titles so they can be used as part of any error messages coming out of form validation.

<?php
 
foreach($form as $key => $value) { // loop through top level
   
if (is_array($form[$key])) {
     
$form[$key]['#title'] = '';
     
$form[$key]['#description'] = '';
      foreach(
$form[$key] as $key2 => $value2) { // loop through second level
       
if (is_array($form[$key][$key2])) {
         
$form[$key][$key2]['#title'] = '';
         
$form[$key][$key2]['#description'] = '';
        }
      }
    }
  }
?>

Step Three: Create "rendered" versions of each of the form elements and set them as variables that can be passed to the template file.

Note: This can also be done with a generic foreach loop (similar to the one in step two) that renders each form element automatically.

<?php
 
// Set up the Vars Array
 
$vars = array();

 
// Render Specific Fields You Want on Your Registration Form
  // note - the specific location of the element in the form array varies
 
$vars['name_element'] = drupal_render($form['account']['name']);
 
$vars['mail_element'] = drupal_render($form['account']['mail']);
 
// continue for each field you want...

  // Don't Forget the Submit Button 
 
$vars['submit_button'] = drupal_render($form['submit']);

?>

Step Four: Create a template file in your site's theme directory to build the user/register form with the customized variables we defined in step three.

Note: This file needs to be the same name as specified in the _phptemplate_callback (example: user_registration_form.tpl.php).

<div class="user-register-element">
  <label>Enter a screen name:</label>
  <div class="user-register-element-input">
    <?php print $name_element; ?>
  </div>
  <div class="user-register-element-description">
    Screen names can be up to 13 characters in length.
  </div>
</div>

<div class="user-register-element">
  <label>Enter an Email:</label>
  <div class="user-register-element-input">
    <?php print $mail_element; ?>
  </div>
  <div class="user-register-element-description">
    Emails must be valid.
  </div>
</div>

<?php // continue on for each rendered form element ?>

The drupal magic here is that the user registration form is now uniquely customizable by anyone who can edit the theme template. This allows for customized "prompts" for each profile field element, without changing the site-wide field name in admin/user/profile, and it allows for customization of the username and email titles and descriptions.

This technique will need to be modified to support external modules that modify the user/register form like LoginToboggan. It also needs to take into account things like "required" fieldstates.

HOWO: Use Drupal For HTTP Authentication

Josh Koenig

Very often, a Drupal website is just one of many tools being deployed on a complex project. For instance, on Chapter Three’s development servers, we keep our own SVN repositories to track custom modules and theme development.

Also often, miscellanious web services like this will want to use the standard HTTP Authentication system. Most simply this is the familiar pair a .haccess and .htpasswd file protecting a directory. Easy to set up, but it requires an admin to keep yet another list of usernames and passwords somewhere on the system which over time becomes quite a pain.

Today, while noodling with some authentication scripts for the Drupal Dojo, I decided to see if Drupal’s own user table could be used as an authentication source for these tasks. Turns out it can, and it’s pretty useful too.

Drupal User Authentication
First off, this requires mod_auth_mysql to be set up in your Apache server. There are packages for most systems, as this is a common and widely used Apache module. Once this is done, use the following code in a .htaccess file or Apache <Directory> or <Location> directive:

AuthName "Use Your Drupal Login"
AuthType Basic
AuthMySQLEnable On
AuthMySQLHost <hostname>
AuthMySQLDB <database>
AuthMySQLUser <user>
AuthMySQLPassword <password>
AuthMySQLUserTable users
AuthMySQLNameField name
AuthMySQLPasswordField pass
AuthMySQLPwEncryption md5
require valid-user

Replace the hostname, database, user and pass values just as you would when configuring your drupal installation’s setting.php file. This will let Apache access the same users table from Drupal and authenticate against it!

Limiting Access By Drupal User Role
For extra credit, you can restrict valid logins to a particular user role by replacing the AuthMySQLUserTable directive above with these two lines:

AuthMySQLUserTable "users, users_roles"
AuthMySQLUserCondition "users.uid = users_roles.uid AND users_roles.rid = 3"

The above assumes that your “admin” role has role id (rid) 3. Your mileage may vary here, and savvy SQL query writers will immediately see how you can use these two directives to limit access in all sorts of ways.

For admins with a lot of experience with mod-auth-mysql, this is all pretty obvious, but I hadn’t seen documentation specific to Drupal anywhere on the web. Hopefully this will simplify your life as much as it’s already simplifying mine!

HOWTO: Keeping Drupal on Your Keychain

Matt Cheney

I am sure it’s a common problem. You are a rocking Drupal software engineer and you are talking to a particular cute guy or girl at a pretty awesome party. Naturally, the conversation turns to open source software projects and you boast that you work on Drupal - the coolest content management system out there. Since this boast is bound to be followed up with questions like “what is Drupal?” or “why is Drupal cool?” - wouldn’t it be grand (instead of trying to explain just how cool the garland color picker is) to whip out a portable USB key, stick it in an available computer, and show them the wonders of Drupal right then and there?

Install Ubuntu onto a USB Key

  • Download Ubuntu and mount [mount -o loop ] the image
  • Use fdisk [fdisk /dev/sda] to delete any existing partitions [fdisk: d], add a new partition [fdisk: n,p,1,*enter*,+700M], set its type to FAT16 [fdisk: t,6], and make it active [fdisk: a, 1], add another partition [fdisk: n,p,2,*enter*,*enter*], and save all the changes [fdisk: w]
  • Install the FAT16 filesystem [mkfs.vfat -F 16 -n usb /dev/sda1] and the ext2 filesystem [mkfs.ext2 -b 4096 -L casper-rw /dev/sda2]
  • Install the Linux System Tools [syslinux -sf /dev/sda1]
  • Mount the USB Key [mount /dev/sda1 /mnt] and copy over Ubuntu [cp -rf casper disctree dists install pics pool preseed .disk isolinux/* md5sum.txt README.diskdefines ubuntu.ico casper/vmlinuz casper/initrd.gz install/mt86plus /mnt]
  • Copy this special file to the USB key [tar xf usyslinux.tar ; cp syslinux.cfg /mnt]
  • Run Lilo [lilo -M /dev/sda]

These instructions and system file are adapted from this tutorial. For the purposes of these directions the USB drive is assumed to be at /dev/sda.

Install and Configure the LAMP Stack

  • Install the stack [apt-get install php5-mysql mysql-server php5 apache2]
  • Enable Apache’s mod-rewrite [ln -s /etc/apache2/mods-available/rewrite.load /etc/apache2/mods-enabled/rewrite.load]
  • Allow .htaccess overrides in apache’s configuration file [vim /etc/apache2/sites-available/default] by changing all “AllowOverride None” configurations to “AllowOverride All”
  • Edit your /etc/rc.local file [vim /etc/rc.local] to add the following line [mount /dev/sda2 /mnt], run the command on the command line [mount /dev/sda2 /mnt], and add a web root directory [mkdir /mnt/webroot]
  • Edit the Apache configuration file to point to your new webroot [vim /etc/apache2/sites-available/default] to change all references to /var/www to /mnt/webroot. ** Note - its important to setup a separate webroot on the ext2 system since apache is not a fan of the FAT16 filesystem **

Install and Configure Drupal

  • Create your MySQL database [mysql -u root], set the appropriate permissions, and copy over your Drupal database (or install a new one)
  • Copy over the Drupal code files to your webroot at /mnt/webroot
  • Do any other Drupal configuration needed

Set up “Kiosk Mode” in Linux

  • Create a shell script [vim /home/ubuntu/kiosk.sh] to execute [/usr/bin/firefox —fullscreen http://127.0.0.1] ** Note - sometimes it takes a second for apache to load and the script may need “sleep 30” at the beginning to give apache time to load **
  • Configure Ubuntu at (System —> Preferences —> Sessions) to run the kiosk.sh script at Startup
  • Install the AutoHide Firefox Extension
  • Add a line [rm /home/ubuntu/.ICE*] to your GDM runtime to remove ICE Authority File Locking Issues [vi /etc/gdm/PreSessions/Default]

To boot off of the USB key, insert the USB key into a computer and set its BIOS to boot from the USB key. Wait a couple of minutes for it to boot up and enjoy the Drupal.

HOWTO: Use Different Node Templates by Node Variables (nid, type, view)

zirafa

With node template files you are often limited to something like node.tpl.php and node-blog.tpl.php. Often times it’d be nice to make a different template for just one specific node or a different template for teaser/list view and full node view.

Using the PHP code below, Drupal will look for these template files, split by page or no page view. This gives more fine grained control over your node tpl.php files.

Page view:

1) node-[nid]-page.tpl.php
   Node by itself on a page, specific NID
2) node-[type]-page.tpl.php
   Node by itself on a page, specific type
3) node-default-page.tpl.php
  Node by itself on a page, default

Listing/Teaser view:

4) node-[nid].tpl.php
   Node in list/teaser, specific NID
5) node-[type].tpl.php
   Node in list/teaser, specific type
6) node.tpl.php
   Node in list/teaser, default.

*UPDATE* Earl Miles has shown this can be done much simpler than what I had previously. Revised code below.

Place this code in your template.php file in your theme’s directory.

<?php
function _phptemplate_variables($hook, $vars = array()) {
  switch (
$hook) {
    case
'node':
     
// Here is the way to switch to a different node-<something> template based on node properties.
     
if ($vars['page']) {
       
// This is LIFO (Last In First Out) so put them in reverse order, i.e
        // most important last.
       
$vars['template_files'] = array('node-default-page', 'node-'. $vars['node']->type .'-page', 'node-'. $vars['node']->nid .'-page');
      }
      else {
       
$vars['template_files'] = array('node-'. $vars['node']->nid);
      }
      break;
  }

  return
$vars;
}
?>

HOWTO: Write Cleaner tpl.php Files

zirafa

The PHPTemplate system in Drupal is a powerful theming system. However, because it is written in PHP it is easy to abuse since it is possible to directly inject PHP logic into the templates. This often creates the effect of HTML-IN-PHP which is not good.



HTML-IN-PHP:

<?php
print '<h2 class="title">'. $title .'</h2>';
?>

PHP-IN-HTML:

<h2 class="title">
<?php print $title ?>
</h2>

Which do you think a themer who understands HTML/CSS will understand better? Of course the second, because it is mostly HTML and the themer can modify the HTML tags quite easily.

Conditional Statements

Another example of this is with logic statements.

HTML-IN-PHP:

<?php
global $user;
if (
$user->uid) { ?>


<h2 class="title">You are now logged in!</h2>

<?php } ?>

PHP-IN-HTML

<?php global $user; ?>
<?php if ($user->uid): ?>

<h2 class="title">You are now logged in!</h2>

<?php endif; ?>

See how the second example is easier to read? It’s also broken up into small pieces that a themer can move around quite easily. Having open and closing braces for an if statement is really hard to follow. But if(conditional): and endif; statements are easy to read, and “chunkify” or “modularize” the text in a clear way.

<?php if ($test == TRUE): ?>

<!— Block of HTML to printout if TRUE —>

<?php endif; ?>

PHPTemplate variables

The last thing that can make your life and the themer’s life easier is to pass variables to the template files using phptemplate_variables. A tpl.php really should be mostly simple conditional statements and print statements. If you have PHP code spanning multiple lines or are working with arrays or something, you can probably pull that code out of the tpl.php and put it in template.php.

Example Node.tpl.php with too much PHP

<?php
if ($node->field_related[0]['nid']) {
 
$related_cck_node = node_load($node->field_related[0]['nid']);
  print
'<div class="related-cck-link">';
  print
l($related_cck_node->title, 'node/' . $related_cck_node->nid);
  print
'</div>';
}
?>

Why is all that logic in the tpl.php? You can move that out into template.php.

Using Template.php to add variables to your tpl.php files

<?php
function _phptemplate_variables($hook, $vars = array()) {
  switch(
$hook){
    case
'node':
      if (
$vars['node']->field_related[0]['nid']) {
       
$related_cck_node = node_load($vars['node']->field_related[0]['nid']);
       
$vars['related_cck_link'] = l($related_cck_node->title, 'node/' . $related_cck_node->nid);
      } 
      break;
  }
  return
$vars;
}
?>

Now the node.tpl.php file will get a new variable called $related_cck_link which you can easily print out.

Example Node.tpl.php file with logic removed

<?php if ($related_cck_link): ?>
  <div class="related-cck-link">
    <?php print $related_cck_link ?>
  </div>
<?php endif; ?>

HOWTO: Quickly Truncate a Block of Text

zirafa

When theming things I run into situations where a block of text is too long and I need a really quick way to truncate text and append an ellipses or custom trailing text. The built in drupal teaser truncates text in a much more logical manner (watches out for html tags and the like) while this php snippet is simpler and meant to run on pure text. You can do strip_tags() if you want to remove all the html tags before running this code on your piece of text. I often just drop this into my template.php and use it in various spots in the theme.

<?php
/**
* Truncate the string if it is beyond a certain $length and append with an ellipses or custom text
* $length is the number of characters allowed before truncating
* $append is appended to the truncated string
*/
function your_theme_custom_truncate($string = '', $length = 30, $append = '&#8230;') {
  return
strlen($string) > $length ? trim(substr($string, 0, $length)) . $append : $string;
}
?>

Before:

Suspendisse potenti. Ut tempus auctor libero. Aliquam molestie dolor quis lectus. Curabitur et erat eget lorem nonummy ultrices. Mauris interdum. Etiam imperdiet viverra purus. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Mauris sem mauris, feugiat at, dictum vitae, placerat nec, odio. Nulla fringilla. Morbi justo nulla, commodo quis, ultricies a, eleifend eu, ante. Morbi eget erat eu ante tincidunt interdum. Nullam at est. Nulla ultrices pede vitae sapien bibendum bibendum. Quisque turpis enim, ullamcorper at, fermentum quis, vulputate quis, libero. In facilisis, dui eget accumsan molestie, justo metus tempor quam, eu tempor ipsum eros a urna. Donec aliquet. Curabitur condimentum volutpat augue. Praesent bibendum commodo enim.

After:

Suspendisse potenti. Ut tempus auctor libero. Aliquam molestie dolor quis lectus. Curabitur
et erat eget lorem nonummy ul…

HOWTO: Creating a URL Shortcut for Drupal API Documentation in Firefox

Josh Koenig

Every Drupal developer/hacker knows (or should know!) about the fantastic API Documentation the project has. This growing collection of documentation is one of the top reasons that Drupal continues to grow and expand as quickly as it does. It makes it very inviting for engineers to start getting savvy.

This started out more than a year ago as an independent project called “drupaldocs.org,” and at that time there was a neat feature that let you type drupaldocs.org/function_name into your browser’s location bar, and it would pull up that function, or search for function names containing whatever you typed if no exact match was found. This is similar to how php.net works (try php.net/preg_replace for instance), and it’s a really nice thing for developers like me who elect to outsource memorizing engineering minutia like argument-order and specific syntax to the collective intelligence.

However, with the launch of api.drupal.org, the old style of finding functions went away. Alas! For months I despaired, until some of the heads in #drupal (developer chat channel) clued me in to a great feature in Firefox that lets you define wildcards in bookmarks.

FF bookmark for drupal api

As it turns out, there still is a url that you can add a function_name to on api.drupal.org to perform a quick search, but it’s http://api.drupal.org/apis/4.7/function_name (or http://api.drupal.org/apis/HEAD/function_name if you want to search the budding 5.0 code). Using Firefox’s bookmark interface (see the image there), I created a bookmark with a wildcard (%s) and a keyword (api). This lets me type “api function_name” into my browser toolbar, getting access to the documentation faster than ever!

While many engineers with a background in big-league IT will probably remain committed to Integrated Development Environments, collecting little tips and tricks like these can give us upstarts and new-schoolers a lot of power and flexibility without very much work at all. Happy drupalling!

HOWTO: Liberating the User Picture Upload Interface

Josh Koenig

One of the things that makes Drupal such a powerful platform for building community websites is its robust and scalable user system. Its got everything you need to start popin’ and lockin’ built right into the core framework: unlimited user roles, granular permissions, easily extensible profiles and more.

Avatar upload screen

Still, as hookable and mashup-friendly as it is, there are a number of things that Drupal core has a stubborn hold on. One of these is the user-picture (aka avatar) upload interface. The picture system is very well implemented — it will resize uploaded images, display them in posts and comments automagically, etc — but the user-interface for you to actually put up your picture is locked onto the catch-all “account settings” part of the user/edit interface, which can get pretty cluttered if you’ve got a lot of modules throwing their settings in there.

In future (5.0+) revisions, I’m sure that the already-awesome profile system will grow and allow site admins to easily reposition all user-account elements, but yesterday I had a need to move that user-picture upload field into it’s own page, and so I did. Less than 50 lines of code, too. Here’s how:

HOWTO: Smart Login Menu Hook

Matt Cheney

It is a neat property of Drupal that you can define a menu item pointing at “logout” that, because of its permissioning, only shows up to users who are logged-in (and in need of logging-out). This same trick, sadly, does not work for login because “user/login” is accessible to both logged-out users (as the login page) and to logged-in users (as their profile page) - so it shows up all the time which can be sort of confusing.

One solution is to employ the following menu hook to create the location “login”. Then you can set up two menu items (Login pointing to “login”, Logout pointing to “logout”) which will smartly switch placement depending on the logged-in/logged-out status of the user. Just throw the following code in a module and away you go:

function smartlogin_menu($may_cache) {
  $items = array();
  global $user;
  if ($may_cache) {
  $items[] = array(
    'path' => 'login',
    'title' => t('Login'),
    'callback' => 'drupal_goto',
    'callback arguments' => array('user/login'),
    'access' => ($user->uid == 0),
    'type' => MENU_CALLBACK);
  }
  return $items;
}

Syndicate content