Let’s jump right in. The scenario is that we have a content type of article. The node-article.tpl.php displays the Drupal node author as part of the by line of the article. In our case, we wanted to change this.

Instead, we will have articles created by staff, as well as articles automatically generated from RSS feeds. It is important for us to honor our partners by not showing the article as being authored by us, but instead to change the authored by line to give credit to the originating feed source where appropriate.

Enough talk, let’s see details.

First, we need to make the parent feed’s title and link available as a variable for the templates. We did this in Drupal 6 by adding to the existing template.php file. Using the phptemplate_preprocess_node hook, we can add variables that can be accessed in node templates. (Note: If you are following along in an OpenPublish distribution, this function does not exist in the standard template.php file. You will need to add it.)

Keep in mind that when you use feedapi/feedapi node module to turn a feed item into a node, the $node object does not have all the details about the parent feed that generated the feed-item. It does however contain the nid (node id) of the feed that generated it. Soooo… in our custom code, we need to get this parent feed nid, load the feed title and url and then stuff the link into a variable to use in our node template.

Here is the function as added to the template.php:

/**
* Override or insert PHPTemplate variables into the node templates.
*/
function phptemplate_preprocess_node(&$vars) {

  // 20091029 Added for Parent Feed Title Link
 if ($vars['node']->feedapi_node->feed_nids) {
    $parent_feed_node_id = array_values($vars['node']->feedapi_node->feed_nids);
    $parent_feed_node = node_load($parent_feed_node_id[0]);
    $vars['parent_feed_link'] = l($parent_feed_node->title, $parent_feed_node->feed->url);
  }

}

Just a note that the array index of feed_nids is not zero based but instead, the array index is the same number as the nid. That makes doing the typical $vars['node']->feedapi_node->feed_nids[0] impossible. That is where the php array_values() function comes to the rescue. It takes all the array values from feed_nids and created a zero base indexed array.

Now, we have a variable called $parent_feed_link that is available in our template files. So, our next step is to use it. Since the content type we want to impact is the article type, we are going to modify our node-article.tpl.php. Below is the portion of the file that outputs the article by line:

<div>Article |
<?php print date('m.d.y', $node->created); ?>
 | By  
<?php  
 $author = user_load(array('uid' => $node->uid));
 if ($parent_feed_link) {
   print $parent_feed_link;
 }
 else {
   print l($author->profile_full_name, 'user/'.$node->uid);  
 }
?>    
</div>

As you can see above, we now test to see if the $parent_feed_link actually has a value. If so, we want to output that link. Otherwise, the article was not created from a feed-item and we want to show the actual author of the node.

I know this is simple for many of you, however it took me a little while to figure out where in Drupal 6 to generate these custom variables. In Drupal 5, you may have typically done this in the _phptemplate_variables hook in your template.php.

Well, did we do it wrong? Do you know a better way? Let us know with a comment below.

Blessings.

But that is only one reason your users might see the maintenance page. If your host has database problems, you could be showing your customers the default Drupal maintenance or offline page. Probably not the image you were looking for. This article will walk you through the process of creating custom maintenance/offline pages for your Drupal sites that will keep a profession look and feel, respecting your site design and style.

Maintenance vs. Offline

After reviewing a number of references on Drupal.org and finally landing on these instructions, I have concluded to following definitions.

Maintenance Mode – This mode is put in place by the site administrator via the Administer > Site configuration > Site maintenance settings on a Drupal site. Administrators can still access the site.

Offline Mode – This mode is enabled when the Drupal site is unable to connect to its database. (Think Maintenance mode without DB access) This typically indicates a significant failure of the database services.

So, maintenance mode is typically done on purpose by an administrator while an offline occurrence typically would be accidental or part of schedule maintenance. This distinction is important because in offline mode, your template needs to be able to function on its own without calling the database in order to function.

Custom Maintenance Mode Page

Let’s tackle the maintenance mode page first. The idea here is that when the administrator places the Drupal website into maintenance mode that a friendly page is served to your customers. We want our maintenance page to have a consistent look and feel with the rest of our site.

By default, when you set your site offline in maintenance mode, your customers see the maintenance page from the Minelli default core theme. This is regardless of the default theme chosen for your site. This is one of the biggest sources of confusion. Drupal has this configured by default in your settings.php file.

In our case, let’s say we are using the wonderful Acquia Marina theme as the default for our site. With this in mind, we need to modify one file on our Drupal site. Navigate to your Drupal site root directory and then to the /sites/default/settings.php file and open it up.  Using your favorite editor, add the following line to the end of the settings.php file.

$conf['maintenance_theme'] = 'acquia_marina';

