Module/plugin details

Drupal Download

WordPress Download

Although this probably can be done in Views, I am none the wiser on how to do it and neither were any of the participants on IRC. So my work around is to use Panels taking advantage of Ctools contexts.

This tutorial is written for Drupal 6.

First of all, we need to download and enable a few modules.

• Ctools – (Chaos Tools, Page Manager, Views Content Panes)
• Panels – (Panels)
• Views – (Views, Views UI)

Once the modules are enabled we can continue.

If you haven’t already, set up your taxonomy vocabulary with terms (they don’t have to be in a hierarchy but I assume most will).

Next we will create our panel pages for the 2 types of term pages. In the image above, we have different types of clothing, most of which have children terms. So we want one page for all the parent terms with the exception of Suits as it doesn’t have any children and we want to show the products in that term, then another page for Suits and all the child terms.

Go to Administer > Site Building > Panels.

On this page, under Manage pages, click the Enable button next to Taxonomy term template. When the new page loads, press the Edit button next to Taxonomy term template.

On this page, click the Add a new variant link.

I will start with the parent terms panel page, so enter in an appropriate admin title and tick the Selection rules box. In the drop down box select Taxonomy: Term and press Add.

In the popup, hold Ctrl and click all the terms that you want this page to apply to and press Save.

Set a page layout type and then add some basic content so that you can test that it is working properly. You will also need to set the Title to %term:name to reflect the standard Drupal taxonomy pages.

Save the page.

Now when you visit one of the parent terms, you will get the custom content rather than the default taxonomy page.

And visiting a child page still displays the standard Drupal taxonomy text.

If this is working, you can repeat the process by adding another Panel variant but this time, under selection rules selected all the child terms rather than the parent terms. Alternatively you could clone the existing variant, then under Selection rules, change the flag to Reverse (NOT), which will also target all the child terms.

Once this is done, your child terms pages will also display some custom text that you defined.

Now that is all working, we can set up our Views.

For the parent terms, we want to display the child terms only, no products. So when settings up the new view, select Term rather than Node.

Add an argument and select Taxonomy: Parent term.

Change the argument to Provide default value then select Taxonomy Term ID from URL.

Set up the rest of the view as you see fit, apply filters etc. Make sure that you add some way of clicking through to the child terms. If using fields, add Taxonomy: Term and make sure the Link this field to its taxonomy term page option is checked.

Save the View.

Now create another view but this time select Node rather than Term. Do the same with arguments and apply any filters, fields etc.

Once you are finished creating your views, head back to Administer > Site Building > Panels and click Edit next to Taxonomy term template.

Select one of the variants on the left and go down to Content. Remove any existing custom block content unless you want to keep it and add a new bit of content. Select Views on the left then select the appropriate view for that variant.

On Select display, just click Continue. On the next page, in the drop box labeled Taxonomy: Term ID:, select Term ID of first term. Repeat for the other page variant.

Now when we visit the taxonomy term pages the correct view will show up depending on what term is being viewed.

Parent item shows the child items:

Children terms show the nodes (in this case the empty text of the view):

You could even change the view for showing nodes of the term, by changing the argument to Taxonomy Term ID (with depth) which will show all nodes for that term and all it’s child nodes, which you could place below the node showing child terms.

Which would result in:

Switching back to Garland and the sidebars disappeared as expected. After a quick search, I found this post on drupal.org which is the same issue but one of the replies essentially says to hack core to get it to work, but that is not necessary.

In Drupal core, it only looks for sidebars named left and right. I have 4 (left_sidebar_primary, left_sidebar_secondary, right_sidebar_primary, right_sidebar_secondary), this allows me to style some blocks easier dependent on their weighting in the sidebars.

The workaround is very simple. All it requires is a few lines in your template.php file in your hook_preprocess_page() function.

If you haven’t that function in your template.php file, then here is the necessary code:

function theme_name_preprocess_page(&$vars) {
  // Code goes in here
}

The code which we need to enter is fairly simple.

function theme_name_preprocess_page(&$vars) {
  if (!$vars['show_blocks']) {
    $vars['left_primary'] = '';
    $vars['left_secondary'] = '';
    $vars['right_primary'] = '';
    $vars['right_secondary'] = '';
  }
}

Here we check to see if the $vars['show_block'] variable is FALSE, if it is then we set the content of all the sidebar regions to nothing.

If you would like to disable more regions, just add them as they are defined in your theme_name.info file.

One other thing to mention is that you need to make sure in your page.tpl.php file that you correctly add the code to not show any HTML markup if the region is empty.

<?php if (!empty($left_primary)): ?>
  <div class="sidebar-primary">
    <?php print $left_primary; ?>
  </div>
<?php endif; ?>
<?php if (!empty($left_secondary)): ?>
  <div class="sidebar-secondary">
    <?php print $left_secondary; ?>
  </div>
<?php endif; ?>

You can download the file from here. I haven’t tested it extensively but selecting the bosses and zones on Settings screen affects the front end and the jQuery code to appears expand and collapse the zones appears to work. So as far as I am concerned it works with WordPress 3.0.1 but may not work with lesser versions (judging by the WordPress Codex/API it should work for WordPress 2.7 onwards.)

Updated module for World of Warcraft: Cataclysm

So I ended up creating the node using node_save() which created the basic product.

function my_module_create_product($data) {
  require_once 'modules/node/node.pages.inc'; // Required for node_object_prepare();
  $node = new stdClass();
  $node->type = 'product';

  node_object_prepare($node); // This sets up all the default node fields so we don't accidentally leave something off.

  // Copy over all the existing settings from Drupal 5.
  $node->uid = 1;
  $node->status = $data->status;
  $node->title = $data->title;
  $node->created = $data->created;
  $node->changed = $data->changed;

  // Set Ubercart variables
  $node->model = $data->model_number; // the SKU is a required field, so I generated a SKU based on the node title
  $node->list_price = $data->price;
  $node->cost = $data->price;
  $node->sell_price = $data->price;
  $node->default_qty = 1;
  $node->pkg_qty = 1;

  // Set taxonomy + menu etc if you need to
  $node->taxonomy = array();
  $node->menu = array();

  // Save the node
  node_save($node);  // This will update the $node object with the $node->nid which is important for the next step.
}

