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)

Hide Author and post date from content

Okay in Drupal 6 to hide “Submitted by” author “on” a date and time you would go to the themes and specify on which content types that information should be displayed and on which not.

In Drupal 7 you can change these settings under Structure > Content types when you edit the content type you want to change.

Of cause for a more a more customized approach what to show and what not you have to work on template.php.

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.

Drupal 6 & Drupal 7 – or why I used Drupal 6…

Ancient history or what happened last year:

When I started with Drupal the current version was 6 (that was still in December…) While learning my way around D6 I read about D7 and I totally missed the release of it in January this year.

Of cause I was nearly done with my first website and couldn’t switch to D7 for the next website, because that would have meant I would have to switch the first one too (the task was to build 3 websites in one system even if I installed Drupal three times).

My main problem then: Modules

I know many developers pledged to get a functional module for D7 by the release day of D7. But most modules were still development builds then.

Well my trust in development builds of modules was never great, because they are mainly build for testing and at the time Drupal 7 was released I needed stable things to work with. And some modules I needed had no Drupal 7 port at all.

Of cause I tried to install D7 on my local testing server but I failed and didn’t have the time to go looking for the reason why. Hopefully I find the time to try it out soon. *exited about it*

What happened after or what happens right now:

I know now that there were some modules missing from my test server. And I am really glad I didn’t switch to D7 the company servers were so restrictive I had problems getting D6 up and running – security is all great but I would have had to change so many things to make it work properly their other projects on the server would just shut down… no fun at all. It took me 2 days for one site fortunately the second site was easier after that (the first site was on another server (which worked great by the way – and I thought that went bad…)

Now enough complaining on my part.

I admit for testing Drupal 7 locally again I didn’t try to install it manually but got myself the Acquia Drupal installer who comes with server and everything. It was really easy to install (and it looks pretty good). *grin*

Now D7 runs smoothly. It looks good from the start but of cause I have some problems going around and finding things I knew from D6.

My main problem now: Modules (see a pattern?)

I know that many module developer are doing it for fun (and for free).

You guys are great by the way.

But many modules are still in the early stages – alpha and beta or still only development builds. I know some already work well in their stages of development and I am sure there are modules already up and running (I haven’t seen any as of yet – not that it means much I just started with D7 after all).

It is still discouraging if you search for a functionality and only get solutions for D6, solutions being code or modules.

And I know how to code some functionality off the top of my head. And I will need my coding skills for sure for my next project if it turns out that we will use Drupal for it. (No switching back to D6 if I can  help it – upgrading doesn’t sound to easy from what I read…)