By now, the vast majority of the development for the new site is complete! You should also feel confident that, from a development perspective, you can respond to whatever demands the site throws at you and work with Drupal with a high degree of proficiency. Like all things in the computing world, however, it is never sufficient to build something and then leave your creation to run by itself. There is always work to be done to ensure that everything runs smoothly.
Often, you will find that there are certain jobs that need to be performed every now and then that are not specifically related to Drupal, but are intrinsic to working with websites in general. These tasks can vary greatly in nature, but all those discussed here will be useful at some stage during the life of your website, even if you don't need them right now.
One of the problems with presenting a chapter like this is that we can't possibly hope to cover each and every nuance of the huge array of different platforms on which Drupal can be run. Internet Service Providers (ISPs) offer wildly varying packages, which can either be totally bereft of any type of helpful functionality, or packed full with all the latest gadgets—most ISPs offer a large variety of packages under one roof.
Because of this, we will look at functionality that is in common use and that, in the event you do not have access to the same software, will clearly demonstrate the tasks you need to perform so that you can still successfully operate with the software you do have access to. For example, by using the Apache2Triad package, we already have certain useful technologies that we can make use of on the development machine, such as phpMyAdmin.
There are also a few other web-related activities inherent to Drupal that we should take the time to look over quickly. As a result, this chapter will talk about:
- Making backups
- Cron and scheduled tasks
- Throttling
- Patching
- Website activities—including search engine optimization and user maintenance
Armed with the information presented in this the final chapter, you will be a fully equipped Drupal-website administrator. However, the experience you gain from running a live website in itself should prove to be far more valuable than this humble book. Hopefully, you will find the entire experience richly rewarding and share your hard-won knowledge with the rest of the community in the future.
We're on the home straight, so let's get on with it.
There are plenty of reasons to make backups of both the file system and database. As mentioned several times throughout the course of the book, you should back up anything that is at risk of being damaged whenever you modify code, or add a new module, or even upgrade versions of Drupal. It sounds like a real pain to do this because the vast majority of the time, nothing goes wrong with the application. However, sooner or later, for some unfathomable reason, if you don't make backups, you will get stung in precisely the most painful spot.
Most especially, corrupting or breaking a database, which in turn leads to a loss of precious data, can be a real pain in the… back end of your application! So, while it is fairly easy to back up the files on the file system by simply making copies of the directories in question, or indeed copying the entire drupal folder (whatever you have named it), it is of paramount importance that you learn how to back up the database too, because this is not as trivial—it will become easy with practice, though.
Before continuing, it is important to have a strategy for backing up files, folders, and data. It is good idea to back up the entire site at regular intervals, as well as backing up the database even more frequently. These backups should be clearly marked so that you know when they were made, making it easy to determine which one to use in the event of some sort of disaster. You might also consider holding these backups away from the main file system, perhaps on a CD, so that if something really bad happens, you don't have to rely on your host's disaster-recovery policy; you have your own.
There are two ways of backing up your database (or any part of it) that we will consider here. One way is to make use of phpMyAdmin, which comes as part of the Apache2Triad package. Let's start with that.
phpMyAdmin is an exceptionally popular and commonplace tool for interacting with MySQL via the Web. Instead of having to learn how to use the MySQL command-line client, phpMyAdmin provides us with a graphical interface, which makes it a lot easier to view and maintain databases tables and content. Issuing commands is also made easier with the interface for many of the most commonplace data-related tasks.
The following steps can be followed in order to create a backup with phpMyAdmin:
- Log into phpMyAdmin and select the relevant Drupal database.
- Click on the Export tab along the top of the page, and set up the options as shown here:
- In the screenshot, all the tables were selected for backup, all the Structure checkboxes were selected in order to prevent us having to manually drop a corrupted database, and a useful name (which automatically contains the database name once the backup file is generated) was provided—appending the date as shown is a good idea as it will help you to keep track of which backup is which.
- Click Go once you are satisfied with your options, and this will then create a SQL file (although there are other formats to choose from such as LaTeX or XML) from which you can recreate the database if needed.
Once you have a backup file, it is a simply matter of causing MySQL to run its contents in order to recreate the database. In order to do this, click on the SQL tab at the top of the page, and enter the name of the .sql file you would like to run against the database, as shown here:
That makes life fairly simple, but it isn't the only way. If you have gotten used to using the command line, or simply prefer it, then we have already seen how it is done, when we issued the command to load the original database:
C: mysql -udrupal -p drupal < C:/apache2triad/htdocs/drupal-4.6.4/ database/database.mysql
You would simply modify the path and filename to reflect the specifics of your new backup file, like so:
C: mysql -uroot -p drupal < C:/backups/drupal_13_04_06.sql
Another way of creating backups is by using the mysqldump utility from the command line.
It is probably worthwhile spending some time using this because it provides greater flexibility should you ever need to perform anything out of the ordinary. I will confess, though, that for most database‑related tasks phpMyAdmin will perform admirably. If you don't have access to phpMyAdmin on your hosted site, or if you are keen to get to know mysqldump, then by all means continue…
To create a backup, simply type in something like the following at the command line:
C: mysqldump drupal > drupal_13_04_06.sql
This will create a backup file called drupal_06_11_05.sql in the current directory. You can then ensure that this has worked by viewing the contents of the file, which will contain reams and reams of SQL statements. There are plenty of different options that you can use to get a variety of different types of backup file; you can simply type in:
C: mysqldump help
in order to obtain a list of what's available. mysqldump is a powerful and flexible tool, and knowing how it works will benefit you in the long run if you are going to attempt some more advanced backup options.
To reiterate, it is good practice to back up your database on a regular basis, regardless of whether your need to do so for upgrading purposes as doing this will protect you from a total loss of data in the event that some sort of disaster destroys the database or loses its information.