Now I talked about updating and backups.

Now on to what you can do with your backups: *drumroll*


While building your page, fixing bugs or testing updates – it’s logical to actually work on a local host and not on your real life website…

But then comes the day of migration (finally)

The way I like to do migration:

  1. update the Drupal core (or find the version of your site)
  2. install the Drupal core normally on the other server
  3. migrate the sites folder (and activate one or two modules for the next step)
  4. migrate the database (using Backup and Migrate)

I like to install the Drupal core normally as it is easier than changing the settings manually in the settings file (but you could do that as well if you are sure of what you are doing)

To make a transition from online to offline and back as smooth as possible I always do one of the following to be sure the will be database working correctly:

  • update both sites at the same time – if by chance you know there will be no problems… which you don’t – or I have a test site running on a server (group projects…)
  • test the update on the test site and afterwards update the productive site 

Always be careful to migrate the database when you have the same versions running otherwise you could get errors (especially if the database was change with the update)

And of cause backup both you test site and your productive site before you do the migration!

And done 🙂

Database backup

I already talked about backing up your Drupal installation in my posts about updating Drupal.

Backing up the code is pretty easy – just copy your whole Drupal installation – and done.

But how do you backup the database nice and easy?

The easiest way I found was the Module Backup and Migrate.

You can easily back up the database just with a click or setup automatic backups for your systems (either saved on a server or send by mail).

You can also setup the backup to be compressed (which is handy, when you need to restore and the Server will not let you do it with a big file)

And the module also restores the database.

You can also update the Database directly with these files (outside of Drupal – useful if your provider let’s you not update the whole database via Restore – I had the problem once :/ )

Of cause there are more cool options waiting in the module (I just never used them 😉 ) and if you search for Backup on drupal.org you find some more Backup and Restore projects not part of the main project (I’ve seen some backup to Dropbox once)

Update Modules on an Acquia Drupal Install

After my post about updating the Drupal core on an Acquia Install now how to update pre-installed modules.

SECURITY: I don’t know if this will work for you (it should!) so go on and back up your database and your code basically your site (database backup and copy of all files in your Drupal install). If something goes wrong and you don’t have a backup – it’s on your head. Try at own risk.

When you get the message you need to update some modules (I know you can update modules from inside Drupal – how cool is that? – sadly it didn’t work with my Acquia install – and I couldn’t test it somewhere else until now) you would normally look for the modules in the sites/all/modules folder (or where ever you stored your modules). But the pre-installed modules aren’t there…

The pre-installed modules coming with Acquia are in the profiles/acquia/modules folder. There you can delete the modules and insert the new version of your modules.

Don’t forget to run the update.php script!

Hide Error Massages

As I started developing my new project in Drupal 7 I stumbled over a couple of Menu changes…

There are several changes (mostly for the better, I think) but for Drupal 6 users it can become quit frustrating to look for a functionality and not finding it where you expect it (happened several times for me already…)

Before I start with my first menu change tip an information for you: I use the Administration Menu module for better access to the admin area of Drupal. And it still is a release candidate so there are still some problems with the themes but otherwise it works fine for me.

On to the tip:

When you want to hide Error reports (showing up at the top of a page) from all users and just log them in the database for the administrators to see:

Got to Development > Logging and errors and choose > None.

Cron in Drupal

Okay so what is cron? Or what’s a cronjob?

Well if you search for it Wikipedia will tell you that cron is a job scheduler in operation systems other than Windows. Consequently a cronjob is a command or a script (basically a series of commands) with is scheduled to be executed at a given interval.

Now in Drupal cron is used for different tasks to maintain the system (search the Documentation for more information about cron).

The main thing you should know is: cron is very important for your search and other modules may need it to do what ever you want them to do (e.g. Rules can use cron to trigger some actions or the other way round, whatever you want to do…).

In Drupal 6 you have the choice between setting up cron with your hosting provider or using your computer or … using the module Poorman’s Cron (how to do one of the others? – search the Documentation). With module you can decide how often cron is run. When you use the module you will find the configuration on the page with the site information.

In Drupal 7 Poorman’s Cron was integrated into the core so you do not have to do anything else. You can find it under > Configuration > System > Cron.

Depending on how busy your site is/will be/ should be you can choose how often you need cron to run. Of cause you can also adapt your configuration. Up until now I didn’t have any problems with using an interval of 3 hours. But I didn’t have so big projects it may be different to you.