Your hosting environment typically includes both the Internet connection and the web server. It frequently includes your database as well. If you already have a website, the easiest choice may be to install Drupal on that host. Just check that the requirements in this section can be met (and try a test installation to see if you encounter any errors).

Your hosting choices are the same as for any website—your own server, a colocated server at a hosting service, or a shared server. If you are using a shared server, make certain that it supports the products and versions that you need. In addition, you need to find out the vendor’s plans for upgrades to new versions. For example, some shared hosting services that provide PHP support took two years to make the transition to PHP 5 from PHP 4. At first, PHP 5 was an option, but then support for PHP 4 was dropped.

If you need a shared hosting vendor, the best choice for many people is to use one that already runs some Drupal sites. You can find a list of Drupal hosts at drupal.org/hosting. The absence of a host from this list is not necessarily an indication that it cannot host Drupal. (For example, Network Solutions provides a number of open source products, including Drupal, with automated installation scripts to its shared hosting accounts, but it is not on the list.)

PHP and the web server are the primary software. PHP 5.2 or higher is required for Drupal 7 and recommended for Drupal 6. If you are using a shared hosting service, the versions they support are important as well as their upgrade policy. In many circumstances, Drupal will need to send email using PHP. Particularly on shared hosting servers, you might need to contact your vendor to enable this. Remember this is email sent from PHP and not the normal email application or web page you can usually access to send and receive email on your web server.

As for a web server, Apache 1.3 or Apache 2.x on Mac OS X, Windows, or UNIX/Linux is the recommended choice. Drupal also runs on Microsoft Internet Information Services (IIS) 6 or IIS 7.

The most common modifications needed are enabling the mod_rewrite extension for Apache or the Microsoft URL Rewrite Modules for IIS 7.0 on IIS. If you do not do this, Drupal will still run but will not be able to create clean URLs. See Hour 6, “Managing URLs: Cleaning, Redirects, and Pathauto,” for more on mod_rewrite.

On a shared server, you may or may not have access to the PHP initialization values in php.ini. (If you do not have direct access to it, contact your hosting service; it may either give you access or make the change for you.) One common value on shared servers that might need to be overridden is the memory setting. It is often set to 16MB, but changing it to 32MB or 64MB will prevent some Drupal memory errors. Drupal is designed to be as fast and efficient as possible, but at some points in its processing, memory requirements can spike. The memory issue is a commonly misdiagnosed Drupal problem. It often occurs after you install a new module and then go to the modules administration page to enable it. That is a moment when memory can spike. Removing the module appears to solve the problem. It can then recur when the same module or another one is installed. Instead of blaming the error on the modules, increase the memory limit to handle these spikes.

Other common php.ini settings that may need attention are the following:

Drupal core has a database abstraction layer that makes it possible for it to use many types of databases. At the moment, MySQL and PostgreSQL are supported. Table 3.1 shows the versions that are required.

Shared hosting packages often limit the number of databases you can have, and they may also limit the creation of databases so that they are done only through a script on the shared server. In addition, some hosting services that provide scripts to perform an automated install of Drupal and creation of its database may not allow you to access the database features such as optimization and data export. This matters only if you need to extract all the data (as when you move to another host). If you are using a host-provided script to set up the database, make certain that you have access to all the functions that you might need for its maintenance. You may need to contact the hosting service to do this.

You need the following permissions for the account that Drupal uses to access the database: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, and ALTER. Contributed modules may need CREATE TEMPORARY TABLES, LOCK TABLES, and other permissions (they should be identified in the module documentation). As noted, you need the ability to create a new database whether with the CREATE DATABASE command or by running a host-provided script that executes the CREATE DATABASE command only after checking that you have not used up your quota of databases and any other constraints the hosting vendor may have implemented.

This is the easiest part: Select from the current or the prior version after having checked the release schedule. Also, if you know the modules you want to use, check to see if they are available for the Drupal version you select.

The numbering convention for Drupal has two numbers: a major version and a release. Drupal 6.13 is thus the thirteenth release of Drupal 6. The number might be followed by -dev to indicate that it is in development. In the listings on drupal.org/project/drupal, you will find an indication of the recommended release for each version of Drupal.

Module numbering uses a similar approach. Because modules are specific to versions of Drupal, the module incorporates a Drupal version but not a release in most cases. Thus, the Panels contributed module can be numbered 6.x-3.0-rc1. The first part indicates that it is for Drupal 6; the x shows that no specific release is targeted (this is the common case). Following the hyphen, you find the module’s numbering. This is version 3 of Panels, and this is the first release (zero); -rc1 indicates that it is a release candidate (other common indicators are alpha and beta). Depending on the developer and the complexity of the module, you might see several release candidates as the module’s latest release is frozen and the last bugs are fixed.

You are now ready to install Drupal. Double-check your hosting settings, create a simple HTML page (such as a Hello World greeting), and upload it to the server. Make certain you can access it from your browser.

Also, make certain that you can access your database host. Create a new database and create a single table in it using phpMyAdmin, MySQL Administrator, or MySQL Query Browser. (You can remove this database as soon as you have tested it.)

If you do not regularly use PHP, create a one-line PHP program to check the PHP settings on your server with the following code:

Save it and place it in your server’s web root (where you successfully placed the Hello World page) and run it from a browser by typing www.myservername.com/phpinfo.php. You should see your server’s PHP settings.

If you cannot create a database and a table, or if you cannot create and run a PHP program, you will not be able to install and run Drupal. Particularly on shared hosting servers, much of the customer support is provided for the initial setup, so don’t be shy about asking.

Now, designate a directory for your Drupal files. It can be the root level of your website, or it can be a subfolder that you create specifically for Drupal. If you want to keep your Drupal files in their own folder, you can place a PHP file at the root level of your account to move to that folder. Particularly with shared hosting, you may already have an index.php file; if you do not, create one with this code:

If you do have an existing index.php file, you can move it to your subfolder or incorporate this code into it.

If you are using localhost to test your Drupal installation, you are done. If you are using a separate server, you may decide to keep a copy of your Drupal site on your own computer for safekeeping. If so, create that directory now.