So, we added the configuration key ‘maintenance_theme key to our settings.php file and changed the theme value to ‘acquia_marina’.

This setting change has now told Drupal to use the acquia_marina theme for the maintenance page. So, reload your browser and refresh your site. Lucky for us, the Acquia Marina theme comes with a custom maintenance page, but if your theme doesn’t, read on.

No maintenance-page.tpl.php In Your Theme?

So, if you refresh and things look odd, Hmmm….so why does the page look like an unstyled page, not like your theme? Well, now we are on step 2. Drupal has looked at our theme for a maintenance-page.tpl.php page, however we don’t have one yet in our theme. So it’s time to created one.

There are two thoughts on how to do this. First, some folks prefer to start with the generic temple found in modules/system/maintenance-page.tpl.php while others prefer to start with their theme page.tpl.php and modifying it. Either way, you need to get a maintenance-page.tpl.php in your theme directory.

Now, theming the page itself is beyond the scope of this article but the same Drupal 6 theme concepts apply.

Maintenance Offline Mode

As we described earlier, there is not only the maintenance mode that the administrator can set, there is also an offline mode that is engaged by an inability of Drupal to connect to the database. Again, there are two ways you can address this in Drupal 6. One is in the maintenance-page.tpl.php and the other is the creation of a separate maintenance-page-offline.tpl.php.

Offline In Maintenance-page.tpl.php

If you want the same maintenance.tpl.php to serve both maintenance mode and offline mode you need to keep one thing in mind. In offline mode, Drupal does not have access to the database. Therefore, any theme template calls for data from the Drupal DB will fail.

As of the writing of this article, the Acquia Marina theme does not gracefully handle the db offline scenario in the template.php

According to the Drupal documentation:

“Any function call that depends on the database should be checked first with db_is_active. The variable $db_is_active can also be used from the template.”

Here is a slightly modified version, available for download, of the Acquia Marina template.php that takes care of the DB errors by checking for $db_is_active where necessary.

Custom Maintenance-page-offline.tpl.php

Another way to handle the offline mode specifically is to create a separate maintenance-page-offline.tpl.php file. The contents of this file will be used to render the custom offline mode page to the user. The benefit here is that your messaging can be different for an offline versus maintenance mode condition.

Personally I prefer this since access to the DB has been lost, theme settings are not available. Thus, you can hard-code, logos or such as needed in this separate file.

Conclusion

Again, Drupal gives you many options to customize your site. It just takes learning the possibilities and intricacies of the platform. We hope this article helps you better theme your maintenance and maintenance offline pages.

Blessings.

I recently came across this blog post talking about someone’s decision to “dump” Drupal as a platform for a site idea they had. As I read the short post, I quickly found that I was shouting “don’t dump Drupal” in the back of my mind.

The author describes three reasons why Drupal didn’t work out for their use.

1. The look and feel of the site was inconsistent between the homepage and forum which made it feel like two separate sites.
2. The homepage, using drupal (sic) plugins for columns was a nightmare to configure – massively overcomplicated! Drupal is simple, but these plugins aren’t!
3. Drupal is too restrictive on styling and based on the complexity of the multi column plugins the idea of customising (sic) it filled be with a horror akin to being told I would have to listen to a Steps album!

Hmmmm….this got me thinking. Drupal can be easily setup and used “out of the box”. Having said that, I still find the available, User centric manuals, tutorials severely lacking for the complete newbie user/contributor (not administrator).

Now, if you really want to use the super powerful platform features of Drupal to provide a more complex solution, as it appears this person want to scratch the surface of, there is a fairly steep learning curve. But, the key is that the framework is VERY powerful and flexible. Unfortunately it sounds like the post author was unable or unwilling to find the time and materials to learn more about the platform.

All three of the reasons given by the author seem to be about look, feel and styling (mostly). Oh my. This is where Drupal theming absolutely shines. With the knowledge of Drupal theming combined with the necessary design skills a Drupal site can be made to look virtually any way you want.

On the surface it sounds like the author could have gotten what he wanted with a custom theme, page-front.php, aggregator, cck, views 2 and view theming.

Its too bad that while the Drupal community is fantastic, there really needs to be some more thought and effort to formalize some good introductory materials to ensure that new folks get ample opportunity to quickly see the pros and cons of the Drupal platform. Of course the community response is “if you feel strongly, then do something about it.” Very true!

Just my 2 cents. I’m certainly biased on Drupal but realistic about the user experience. I continue to find organizations we interact with being confused, lost and at times frustrated with the administrative user experience. Some of this is core Drupal, some is on the module developer, and some is on the implementer. Between us all, we have made big improvements but there is plenty of room to grow.

Blessings all.