Apr 09 2008
Nik
Apr 09

Just a quick tip for an extra, more accessible theming variable. I have personally found that on nearly all the sites I’ve built, I’ve never had a use for the Mission variable. So it struck me that I could probably use this field to output something else; something relevant to the general workings of the site, for sure though.

So, on this site, I have edited the mission variable and put in the copyright notice that you see at the bottom of the page. I saved the config screen and carried on, thinking that it would just be working – I had tested it out on the front page, and the value was appearing where I had placed the $mission variable in the footer area in my page template. No problems, I thought.

Today, I actually noticed that this was not appearing, and I couldn’t work it out for a while, but I trawled through the phptemplate.engine, and in there is some code that conditionally sets the $mission variable on only the front page – perhaps that’s why it doesn’t get used so much?

Anyway, I opened up the template.php file for my theme, and placed in it the code below, in the _phptemplate_variables bit under case 'page' – see here. Now I have a usable variable across all pages of my site, with the added advantage that this is accessible from the admin interface at “site information”. I guess that the theme settings API in Drupal 6 may alleviate this problem, but for simple things like updating the year (which is contained in my © statement) in D5, this is a potential time saver (and face-saver) for administrators.

<?php
 
// populate the $mission variable on every page so we can use it universally
  // don't check <front>, it's already handled in phptemplate.engine
if (!$vars['is_front']) {
   
$vars['mission'] = filter_xss_admin(theme_get_setting('mission'));
  }
?>
Mar 26 2008
Nik
Mar 26

Today I’m just demonstrating a few simple theme adjustments to comments. Comments in Drupal 5 are “not sexy”, out of the box, so in this short post I’m going to illustrate how to:

  • change the text on “submitted” lines in comments (just a little)
  • add nofollow to username links – unless you’re feeling generous
  • remove the “not verified” marker from anonymous users

<?php
// change the "submitted by" text to "posted by"
// note that you can alter the date display too, by changing the way
// format_date() is called - see http://api.drupal.org/api/function/format_date/5
$vars['submitted'] = t('Posted by !a on @b.',
                     array(
'!a' => theme('username', $vars['comment']),
                    
'@b' => format_date($vars['comment']->timestamp)));
?>

This first snippet belongs in the ‘comment’ section of your _phptemplate_variables function in template.php; I have an example of this here.

Moving on to that “not verified” business, and the question of holding on to your link juice, adding an overridden theme_username() function is the way to go. Here’s some code, which you can also place in your template.php file in your theme. Remember, if you don’t have that file in your theme, you can just create it yourself. I personally recommend Zen as a starting point for theming.

<?php
// we can't use phptemplate_username as this is already declared in that engine
function mytheme_username($object) { // rename according to your theme

  // this basically means "if the user has an account"
 

if ($object->uid && $object->name) {
   
// Shorten the name when it is too long or it will break many tables.
   
if (drupal_strlen($object->name) > 20) {  // obviously you could change this value
     
$name = drupal_substr($object->name, 0, 15) .'...';
    }
    else {
     
$name = $object->name;
    }

    if (

user_access('access user prosites/default/files')) {
     
// we could nofollow the internal links too (authenticated user's pages)
      // but there's not really any point - my site doesn't use membership,
      // so usernames are not highlighted -
      // commented line below would do that, though.
      // $output = l($name, 'user/'. $object->uid,
      //     array('title' => t('View user profile.'), 'rel' => 'nofollow'));
     
$output = l($name, 'user/'. $object->uid,
          array(
'title' => t('View user profile.')));
    }
    else {
     
$output = check_plain($name);
    }
  }
// if we're entering this func, the user is anon (i.e. we want to nofollow them)
 
else if ($object->name) {
    if (
$object->homepage) {
     
// this is where we're nofollow-ing the external links to comment authors' pages
      // we don't really need to use t() here, as rel=nofollow is language independent
     
$output = l($object->name, $object->homepage, array('rel' => 'nofollow'));
    }
    else {
     
$output = check_plain($object->name);
    }
   
// commenting out this line prevents "teh ugly" in the $submitted text
    // $output .= ' ('. t('not verified') .')';
 
}
  else {
   
$output = variable_get('anonymous', t('Anonymous'));
  }
  return
$output;
}
?>

If you’ve got any other simple tips like these, let me know, so I can use & share those too!

Update: This code works fine under Drupal 6 as well – but don’t forget to clear your theme registry when you’ve modified things in your theme!

Mar 16 2008
Mar 16

The number of available Drupal modules is continuing to grow dramatically. Like a lot of other Drupal users, I spend a good deal of time downloading new modules and trying them out to see what they do. Unfortunately, not all contrib modules work as advertised. I may spend several hours working with a new module before realizing there's some small issue with it that prevents it from solving my problem.

Similarly, there are often modules out there that solve problems I didn't even know I had, but I'm simply not aware they exist.

What I want is a resource that leverages the experience of thousands of Drupal administrators. I want to know that I shouldn't even bother with a module because it's too buggy. I want to know what modules other users find useful in specific areas (such as multimedia, file handling, cache issues, etc.).

Other large OSS communities often solve this need for a shared knowledge base by providing user reviews. Mozilla, Thunderbird, Joomla and other modular systems provide user reviews and ratings. It is time that the Drupal community have one too.

When I first started using drupal about three years ago, it was not all that difficult to simply be aware of most modules and how effective they were because there just weren't that many. Now there are multiple new modules released on a daily basis, and I just can't keep up anymore.

Why do we, the Drupal community, not have a shared review/rating system? It's certainly not due to lack of demand. A search for "module ratings" on Drupal.org reveals a great deal of interest in this functionality.

As far as I can tell, the primary reason for not having a rating system for modules is fear. Module developers in particular are concerned with the fairness of ratings. They are concerned with "gaming" of ratings. They are concerned that inexperienced or "dumb" end users may unfairly give a bad review of a module simply because they don't understand how to use it. These are all reasonable concerns. But they are concerns shared by other OSS projects as well. Sure you will see "bad" reviews, giving a module the lowest possible rating along with some inane review such as "tis modules sukcs BEWARES" :) But who cares, it's just noise that will be drowned out by valid reviews. It works for other OSS projects, and it can work for Drupal.


John Forsythe
has released what I believe is the first site dedicated to rating and reviewing Drupal modules drupalmodules.com. No doubt this site will be a source of controversy as developers voice their concerns. But we need this resource now.

I encourage my entire audience (hi, mom!) to register at drupalmodules.com and to submit reviews for both your favorite and most hated Drupal contributions. This is a great way for non-techies to contribute to the community. The site is young, and there is naturally a shortage of ratings on the site now, but that will change as the site brings on more users.

Maybe this database will eventually make its way to Drupal.org. For now we can show our support for this type of system by helping build out the database at drupalmodules.com.

Feb 28 2008
Nik
Feb 28

This snippet of code gives a brief example of how to rewrite components of the $links variable to make them prettier :) Specifically, here I’m overwriting the link generated by the Forward module. You can see the result below: the little envelope icon labelled “Email”. Normally, this would just say “Forward this page”, which is a bit… well, it could be better. Obviously, it’s nice to be able to change these things to taste.

There are two ways to achieve this result: using theme code in template.php, or inside of a helper module. First, I’ll discuss the module approach.

The helper module method is what I had originally used. It’s a little neater, in that you code it once and forget about it, and it doesn’t clutter up template.php’s _phptemplate_variables function, which can easily become bloated with code.

In the module, I’ve added a function to implement Drupal’s hook_link_alter() function. Here’s the code to do it:

<?php
function mymodule_link_alter(&$node, &$links) {
  foreach (
$links as $module => $link) {   // iterate over the $links array
    //drupal_set_message(print_r($links)); // uncomment to display your $links array

    // check if this element is the forward module's link
   

if ($module == 'forward_links') {
     
$title = t('Email this page to a friend');    // change the title to suit
     
$path = path_to_theme() . '/images/email.png' // make an image path

      // now update the links array
      // set the title to some html of the image and choice of link text
     

$links[$module]['title'] = theme('image', $path, $title, $title) . ' Email'; // let's set some attributes on the link
     
$links[$module]['attributes'] = array(
       
'title' => $title,
       
'class' => 'forward-page',
       
'rel' => 'nofollow',
      );
// this must be set, so that l() interprets the image tag correctly
     
$links[$module]['html'] = TRUE;
    }
  }
}
?>

