Fixing Drush to work with Custom Drupal modules

I’ve mentioned that I consider Drush to be an absolutely essential tool if you’re running more than one Drupal site.  However, I recently ran across an issue that took a little while to figure out.  First of all, the latest update to Firefox seems to have broken something in the FCKEditor module.  I may talk about that later, but it’s not the main point here.  The fix is to disable FCKEditor, and switch to the newer CKEditor.  Using Drush, that’s a simple matter of two commands

1
2
drush disable fckeditor
drush enable ckeditor

However, when trying to run Drush, I got the following error:

1
Drush command terminated abnormally due to an unrecoverable error.

That’s right, Drush wouldn’t even run.  It turns out that the problem was caused by a custom module that I had written for the site that does a redirect.  When Drush accessed the Drupal core, it was being redirected to a static page, which caused it to barf.  So, I needed to figure out a way to make sure the redirection doesn’t happen if the request is being made by Drush.  I tried for quite a while to use the Apache $SERVER global to check the request origination, but I just couldn’t figure out what the value should be to check for Drush.

What I finally settled on was checking for the existence of one of Drush’s methods.  Due to the way that php operates in Drupal, once a method (function) is defined, it’s essentially a global function (Drupal’s not object oriented, so there’s no real concept of access modifiers).  So simply making the following check fixed the issue:

1
2
3
4
5
if(function_exists('drush_main')){
  //don't redirect
}else{
  //redirect
}

Easy!

Convert a Drupal Multi-site Installation to a Single Site.

One of Drupal’s more interesting abilities is the “Multi-site” installation.  Drupal allows you to run multiple, separate websites with different users and different content, all on one single installation of Drupal.  At first, this sounds exciting, because it has the potential to simplify site maintenance and updates.  You only have to install a module once, and share it across all of your sites, etc…  Like everything else in the web development world, this method has its proponents and its detractors.  I’m not going to discuss the pros and cons of Drupal’s multi-site installation right now.  However, I’ve recently decided to switch AutoRemarketing.com from a multi-site to a stand alone.

AR.com is the biggest site I’ve ever worked with.  It’s a trade publication for the Used Car industry.  It gets updated with new content several times a day, and it gets, on average, 130,000 page views every month.  I inherited the site, and it had been set up initially as a multi-site, along with several other sites.  So, trying to move the installation, without breaking anything, and without interrupting traffic would be challenging to say the least.

In the end, I was able to move everything over, with no loss of functionality, although I did have to take the site down for about 10 minutes.  Here’s the procedure that I followed.  First & foremost, I made backups of absolutely everything, then I made sure that I had multiple copies of the backups (I’m a little paranoid!).  I also made sure to install drush, the Drupal shell.  You can read more about drush at their site, but let me just say that it’s an amazing tool, and it’s utterly indispensable for serious Drupal work.

Once I had everything backed up and ensured that Drush was installed, my next step was to create drush aliases for everything.  I simply added the following code to ~/.drush/aliases.drushrc.php:

1
2
3
4
5
6
7
8
9
10
11
12
<?php
$aliases['ar_dev'] = array(
    'uri' => 'ar.sacherokeedev.com',
    'root' => '/var/www/html/ar.sacherokeedev.com',
    'db-url' => 'mysql://dbuser:dbpassword@localhost/database',
);
 
$aliases['ar_prod'] = array(
    'uri' => 'autoremarketing.com',
    'root' => '/var/www/html/drupal_media',
    'db-url' => 'mysql://dbuser:dbpassword@localhost/database',
);

I then used drush’s rsync capabilities to copy everything from the multi-site to the new location with this simple command:

1
drush rsync @ar_prod @ar_dev