We now have the node created with all the required information. From here, you would usually set up a the $form_state['values'] array and pass on to uc_object_attributes_form() to add the attributes to the form followed by uc_object_options_form() to set the options for these attributes both using drupal_execute(). But as we can’t do this, I copied the code from the submit handlers for both of these forms and merged them in to one (there are a few queries which are written by uc_object_attributes_form_submit() which are then overwritten or delete by uc_object_options_form_submt() which we can leave out or alter slightly to make the code shorter and to do less database queries. I have added some comments to the code which shows you the process.

function my_module_create_product($data) {
  // $node creation stuff from above

  // To set up the attributes we need to create a keyed array where the key is the attribute ID which contains an array of the options which need to be set.  The option in the keyed array will be set as the default option for that attribute.  If the attribute is just a blank textfield and doesn't have any options, then just pass an empty array.
  $attributes = array(
    1 => array(1, 2, 3, 4, 5, 6, 7, 8), // This could be a list of T-shirt colours, so which ever colour option 1 is will be the default option.
    2 => array(9, 10, 11, 12, 13), // This could be T-shirt sizes, again the first number will be the default which in this case is option 9.
  );

  // Go through all our attributes that we have set and set up the options in the database.
  foreach ($attributes as $aid => $options) {
    // Load the attribute
    $attribute = uc_attribute_load($aid);
    // Set the default to be the first option.
    $oid = $attributes[$aid][0];
    // Add the attribute to for the node and set the default option
    db_query("INSERT INTO {uc_product_attributes} (nid, aid, label, ordering, default_option, required, display) SELECT %d, aid, label, ordering, %d, required, display FROM {uc_attributes} WHERE aid = %d", $node->nid, $oid, $aid);
    // Set the options if they are provided
    if (is_array($attribute->options) && count($attributes[$aid]) > 0) {
      // Cycle through all the available options (the $option object here contains all necessary values to be put in the database.
      foreach ($attribute->options as $option) {
        if (in_array($option->oid, $attributes[$aid])) { // Check to see if the current option is in our keyed array.
          db_query("INSERT INTO {uc_product_options} (nid, oid, cost, price, weight, ordering) VALUES (%d, %d, %f, %f, %f, %d)", $node->nid, $option->oid, $option->cost, $option->price, $option->weight, $option->ordering);
        }
      }
    }
  }
}

We won’t be using adjustments, so I haven’t added that to my code. If you wish to further your code with adjustments you will need to find the necessary form and submit function for it.

To fix this, make sure you use a single database driver so stick to mysql or mysqli and don’t mix the two together.

function validateCurrency(amount) {
  var regex = /^[1-9]\d*(?:\.\d{0,2})?$/;
  return regex.test(amount);
}

The amount must start with a number 1 through 9, you can change this to 0-9 but potentially allows someone to put 0.00 so you would have to apply further validation. Then optionally the user can enter a decimal to 2 decimal places.

This validates for:

• 20.00
• 13.12
• 12.5
• 1.00
• 1.50

But fails on:

• 20.000
• 0.50
• 0.2
• 1,500
• 1,200.50

I have just come across a great example of how not to deal with users logging in or registering for a site with T-Mobile (UK).

I am on my second phone with them and had an account with them for the original phone, so I tried logging in using my username which I had in an email and my password. It wasn’t having it.

So I tried the forgotten password route. This asked for my mobile number and my username. Entered my original number and username. Nope. Entered my new number and username. Nope.

So I tried the forgotten username + password route. This asks for your name, phone number and email. I entered all this information using my original phone number. Nope. Tried again with my new phone number. Nope.

At this point I guess that I may not have an account for my new phone and my old phone was removed even though the number is still on the go on a second phone I have.

This time I went to the registration form. Put in my new number and entered the captcha. I was presented with another screen asking if I was the account holder, what my email was, how I was paying for the number, and a password. I filled all of this only at this point to be told that an account already existed for this number. Why couldn’t this error be present after the first step rather than making me enter in loads of data which was redundant.

So I tried to register again using my original number, entered the captcha and on to step two. This time I was asked for different information, I assume it recognised that this was a PAYG phone and not a contract phone so rather than being asked about how I paid for it, I was asked for my name address as well as my email, password. I filled this in, but the post code lookup didn’t recognise my post code, so I tried another post code, nope, and my works post code…nope. I carried on with the form assuming that it would present some more text fields to enter my address and pressed Submit.

“Please select your address before proceeding”

It wouldn’t let me proceed as I didn’t select my address which it wouldn’t find. Being a developer, I thought I would disable javascript. Obviously there was a problem, with their post code look up service and with javascript disabled the form would degrade nicely with all the address fields. Nope. The same form is displayed, still showing the Find address button which the href is set to javascript:; so the link wouldn’t do anything.

I am now in a situation where I can’t login to a pre-existing account or create a new account for not one but two phones.

Fixes

There are quite a few fixes that T-Mobile need to do to get their forms up to scratch. I can’t really say much about the login process as it may just be that the accounts don’t exist for whatever reason, I will have to wait and hear back from T-Mobile. But the registration form needs a lot of work.

When registering a new account and the number exists, throw an error straight away. Some inline validation would be great, at the very least throw up an error on submitting the form rather than getting the user to type another page of information before being told that the very first thing that did on the previous page was wrong.

Sort out the post code lookup service. I tried 3 different post codes. I know they exist. The look up service they are using just doesn’t work. A query is sent off by the javascript but there is no response (used Firebug).

Degrade the form if javascript is not available. Not everyone has javascript enabled, especially on some phones. Making sure an application degrades properly if javascript is absent is vital. If the post code lookup did work, then I wouldn’t of found this problem, but it doesn’t work and as it is javascript only, you can’t go any further.

So what has changed?

hook_block() no longer exists in Drupal 7. It has been split in to individual hooks for each $op. So rather than hook_block() we now have:

• hook_block_info()
• hook_block_configure()
• hook_block_save()
• hook_block_view()

A few of these new hooks conflicted with the hooks put in place by the Block API module, so I have made a few changes to the way other modules hook in to it.

function html_block_block($op = 'list', $delta = NULL, $edit = array()) {
  $function = 'block_api_block_'. $op;
  return $function('html_block', $delta, $edit);
}

The above has gone completely. Rather than passing the modules name to the core Blocks module, Block API will pass on it’s own name and handle the block management of modules using the API itself. This reduces the amount of code needed (although it wasn’t that much to start off with) and also makes it easier to remember what you need to use to hook in to Block API.

hook_block_api_info() has now changed to hook_block_api_block_types(), the code stays exactly the same. This was caused by the function name changes made in Drupal 7.

hook_block_api_view() has changed to hook_block_api_display(), this was also due to the function change in Drupal 7.

Everything else stays the same. The Block API has now been made slightly easier to use and hook in to thanks to Drupal 7.

The code on d.o should be updated soon.

Download: ZIP Last updated: 2010-07-13 18:30

The block displays however many raids you want to display and gives you more information which is available on mouseover.

As well as the block configuration, the module has an admin form that must be filled in before any blocks can be created. This is to make sure that Drupal knows where PHP Raider is located and where the database is.

So far I have created two blocks using the Block API module I developed and will release more when I have written and tested them.

Both blocks are set up in one module, which I have called wow_blocks. If you already have a module called wow_blocks, it may be a bit of a mission getting this to work, so you will have to chose one of the modules.

Download: ZIP. Last updated: 2011-01-09 00:35

Updates

2011-01-09 00:35

Added new zones and bosses to progression block. – ZIP

2010-11-14 09:00

Fixed image paths to work if base_path isn’t /.

2010-11-12 19:30

Updated the code for the newest version of block_api.

Block 1: Recruitment

The first block is a block for recruitment. An admin can set the roles and specs that the guild requires to be displayed in the block, so users know which areas the guild is recruiting in.

All the images are included in the ZIP file.

The admin screen, allows the admin to select the links to use for the Apply now and Recruitment details buttons as well as options for each individual role and spec.

Click for larger version

Block 2: Progression

This block shows the guilds progression against the bosses of the game.

The block features an expandable group of game zones with all the bosses in the zone.

All bosses from the following zones are in the module:

• Icecrown Citadel
• Argent Coliseum
• Ulduar
• Eye of Eternity
• Obsidian Sanctum
• Naxxramas
• Vault of Archavon

As of 9th January 2011 the following extra zones are available:

• Blackwing Descent
• Bastion of Twilight
• Throne of the Four Winds

Admins have full control over which zones are available and shown in the block as well as selecting which bosses have been defeated.

If you have any requests for World of Warcraft related blocks, let me know in the comments.

The AHAH helper module does provide a demo, but the demo shows how to change a few fields depending on a selection made from a select element. The tutorials I looked at online either didn’t cover the issue properly or just didn’t work.

Currently the 6.x-2.0 release throws up errors if you are using certain PHP versions, but these are gone in the 6.x-2.x-dev release.

Scenario

You want the user to enter in some data, lets say their favourite car. But you want the ability for them to add as many cars as they want if they have more than one.

Code

Firstly you will need to set up a menu callback for your form, but I will assume you know how to do this if you are looking at this tutorial.

We will set up the basic form first, this includes one textfield and a submit button to submit the form with the textfield in a wrapper (this is important later on for the ahah_helper module).

function test_form($form_state = NULL) {
  $form['cars'] = array(
    '#type' => 'fieldset',
    '#title' => t('Favourite cars(s)'),
    '#prefix' => '<div id="favourite-cars-wrapper">',
    '#suffix' => '</div>',
  );
  $form['cars']['car'] = array(
    '#type' => 'textfield',
    '#title' => t('Favourite car'),
    '#size' => 36,
    '#default_value' => $form_state['values']['car'],
  );
  $form['submit'] = array(
    '#type' => 'submit',
    '#value' => t('Submit'),
  );
  return $form;
}

This is very basic and allows the user to enter one car and submit the form. We now need to add in the extra functionality of ahah_helper to be able to add mulitple fields.

function test_form($form_state = NULL) {

  ahah_helper_register($form, $form_state); // Absolutely vital for ahah_helper to do it's job

  // We check to see if quantity has been set, ie if the form has been submitted yet.  If not, we show 1 field, you can change this to however many fields you want to show up as default.
  if (!isset($form_state['storage']['quantity'])) {
    $quantity = 1;
  }
  else {
    // If the form has been submitted we get the quantity that was stored.
    $quantity = $form_state['storage']['quantity'];
    // We then do a check to see if the user has clicked the "Add another car" button, if they have we increase the amount by 1.
    if (isset($form_state['values']['cars']['add_more']) && $form_state['values']['op'] == 'Add another car') {
      $quantity++;
    }
  }

  // We create a hidden form element to store the amount of fields that the user has added.
  $form['quantity'] = array(
    '#type' => 'value',
    '#value' => $quantity,
  );

  $form['cars'] = array(
    '#type' => 'fieldset',
    '#title' => t('Favourite cars(s)'),
    '#prefix' => '<div id="favourite-cars-wrapper">',
    '#suffix' => '</div>',
    '#tree' => TRUE // This is important for ahah_helper.
  );
  // We now do a simple loop, creating however many textfields are defined by $form_state['storage']['quantity']
  for ($i = 1; $i <= $quantity; $i++) {
    // The element name needs to be different for each textfield, otherwise we will only get one value after the form is submitted.
    $form['cars']['car_'. $i] = array(
      '#type' => 'textfield',
      '#title' => t('Favourite car'),
      '#size' => 36,
      '#default_value' => $form_state['values']['cars']['car_'. $i],
    );
  }

  // We add in a button with the #ahah element which will handle all our work for us.
  $form['cars']['add_more'] = array(
    '#type' => 'submit',
    '#value' => t('Add another car'),
    '#ahah' => array(
      'event' => 'click', // When the button is "clicked", AHAH will do it's job
      'path' => ahah_helper_path(array('cars')), // The array features the wrapper form field. So our form wrapper is $form['cars'], so we set this to array('cars'). If your form was $form['cars']['another_wrapper'], the path would be array('cars', 'another_wrapper').
      'wrapper' => 'favourite-cars-wrapper', // We then define the wrapper which will be changed.
    ),
  );
  $form['submit'] = array(
    '#type' => 'submit',
    '#value' => t('Submit'),
  );
  return $form;
}

So what have we done…first we added the following line:

ahah_helper_register($form, $form_state);

This is a vital function that needs to be present in your form for ahah_helper to do it’s job.

Next we check to see if the form has been submitted before and if it has, get the amount of textfields that the form had by storing it in a hidden field. We then do a further check to find out what button was clicked. If the “add more” button was clicked, then we add another textfield by increasing the value of the quantity variable.

A minor, but very important change we make is adding ‘#tree’ => TRUE to our wrapper element, this is a requirement for ahah_helper to do it’s job properly.

Next we use a for loop, to add all our textfields into the form. This should be self-explanitory but will go in to a bit more depth further on when we talk about the #ahah element.

We added an additional button to the form, this is so that the user can add another field to the form. You don’t need to worry about javascript degradation as ahah_helper takes care of this.

One attribute of #ahah on the button that isn’t listed in the form, but is very important, is the “method”. The default value of this is replace, which is what we want. This replaces the whole contents of the wrapper which we define with the data from the path which we defined. This is why we needed the for loop to recreate the textfields.

To take care of the form when javascript is disabled, you must check which button was pressed when the form was submitted.

function test_form_submit($form, $form_state) {
  if ($form_state['values']['op'] == 'Submit') {
    drupal_set_message('Submit button clicked');
  }
  else {
    drupal_set_message('Add more button clicked');
  }
}

With javascript enabled, when clicking the Add more button, Drupal will perform validation on the form, but will not submit the form. Whereas clicking the submit button will perform validation and submit the form.

Not every user will understand this:

<iframe src="http://drupal.org/" width="100%" height="500px" frameborder="1" scrolling="no"></iframe>

And will find this much simpler and easier to use:

First off, you need to create a module like you normally would with your .info and .module files.

My module is going to be called iframe_block, so you will need to change this in certain cases if you use a different name.

name = Iframe Block
description = Add new blocks which contain an iframe of a specified URL.
core = 6.x
dependencies[] = block_api

That is for the .info file which sets the dependency on block_api. If block_api isn’t available then this module can’t be used.

Our .module file is going to be fairly simple and just hooks in to Block API, using three of the available hooks. But before we use any of the Block API hooks, we need to forwards the Drupal block related calls to the Block API module.

function iframe_block_block($op = 'list', $delta = 0, $edit = array()) {
  $function = 'block_api_block_'. $op;
  return $function('iframe_block', $delta, $edit);
}

This will pass any calls to iframe_block_block() to the Block API module which in turn will add it’s own hooks which we can take advantage of.

The first one and most important is hook_block_api_info(), which we use to tell Drupal about our block type.

function iframe_block_block_api_info() {
  $types['iframe_block'] = array(
    'title' => t('Iframe Block'),
    'description' => t('Create a block from with content from a specified URL using an iframe.'),
    'storage' => BLOCK_API_STORAGE_DATABASE,
  );
  return $types;
}

Next we define our form for the user to fill in. The attributes we require are the source (the URL), the height and the width. I am also going to provide the user the option of overriding the frameborder and scrolling attributes.

function iframe_block_block_api_form($config, $edit) {
  if ($config['block_type'] == 'iframe_block') {
    $form['url'] = array(
      '#type' => 'textfield',
      '#title' => t('URL'),
      '#description' => t('The URL of the page you would like to use as the source of the iframe.'),
      '#required' => TRUE,
      '#default_value' => $config['settings']['url'],
    );
    $form['width'] = array(
      '#type' => 'textfield',
      '#title' => t('Iframe width'),
      '#description' => t('Enter the width of the iframe. Include the measurement type (px, em or %)'),
      '#default_value' => $config['settings']['width'] ? $config['settings']['width'] : '100%',
      '#required' => TRUE,
      '#size' => 10,
    );
    $form['height'] = array(
      '#type' => 'textfield',
      '#title' => t('Iframe height'),
      '#description' => t('Enter the height of the iframe. Include the measurement type (px, em or %)'),
      '#default_value' => $config['settings']['height'] ? $config['settings']['height'] : '300px',
      '#required' => TRUE,
      '#size' => 10,
    );
    $form['frameborder'] = array(
      '#type' => 'select',
      '#title' => t('Iframe border'),
      '#description' => t('Select whether you want to show a border around the iframe.'),
      '#default_value' => $config['settings']['frameborder'] ? $config['settings']['frameborder'] : 0,
      '#required' => TRUE,
      '#options' => array(1 => t('Show border'), 0 => t('Don\'t show a border')),
    );
    $form['scrolling'] = array(
      '#type' => 'select',
      '#title' => t('Scrolling'),
      '#description' => t('Select whether the iframe should be scrollable or not'),
      '#default_value' => $config['settings']['scrolling'] ? $config['settings']['scrolling'] : 'auto',
      '#required' => TRUE,
      '#options' => drupal_map_assoc(array('yes', 'no', 'auto')),
    );
  }
  return $form;
}

This will allow the user to set up their iframe by entering the required information.

Finally, we need to hook in to hook_block_api_view() to be able to display our iframe using the users input.

function iframe_block_block_api_view($config) {
  if ($config['block_type'] == 'iframe_block') {
    $output = '<iframe src="'. $config['settings']['url'] .'" width="'. $config['settings']['width'] .'" height="'. $config['settings']['height'] .'" frameborder="'. $config['settings']['frameborder'] .'" scrolling="'. $config['settings']['scrolling'] .'">'. $config['settings']['no_iframes'] .'</iframe>';
  }
  return array('content' => $output);
}

Very simply we are taking the users input and entering it in to some HTML code to give us the desired output.

Click for larger version

The example module included copies the functionality of the core block module. Below I will show how to use Block API to display a specific node as a block with further configuration options available to the user to choose from.

First off, if you just want to download this module to use, you can do so by clicking here.

As with any other module, create an info file using whatever module name you want. The module name I will be using is node_block.

name = Node Block
description = Add new blocks by using pre-existing nodes.
core = 6.x
dependencies[] = block_api

In your .module file, we need to first set up the hook to allow Block API to do it’s job. So our first function will be the following:

function node_block_block($op = 'list', $delta = 0, $edit = array()) {
  $function = 'block_api_block_'. $op;
  return $function('node_block', $delta, $edit);
}

This passes all the hook_block calls through the Block API which then allows users to select your block types through a single interface.

Next, we need to define our block types that we will provide users. To do this we use hook_block_api_info().

function node_block_block_api_info() {
  $types['node_block'] = array(
    'title' => t('Node Block'),
    'description' => t('Create a block from a pre-existing node.'),
    'storage' => BLOCK_API_STORAGE_DATABASE,
  );
  return $types;
}

This is very simple, and defines the block type.

For this module we are going to allow the user to select a node to display and choose whether to display the full node or just the teaser. As well as this, we are going to give the administrator the choice of which node types are available to the user to chose nodes from as well as selecting whether users can use unpublished nodes or not.

First we will define the administration form to chose which content types are available. To do this, we need to use hook_menu() to define our menu item pointing to our form.

function node_block_menu() {
  $items['admin/settings/node_block'] = array(
    'access callback' => 'user_access',
    'access arguments' => array('administer blocks'),
    'page callback' => 'drupal_get_form',
    'page arguments' => array('node_block_admin_form'),
    'title' => 'Node Block Configuration Settings',
    'description' => 'Set the configuration options for Node Blocks.',
    'type' => MENU_NORMAL_ITEM,
  );
  return $items;
}

There is nothing complex here, just a standard menu item. We now have to create the form node_block_admin_form().

function node_block_admin_form() {
  $types = node_get_types('names');
  $form['node_block_content_types'] = array(
    '#type' => 'checkboxes',
    '#title' => t('Node types available to create blocks'),
    '#description' => t('Set the node types that are allowed to be displayed as blocks.'),
    '#required' => TRUE,
    '#options' => $types,
    '#default_value' => variable_get('node_block_content_types', ''),
  );
  $form['node_block_published_only'] = array(
    '#type' => 'checkbox',
    '#title' => t('Only allow published nodes to be shown as blocks.'),
    '#description' => t('By checking this box only published nodes will be available for selection and appear as blocks.'),
    '#default_value' => variable_get('node_block_published_only', 1),
  );
  $form['node_block_sql_order'] = array(
    '#type' => 'select',
    '#title' => t('Order autocomplete results by'),
    '#description' => t('Select the column name to order the autocomplete results by.'),
    '#default_value' => variable_get('node_block_sql_order', 'nid'),
    '#required' => TRUE,
    '#options' => array('nid' => t('Node ID'), 'title' => t('Node title'), 'type' => t('Node type')),
  );
  $form['node_block_sql_sort'] = array(
    '#type' => 'select',
    '#title' => t('Order of autocomplete results'),
    '#description' => t('The order in which autocomplete results will be ordered.'),
    '#default_value' => variable_get('node_block_sql_sort', 'ASC'),
    '#options' => array('ASC' => t('Ascending'), 'DESC' => t('Descending')),
    '#required' => TRUE,
  );
  $form['node_block_autocomplete_limit'] = array(
    '#type' => 'textfield',
    '#title' => t('Amount of results to display in autocomplete'),
    '#description' => t('Enter the amount of results to appear in the autocomplete when selecting a node.'),
    '#required' => TRUE,
    '#default_value' => variable_get('node_block_autocomplete_limit', 25),
    '#size' => 5,
  );
  return system_settings_form($form);
}

To get a list of nodes types, you can run your own custom SQL query, but it is a lot easier to use Drupal’s built in node_get_types() function. If you pass along ‘types’ as the first argument, you will get a lot more information, but all we need is the node type machine name and the display name. node_get_types(‘names’) does exactly this with an associative array with the key being the machine name and the value being the display name.

The rest of the form is very simple, giving the administrator full control over the ordering of the autocomplete which users will select their node from.

We now have our admin form set up, so now it is time to create the configuration form for the users when adding a new block. Again we hook in to the Block API, this time using hook_block_api_form($config, $edit).

function node_block_block_api_form($config, $edit) {
  if ($config['block_type'] == 'node_block') {
    $form['nid'] = array(
      '#type' => 'textfield',
      '#title' => t('Node ID'),
      '#description' => t('Start typing the title of the node and select it from the autocomplete list.'),
      '#required' => TRUE,
      '#default_value' => $config['settings']['nid'],
      '#autocomplete_path' => 'js/node_block/autocomplete',
    );
    $form['teaser'] = array(
      '#type' => 'select',
      '#title' => t('Show the Teaser or full node'),
      '#description' => t('Select whether you would like just the teaser displayed in the block or the full node.'),
      '#default_value' => $config['settings']['teaser'],
      '#required' => TRUE,
      '#options' => array(0 => t('Full node'), 1 => t('Teaser')),
    );
  }
  return $form;
}

Here we give the user two options. The first is an autocomplete field to select the node and the second being a simple checkbox allowing the user to select whether they want to show the teaser of the node or the full node.

To get the autocomplete working, we need to set up our autocomplete menu item and function to run the search query.

In your existing hook_menu(), add the following to create a menu callback for our autocomplete textfield.

$items['js/node_block/autocomplete'] = array(
    'page callback' => 'node_block_js_autocomplete',
    'access callback' => TRUE,
    'type' => MENU_CALLBACK,
  );

A very simple callback, no need for a title or description and access is open to everyone, although you could limit it to the users who are able to create blocks.

Next we need to set up the SQL query that will fetch the nodes based on the users input.

function node_block_js_autocomplete() {
  $str = $_POST['nid'];
  $sql = "SELECT nid, title FROM {node} WHERE LOWER(title) LIKE LOWER('%%%s%%')";
  foreach (variable_get('node_block_content_types', '') as $type => $value) {
    if (strlen($value) > 1) $types[] = '"'. $type .'"';
  }
  $sql .= " AND type IN (". implode(", ", $types) .")";
  if (variable_get('node_block_published_only', 1) == 1) {
    $sql .= " AND status = 1";
  }
  $sql .= " ORDER BY ". variable_get('node_block_sql_order', 'nid') ." ". variable_get('node_block_sql_sort', 'ASC');
  $sql .= " LIMIT 0, ". variable_get('node_block_autocomplete_limit', 25);
  $query = db_query($sql, filter_xss($str));
  $results = array();
  while ($data = db_fetch_object($query)) {
    $results[$data->nid] = check_plain($data->title);
  }
  print drupal_to_js($results);
}

We get the users current inputted text from $_POST and set up the basic SQL. As we gave the administrator the chance to limit the options available, we must now apply those filters. First we make sure the query only gets results for the right content types, then check for only published nodes if defined by the administrator. The next few lines are for the autocomplete ordering and limiting the amount of results.

We now have our two admin forms configured, the only bit remaining is showing the block on the page. This is done by using hook_block_api_view().

function node_block_block_api_view($config) {
  if ($config['block_type'] == 'node_block') {
    $node = node_load($config['settings']['nid']);
    if ($node->status == 0 && variable_get('node_block_published_only', 1) == 1) return FALSE;
    $output = node_view($node, $config['settings']['teaser'] == 1 ? TRUE : FALSE);
  }
  return array('content' => $output);
}

First, we load the node using the NID saved from our form by Block API. It is probably best to add some code in to make sure that a node ID has been saved either at view stage or when saving the block.

Next we make sure the node is not unpublished if the administrator has defined that only published nodes can be shown as blocks.

Then we use the function node_view() to display the node. The second argument is the $teaser argument. If TRUE it will display the teaser of the node, otherwise the full node will be published.

Click for larger image

You may also want to hide the node block if you are viewing the node page itself, so adding a line after the status line such as:

if (arg(0) == 'node' && arg(1) == $config['settings']['nid']) return FALSE;

And that is it. You will now be able to create blocks

Scenario

A user submits a piece of content, we will refer to this user as the author. The content is not published and is sent to another user for moderation, we will refer to this user as the moderator.

The moderator can then either set the content from a moderation state back to a draft state for the author to amend or through to a “to be published state”.

Once the moderator has checked the content and made amends they can mark the content as ready for publishing. At which point a third user which we will refer to as the publisher, can make further amends to the content and publish it, make further amends and send back to the moderator to check through the changes or mark the content as back to draft to allow the author to change it.

Required modules

A few contributed modules are required to get this process in place as well as a couple of core modules.

• Trigger (Core, optional)
• Profile (Core)
• Module Grants (Contrib)
• Smart tabs (Contrib)
• Revisioning (Contrib)
• Token (Contrib)
• Workflow (Contrib)
• Diff (Contrib, optional)

The Diff module is optional, but can be useful to easily see what parts of the content have changed from each revision.

Enable modules

Some of the modules have sub-modules which come with the main module, so be sure to check all the required modules, which are:

• Module Grants
• Module Grants Monitor (Optional)
• Node Tools
• User Tools
• Profile
• Trigger (Optional)
• Smart tabs
• Diff (Optional)
• Revisioning
• Token
• Token actions
• Workflow
• Workflow access

If you already have content on your site, you will also need to download and install Workflow Post Install, otherwise all old content may only be accessible by administrator.

Create user roles

You can have as many different roles to allow more fine grained control over who can create what content types, but to try and keep this tutorial as simple as possible, I will stick to the three main roles defined in the scenario.

• Author
• Moderator
• Publisher

It may be best to give your author role a different role name as the Workflow module automatically adds a line in the admin for “author” which applies to any role creating content.

Go to Administer > User management > Roles (admin/user/roles).

Then add your three roles, I will be using author role, moderator role and publisher role.

Set up workflow settings

Go to Administer > Site building > Workflow (admin/build/workflow).

Create a new Workflow and call it Moderation.

In the State name box, enter in draft and set the weight to -10. Save the state.

Once the state has saved, click the List tab and click the Add state link.

Add the following states:

• in moderation (weight: -2)
• is moderated (weight: 2)
• live (weight: 10)

Underneath your states, you can apply the workflow to separate content types. I will be applying it to both the default content types (Page and Story).

Next to the Moderation workflow, click the Edit link.

This page may seem a little daunting at first, but don’t panic. The first set of checkboxes allow you to set out which roles can transition the node between certain states. You will also see the extra “author” role that I refered to earlier.

The first row is for the original creation of the node. This is the transition from the (creation) state to the in draft state. The only role we are giving access to this is the Workflow defined author, note that this is not the author role that we created.

Click for larger version

The next transition is from being in draft to in moderation. For this transition, we want to set this to our author role as opposed to the workflow defined author.

Click for larger version

The next transition is from in moderation to is moderated. This is our moderation step where the content is moderated prior to being sent back to the author for further amends or to the publisher for final approval and publishing. We want to set the moderator role under in draft and is moderated.

Click for larger version

Next is the step from being moderated to going to the publisher. There are some optional transitions that you can put in here, depending on how you want to work. The one that everyone would need is the transition from is moderated to live. The one that will differ is for rejections. Some people will want it to go back to draft, whereas others will want it to go back to moderator, others will want both options. This way if there isn’t a major problem, the content can be sent back to the moderator for further moderation rather than having to go back to the author only to be sent back to the moderator.

Click for larger version

The final transition is from the live state. The only role that needs this is our author role (not the workflow author role) to be able to take the content back to in draft. This will not change the live copy, but create an unpublished revision which we will set up in the next part of the tutorial.

Click for larger version

After the checkboxes, in the Comment for Workflow Log section, make sure both boxes are ticked to show a comment form in the Workflow and node edit screens to allow the roles to add their comments for the next role to read to understand why the amends were rejected or what was changed.

In the Workflow tab permissions, check our three roles.

Next we have the Access control section. These permissions allow you to set permissions to certain roles based on the state of the content (in draft, in moderation, is moderated, live). Take in to account that these permissions will be overridden by some of the permissions in the User management > Permissions page which we will get on to later.

In the sections for each state, the anonymous user and authenticated user should stay ticked under Roles who can view posts in this state.

Under in draft, check our author role for Roles who can edit posts in this state.

Click for larger version

Under in moderation, check our moderator role for Roles who can edit posts in this state.

Click for larger version

Under is moderated, check our publisher role for Roles who can edit posts in this state.

Click for larger version

Leave the live state with only the default view options checked.

Press Save.

Configure content types

Go to Administer > Content management > Content types (admin/content/types).

Click the Edit link next to the content type you wish you apply the moderation workflow.

Under the Workflow settings, uncheck the Published box as we don’t want to publish the content until it has been moderated and approved.

Check both the Create new revision and New revision in draft, pending moderation (requires “Create new revision”) boxes to create a revision for each modification of the content.

Under Create new revision, it is up to you what setting you use, but remember to read the description text below the options.

Click here for larger version

If you have the Diff module enabled, you will get the additional option Show Preview changes button on node edit form which will allow you to see the difference between the current edits and the current revision.

Repeat this step for all content types that you wish to have moderation enabled for.

Set up user permissions

Go to Administer > User management > Permissions (admin/user/permissions).

Under the module_grants_monitor module section. Tick the boxes access All tab, access I Can Edit tab and access I Can View tab for the moderator role. For the publisher role, you can tick the same boxes plus access Published tab and access Unpublished tab.

Click for larger version

Under node module, make sure anonymous user and authenticated user are both checked for access content.

For author role, tick the boxes to allow them to create content of selected content types as well as being able to edit their own content.

For the moderator and publisher roles, allow them to edit any content as well as view or revert any revisions, but if you want further control over this, you can set this later on in the revisioning section.

Click for larger version

Under revisioning module, give the author role the ability to view revision status messages and to edit revisions of their own content. Moderators should have permission to access Pending tab, edit revisions and view revision status messages. The publisher role should have the same permissions as the moderator role, but should also have unpublish current revision and publish revisions.

Click for larger version

Press Save.

Set up email triggers

For information on setting up and using Triggers and Actions in Drupal 6, it is best to read the excellent page on the Drupal.org website at http://drupal.org/node/199254

Block API is a new module I have developed for Drupal 6 which gives greater control over block templates much like you do with nodes.

More information is available on my Block API page under Projects.

Developer information on how to use the module is available on the Block API Developer information page.

They offer very good VPS packages which are very fast for a very good price and allow a lot of customisation with some excellent backend configuration options.

Step 1: Create a new canvas and fill the background with black (#000000)

Open Photoshop and create a new canvas, whatever dimensions you want to use, I am using 500×500.

Fill the background layer with black (#0000000).

Step 2: Create the initial burst of light

Set the foreground colour to white (#ffffff) (you can do this by pressing d on the keyboard to reset the foreground and background colours then pressing x to switch the foreground and background).

Now select the Gradient tool and set the gradient to be foreground to transparent and set to a radial gradient.

Now draw a radial gradient from the center of the document on a new layer.

Next create another layer. Go to Filters > Render > Clouds. Set the layer blend mode in the layers panel to Soft Light.

With the same layer still selected, go to Filters > Artistic > Plastic Wrap. You will need to play around with the settings here to get your desired result, I will leave them as the defaults.

Next, go to Filters > Blur > Radial Blur. Set the Amount to 100 and the Blur Method to Zoom.

Click OK to apply the blur.

Step 3: Add colour to the burst

Create another layer and fill it with whatever colour you want the burst to be. I am using #8dc63f. Set the layers blend mode in the layers panel to Colour. Lower the opacity to 60-80% to get more detail from the burst.

Result

Step 1: Create a new canvas and create a new layer

In Photoshop, create a new canvas and add a layer. In this layer draw a rectangular shape using the marquee tool while leaving a small space around the canvas border.

Fill this shape with white on the new layer.

Step 2: Set the layer styles

Right click the layer and select Blending Options.

Tick Outer Glow and set the Blend Mode to Normal and the Colour to black (#000000) and lower that Opacity to 10%. In the Elements section, change the Size to 10px.

Next tick Inner Glow and set the Blend Mode to Normal and the Colour to white (#ffffff) and set the Opacity to 40%. In the Elements section, change the Size to 15px.

Next select Gradient Overlay, leave all the settings at their defaults, but change to the Gradient to the colour you want. In this example I have chosen #ec2f03 to #c02502.

Finally, tick the Stroke checkbox, and lower the Size to 2px and the Position to Inside. Set the Colour of the stroke to something slightly different than the gradient. I chose #ed1c24.

Step 3: Add a slight shine to the button

Create another layer on top of the button and select the Eliptical Marquee Tool and draw an elipse covering the top half of the button.

With the selection active, press and hold Ctrl, Alt and Shift and left click the layer preview of the button. This should limit the selection just to the area of where the selection meets the button.

On the new layer, Fill this with white (#ffffff) and set the Opacity of the layer to 15%.

Result

I will be doing this using WAMP on a Windows XP machine, so some of the steps won’t work if you are using IIS or will differ if you are using a different setup.

The result we will be aiming for is a shared user system allowing the user to log in/out of 3 sites which I will use the following domains:

• http://www.local.com
• http://community.local.com
• http://support.local.com

WAMP installation

Download and install the latest version of WAMP from the WAMP website. The latest version comes with PHP 5.3 which has problems with Drupal 6, so you will also need to download and install PHP 5.2.x from the WAMP Addons page once WAMP is installed.

Once WAMP and PHP 5.2.x have been installed and WAMP has restarted, left click the WAMP icon in the system tray and go to PHP > PHP Version and select the 5.2.x version you downloaded.

Left click the WAMP icon again and this time select Apache > Apache Modules and scroll down and select rewrite_module and vhost_alias_module.

WAMP Virtual Hosts set up

Again, left click the WAMP icon and go to Apache then select httpd.conf.

Scroll down to the bottom of this file and look for the following lines:
# Virtual hosts
# Include conf/extra/httpd-vhosts.conf

Remove the comment from the beginning of the second line to end up with this:
# Virtual hosts
Include conf/extra/httpd-vhosts.conf

Save and close the file.

Now in Explorer, navigate to the WAMP directory\bin\bin\apache\Apache2.2.11\conf\extra\ directory.

Open the httpd-vhosts.conf file with your favourite text editor.

Replace the contents of this file with the following:

NameVirtualHost *:80
#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for all requests that do not
# match a ServerName or ServerAlias in any <VirtualHost> block.
#
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot "c:/wamp/www/"
ServerName www.local.com
ErrorLog "logs/local-www-error.log"
CustomLog "logs/local-www-access.log" common
<directory "c:/wamp/www/">
Options Indexes FollowSymLinks
AllowOverride all
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</directory>
</VirtualHost>
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot "c:/wamp/www/"
ServerName community.local.com
ErrorLog "logs/local-com.localhost-error.log"
CustomLog "logs/local-com.localhost-access.log" common
<directory "c:/wamp/www/">
Options Indexes FollowSymLinks
AllowOverride all
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</directory>
</VirtualHost>
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot "c:/wamp/www/"
ServerName support.local.com
ErrorLog "logs/local-sup.localhost-error.log"
CustomLog "logs/local-sup.localhost-access.log" common
<directory "c:/wamp/www/">
Options Indexes FollowSymLinks
AllowOverride all
Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</directory>
</VirtualHost>

This sets up 3 virtual hosts all using the same directory for the files, as we are using a shared codebase. This is also set up to only allow traffic from the localhost. To make the site public to all, change the line:

Allow from 127.0.0.1

To:

Allow from all

Save and close the file.

HOSTS set up

The local.com domain already exist, so we need to overwrite the IP address where it points to be the local computer in the HOSTS file. We do this by editing the HOSTS file which on Windows is located in the following directory:

C:\WINDOWS\system32\drivers\etc

The HOSTS file has no file extension. So open it up in Notepad and add the following line at the very bottom:

127.0.0.1 www.local.com community.local.com support.local.com

Save the file, but make sure you don’t add a .txt extension.

You will need to close all your browser windows and in some cases restart the computer for the changes to take effect.

Open a new browser window and try to navigate to www.local.com, you should now get the WAMP welcome screen.

Create a database in MySQL

Using which ever MySQL admin tool you prefer, create a new database to use for Drupal. If using WAMP, you can use PHPMyAdmin by navigating to http://localhost/phpmyadmin/

By default MySQL has no password in WAMP.

Download and set up Drupal

Download the latest version of Drupal 6 which at the time of writing is Drupal 6.17.

Extract the files and subfolders to the C:\wamp\www directory overwriting the existing index.php when asked. If you are not asked to overwrite the index.php file, you have tried to extract the files at the wrong directory level.

Navigate to the /sites/ directory and copy the default directory twice and rename the 2 new directories support.local.com and community.local.com.

Navigate in your browser to www.local.com, you should get the Drupal installation screen. Follow the screens through and install Drupal how you normally would. Once installation has finished and you are at the Welcome screen, navigate to support.local.com.

During installation, add a database prefix as support_ and continue with installation.

Once at the welcome screen, do the same with community.local.com but this time using the prefix comm_.

Configure Drupal for multisite by modifying settings.php

In the /sites/ directory there are now 4 directories.

- all
- community.local.com
- default
- support.local.com

The default directory is used for www.local.com, the other 2 xxx.local.com directories should be self explanitory and the all directory is present for modules and themes.

Open up the settings.php file in the default directory.

Around a quater of the way down the file (around line 93 for most people) there is a line for $db_prefix, if you didn’t set one it should just say:

$db_prefix = '';

Scroll 3 quaters down (around line 169) and uncomment the line:

# $cookie_domain = 'example.com';

And change to:

$cookie_domain = '.local.com';

This will share the session cookie across all subdomains of local.com

Save and close the file.

Now open up settings.php from within the community.local.com directory.

Scroll down to line 93 and replace with the following:

$db_prefix = array(
'default' => 'comm_',
'users' => '',
'sessions' => '',
'role' => '',
'authmap' => '',
'users_roles' => '',
'profile_fields' => '',
'profile_values' => '',
);

Save and close the file.

And again, scroll 3 quaters down (around line 169) and uncomment the line:

# $cookie_domain = 'example.com';

And change to:

$cookie_domain = '.local.com';

Repeat the same for support.local.com, although this time set the default $db_prefix to support_.

Save and close the file.

Navigate to each site in the browser and log out of each site. Now log in to www.local.com. Now if you navigate to support.local.com, you should be logged in, same with community.local.com.

We now have 3 sites with a shared user base and a single signon. As you may be able to tell from the $db_prefix array above, we are sharing the users table as well as sessions which keeps the user data and log in data the same across all the sites. We also share the role and users_roles tables to be able to set multi-sitewide roles as well as the profile tables so that the user doesn’t have to type any information over and over again.

Cleaning up unneeded MySQL tables

Now in our database, we have redundant tables which aren’t doing anything and aren’t being used. We can now delete these to keep the database a bit tidier. Delete the following tables:

• support_users
• support_sessions
• support_role
• support_authmap
• support_users_roles
• support_profile_fields
• support_profile_values
• comm_users
• comm_sessions
• comm_role
• comm_authmap
• comm_users_roles
• comm_profile_fields
• comm_profile_values

find . -exec grep -l "string to find" {} \;

This will search all subdirectories from the current directory for the “string to find”.

Step 1: The basics behind grid systems

Grid systems allow you to create a quick framework using HTML and set CSS styles to set up div tags in to a grid like formation which saves you from having to worry about floating elements and margins etc.

This tutorial is going to focus on a very basic grid that allows you to easily create 1, 2, 3, 4 column layouts. If you are looking for something that has more depth to it and more flexibility, it will be better to look at 960.gs or Blueprint CSS, as they will provide you with a lot more options on how you want to display your content.

Step 2: The start of the CSS

We need to set up some basic CSS rules to set up our grid elements or cells so that they line up in a grid like we want them to.

.cell, .cell-2, .cell-3 {
  float: left;
  display: inline;
  margin: 0 10px;
  position: relative;
}
.alpha { margin-left: 0; }
.omega { margin-right: 0; }

Our first rule is setting the cell to float and display inline with a 10px margin on the left and right. The next two rules allow us to remove the margin if we need to from the first rule. So with the following HTML, the second cell would have no right margin.

<div class="cell"><p>Text</p></div>
<div class="cell omega"><p>Text</p></div>

To make sure our cells line up properly on different rows we need to wrap them with another div which we will give the class grid.

.grid, .grid-2, .grid-3, .grid-4 {
  clear: both;
  overflow: hidden;
  margin-bottom: 1.5em;
}

This makes sure that the div is a new row if the row above doesn’t use the full width.

Step 3: The mathematics

The basis of grid systems is some simple mathematics. If you look at the 960.gs size and the column counts available, you can see that they are divisable to a whole number. 960/12 = 80 and 960/16 = 60.

To be able to start off with the maths, you need to decide on the width of the wrapper of the whole page. Take in to account the different resolutions that people use. At the moment the majority of users are using 1024×768, so the width shouldn’t be any more than 1000px wide (also take in to account a scrollbar on the right).

For this tutorial I am going to show the maths for a grid system with a width of 960px.

So we need to set the CSS for this:

.container {
  width: 960px;
  margin: 0 auto;
}

To work out the width of a single cell that fills the full width of the wrapper we need to divide the width of the container by the number of columns (in this case 1) then minus 20 (due to the 10px margin on both the left and right).

So; (960 / 1) – 10 – 10 = 940

.grid .cell { width: 940px; }

That is the most basic cell in the grid which will fill up the whole width of the container with the margins.

Now lets work out the width needed for a 2 column layout.

(960 / 2) – 10 – 10 = 460

.grid-2 .cell { width: 460px; }

This would be displayed using the following HTML:

<div class="container">
  <div class="grid-2">
    <div class="cell"><p>Text</p></div>
    <div class="cell"><p>Text</p></div>
  </div>
</div>

Let’s work through it backwards to make sure the maths works out. 460 + 460 = 920. That is the total width of the available content areas. But on top of that we need to add our margins in, we have the 10px on the far left, then there are 2 lots of 10px margins in the very centre of the grid and the last 10px at the very far right side of the grid making a total of 960px.

A 3 column layout can container 3 cells or 2 cells where one of the cells is the size of 2 single cells. So lets see how that works.

(960 / 3) – 10 -10 = 300

.grid-3 .cell { width: 300px; }

So, 3 x 300px = 900px + (20px x 3) = 960px. That is the CSS needed for 3 single cells.

<div class="container">
  <div class="grid-3">
    <div class="cell"><p>Text</p></div>
    <div class="cell"><p>Text</p></div>
    <div class="cell"><p>Text</p></div>
  </div>
</div>

There are 2 easy ways to find out the width of the 2 cell.

One way, is to take the result of the single cell which in this case is 300, then add that on again to make 600. We then need to add 20 to that to take in to account the margin that is no longer needed between the cells.

((960 / 3) – 20) + ((960 / 3) – 20) + 20 = 620

The other way is to do the original sum without taking the margins off until you have the full width of 2 cells, like so:

((960 / 3) * 2) – 20 = 620

So the CSS would like this:

.grid-3 .cell-2 { width: 620px; }

With the HTML like this:

<div class="container">
  <div class="grid-3">
    <div class="cell-2"><p>Text</p></div>
    <div class="cell"><p>Text</p></div>
  </div>
</div>

We then use exactly the same principles for the 4 column layout.

Single cell: (960 / 4) – 10 – 10 = 220
Double cell: (220 + 220) + 20 = 460
Triple cell: (460 + 220) + 20 = 700

.grid-4 .cell { width: 220px; }
.grid-4 .cell-2 { width: 460px; }
.grid-4 .cell-3 { width: 700px; }

Which would give you the following combinations available:

<div class="container">
  <div class="grid-4">
    <div class="cell-3"><p>Text</p></div>
    <div class="cell"><p>Text</p></div>
  </div>
  <div class="grid-4">
    <div class="cell"><p>Text</p></div>
    <div class="cell"><p>Text</p></div>
    <div class="cell"><p>Text</p></div>
    <div class="cell"><p>Text</p></div>
  </div>
  <div class="grid-4">
    <div class="cell"><p>Text</p></div>
    <div class="cell"><p>Text</p></div>
    <div class="cell-2"><p>Text</p></div>
  </div>
</div>

Step 4: The result

The result should be the following:

.container {
  width: 960px;
  margin: 0 auto;
  padding: 1.5em 0;
}
.grid, .grid-2, .grid-3, .grid-4 {
  clear: both;
  overflow: hidden;
  margin-bottom: 1.5em;
}
.cell, .cell-2, .cell-3 {
  float: left;
  display: inline;
  margin: 0 10px;
  position: relative;
}
.alpha { margin-left: 0; }
.omega { margin-right: 0; }
.grid .cell { width: 940px; }
.grid-2 .cell, .grid-4 .cell-2 { width: 460px; }
.grid-3 .cell { width: 300px; }
.grid-3 .cell-2 { width: 620px; }
.grid-4 .cell { width: 220px; }
.grid-4 .cell-3 { width: 700px; }

I have tidied up the code slightly, as the width for a 2 column cell is the same as a double cell in a 4 grid system.

If you look at the source code for this site, you will see that there are 2 sets of widths defined. This is to cater for larger screens. A piece of javascript is triggered as soon as the page has finished loading and any resizing of the browser window which applies a class called wide to the body of the HTML. If the window width is larger than 1200px then the site will be displayed in a larger grid system. You could do the same using a stylesheet switcher to be able to change from a narrow to wide theme.

Step 1

Open Photoshop and create a new image how ever big you want it.

Step 2

Create a black bar using the rectangular marquee tool on a new layer.

Step 3

Using the same selection go to the Select menu and select feather, set to 10px. On a new layer fill this with white.

Step 4

Press Ctrl + T to transform the layer. Drag the bottom slider up to the top to shrink the layer.

Step 5

Move the layer in to place and set the opacity to 30%.

Step 6

Select the Single Row Marquee tool and create a selection, press and hold Ctrl + Alt + Shift and click on the preview area of the black box in the layers panel.

On a new layer fill with #00adef do this again and make sure they are one on top of the other so it’s 2px high.

Step 7

Now we will add some shading over the clue bar so it isn’t so bright.

Press and hold Ctrl and left click the preview area of the blue bar in the layers panel.

On a new layer fill the selection with black.

Press Ctrl + D to deselect the selection.

Go to Filter » Blur » Gaussian Blur and set to 1px.

Set the layer opacity to 60%.

Press V and move up 1px.

Step 8

Add extra details to it such as text and reflection and you are finished.

Step 1: The HTML

For the HTML we will use an unordered list so the navigation is accessible and will still partly work without the CSS file such as in text browsers.

<div class="steps">
  <ul>
    <li class="step step-1">
      <a href="#"><strong>Step 1</strong><br />Some random text that describes the step</a>
    </li>
    <li class="step step-2">
      <a href="#"><strong>Step 2</strong><br />Some random text that describes the step</a>
    </li>
    <li class="step step-3">
      <a href="#"><strong>Step 3</strong><br />Some random text that describes the step</a>
    </li>
  </ul>
</div>

This will leave us with the following – view step 1 result.

Step 2: Style with CSS

We now need to make it pretty, firstly we reset the default CSS rules applied to unordered lists by the browsers.

.steps ul, .steps li {
  margin: 0;
  padding: 0;
  list-style: none;
}

This resets the margins and padding around each the list itself and each list element within the list as well as removing the list-style (i.e. the bullet).

To make the elements appear side-by-side rather than on top of one another, we need to float the list elements.

.steps ul { float: left; }
.steps li {
  float: left;
}

This will leave you with your list elements side-by-side. View the result of step 2.

Step 3: Make the steps in to arrows

The next step is to add in our arrows to be background images.

.steps li a {
  display: block;
  padding: 15px 20px;
  color: #fff;
  line-height: 1.5em;
  text-decoration: none;
}

This makes the anchor tags act like block level elements so that they fill out in to their parent item which is the <li>. We also add some padding and set the line-height to make it look nicer.

Next we add in the background images for our list elements. You can use these images for the time being to speed up the process, just right click them then save them in the same folder as your CSS file. Normal & Hover. The images are basic PNGs with transparent sections on the end of arrow. There is also a 1px stroke to the right which gives you the seperator between the steps. The images should be as wide as your container, the reason for this is mentioned in step 5.

.steps li.step a { background: transparent url(step.png) center right no-repeat; }
.steps li.step a:hover { background: transparent url(step_over.png) center right no-repeat; }

This adds in the images to our steps with the hover state. View result of step 3

Step 4: Setting the width and aligning the steps

As you can tell from the result of step 3, we have a bit of a mess now. So now we can clear it up. My example is wrapped in a container which is 960px wide, so what I am going to do, is divide that by 3 as I have 3 steps. That means each step should be 320px wide. So alter the CSS for .steps li to the following:

.steps li {
  float: left;
  width: 320px;
}

This now lines our steps side-by-side again with the text wrapped to fit in the width, but the arrows are stop start and aren’t covering each other.

To get around this, we use a negative margin to pull the element to the left, although we only apply this to the 2nd and 3rd steps.

.steps li.step-2, .steps li.step-3 { margin-left: -30px; }

Now you will notice a new problem. The later steps are covering the earlier steps so the arrow isn’t visible. To get around this, we will use the CSS property z-index to change the layering on the z-axis.

For z-index to be effective though, we also need to change the positioning type of the list element and child anchor.

.steps li.step, .steps li.step a {
  position: relative;
  z-index: 3;
}
.steps li.step-2, .steps li.step-2 a { z-index: 2; }
.steps li.step-3, .steps li.step-3 a { z-index: 1; }

Once again we have created more problems. The first one being that some of the text is now hidden beneath the arrow of the preceeding step. We can get around this by adding some extra padding.

.steps li.step-2 a, .steps li.step-3 a { padding-left: 50px; }

The 50px comes from the -30px which is the left negative margin + the extra 20px of padding we defined earlier on for each anchor element.

The negative margins also made the total width of our stepped element less than 960px so we have a gap at the end. With some simple maths we can work out the new width that each list element must be to fit the 960px width. We have a 960px container with 2 elements with negative margins of 30px, so 960px + 60px = 1020px. Now we divide that by 3 to get our new width which is 340px.

.steps li {
  float: left;
  width: 340px;
}

This then leaves us a lot closer to our goal. View result of step 4.

Step 5: Fix the background position of the last step

The arrow is showing on the 3rd step although it doesn’t go anywhere, it is the end. To fix this, we just need to change the background position for step 3, this is the reasoning for our images being long.

.steps li.step-3 a { background-position: center left; }
.steps li.step-3 a:hover { background-position: center left; }

We change the background image to be aligned to the left so it is solid colour, as we made the images longer than the content, unless there is only 1 step (why would you be doing this tutorial if you only had 1 step?) the arrow won’t be seen.

Then you have a finished stepped navigation. View result of step 5.

Then with a little extra CSS for text formatting and some borders on the parent element you are left with the final result.

Unfortunately from what I can tell Drupal’s pagination function only works with SQL queries so we are unable to use the existing data available in the node object. But due to Drupal’s nice database schema, it is very simple to write some simple SQL to give us the pager.

Below is the full code and below the code I will explain what each part does.

<?php
$count = count($node->field_images);
if ($count > 0):
	$images_per_page = 9;
	$sql = "SELECT f.fid, i.field_images_data, f.filepath FROM content_field_images i JOIN files f ON f.fid = i.field_images_fid WHERE nid = ". $node->nid;
	$count = "SELECT COUNT(f.fid) FROM content_field_images i JOIN files f ON f.fid = i.field_images_fid WHERE nid = ". $node->nid;
	$query = pager_query($sql, $images_per_page, 0, $count);
	while ($data = db_fetch_object($query)) {
		$images[$data->fid] = array(
			'filepath' => $data->filepath,
			'data' => unserialize($data->field_images_data),
		);
	}
	$rows = array();
	$images_per_row = 3;
	$i = 0;
	$row = 0;
	foreach ($images as $image) {
		$rows[$row][$i] = '<a class="gallery-thumbs" title="'. htmlspecialchars($image['data']['description']) .'" rel="lightbox[photo_gallery-'. $node->nid .']" href="'. imagecache_create_url('lightbox', $image['filepath']) .'">'. theme('imagecache', 'thumbnail', $image['filepath'], $image['data']['title'], $image['data']['title']) .(trim($image['data']['description']) != '' ? '<br /><small>'. $image['data']['description'] .'</small></a>' : '');
		$i++;
		if ($i == $images_per_row) {
			$row++;
			$i = 0;
		}
	}
	?>
  <table class="views-view-grid">
    <tbody>
      <?php foreach ($rows as $row_number => $columns): ?>
        <?php
          $row_class = 'row-' . ($row_number + 1);
          if ($row_number == 0) {
            $row_class .= ' row-first';
          }
          elseif (count($rows) == ($row_number + 1)) {
            $row_class .= ' row-last';
          }
        ?>
        <tr class="<?php print $row_class; ?>">
          <?php foreach ($columns as $column_number => $item): ?>
            <td class="<?php print 'col-'. ($column_number + 1); ?>">
              <?php print $item; ?>
            </td>
          <?php endforeach; ?>
        </tr>
      <?php endforeach; ?>
    </tbody>
  </table>
  <?php print theme('pager', array(), $images_per_page, 0); ?>
<?php else: ?>
  <p>No images in album</p>
<?php endif; ?>

First thing we do is check to see if there are any images. Rather than doing a SQL query to get the result, I have chosen to use the already existing array of images in the node object.

$count = count($node->field_images);

Then as before we check to make sure we have images, then create our query to generate the pager.

$images_per_page = 9;
	$sql = "SELECT f.fid, i.field_images_data, f.filepath FROM content_field_images i JOIN files f ON f.fid = i.field_images_fid WHERE nid = ". $node->nid;
	$count = "SELECT COUNT(f.fid) FROM content_field_images i JOIN files f ON f.fid = i.field_images_fid WHERE nid = ". $node->nid;
	$query = pager_query($sql, $images_per_page, 0, $count);
	while ($data = db_fetch_object($query)) {
		$images[$data->fid] = array(
			'filepath' => $data->filepath,
			'data' => unserialize($data->field_images_data),
		);
	}

In the query, we are gathering the file id (fid) of each individual image, the field_images_data which is a serializd array of the title, description and alt text of the image from when it was uploaded and the filepath of the image. The count isn’t necessarily needed, but I have found the pager can act oddly when the $count part of pager_query() is missing.

pager_query() also requires 2 other elements. The first after $sql, is the amount of rows to be taken out the database. The next number is the element number. This is needed for pages with multiple pagers on them. If you have got multiple pagers and experience trouble then you will need to change this.

Then from this we recreate the $images array that we had before, although it is missing some information which is provided through the $node object, it provides everything that we need to display the image on the page.

The whole table HTML section remains untouched, but it is followed by an extra line:

<?php print theme('pager', array(), $images_per_page, 0); ?>

This prints out the Drupal pager below out table of images. This can be used multiple times on a page, so you can have some pagination below and above the table of images.

If the page you are displaying the albums on already has pagers, you may need to change the 0 in both the theme_pager() and pager_query().

You should now have a fully working grid with pagination.

Edit: As pointed out by dukat in the comments, you can change the original SQL query to the following to keep the images in the order defined in the node.

$sql = "SELECT f.fid, i.field_images_data, f.filepath FROM content_field_images i JOIN files f ON f.fid = i.field_images_fid WHERE nid = ". $node->nid ." ORDER BY i.delta ASC";

Obviously you can change the order between ASC or DESC.