University of Oregon

Drush Make post processing – Adding module type

We’re using drush make files to keep our Drupal sites updated.
Aegir will build a platform (base install for a multisite) from a make file. I believe it also re-builds the platform from that makeFile each time the platform is verified.

This is pretty handy but requires some leg work up front to generate the makeFile. http://drushmake.me is the go-to site to get a fresh makeFile built.
Though I just looked at the drush help file and saw that there’s a drush make-generate command ($ drush make-generate myMakeFile.make) that

Attempts to generate a makefile from the current Drupal install, specifying project version numbers unless not known or otherwise specified. Unversioned projects will be interpreted later by drush make as “most recent stable release”

So I gave it a shot and it did a great job.
(more…)

Handle sites/default/files redirect in Drupal 6 with Custom Errors module

When I’ve migrated sites into Aegir recently, I find that the users have many links in the content hard-coded to files in the default directory.
While it is possible to use the Scanner search & replace module to ferret those out. It’s not always thorough enough. For example, it doesn’t search and replace menu link urls, or content in blocks, views, headers, footers or custom fields. You can specify custom fields and locations to search but that’s another bag of worms that fraught with issues.
So I wanted to find a simple way to catch any hard coded links that I missed.
Enter the Custom Error module.

I’ve been using it to provide a populated search form on the 404 ‘Not found’ page as well as a site map but I also have a few custom redirects in there so adding an option for sites/default/files was simple.

Here’s the code: (more…)

Aegir: Adding external databases / injecting data in the settings.php file

I’ve been using Aegir a lot lately and it’s nice to find built-in work-arounds when you need one.
I needed to add an external database to my drupal site. As it turns out you can create a local.settings.php file in your site folder, and extend your settings.php file. See Injecting into settings.php for a full description.

Aegir manages the settings.php file. So any changes you make there will be overwritten. But we have control over the local.settings.php file.
As an example, I needed to include an external database that I incorporate into my site via TableWizard. To achieve that I created this local.settings.php file:

[code:php] ‘mysqli’,
‘database’ => ‘hr_ee_forms’,
‘username’ => ‘hr_reader’,
‘password’ => ‘******’,
‘host’ => ‘hrpub’,
‘port’ => ‘3306’,
);
$db_url[‘uo_ee_forms’] = $databases[‘uo_ee_forms’][‘default’][‘driver’] . ‘://’ . $databases[‘uo_ee_forms’][‘default’][‘username’] . ‘:’ . $databases[‘uo_ee_forms’][‘default’][‘password’] . ‘@’ . $databases[‘uo_ee_forms’][‘default’][‘host’] . ‘:’ . $databases[‘uo_ee_forms’][‘default’][‘port’] . ‘/’. $databases[‘uo_ee_forms’][‘default’][‘database’];

$db_prefix = array(
‘default’ => ”,
‘org_level’ => ”,/*org_chart*/
‘uo_oa’ => ”/*uo_ee_forms*/
);
[/code]

The above code adds an external DB that TableWizard can read, providing access to the data via views.

Note that I had to ‘hard code’ the values. We can’t take advantage of the stored $_server vars that Aegir keeps in the vhost file. For ex:

[code:php]
$databases[‘default’][‘default’] = array(
‘driver’ => $_SERVER[‘db_type’],
‘database’ => $_SERVER[‘db_name’],
‘username’ => $_SERVER[‘db_user’],
‘password’ => $_SERVER[‘db_passwd’],
‘host’ => $_SERVER[‘db_host’],
‘port’ => $_SERVER[‘db_port’],
);
[/code]

Those are available in the settings.php file but unset before the our local.settings.php file is run.

There’s also an option for a global.inc file that can apply settings to all your sites.

Keeping Aegir up to date

We’re starting to use Aegir to manage our Drupal sites. It’s shaping up to be a great site hosting management tool.

The three developers currently using it also have a local VM copy of the server running Aegir for testing. Thanks Max!

I updated my VM Aegir install today and I thought I’d share the steps.

First thing I noticed is that I didn’t have a cronjob scheduled, so I set up a cronjob and then I realized that there wasn’t a link to Available Updates in my reports menu and found out that the Update Status module wasn’t enabled. So that was next. After that I updated Drush and used it to update the site.

Steps:

  1. Set up a cron job for the Aegir site
    $ crontab -l
    ## Result: no crontab for maxbrons
    $ crontab -e
    ## insert: i and paste
    0 * * * * wget -O - -q -t 1 http://aegir.example.com/cron.php
    ## save and quit: :wq
    ## Result: no crontab for maxbrons - using an empty one
          crontab: installing new crontab $ crontab -l
    ## Result: 0 * * * * wget -O - -q -t 1 http://aegir.example.com/cron.php
  2. Enable the Update Status module: http://aegir.example.com/admin/build/modules
  3. I immediately received warnings about available updates.
  4. Open a terminal and get ready to flex your Drush muscles.
  5. $ cd /var/aegir/hostmaster-6.x-1.1/sites/aegir.example.com
  6. ## Run drush self update
    $ drush selfupdate
    ## Result: Drush folder at /var/aegir/drush is not writable                                                                  [error]
    ## Log in as root
    $ su root
    [root]# drush selfupdate
    ## Result: A newer version of drush, 7.x-4.5-rc1, is available.  Would you like to back up your current drush, version 4.4, to /root/drush-backups/drush/20110803172202 and replace it with the newer release? (y/n): y
    drush backed up to /root/drush-backups/drush/20110803172202/drush
    ## [ok]
    Project drush (7.x-4.4) downloaded to /var/aegir/drush.
    ## [success]
    ## Result: Drush successfully updated to version 7.x-4.4.
  7. ## update the site
  8. [root@localhost aegir.example.com]# drush up
  9. ## Append -v to see behind the scenes: # drush up -v
  10. ## update the db
  11. [root@localhost aegir.example.com]# drush updb
  12. Confirm updates to core and contrib modules
  13. Now visit: http://aegir.example.com/admin/reports/updates to verify.

Done!

Thoughts: I have no idea why the Update Status module wasn’t enabled.

Lessons learned.

  1. Drush is cool
  2. I really like that there’s a “drush selfupdate” cmd. Also cool.
  3. su root is really handy! Without it I think I’d have to temporarily chown or chmod the drush directory