The one gotcha in this case, is that drush rsyncs the entire directory, which means that you get a complete copy including all of the multi-site files.  There’s probably a way to tell drush to only sync certain files, but I just copied everything then deleted what I didn’t need.  The next thing to worry about is that multi-site & standalone installations use different file paths, so images won’t show up, until you run the following MySQL commands (either via phpMyAdmin or command line or your MySQL tool of choice:

 

1
UPDATE files SET filepath = REPLACE(filepath, 'autoremarketing', 'default') WHERE filepath LIKE '%autoremarketing%';
1
UPDATE boxes SET body = REPLACE(body, 'autoremarketing.com', 'default') WHERE body LIKE '%sites/autoremarketing.com%';

The first command changes the file path for all of the files in your database, the second changes the path to any images that are contained in Drupal blocks.  That’s essentially it, but I also ran the following drush commands just to make sure:

1
drush updb
1
drush cc

Finally, I had to log back into the site as admin, and reset the favicon and logo paths at admin/build/themes/settings.  Once that was done, all is well, and I now have a stand alone installation instead of a multi-site.

 

A Better Approach to WordPress Portfolios

This idea was directly taken from John Watson’s excellent post, Building a better WordPress portfolio.  I’ve taken his concept, and I think, improved upon it slightly.  Thanks John.

I’m always looking for a better way to display my portfolio of various projects.  I’ve tried hand-coded pages, WordPress pages, custom WP functions that pull all the posts from a special category, etc…  and I just never have been able to come up with something that I really like.

See how meta I can be?!

Enter John Watson’s post about using WordPress Custom Post Types (CPT).  Custom post Types were, technically, introduced in WP 2.9, although there was no way to work with them in the user interface until 3.0.  Basically, they are WP’s answer to Drupal’s Custom Content Kit (CCK).  You know about Pages and Posts.  Well, Custom Post Types let you define additional “things”, so that you might have Pages, Posts, Teapots, and Projects.  The basic idea is that you define a Custom Post Type in functions.php, which gives you an entry in the WP admin sidebar to manage those entities.  In this instance, I’ve created a Custom Post Type of “Projects”, so that I can now add, edit and manage my portfolio, directly in the admin area.

The first step is to create the CPT in your themes functions.php.  The function that you need is register_post_type(), which you can read about in the Codex.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
add_action('init', 'techno_init');
function techno_init() {
  register_post_type('project',
    array(
      'labels' => array(
      'name' => __('Projects'),
      'singular_name' => __('Project'),
      'add_new_item' => __('Add New Project'),
      'edit_item' => __('Edit Project'),
      'new_item' => __('New Project'),
      'view_item' => __('View Project'),
      'search_items' => __('Search Projects'),
    ),
    'public' => true,
    'exclude_from_search' => true,
    'has_archive' => true,
    'menu_position' => 5,
    'supports' => array(
    'title', 'editor', 'excerpt','thumbnail', 'custom-fields', 'revisions'
    )
  )
 );
}

Technically, that’s all that you need to do.  However, one thing I wanted, was the ability to have snippets from each project displayed on a parent “Projects” page.

Themeing the output

It turns out, that this is very easily done.  You simply need to add a file to your theme, in this case, titled “archive-project.php”.  That keys the WP theme system to use that file in order to display a listing of all of your custom post types.  You can also create a custom template to display single project pages, by creating a new file, again directly in your theme directory.  This file should be titled “single-project.php”.  Again, that title causes the WP template heirarchy to choose the file to display your post.

Finally, you may get a 404 page not found error when you first try to load the Projects page.  To fix that, go to Settings->Permalinks in order to rebuild the permalink structure.  You don’t have to make any changes, just visit the Permalinks page, and click Save.  You now have a “Projects” parent page, themed by “archive-project.php”.  In my case, each individual Project page is still being themed by “single.php”.

 

Learning to Love Drupal

Or at least learning, to hate to love, Drupal.  Drupal is a Content Management System, or CMS, that is highly popular and very powerful.  It is also one of the most polarizing CMS’s in existence.  You either love it or you hate it.  The core of the issue is that Drupal is not really a CMS in the traditional sense that, say, WordPress is.  An out of the box installation of WordPress, is ready to run a standard, attractive blog with little to no configuration.  On the other hand, Drupal needs some pretty major configuration, just to see a plain vanilla “Hello World!” type page.

Drupal has been called a Content Management Framework, and with good reason.  Drupal is very powerful, and can be made to do most anything.  The White House website, www.whitehouse.gov, runs on Drupal.  The problem is that to do anything really complex, you really have to know Drupal.  I think that this is where the love/hate choice comes into play.  Drupal allows you to do some really radical stuff, without programming, although you could argue that, in some cases, programming would be simpler than figuring out the proper “Drupal Way” to perform a task.

I’ve tried Drupal in the past, and found it interesting, but I never had the time or inclination to really dig into the system and learn it.  Recently, as part of a job change which I’ll be posting about soon, I inherited a rather large, high traffic, website that runs on Drupal.  So, I’ve finally had to make the time to learn it.  There are a lot of things about Drupal that I don’t like, but overall, it’s an extremely powerful system, and it’s going to be a valuable addition to my toolkit.  In the future, in addition to WordPress, CodeIgniter, and raw PHP I’ll be using Drupal often.

How to get Free Electronic Components…

I’m currently working on a personal project for my shop.  It’s always a pain, when you’re working with electronics to set up a proper power supply.  So, tooling around Instructables the other day, I was inspired by several posts.  Instructables has several posts for building a dedicated benchtop power supply from old desktop computer components.  You see, desktops use a spec called ATX to ensure compatibility between components and power supplies.  This spec simply ensures that that shiny new 500 watt power supply that you bought to power your AlienWare gameing system can be plugged directly into your case without worries.  What it also means is that the connections are well documented for power supplies that can generally supply 3.3V, 5V, -12V & 12V.  These power supplies also have several advanced features already built in, like 110V – 240V switching, thermal overload protection, standby power etc…  Since benchtop power supplies generally run several hundred dollars, I was inspired to build my own.  You can see some of these Instructables at:

So, I went down to my local dump and pulled out a busted up Compaq desktop and started tearing into it.  I’ll be posting my progress, and I may even write my first Instructable based on this, although there are already several existing.  Old computers are excellent sources for parts, especially CD & Floppy drives, since these contain motors, switches, etc…  Today, I just tore everything out of the case, and started sorting parts.  I’m starting to plan my system, and I’d like to figure out a nice case using parts from Ponoko.

Here’s the Picasa stream of the pics that I took.