Ok so really, this ought to be done in the theme layer. Like I said, it’s perhaps not as compact and neat, but here’s the code. It’s mostly the same, but note a couple of additions and changes: firstly, we are not changing $links – this is a pre-rendered string by the time it gets to the template.php. We need to get to the original goodies! Hence, we use $vars[&#039;node&#039;]-&gt;links[module-name][field-name].

Secondly, note that because we have now altered the value of one of the original links’ values, does not mean that the node’s $links is correct. This is the bit that caught me out! We must now regenerate the $links variable using the theme_links() function, as per the last line of code below. This mimics what phptemplate.engine does in core.

<?php
function _phptemplate_variables($hook, $vars = array()) {
  switch (
$hook) {
    case
'node':
      foreach (
$vars['node']->links as $module => $link) {
        if (
$module == 'forward_links') {
         
$title = t('Email this page to a friend');
         
$path = path_to_theme() . '/images/email.png';
         
$vars['node']->links[$module]['title'] =
             
theme('image', $path, $title, $title) . ' Email';
         
$vars['node']->links[$module]['attributes'] =
              array(
'title' => $title, 'class' => 'forward-page', 'rel' => 'nofollow');
         
$vars['node']->links[$module]['html'] = TRUE;
        }
      }
     
$vars['links'] = theme('links', $vars['node']->links,
                                           array(
'class' => 'links inline'));
      break;
  }
}
?>

You can achieve this effect for anything that’s in the $links array. On this page (below), you can see the link I’ve described here, another for print-friendly pages and also a themed comment link.

Feb 27 2008
Nik
Feb 27

Currently there are three options for creating error pages in the Drupal system, that I know of. I’m going to show here which I think is the best, for reasons of usability, performance and general webmaster sanity. At the foot of this article, there’s some free code too!

The options:

Drupal’s build in error page support

Drupal provides, out of the box, two fields in the Error Reporting configuration screen. These fields can be set to any internal Drupal path. Usually, they will be set to point the user to a page created specifically for the purpose.

The downside to this is that these will now be nodes in the system, and as such they will show up in popular content lists, site searches and the like. This is clearly not desirable.

Update: I have been made aware of an outstanding issue in Drupal core with error pages. This issue means that a user without “access content” permissions cannot access 403 error pages that are created as nodes. This is true in Drupal 5.x and even 6.1, and is another weak point for this mechanism.

Search404 module

Until very recently I was using search404 but I became less than pleased with the results. To start with, I thought I was aiding usability, but as it transpires… not really. The real killer for me is that search404 often gives me empty search result sets, because the path elements just don’t relate specifically enough to the content.

For instance, the node “/blog/my-drupal-article” will almost certainly contain all the words “my drupal article”, but may not contain the word “blog”, except in the path. This means the search doesn’t catch that article, so you get no results. Given that every 404 page the module generates incurs a DB query automatically, this query is effectively just trash, but cannot be disabled.

Customerror module

Customerror module skirts round the issues of having nodes as error pages. The module makes error handling pages available as custom paths inside Drupal. These aren’t nodes, so we have no issues there.

The configuration screen offers up two textarea fields which will contain the page content to be rendered on each of the 403 and 404 page errors. The key to making this more special than just a plain text or html page is the availability of PHP processing for these fields whilst not requiring nodes for the task.

Ok, so what I’m doing here is recommending customerror as the best choice for this task. That said, let’s throw down some code and make this more useful.

To start, visit the standard Drupal error reporting page at “/admin/settings/error-reporting”. Here, set the default error page fields to “customerror/403” and “customerror/404” respectively, if you’re going to override both these pages.

Now, on the Custom Error module’s config page at “/admin/settings/customerror”, enable both checkboxes that say “Allow PHP code to be executed for 40x”. Now let’s look at handling the 404 error. I’ve added the following code for this site, in the “Description for 404” textarea, and a suitably snappy title in the other field: “404 Not Found Error: No content found at the requested URL”.

<p>Sorry, no content was found at the requested path - it's possible that you've requested this page in error.</p>

<p>Use the search form below, or go to the <a href="http://www.kinetasystems.com/">home page.</a></p>

<?php
// check that the search module exists and the user has permission to hit the form
if (module_exists('search') && user_access('search content')) {
 
// cool! - customerror doesn't trash the page request and the full path is available
 
$path = $_REQUEST['destination'];
 
// bin anything that's not alphanumeric and replace with spaces
 
$keys = strtolower(preg_replace('/[^a-zA-Z0-9-]+/', ' ', $path));

  // retrieve the search form using the data we've pull from the request
  // note that we can override the label for the search terms field here too
 
print drupal_get_form('search_form', NULL, $keys, 'node', 'Search terms');
}
?>

In the 403 error fields, we adopt a similar technique. I’ve used “403 Forbidden Error: Access to this page is denied” for the title. Here we display different content depending on whether or not the user is logged in. If you’re running a site with lots of members, you can uncomment the user login line towards the bottom and the login form will be rendered on the 403 page!

<?php global $user; ?>
<?php if ($user->uid): ?> 
  <p>Sorry <?php print $user->name; ?>, you don't have permission to view the page you've just tried to access.</p>
  <p>If you feel that you have received this message in error, please
    <a href="http://www.kinetasystems.com/blog/creating-custom-error-pages-in-drupal/contact">contact us</a> with specific details so that we may review your access to this web site.</p>
  <p>Thanks</p>
<?php else: ?>
  <p>This page may be available to clients and registered users only. Please select from one of the other options available to you below.</p>
  <ul>
    <li><a href="http://www.kinetasystems.com/user/login?<?php print drupal_get_destination(); ?>">Login</a> to view this page</li>
    <li>Use the <a href="http://www.kinetasystems.com/blog/creating-custom-error-pages-in-drupal/search">search</a> facility</li>
    <li>Go to the <a href="http://www.kinetasystems.com/">home page</a></li>
    <li>Go to the <a href="http://www.kinetasystems.com/blog/creating-custom-error-pages-in-drupal/sitemap">site map</a></li>
  </ul>
<?php //print drupal_get_form('user_login'); ?>
<?php endif; ?>

Now we’ve got friendly, usable error pages that are helpful and don’t scare off visitors!

Updated 24th April 2008

Feb 23 2008
Nik
Feb 23

Quite frequently I’ve been asked about putting images into site “sections”, depending on path or menu trail. Look up, that “Blog” image is what I’m talking about. It’s on all blog related pages. So, here goes – it’s nice to be able to finally offer this information here.

The first main chunk of code attempts to get a menu item and build an image link from that. The second chunk assumes failure of the first and tries again using a partial path method.

If all nodes on your site have menu entries, you can use that piece of code independently. Likewise, if all your nodes can be identified by the first bit of the path, the second chunk will stand alone.

I have got a mixture of the two on this site. A lot of the entries have menu entries, but the blog and portfolio section do not. Therefore, the image links on those sections are powered by the second chunk.

Note: this code expects to find sites/default/files of the GIF type in a directory ‘images/sections’ within my own theme directory. It also will only pick up sites/default/files that have names which are all lower case. In the case of menu entries that contain spaces, those will be replaced with hyphens, so if the menu link is “Site Map”, the image name will have to be “site-map.gif”. Path-based is really dependant on how you are using aliases (e.g. your pathauto.module setup) and isn’t really inside the scope of this article. You’ll have to figure that out yourself.

Okay; in order to not crowd up _phptemplate_variables(), I add just this one line of code in template.php inside that function (under ‘page’ – see here for details):

<?php
$vars
['section_link'] = get_section_link();
?>

Then, elsewhere in that file, this code:

<?php
function get_section_link() {
 
// MENU - attempt to make a section link from a menu item, for this page
  // get active menu trail into an array
 
$menu_items = _menu_get_active_trail(); // $menu_items[1] is the top parent of our menu container, e.g. primary links
  // this gets the required menu item into an array
 
$link_array = menu_item_link($menu_items[1], FALSE); // whip out spaces and make the name lower case
 
$section_name = strtolower($link_array['title']);
 
$section_name = str_replace(' ', '-', $section_name);

  if (

$section_link = render_link($section_name)) {
    return
$section_link;
  }
// PATH - if we've not returned, we couldn't make a valid link from menu
  // let's try a path approach instead?
 
if (module_exists('path')) { // dependency for drupal_get_path_alias $sections = array(); // an empty array to collect stuff in

    // get all the top level links in the primary nav (id of 2) into a array
   

$primary_nav = menu_primary_links(1, 2); // iterate over the array and pull out the top level paths
   
foreach ($primary_nav as $menu) { // get the first element of the aliased path for this menu item
     
$path_element = explode('/', drupal_get_path_alias($menu['href'])); // put the first chunk of each path onto an array
     
$sections[] = $path_element[0];
    }
// get the aliased path for the page we're on
   
$section = explode('/', drupal_get_path_alias($_GET['q']));
   
$section_name = $section[0]; // if the path matches a nav item, create a section image
   
if (in_array($section_name, $sections)) {
      if (
$section_link = render_link($section_name)) {
        return
$section_link;
      }
    }
  }
}

function

render_link($section_name) {
 
// construct the image's path (mine are GIFs stored in a subdir of my theme)
 
$image_path = path_to_theme() . '/images/sections/' . $section_name . '.gif'; // make some text for the image's alt & title tags (SEO, accessibility)
 
$image_alt = $section_name . t( ' section');
 
$image_title = $section_name . t( ' section link'); // render image html using theme_image (returns NULL if file doesn't exist)
 
$section_image = theme('image', $image_path, $image_alt, $image_title); // if the image rendered ok, render link using above variables
 
return ($section_image) ? l($section_image, $link_array['href'],
      array(
'title' => $image_title), NULL, NULL, FALSE, TRUE) : NULL;
}
?>

Then finally in page.tpl.php (and any other page templates) we can use the variable in the “Drupal Way”, and print our variable where we like!

<?php if ($section_link): ?>
  <div id="sectionTitle">
    <?php print $section_link; ?>
  </div>
<?php endif; ?>

Feb 16 2008
Feb 16

The importance of project management tools is almost never fully appreciated. I am shocked at how common it is for a group of developers to go working without version control, ticket tracking, development documentation and so on. The very first thing I do when working with a new client is to make sure that they get these tools in place if they haven't already.

Those who are used to working without a complete set of project management tools never fail to appreciate the benefits of them once they are introduced. I consider it next to impossible for a team to work together without managing code and tasks in an efficient and highly organized way.[img_assist|nid=155|title=|desc=|link=none|align=right|width=250|height=156]

Hopefully you do not need to be sold on this idea and are using CVS or SVN to manage your project already. You likely have some sort of ticket system. It is a little less likely that you have both of these components integrated with each other.

When it comes to choosing a solution for project management software, a die-hard Drupal user has a dilemna. On one hand, Drupal seems as though it should be the perfect solution. It's fully customizable, has lots of nifty project management related modules and, most importantly, it's Drupal! Why would you not use it? "Eating your own dogfood" is the way to go, right? Meh...

Drupal is generally considered a content management system. Personally, I like to refer to it as a website management system. It is great at managing website related stuff like users, posts, permissions, categorization, and so on. Using contrib modules, you can customize and enhance this core functionality to almost no end. But at the end of the day, Drupal is designed to handle web content and the users that are accessing it. That's what a content management system is (and if content is king, that would make Drupal... well... God).

Managing a project, on the other hand, is a much different business from managing a website. Yes, you have many shared properties such as content and users. But the essence of project management involves things that have nothing to do with website management such as a revision controlled code base edited by multiple users, a need for efficient ticket management, and ideally full integration of everything. Essentials also include stuff like a nice repository browser, user management interface for repository access, fancy reporting for tickets, organization of tasks by milestone, date, person, severity, etc...

It's a very tall order. Yes, you can do all this in Drupal, but not very well. You can piece together something that sorta kinda resembles a project management solution, but in the end, you need to invest a relatively large amount of time to create something that is less than ideal and will require ongoing tweaking and modification. Unless your business is creating an effective project management solution in Drupal (something I dream of!), you should not be using Drupal for project management.

I'm a one man shop, and I do not have time to spare. I cannot justify spending any time at all kludging together a project management solution for a client when there are already far superior solutions available at low cost. I would much rather pay someone a few bucks a month and be done with it. Let them deal with SVN administration and enhancements; let me focus on my primary task which is building cool sites with Drupal.

While there are numerous project management related service providers out there (Fogbugz, Basecamp , Beanstalk to name a few), I want to talk about my personal favorite, Unfuddle. Unfuddle has taken obvious inspiration from the folks over at 37signals, innovators of the simple, clean, effective, it-just-works web application. Unfuddle is an instant project management solution that takes minutes to set up and costs a few dollars a month. The time you'll save in not having to set up SVN and manage SVN users alone makes it worth every penny.

[img_assist|nid=156|title=|desc=|link=none|align=left|width=250|height=221]What you get with a solution such as unfuddle is a ready-to-use repository with integrated documentation, ticketing and reporting. It takes seconds to set up a new user account with permission levels fit for everyone from a developer (gimme root!) or a suit (look but don't touch).

From a single interface, you can browse code, tickets and documentation. Every component integrates with the others. You can even resolve a ticket with an SVN commit message, saving you the trouble of having to go and edit the ticket after your commit! Users can individually subscribe to whatever level of email notificaton they would like to recieve and how often. The developer can shut off all notifications while the manager can get a nice daily summary each morning of milestone completion progress, new tickets, added documentation and so on. The project manager can glance over one of the ticket reports and group tickets into milestones for reasonable short vs long term goals.

SVN comments link back to the tickets they are related to. Tickets contain links to the changesets that resolved them. Viewing these changesets, you can see a beautiful code diff and quickly see what fixed the problem. Senior team members can quickly and easily review code changes submitted by junior staff.

With tools like this available these days, it's just not worth it spending any effort whatever on a lesser solution.

Feb 14 2008
Nik
Feb 14

Yesterday afternoon, I popped my head onto the Drupal IRC channels, and suddenly everything went a bit strange…

Somebody shouted, “Drupal 6 is out!” – and then the whole place erupted into hysterical blogging and Digg-ing (over 1000 now) and general chaos. Millions of tiny blue aliens are unleashed – Drupal 6 is ALIVE!

But the real story is obviously the news of the latest release of our favourite content management system-stroke-framework! Or should that be “community site building system” or “social publishing platform” or… well. That’s the great thing about Drupal, it can do pretty much anything! Expect it to be doing the washing-up for you by v7.

So what’s under the hoody? More features! Even better security! Massively improved language support! Performance streamlining! Usability enhancements up the wazoo! Just… loads of stuff. Loads.

Please Digg the story if you can, or for a clearer idea of what’s going on, check the official Drupal.org thread on the release here. As if it wasn’t crystal clear already…

Oh, and here is the official Drupal 6 press release. I quite like this doc – cos I helped write it! I wrote the intro text and title (with some help from Keith and final mods). That’s my fifteen nanoseconds of fame…

Feb 11 2008
Nik
Feb 11

I sometimes run into people on the Drupal IRC channels that have a theming issue they just can’t fathom – dysfunctional CSS. Some poor guy has overridden a core CSS class, but his styles just don’t work. I’ve been there myself before and I know it can be very frustrating.

Rather than showering your CSS with !important tags, here is an alternative – remove the offending style file altogether. You can then copy the style information into your own theme, remove any bits that you don’t want and alter it as you see fit.

Let’s see how we get rid of those sites/default/files and regain control of our CSS. Put some code similar to this in the “page” section of your template.php file’s _phptemplate_variables function (see this example).

<?php
// get all the current css information into an array
$css = drupal_add_css();// copy stuff you want to keep from these sites/default/files into your theme's style.css
// or maybe make a separate file for that and @import it into that file

// now we can ditch unwanted core css sites/default/files from the array and they won't be included

unset($css['all']['module']['modules/user/user.css']);
unset(
$css['all']['module']['modules/node/node.css']);// and now, removing the css sites/default/files of some contributed modules
// I'm putting them into an array to save space and code repetition
$rm[] = drupal_get_path('module','content').'/content.css';
$rm[] = drupal_get_path('module','devel').'/devel.css';
$rm[] = drupal_get_path('module','gotcha').'/gotcha.css';// now we can remove the contribs from the array
foreach ($rm as $key => $value) {
  unset(
$css['all']['module'][$value]);
}
// now place the remaining css sites/default/files back into the template variable for rendering
$vars['styles'] = drupal_get_css($css);
?>

You should now be able to see that the CSS sites/default/files have disappeared from the head of your document – a pretty drastic step, but it’s pretty much guaranteed…!

Feb 07 2008
Nik
Feb 07

Recently released – a Javascript aggregator module for Drupal 5. This function is included in core in Drupal 6, but users of 5.x are left hanging on. Enter, the Javascript Aggregator module.

I put this onto my own site straight away to test it out, as I’m using shared hosting at the moment, and I want to reduce page load times as much as I can. It seems to work just fine. The module requires no core patches, and also includes an interface for file exceptions, as TinyMCE (natch) causes the module to fail.

Theming purists should maybe note the issue I filed here, which clears up a problem with having to add unnecessary PHP into the page.tpl.php file. It looks like this will get sorted and patched fairly soon, though [Edit: that’s fixed]. This is another great way to speed up Drupal page load times!

Posted by Nik - February 7th, 2008 at 11:58am

Dec 19 2007
Dec 19

Views Bulk OperationsViews bulk operations is ready for some beta testers.

It is essentially the admin nodes page on steroids. It enables you to perform node operations as well as actions from a custom view.

If you want to quickly check it out, install it, then go to the views overview page. Select 'add' for the 'admin_content' view, configure it and save it. When you first go to the view, you will be prompted to enable actions and/or operations.

For the full effect, install the actions module as well.

If you have any problems using it, please submit a bug!

Nov 29 2007
Nov 29

Drupal books are a great way to organize content. Unfortunately, there is no way to control access to individual books by default. Like default forums, it's all or nothing.

The Book Access module adds the ability to set view, edit and delete access control for individual books and all pages therein.  

This module has no official release as it needs to be tested. The development snapshot is ready for testing though.

If you're interested in such functionality, install this module and please submit feedback and bug reports

Thanks to LifeWire for sponsoring development of this module. 

May 24 2007
May 24

SWF Charts is a API wrapper for PHP/SWF Charts.

I have just finished the basic module and want to get feedback and see if there's any interest in such a module. The primary reason there may not be interest in this module is that PHP/SWF Charts is not GPL'd, and that's generally a major turnoff for most (including me). But I'm not aware of any other method of generating high quality charts and graphs while not introducing unnecessary server load and not requiring fancy PHP Graphing libraries.

Right now the module relies on a moderately complex data structure as input. I did not want to try to create an abstraction layer initially as that inevitably results in "hiding" functionality, though it would make the module much easier to use.

The following sample charts are based on those from the PHP/SWF Charts Gallery page. The first sample graph consists of the following code saved as a PHP node:

<?php
$config
['height'] = 300;
$config['width'] = 400;
$config['bgcolor'] = '#FE8F01';$chart[ 'axis_category' ] = array ( 'font'=>"arial", 'bold'=>true, 'size'=>16, 'color'=>"000000", 'alpha'=>60, 'skip'=>0 ,'orientation'=>"vertical_up" );
$chart[ 'axis_ticks' ] = array ( 'value_ticks'=>false, 'category_ticks'=>false, 'major_thickness'=>2, 'minor_thickness'=>1, 'minor_count'=>1, 'major_color'=>"222222", 'minor_color'=>"222222" ,'position'=>"centered" );
$chart[ 'axis_value' ] = array ( 'font'=>"arial", 'bold'=>true, 'size'=>10, 'color'=>"ffffff", 'alpha'=>50, 'steps'=>6, 'prefix'=>"", 'suffix'=>"", 'decimals'=>0, 'separator'=>"", 'show_min'=>true );$chart[ 'chart_border' ] = array ( 'color'=>"000000", 'top_thickness'=>0, 'bottom_thickness'=>0, 'left_thickness'=>5, 'right_thickness'=>0 );
$chart[ 'chart_data' ] = array ( array ("", "2007", "2006", "2005" ), array ( "Drupal", 100, 45, 25), array ( "Joomla", 80, 65, 35 ), array ( "Wordpress", 55, 30, 10 ) );
$chart[ 'chart_grid_h' ] = array ( 'alpha'=>10, 'color'=>"000000", 'thickness'=>0 );
$chart[ 'chart_grid_v' ] = array ( 'alpha'=>10, 'color'=>"000000", 'thickness'=>20 );
$chart[ 'chart_rect' ] = array ( 'x'=>50, 'y'=>50, 'width'=>320, 'height'=>200, 'positive_color'=>"ffffff", 'positive_alpha'=>30, 'negative_color'=>"ff0000"'negative_alpha'=>10 );
$chart[ 'chart_type' ] = "stacked bar";
$chart[ 'chart_value' ] = array ( 'prefix'=>"", 'suffix'=>"", 'decimals'=>0, 'separator'=>"", 'position'=>"cursor", 'hide_zero'=>true, 'as_percentage'=>false, 'font'=>"arial", 'bold'=>true, 'size'=>12, 'color'=>"ff8888", 'alpha'=>100 );$chart[ 'draw' ] = array ( array ( 'type'=>"text", 'color'=>"000033", 'alpha'=>25, 'font'=>"arial", 'rotation'=>0, 'bold'=>true, 'size'=>30, 'x'=>0, 'y'=>0, 'width'=>380, 'height'=>295, 'text'=>"CMS Progress Report", 'h_align'=>"right", 'v_align'=>"bottom" ) );$chart[ 'legend_label' ] = array ( 'layout'=>"horizontal", 'font'=>"arial", 'bold'=>true, 'size'=>13, 'color'=>"ffffff", 'alpha'=>50 );
$chart[ 'legend_rect' ] = array ( 'x'=>25, 'y'=>15, 'width'=>350, 'height'=>5, 'margin'=>3, 'fill_color'=>"ffffff", 'fill_alpha'=>10, 'line_color'=>"000000", 'line_alpha'=>0, 'line_thickness'=>0 ); $chart[ 'series_color' ] = array ( "3b5743", "303d3d", "4c5e6f", "564546", "784e3a", "677b75" );print module_invoke('swfcharts', 'chart', $chart, $config);
?>

Now go see the pretty sample charts.

Nov 25 2006
Nov 25
Nostradamus

I began the Devbee website back in March as a way to help others by way of documenting what I have learned about Drupal and also to drum up a little bit of business for myself. The content of this site is extremely targeted, and I don't ever expect to see more than a few hundred visits a day. This definitely does not reflect the expectations, or at least hopes, of most website owners. It's typically all about bringing in as many visitors as possible to generate money through advertising or purchases. Sites interested in bringing in large numbers of visitors typically do this by spending a lot of time focusing on "search engine optimization" (SEO). Absolutely nothing can drive traffic to a site like a top placement in the search results on one of the major search engines.

Back in the day (way back during the last millennium), all one needed to do was have a simple HTML page containing relevant words or phrases and he was fairly likely to make a decent showing in results pages. In fact, this is exactly how I shifted from studying literature to building websites. I built my first homepage (don't laugh!) for fun. It was found by an employer, and I got a cool job at a major search engine. Today, it is not so simple.

Fortunately for us, as Drupal users, we have a secret weapon, Drupal itself. Drupal SEO does not require any witchcraft or elaborate HTML trickery. It's simple, and in this article, I'm going to explain how I get consistent premium search placement with very little effort.

Stumbling upon Drupal SEO

Today I discovered that an article I wrote recently is the top result for the query "opcode cache" on Google. I almost feel guilty about it. There are countless pages out there with much more information on the topic than my article, yet I'm at the top. I guess I'll just have to deal with it.

This is not unusual. I find myself on "the first page" of many searches for terms relevant to my site. And when I'm not seeing a premium placement (top-ten), it's either because the search term is very broad (e.g. "Drupal") or there are simply much more relevant pages pushing my placement down. Just like the old days.

And more than half of my very modest traffic comes through these search results.

What's the Secret?

Now comes the mysterious part. I make no claims of expertise in the area of SEO. It's mostly voodoo as far as I'm concerned. The search engines are necessarily very secretive about their methods, trying to stay ahead of search engine spammers. And what works today may be detrimental tomorrow. What I'm going to describe below is entirely based on my own, very subjective, experience with various techniques and modules. These are the things that I believe are resulting in my accidental SEO success.

Drupal SEO

Drupal itself is well-known for its search-engine friendliness. Its markup is clean and standards-compliant. It creates all the tags the engines are looking for. And unlike so many other CMSs, Drupal creates search engine friendly URLs. Using Drupal is the first step in this process, but presumably you're already doing this, so let's move on.

The Right Path

Here's an example of the URL to a Joomla forum topic: http://forum.joomla.org/index.php/topic,65.0.html

And here's an example of a URL to a Drupal forum topic: http://drupal.org/drupal-5.0-beta1

Do you notice a difference? Can you tell me anything about the Joomla article without going to the page? In fact you can, sort of: you might conclude that the page covers a topic, a fact of dubious value. The URL really provides no useful information to you. Nor does it provide anything useful to a search engine. This is key. Unless you're searching for "index topic 65.0 html", this URL isn't going to help you find the information on this page.

Looking at the Drupal URL is another story. Based on that URL, one can assume that it has something to do with "drupal 5.0 beta1", and so can a search engine. If that's what you're looking for, this page will come up #1.

Most SEO "experts" agree that the search-engine-friendly URLs are critical to a page's search ranking.

Drupal allows you complete control of the path of any page. Creating short, clean and informative paths will improve your rankings. And the Pathauto module automates the process of generating relevant paths. But be extremely careful when experimenting with Pathauto, particularly on sites with existing content. Using Pathauto without first understanding how to use it properly can result in all of the URLs on your site changing, and thereby breaking existing links to your content. If you are going to introduce Pathauto on an existing site, play it safe and enable the Create a new alias in addition to the old alias option in Pathauto's settings. But keep in mind that having multiple URLs pointing to the same page on your site may result in a search engine penalty for "duplicate content".

Sitemaps

Sitemaps are an easy way for webmasters to inform search engines about pages on their sites that are available for crawling. In its simplest form, a Sitemap is an XML file that lists URLs for a site along with additional meta data about each URL (when it was last updated, how often it usually changes, and how important it is, relative to other URLs in the site) so that search engines can more intelligently crawl the site.

I've seen no solid evidence that implementing a sitemap will directly improve search rankings. However, even if search engines do not use your sitemap to to adjust the ranking of your pages (which I doubt), it does help them more efficiently index your site, thereby increasing the likelihood of your pages being included in search results. This one's a no-brainer.

Sitemaps would be virtually impossible to maintain by hand. And this is where the excellent XML Sitemap (formerly Google sitmeap) module comes in. Installing this module is simple and comes with reasonable default settings that don't require changing unless you want to fine tune your sitemap. After you've installed and enabled this module, you'll need to tell search engines about your sitemap. At this point, I'm only familiar with Google Sitemaps, Though other major companies are beginning to adopt this concept as an new open standard.

Leaving Comments

Another common method used by search engines to determine the importance of your pages is the number of other sites that link to them. A simple way to continually promote your site while helping improve your search rankings is to make regular comments on other sites like Drupal.org. Take the time to create an account on sites similar to yours and complete your public profile. Then leave useful comments where appropriate. Do not post comments simply to include a link back to your site. This is in very poor taste and may get you blocked. Instead, post comments where you have something to contribute to the topic being discussed. If you have nothing useful to add, don't post a comment. I'm a regular participant over at Drupal.org, and I'm confident this helps the "relevance" of my own site.

Page Title

By default, Drupal will use the title of your node as the page HTML title (the bit that appears in the <title></title> tags of the HTML and shows up in the title bar of your browser). This is very reasonable behavior. However, if you want to give your page that extra SEO boost, you may want to allow for two different page titles, one that appears at the top of the page in <h1> tags and the other that appears in the head of the HTML document in the <title> tag. the <h1> and <title> tags are both pieces that search engines will consider when reviewing your page. If they are identical, you're missing out on an opportunity to further promote the page!

So how do you manage to control the <title> tag contents if Drupal automatically sets it based on the node title? The Page Title module does this. Install and enable this module, and you will see an additional field on the node edit form called "page title". Use this field to configure the phrase that you think will most likely attract users to the page. Use something eye catching and alluring, something the user will feel he has to read. If you're writing about an article you found on another site, don't title the page "cool link!", instead, something more enticing: "Fascinating study of the Indonesian spotted tadpole". Follow that up with a relevant <h1> title: "National Geographic looks at one of nature's most mis-understood wonders".

The Prophecy

Search result placement was not a top concern of mine when I built this site. But it has become a bit of an obsession now. I have no need to drive thousands of visitors seeking information on opcode caching to my site, but hitting that number one position for a query is a bit of a rush! Thanks Drupal!

Lastly, I asked myself a question as I wrote this article: Is there anything at all to what I'm saying? Well, I think there is, and I'm willing to make a bold prediction based on this belief. Within three days of posting this article, I believe it will appear in the top-ten search results for "Drupal SEO" on Google. If I'm right, that should serve as some pretty solid evidence that there's something to all this. There are currently 1,090,000 pages competing for placement in this results page. The odds of making it into the top-ten by shear luck are 1 in 109000.

And if I'm wrong, well, I can always come back and edit out this prediction to save face %^)

The Revelation

Update: Mon Nov 27 23:19:42 2006

A search for "Drupal SEO" now shows this article as the second result out of 1,080,000 pages. I come in just below an article on Drupal.org.

So as you now see, there is not a lot of work involved in getting premium search placement if you are using Drupal. Of course, the broader your topic, the more difficult it will be to hit the top-ten. While you can almost certainly hit number one for surfers searching for a certain rare antiquity, your less likely to see much success attracting surfers hunting for the term "sex".

drupal_seo
Nov 16 2006
Nov 16

Until the mid 90s, spam was a non-issue. It was exciting to get email. The web was also virtually spam-free. Netizens respected one another and everything was very pleasant. Spam Those days are long gone. Fortunately, there are some pretty amazing tools out there for fighting email spam. I use a combination of SpamAssassin on the server side and Thunderbird (with its wonderful built in junkmail filters) on the desktop. I am sent thousands of spam messages a day that I never see thanks to these tools.

But approximately five years ago, a new type of spam emerged which exploited not email but the web. Among this new wave of abuse, my personal favorite, comment spam.

I love getting comments on my blog. I also like reading comments on other blogs. However, it's not practical to simply allow anyone who wants to leave a comment, as within a very short period of time, blog comments will be overrun with spam generated by scripts that exploit sites with permissive comment privileges. To prevent this, most sites require that you log in to post a comment. But this may be too much to ask of someone who just wants to post a quick comment as they pass through. I often come across blog postings which I would like to contribute to, but I simply don't bother because the site requires me to create an account (which I'd likely only use once) before posting a comment. Not worth it. Another common practice is the use of "captchas" which require a user enter some bit of information to prove they are human and not a script. This works fairly well, however, it is still a hurdle that must be jumped before a user can post a comment. And as I've personally learned, captchas, particularly those that are image based, are prone to problems which may leave users unable to post a comment at all.

As email spam grew, there were various efforts to implement similar types of protection, requiring by the sender to somehow verify he was not a spammer (typically by resending the email with some special text in the subject line). None of these solutions are around anymore because they were just plain annoying. SpamAssassin and other similar tools are now used on most mail servers. Savvy email users will typically have some sort of junkmail filter built into their email client or perhaps as part of an anti-virus package. And spam is much less a nuisance as a result.

What we need for comment spam is a similar solution. One that works without getting in the way of the commenter or causing a lot of work for the blog owner. Turn it on, and it works. I've recently come across just such a solution for blogs which also happens to have a very nice Drupal module so you can quickly and easily put this solution to work on your own Drupal site.

Enter Akismet

It's called Akismet, and it works similarly to junkmail filters. After a comment (or virtually any piece of content) has been submitted, the Akismet module passes it to a server where it is analyzed. Content labeled as potential spam is then saved for review by the site admin and not posted to the blog.

Pricing

Akismet follows my absolute favorite pricing model. It's free for workaday Joes like me and costs money only if you're a large company that will be pumping lots of bits through the service. They realize that most small bloggers are not making any money on their sites, and they price their service accordingly. Very cool.

Installation

In order to use Akismet, you need to obtain a Wordpress API key. I'm not entirely sure why, but it is free and having a collection of API keys is fun. So get one if you have not already.

The Akismet Drupal module is appropriately named Akismet. It's not currently hosted on Drupal.org, but hopefully the author will eventually host it there as that is where most people find their Drupal modules. Instead, you will need to download the Akismet module from the author's own site. The installation process is standard. Unzip the contents into your site's modules directory, go to your admin/modules page and enable it. There is no need for additional Akismet code as all the spam checking is done on Akismet's servers.

Configuration

After installing Akismet, I was immediately impressed at how professional the module is. There were absolutely no problems after installation. Configuration options are powerful and very well explained. The spam queue is very nice and lets you quickly mark content as "ham" (ie not spam) and delete actual spam. As you build up a level of trust with the spam detection, you can configure the module to automatically delete spam after a period of time.

Spam filtering can be enabled on a per node type basis, allowing you to turn off filtering for node types submitted by trusted users (such as bloggers) and on for others (eg forums users). Comment filtering is configured separately.

Another sweet feature is the ability to customize responses to detected spammers. In addition to being able to delay response time by a configureable number of seconds, you can also configure an alternate HTTP response to the client, such as 503 (service unavailable) or 403 (access denied). Nice touch.

One small problem

I've only been working with Akismet for several days now. And I'd previously been using captcha, which I imagine got me out of the spammers sights for a while (spammers seem to spend most of their efforts on sites where their scripts can post content successfully). So far, Akismet has detected 12 spams, 2 of which were not actually spam. These were very short comments, and I imagine Akismet takes the length of the content into consideration. I assume that as the Akismet server processes more and more pieces of content, it will become more accurate in picking out spam versus legitimate content. Each time a piece of flagged content is marked as "ham", it is sent to Akismet where it can help refine their rule sets and make the service more accurate.

Perhaps Akismet could provide an additional option that allows users to increase or decrease tolerance for spam. I would prefer to err on the side of caution and let comments through.

Nov 13 2006
Nov 13

PHP is an interpreted language. This means that each time a PHP generated page is requested, the server must read in the various files needed and "compile" them into something the machine can understand (opcode). A typical Drupal page requires more than a dozen of these bits of code be compiled.

Opcode cache mechanisms preserve this generated code in cache so that it need only be generated a single time to server hundreds or millions of subsequent requests.

Enabling opcode cache will reduce the time it takes to generate a page by up to 90%.

Vroom! PHP is known for its blazing speed. Why would you want to speed up your PHP applications even more? Well, first and foremost is the coolness factor. Next, you'll increase the capacity of your current server(s) many times over, thereby postponing the inevitable need to add new hardware as your site's popularity explodes. Lastly, high bandwidth, low latency visitors to your site who are currently seeing page load times in the 1-2 second range will be shocked to find your vamped up site serving up pages almost instantaneously. After enabling opcode cache on my own server, I saw page loads drop from about 1.5 seconds to as low as 300ms. Now that's good fun the whole family can enjoy.

Opcode Cache Solutions

There are a number of opcode caching solutions. For a rundown on some of them, read this article. After a bit of research and a lot of asking around, I concluded that Eaccelerator was the best choice for me. It's compatible with PHP5, is arguably the most popular of its kind, and is successfully used on sites getting far more traffic than you or I are ever likely to see.

Implementing Eaccelerator

This is the fun and exciting part. Implementing opcode cache is far easier than you might imagine. The only thing you'll need is admin (root) access to your server. If you're in a shared hosting environment, ask your service provider about implementing this feature if it is not in place already. These instructions apply to *nix environments only.

Poor Man's Benchmarking

If you would like to have some before and after numbers to show off to your friends, now is the time to get the 'before' numbers. Ideally, you will have access to a second host on the same local network as your server so that the running of the test does not affect the results. For those of us without such access, we'll just have to run the test on the actual webserver, so don't submit these results in your next whitepaper:

Apache comes with a handy benchmarking tool called "ab". This is what I use for quick and dirty testing. From the command line, simply type in the following:

ab -n 1000 -c 10 http://[YOURSITE.COM]/

Here is a portion of the results I got on my own test:

    Concurrency Level:      10
Time taken for tests:   78.976666 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      13269256 bytes
HTML transferred:       12911899 bytes
Requests per second:    12.66 [#/sec] (mean)
Time per request:       789.767 [ms] (mean)
Time per request:       78.977 [ms] (mean, across all concurrent requests)
Transfer rate:          164.07 [Kbytes/sec] received
Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    7  51.3      0     617
Processing:    77  725 1704.4    300   21390
Waiting:        0  673 1697.5    266   21383
Total:         77  732 1706.2    307   21390
Percentage of the requests served within a certain time (ms)
50%    307
66%    468
75%    625
80%    639
90%    805
95%   3808
98%   6876
99%   8529
100%  21390 (longest request)

The single most useful number is 'Requests per second', which in my case was 12.66.

Download, Build and Install

First, download the source code.

Get it to your server and do the following (I'm assuming you have gcc on your system, if not, get it):

tar jxvf  eaccelerator-0.9.5.tar.bz2
cd eaccelerator-0.9.5
phpize
./configure
make
make install

Configure Apache and Restart

If you have an /etc/php.d directory, create the file /etc/php.d/eaccelerator.ini for your new settings. Alternatively, you can put them in your php.ini file. Your configuration should look something like this:

zend_extension="/usr/lib/php/modules/eaccelerator.so"
eaccelerator.shm_size="32"
eaccelerator.cache_dir="/var/cache/eaccelerator"
eaccelerator.enable="1"
eaccelerator.optimizer="1"
eaccelerator.check_mtime="1"
eaccelerator.debug="0"
eaccelerator.filter=""
eaccelerator.shm_max="0"
eaccelerator.shm_ttl="0"
eaccelerator.shm_prune_period="0"
eaccelerator.shm_only="0"
eaccelerator.compress="1"
eaccelerator.compress_level="9"
eaccelerator.log_file = "/var/log/httpd/eaccelerator_log"
; eaccelerator.allowed_admin_path = "/var/www/html/control.php"

Adjust values according to your particular distribution. For more details on configuring eaccelerator, see the settings documentation.

See Eaccelerator in Action

The value eaccelerator.allowed_admin_path, if enabled, should point to a web accessible directory with a copy of 'control.php' (which comes with the eaccelerator source code). Edit this script, changing the username and password. You can then access this control panel and see exactly what eaccelerator is caching

See the results

After enabling Eaccelerator on devbee.com, I ran my benchmark again, and here are the results:

    Concurrency Level:      10
Time taken for tests:   10.472143 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      13129000 bytes
HTML transferred:       12773000 bytes
Requests per second:    95.49 [#/sec] (mean)
Time per request:       104.721 [ms] (mean)
Time per request:       10.472 [ms] (mean, across all concurrent requests)
Transfer rate:          1224.30 [Kbytes/sec] received
Connection Times (ms)
min  mean[+/-sd] median   max
Connect:        0    0   0.1      0       4
Processing:    20  103  52.1     96     345
Waiting:       17   92  50.1     83     342
Total:         20  103  52.1     96     345
Percentage of the requests served within a certain time (ms)
50%     96
66%    122
75%    137
80%    147
90%    176
95%    201
98%    225
99%    248
100%    345 (longest request)

We are now serving up 95.49 requests per second. That's 754% increase in server capacity. Had I been able to run the tests from another machine on the same network, I believe the numbers would be even more dramatic.

Jul 23 2006
Jul 23

The number one quality that separates Drupal from other popular CMS is its API (most often referred to as "the Drupal API).  Drupal is designed explicitly to allow for adding, altering or removing core functionality. Thanks to this API, there are hundreds of third party modules available for Drupal. Some of these modules provide very specialized features. Others provide integration with the most popular services on the web (including Google Maps, Flickr, del.icio.us, Digg and more). All take advantage of the Drupal API and none include modification of core (again, the basic code base required to run Drupal).

Hacking

Enhancing software that doesn't provide an API usually involves modifying its core code directly. If software doesn't open up its functionality to developers, then developers are left to go in and manipulate the original source code to achieve their goals. In many cases, this is just how you have to do things. Drupal is not one of those cases.

To be clear, when I refer to 'hacked Drupal core', I'm referring specifically to modifications of the files that come with the standard distribution of Drupal, most importantly, the files that are in the /includes/ and /modules/ directories. All of the same concepts apply as well to third party modules, but that's not what I'll be focusing on here.

Who Cares?

Does it really make a difference whether you do things correctly as long as they work? Absolutely. While it may seem much more effective at first to edit Drupal core to add the features you want, this is a big mistake. Let's talk about some of the problems you will run into.

Updates

The first problem you'll likely run into is applying Drupal updates. The Drupal team is excellent about patching security vulnerabilities. This means that if you are steadfast in keeping your Drupal instance updated, your chances of getting 'hacked' are greatly reduced. However, if your team has modified Drupal core, applying updates becomes a painful process requiring careful scrutiny of each update and possibly an even more painful merge of those changes with your hacked core files. In my experience, rather than go through this unpleasant process, owners of sites with a hacked core tend to postpone applying patches and updates. The more the owner procrastinates, the more likely his site is to suffer an attack using a known exploit. Once your site has been exploited, there's no telling how long your site may be down or how long it will take you to recover.

Functionality

The next problem you may run into is broken functionality. By altering Drupal core files, you may be inadvertently modifying functionality depended upon by other parts of the system. You are messing around inside the "black box" that Drupal as a whole depends on. While you may think it's clever to go in and modify the phptemplate engine directly, what you could be very well doing is creating bugs somewhere else in your site. By the time you come across the problem, it is unlikely that you'll immediately realize that it is caused by the changes you made to phptemplate. And, friend, you are now in for a lot of hurt as you rip apart code trying to fix it.

Maintainability and Longevity

Drupal's API is known by hundreds of developers all around the globe. The hacks introduced by your $20/hr programmer found on craigslist are known only to one developer. Should you ever need to update or extend your site, you better have that $25/hr developer on staff or you better be using the Drupal API. If you play by the rules, you can hire any experienced Drupal developer.

Bottom Line

There are legitimate reasons to modify Drupal core. If you've found an actual bug in Drupal, the best thing you can do as a developer is to fix it and submit a patch. Likewise, if you've come up with an enhancement that you feel should live in core, submit it. Aside from these two reasons, neither you nor anyone in your employ should be touching anything in that drupal .tgz file.

If you want to develop extended functionality for Drupal, use the API. If you're hiring a Drupal consultant, find one who is familiar with the Drupal API. Find a developer who's active in the Drupal community. Hiring a knowledge Drupal developer may cost more initially, but if you plan on maintaining your site for any length of time, this investment is sure to pay off down the road.

Jul 10 2006
Jul 10

A search for "blank page" of the Drupal.org domain yields about 37,000 results.

This is probably one of the more common and frustrating problems for Drupal admins.

I've had the problem dozens of times myself. For no apparent reason, pages will simply come up blank. Drupal returns nothing at all, not even a set of empty HTML tags. As a developer, I'm used to seeing broken sites and fixing them. But the typical site administrator may not have the knowledge or experience necessary to debug something like a blank page.

The first thing you want to do is gather all available debugging info. The two primary places you'll find this information is in Drupal's logs (Administer >> Logs) and in your Apache log files (/var/log/httpd on Linux systems). If you're lucky, these logs will provide obvious clues as to what's wrong. Whether or not your able to gather any clues as to the source of your problem, below is a list of the most common causes of empty server responses:

  1. Memory: In your php.ini file there is a value called memory_limit, which is set to 8 megabytes by default. If you've installed a lot of modules, you can easily exceed 8 megs on a given page request. The solution is to increase this limit (I set mine to 32 megs because I have lots of memory on my host and few domains being served on it). If you're in a shared host environment, you won't be able to modify this value. In this case, you'll need to disable modules or get a new host.
  2. Buggy Modules: If you're problem began after installing and activating a new module, move the module's directory outside of /ROOT/modules/. Experimenting with modules is probably the easiest way to "break" your site. My suggestion is to test all modules on a non-production Drupal installation. Move them to your production site only after making sure they work properly (This message approved by Captain Obvious).
  3. Incompatible Modules: Using 4.6 modules on a 4.7 site is also a great way to break stuff. Make sure you've installed the module versions that match your Drupal version.
  4. Broken Themes: A buggy theme can easily render a site unusable. My suggestion is to preview themes at the Drupal Theme Garden or on a non-production Drupal installation. If it's too late for that and you're experiencing blank pages, you should try setting the theme to a "safe", stock theme. If you cannot access your administrative pages (http://.../admin/themes), you will need to move your custom theme from your /themes/ directory to another temporary location. Alternatively, you can run this SQL command on your Drupal database: UPDATE variable SET value = 's:10:"bluemarine";' WHERE name = 'theme_default';

I don't believe I've ever seen the 'blank page' problem in a production release of Drupal core. The problem only crops up when installing and playing around with new modules. So the bottom line is be very careful when experimenting with modules. I almost always use a sandbox installation of Drupal to test modules before installing them on a production site. (updated: Thu Jul 13 14:11:27 2006)
Jun 27 2006
Jun 27

The contributions process for non-core Drupal themes and modules is in need of a revamp.

Currently the process is a very loose one that does not require adherence to any tagging conventions or release process. This makes it very difficult to know the status of the modules that make up a given site. I believe this probably results in many site admins out there just leaving their site as-is because the process of updating is somewhat confusing and tedious.

We want to fix this.

While there are existing 4.6, 4.7, etc... tags applied to contrib modules, they are not consistently used by module authors. Furthermore, tags are being applied inappropriately (4.7 tags applied to 4.6 code that is not actually upgraded).

Ultimately, I'd love to see version and update management built right into Drupal (in the same way it's built into most OSs and many software packages). Drupal might have a single page the admin can visit to check the status of his core Drupal installation as well as all modules and themes he is using. The process of upgrading to the latest versions could be a very simple matter of selecting desired updates and hitting a submit button.

That, however, is a long way off. We need to start by creating a process with which Drupal developers and contributors can "tag" their software releases and make those releases available quickly and easily.

To take part in defining this new release process, please visit "Versioning and release process for contributed projects" and leave a comment.

Jun 26 2006
Jun 26

I just returned from BarCamp San Francisco , and I'd have to say it was a success.

This was my first BarCamp, so I had no idea what to expect. It really is as simple as it sounds. A bunch of folks show up and schedule events on the spot based on who is present and what they're interested in.

It took place at Microsoft's offices on Mission and Embarcadero. While normally I'd be inclined at this point to offer one of several heartfelt opinions about Microsoft, I'll just say that it was very generous for them to allow us their location for the weekend, and it was very well suited for this great event. <gulp> Thanks, Microsoft.

"Take Aways"

One of the unfortunate survivors of the dot-com bust was a vast set of obfuscated vocabulary collectively known as buzzwords, a value-add semantical meta-markup linguistic solution used to define hi-tech marketecture and other domains. Can you feel the synergy?

Yes, there was no shortage of buzzwords floating through the air, and it's hard to avoid them when they are made up largely of otherwise very usable terms such as "solution" (which now means software application), bandwidth (which now means intelligence or ability ["I don't have the bandwidth to..." actually means "I'm not smart enough to..]") and "orthogonal" (which is used in so many disparate contexts, I don't know what to make of it).

Point being that the following section may be populated with buzzwords, so watch your step.

Talent Co-op

This was probably the coolest concept I came across (read: most relevant to me). The idea of bringing together in a single (virtual) place geographically dissimilar supplies and demands is not new. Elance.com, Guru.com, blah, blah. What hasn't been done, to my knowledge, is this sort of thing without the blatant and irritating commercial aspect to it. Something just plain bothers me about relying on some corporate interloper to supply me with suitable clientèle, particularly when they have no reason to take any concern for the quality of either the supplier or the suplyee.

The internet is too obvious an answer to the problem of many people working (or wanting to work) from Location Unknown doing things they love and are good at, and other people wanting to find good worker units and not really caring where, when or how they work as long as they can do the job.

Citizen Agency is the first effort (that I'm aware of) to bring a bunch of talent together to pool talents, resources and work. The effort is only weeks old, and I believe BarCampSF was the official announcement of the effort.

Micro Formats

Here's an example of something I ignored as more buzzword blather that turned out to actually be something potentially very useful. Microformats is like XML in that it's easy to explain and difficult to completely understand. As I see it, microformats would turn any standard web page into a potential source of data objects like contacts, locations, content objects like reviews, and anything else you might normally look for in a database. Main problem, widespread adoption. Microformats probably won't blossom until these formats are managed behind the scenes by blog software, document editors, email and so on. But I can definitely see that happening, at which point you'll see all sorts of useful tools (first appearing as extended functionality to clients like browsers and email apps). Read up a bit on this so when it finally breaks out, you can say something like, yeah, I saw that coming back in 06.

Communities

No need to go into any detail here. Everyone wants to be like MySpace, Flickr, Facebook, etc... I find the subject tiresome myself. The *concept* of community has no meaning or value to me. Implementation of community oriented websites, features and so on is what interests me.

Drupal

While there was a very nice showing from the Drupal camp. I got to meet Drupal luminaries jjeff, dries, drumm, roland and others. Sporting my own Drupal tag, I struck up Drupal related conversations with most of the folks I met. (I'm hereby pronouncing myself as Drupal's chief petty evangelist.) I don't think I met anyone who wasn't aware of Drupal. Most had at least some direct experience with Drupal. Most folks had a lot of questions about it. Some had the common "I installed it, now what" experience with Drupal. I think we might benefit from expanding, somehow, our efforts to help folks (hi sepeck!) install, use and love Drupal.

The BarCamp experience was better than I had anticipated. I highly recommend you attend one when it hits your town. I'm going to attempt to help organize the first BarCamp San Diego.

References

May 03 2006
May 03

One of the great features of Drupal is its ability to run any number of sites from one base installation, a feature generally referred to as multisites . Creating a new site is just a matter of creating a settings.php file and (optionally) a database to go with your new site. That's it. More importantly, there's no need to set up complicated Apache Virtual hosts, which are a wonderful feature of Apache, but can be very tricky and tedious, especially if you're setting up a large number of subsites.

No worries, there is a solution.

Create a new LogFormat

Copy the LogFormat of your choice, prepend the HTTP host field, and give it a name:

LogFormat "%{Host}i %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vcombined 

Get the script

Next, download the attached script (split-logfile) and store it somewhere like /usr/bin (don't for get to chmod 755 that baby!)

Now, tell apache to use pipe logfiles to your script rather than writing them directly to disk:

CustomLog "| /usr/bin/split-logfile" vcombined 

Restart Apache

/etc/rc.d/init.d/httpd restart

That's it.

Naturally, you may have to modify split-logfile if you don't store your logfiles in the default location.

 

 

Apr 21 2006
Apr 21

This article explains a practical implementation of a technique outlined in the article "Sharing Drupal tables between databases using MySQL5 Views".

Problem

You have multiple (multisite) Drupal sites and you would like to manage the content for all of these sites through a single interface. Depending on the nature of a given piece of content, you may want the content published on one, several or all of your subsites, but you do not want to have to create copies of the same content for each site.

Solution

Taxonomy plus MySQL5 views. (NOTE: this solution will not work with versions of MySQL prior to 5.)

Assumming you have your subsites properly set up and running, the first step is to create a special vocabulary which you will use to target content.

Go to [your site's baseurl]/admin/taxonomy/add/vocabulary and create a vocabulary. We'll call it simply "sites".

Next, go back to your taxonomy page (/admin/taxonomy) and select "edit vocabulary" for the "sites" vocabulary.

Add a name for each of the subsites you would like to manage. For our example, we'll have two subsites, "foo" and "bar", and one master site, "master".

Now add at least three pieces of test content. Target one piece of content for each of foo, bar and both.

Next, we're going to create a node view for each of our subsites that we'll use to replace the actual node table.

The SQL is as follows:

CREATE VIEW [subsite, eg. "foo"]_node AS SELECT n.* FROM node n, term_data td, term_node tn, vocabulary v WHERE v.name = '[vocabulary name, eg. "sites"]' AND td.vid = v.vid AND td.name = '[subsite vocab term, eg. "foo"]' AND td.tid = tn.tid AND n.nid = tn.nid ;

Because the terms that serve as our subsite labels may very well exist within other vocabularies, we also need to join on the vocabulary table to ensure our solution works reliabley.

Finally, we need to have our subsites use the views we have created instead of our master nodes table, which only the "master" site will have access to directly.

In your drupal's sites directory, you should have directories that correspond to each of your drupal sites (both master and subsites). Edit the settings.php file for each of your subsites, and use the db_prefix variable to point the site to your view. So sites/foo.example.com/settings.php would contain the following:

$db_prefix = array( 'node' => 'foo_', );

At this point, you'll want to disable creation of content from within each of your subsites. You can do this in the from the admin/access page. If you attempt to create content from within the subsites, you'll likely get a 'duplicate key' error.

I hope that explanation is clear. These articles are written rather hastily. If you questions or suggestions regarding this solution, please leave a comment.

Apr 11 2006
Apr 11

Drupal is an open-source Content Management System (CMS), which is particularly suited to customization through use of blocks, themes and modules. Drupal's innovative use of taxonomy and its unique menu system allow for effective management of content as a site grows or evolves.

Driving the ongoing development of Drupal is the desire for a simple and powerful framework which developers can work within to create custom web applications without having to build the pieces that nearly all websites have as a foundation (user authentication, content creation interface, layout managment).

And unlike other similar CMSs, Drupal takes its role as a framework very seriously. Take a look at the database structure of any other CMS that has been around for a while, and you'll almost certainly find a labyrinth of tables with mysterious names and seemingly redundant purposes. Drupal's database design is clean and constantly being re-factored. Tables that have outlived their purpose are removed from the schema and the code. Table design is very generic, allowing different types of content and modules to share the same table space.

Drupal also has an actual API. It too is refactored on a regular basis as the web and user needs change. Drupal 4.7, for example, has a completely redesigned Forms API which now allows developers a much broader reach into the entire Drupal framework, allowing her to tweak parts of Drupal that were previously pretty much set in stone.

From a webmaster's point of view, Drupal may not have the most eye-candy or largest feature set when compared to other CMSs. However, there's virtually nothing that can't be built into Drupal, making it the most flexible CMS out there.

Go with Drupal, and you will have no regrets.

Mar 25 2006
Mar 25

Ok, ok, maybe there actually is something to this Web2.0 business. A lot of the Web2.0 hype stems from the maturation of blogging, the software that helps people blog and RSS. All of these are good and bad things. Good in that there's more information available to more people today than ever before. Bad because there's more information available to more people today than ever before. Even before the term "blog" was coined, people were publishing personal journals, ramblings and general rants on the web. It was as true ten years ago as it is now, most of this content is... well... not very interesting to most people. Maybe it's poorly written blather about why someone hasn't posted poorly written blather recently. Or maybe it's well written content on a very specialized topic that is only relevant to a small number of people.

Good, bad, relevant, meaningless, it's all out there somewhere. The key to finding it is RSS. I used to subscribe to the Los Angeles Times. I'd poke through it every day and read a sentence or two and then tossed it in the recycling bin. The fact is, my interest in polotics, world affairs, sports, gardening, real estate and used cars is pretty limited, and that's all you're going to read about in most newspapers. My interests are elsewhere. Software programming, guns, literature, skiing, and so on. The best way to feed my desire for information is to turn to the web. But turning to the web for information is like visiting Niagra Falls for a sip of water. It's just too much. You need something like Google, Yahoo or now RSS to filter the information for you.

Will Web2.0 ever mean anything? Absolutely. I believe Web2.0 will eventually become something even grandma can understand. Presentation will be fast and flexible (AJAX, DHTML). Content will be tightly filtered with RSS. Folks can easily take advantage of all this stuff now with sites such as Bloglines, Feedster (update: now dead) and Feedburner. And all of this falls under the annoying label of Web2.0. This site is dedicated to Drupal. One of the things I wanted to provide was an aggregate feed of the most relevant Drupal news available. So using Drupal's aggregator module, I began creating the Drupal news page. You'd think that would be a simple task, but it isn't. With so many feeds, and so many feeds of feeds, and so much information available, pulling down just the right content is still very hard, and I still don't have the desired page I want. But the fact that it is even possible is something I'm very excited about. Here's a link to the story I was going to originally write about before my ADHD kicked in: The bottom line on blogging.

Mar 24 2006
Mar 24

Problem:

You have a "master" database that contains data from multiple Drupal sites and you want to share it among them. Normally, you could use table prefixing to allow each of your sites to point to a single table. But what if you do not want content from one site to "bleed" across to the other sites? Let's say you have a network of Drupal sites sharing a user database. You want to share that user's information across your entire network of sites, but only make the information visible from those sites to which the user has subscribed. Or maybe you want to populate baz.com with users who meet some arbitrary criteria. There are lots of possibilities here, but nobody's paying me to write this, so let's get on with it.

Solution:

Use MySQL5 Views. For our example, we'll use the users table. Our "master" users table (the table that contains all users for all of our sites) resides in a database called "master". The database of the our example site that will have restricted access to our masters users table is called "banana". Assuming you're starting with a fresh instance of the Drupal schema in your database "banana", do this:

use banana;
drop table users;
CREATE VIEW users AS
SELECT *
FROM master.users
WHERE uid IN (
SELECT uid
FROM somedatabase.sometable
WHERE uid = 0
OR label = 'foo'
)

Drupal will use banana.users just as it would a normal users table. No other modifications are necessary. Now only "foo" users will be included in the users table for your banana website. Note: Drupal has a dependency that is not really documented. Every users table must have an entry that contains uid=0. It's a "stub" entry that Drupal needs to function properly when a user is anonymous. A workaround for this dependency is to include "user 0" in the results set that defines your view. See, wasn't that easy? Please post questions here, and I'll update these instructions as needed.

Mar 15 2006
Mar 15

Today, the folks over at Performancing.com announced the realease of Performancing Metrics, a free new service for tracking statistics for Blogs. Best of all, it's all in Drupal. OK, I'll come clean, I was involved in this project. My primary role was integrating Performancing's existing website with the Metrics tool. The entire toolset runs behind a single Drupal module that acts as a wrapper for what are essentially standalone PHP scripts.

Disclosure out of the way, I've also been using this tool for some of my own websites for the last month or so. When Google Analytics launched, I was able to get an account before they blocked new subscribers due to load issues. I've been monitoring my sites with Google Analytics for about four months. It seems to be a very powerful tool, but to be honest, I don't understand how to use it. There are just too many views and parameters and summaries. Using it, I feel like I did when I first used Vim or MS Word or Paint Shop Pro, overwhelmed and confused. Hey, I just want to write a letter to Mom, and I'm staring what looks like the cockpit of a 747. Similarly, when I look at website stats, I just want to see how many folks are visiting, where they come from, how long they stay, what they like, whether they bothered to leave comments, etc... I don't need a pivot table detailing gross ROI per visitor vectored over a decreasing granular matrix margin. Eeeek! Just show me the big pic and let me get on with my day.

If you're like me, you'll appreciate this new tool. It's light on eye-candy and heavy on simplicity and quick access to what you want to know. It's also somewhat addictive.

To use it, you'll need to sign up over at Performancing.com. Then all you have to do is paste a bit of javascript into your Blogs pages (via templates or footer configuration).

What distinguishes this tool from others is that it's focused on Blogs. The javascript you use will vary depending on which blogging software you're using. This way the javascript is able to glean information from your site that other trackers simply can't. Author names, Comments, Posts, etc...

We're working on making this embedded javascript tracking more effective and specific to the various blog systems, but even this beta version of Performancing Metrics is worth the effort of signing up.

You'll also find lots of cool articles regarding professional blogging. Even if this isn't how you make your living, there is some excellent information that non-professionals can use. Stuff like how to bring more people to your site and how to "monetize" your website more effectively.

Check it out.

Mar 14 2006
Mar 14

Web2.0 is now, and it's here. If you're not Web2.0, you're out like 2005. If you have to ask, you wouldn't understand.

Well, I have to admit, I need to ask. In fact, I have several questions about all this Web2.0 fanfare.

Why should I upgrade? How much will it cost me? How come nobody has it in stock when I try to buy it?

I've been making my living doing web stuff since 1996, and I never got my copy of Web1.0. I didn't even realize it had been released. Now I just sit and nod in meetings where people talk about "synergistic solutions", or throw in a "user comprehensible value prop" in such a way that you just scratch your head and think it must mean something. "This needs to be Web2.0" is a favorite of mine. Whatever Web2.0 is, obviously it's critical to the success of new projects. (I need to remember to remember that for my next project.)

Who owns Web2.0? For now, I guess the safe assumption is that Google does. That would explain both all the ballyhoo as well as the mystery surrounding this next generation breakthrough. Ask someone at work what Web2.0 is and you'll likely get the curly brows and a loud "Pffft!", in which case you just give them a, "... I guess some of the folks in this meeting haven't gotten the Web2.1 pre-release yet ..." and give them the reverse curly brows and a subtle sigh.

Look around for Web2.0 and you will no doubt find everyone talking about it, but you're not likely to actually find an example of it. I found no screenshots on Google Images. No info on where to order it or how to install it. However, I do think I'll be able to recognize it once I find it. I know it will have an "API". I know it will also be very clean because it requires Ajax. It will probably involve pastels contrasted with ridiculously bright primary colors.

It will also have a very fancy look to it. I imagine the email icon above probably isn't very Web2.0. (though I'm not claiming to be a Web2.0 authority, of course.

And I'm sure all the experts would agree that this RSS icon is definitely Web2.0.. However, my failure to convert the white background to transparent is probably more web 1.1 or so.

If you know as little about Web2.0 as I do, I wouldn't worry about it too much. If there's anything to it, I'm sure we'll all be getting 3000 free hours of it in the mail from AOL real soon.

Mar 10 2006
Mar 10

Rumor is spreading of some sort of new analytics tool from the blogging experts over at Performancing. This tool utilizes Drupal and is designed specifically for bloggers. It's a tool similar to others like Google Analytics and Sitemeter. What makes it different is that it is designed to track blogs specifically. Read more about it at Performancing, Problogger and Code Professor.

Sep 14 2005
Sep 14

A lot of people have already blogged about the new Planet Drupal. It's about time to get my act together and blog about it, too.

I have been submitting a few patches for Drupal's aggregator module recently and working closely together with Dries (Drupal's Benevolent Dictator for Life) to create the planet. He mercilessly reviewed (and applied!) my patches, commented on my ideas and suggested lots of improvements. Without him the planet wouldn't be here today.

As I already stated in the original announcement, we run the planet using Drupal, of course (dogfood etc.), and not the (otherwise quite nice) PlanetPlanet, which most other planets use.

The now improved aggregator module is capable to create a Planet site like Planet Drupal in a few minutes and mostly out-of-the-box, requiring no changes to the code. There are a few minor issues which we need to sort out, but the Planet is there now, and you can subscribe to it in any RSS feed reader.

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web