drupal/INSTALL.txt

236 lines
9.9 KiB
Plaintext
Raw Normal View History

// $Id$
2001-01-13 17:16:05 +00:00
- Patch #18641 by Morbus: # The INSTALL.txt no longer contains the SERVER CONFIGURATION block. These settings are now hardcoded into sites/default/settings.php, and are merely scary technical junk here. # The INSTALL.txt has been updated with the latest system requirements. A whole sentence was struck regarding differing versions of PHP for the OSs. # The INSTALL.txt contains URLs to MySQL and PostgreSQL. If we're including the URL for PHP in the same sentence, then there's no reason why we wouldn't include them for the database engines. What are the minimal requirements for the RDBMS? Those should be included here too. # The INSTALL.txt's OPTIONAL COMPONENTS has renamed to OPTIONAL REQUIREMENTS. The only difference between the meaning is the amount of user confusion. # The INSTALL.txt has a new CONTENTS OF THIS FILE, in hopes that people will more immediately notice that there are upgrade instructions at the bottom. # The INSTALL.txt had some potentially confusing lines adjusted, including further clarifications, standarding to "userid" (instead of using both userid and username interchangebly) and so on. # I've moved most of .htaccess php_value's to the ini_set system for /sites/. There are a few reasons for this, chiefly that it is centralizing all the PHP setting modifications to one place. But, this also clears up a few initial configuration issues: first, the user doesn't have to worry about whether they have Apache 1 or 2, and whether they need to change an IfModule line. Also, the running assumption is that these php_value's are /going to work by default anyways/, when the INSTALL.txt suggests otherwise (under OPTIONAL REQUIREMENTS, it talks about "the ability to use local .htaccess files", which suggests that "local .htaccess files" INCLUDING "mod_rewrite" are entirely optional.) Some variables, however, had to remain in .htaccess because they can't be overridden at runtime, but the amount was so small that duplicating them for both Apache 1 and Apache 2 possibilities is no longer a prohibitive concern. # There are two variables in .htaccess that I'm concerned about: track_vars, and allow_call_time_pass_reference. track_vars appears to be no longer necessary (as of 4.0.3, track_vars is always on, and my setting it here had no impact on the results of a phpinfo), and allow_call_time_pass_reference seems, at least here, to ONLY WORK if the .htaccess value is set to "1", and not "On" - meaning that Drupal installations are currently working correctly with its default value (off). According to the PHP docs, this feature is now deprecated. However, since both of these variables require further investigation, track_vars has been moved to settings.php, and allow_call_time_pass_reference has been "fixed" to a 1 (not 'On'). # Along with the changes above for sites/default/settings.php, I've also removed the spacing indent in the documentation, as well as many a few grammatical/punctuation changes here and there. I don't think the leading spacing is "right" according to the style guidelines, but maybe there's a special need for it. Correct me if I'm wrong.
2005-03-12 10:51:32 +00:00
CONTENTS OF THIS FILE
---------------------
* Requirements
* Optional requirements
* Installation
* Drupal administration
* Customizing your theme(s)
* Multisite Configuration
- Patch #18641 by Morbus: # The INSTALL.txt no longer contains the SERVER CONFIGURATION block. These settings are now hardcoded into sites/default/settings.php, and are merely scary technical junk here. # The INSTALL.txt has been updated with the latest system requirements. A whole sentence was struck regarding differing versions of PHP for the OSs. # The INSTALL.txt contains URLs to MySQL and PostgreSQL. If we're including the URL for PHP in the same sentence, then there's no reason why we wouldn't include them for the database engines. What are the minimal requirements for the RDBMS? Those should be included here too. # The INSTALL.txt's OPTIONAL COMPONENTS has renamed to OPTIONAL REQUIREMENTS. The only difference between the meaning is the amount of user confusion. # The INSTALL.txt has a new CONTENTS OF THIS FILE, in hopes that people will more immediately notice that there are upgrade instructions at the bottom. # The INSTALL.txt had some potentially confusing lines adjusted, including further clarifications, standarding to "userid" (instead of using both userid and username interchangebly) and so on. # I've moved most of .htaccess php_value's to the ini_set system for /sites/. There are a few reasons for this, chiefly that it is centralizing all the PHP setting modifications to one place. But, this also clears up a few initial configuration issues: first, the user doesn't have to worry about whether they have Apache 1 or 2, and whether they need to change an IfModule line. Also, the running assumption is that these php_value's are /going to work by default anyways/, when the INSTALL.txt suggests otherwise (under OPTIONAL REQUIREMENTS, it talks about "the ability to use local .htaccess files", which suggests that "local .htaccess files" INCLUDING "mod_rewrite" are entirely optional.) Some variables, however, had to remain in .htaccess because they can't be overridden at runtime, but the amount was so small that duplicating them for both Apache 1 and Apache 2 possibilities is no longer a prohibitive concern. # There are two variables in .htaccess that I'm concerned about: track_vars, and allow_call_time_pass_reference. track_vars appears to be no longer necessary (as of 4.0.3, track_vars is always on, and my setting it here had no impact on the results of a phpinfo), and allow_call_time_pass_reference seems, at least here, to ONLY WORK if the .htaccess value is set to "1", and not "On" - meaning that Drupal installations are currently working correctly with its default value (off). According to the PHP docs, this feature is now deprecated. However, since both of these variables require further investigation, track_vars has been moved to settings.php, and allow_call_time_pass_reference has been "fixed" to a 1 (not 'On'). # Along with the changes above for sites/default/settings.php, I've also removed the spacing indent in the documentation, as well as many a few grammatical/punctuation changes here and there. I don't think the leading spacing is "right" according to the style guidelines, but maybe there's a special need for it. Correct me if I'm wrong.
2005-03-12 10:51:32 +00:00
* More Information
REQUIREMENTS
------------
Drupal requires a web server, PHP 4 (4.3.3 or greater) or PHP 5
(http://www.php.net/) and either MySQL (http://www.mysql.com/) or PostgreSQL
(http://www.postgresql.org/). The Apache web server and MySQL database are
recommended; other web server and database combinations such as IIS and
PostgreSQL have been tested to a lesser extent. When using MySQL, version 4.1
or greater is recommended to assure you can safely transfer the database.
For more detailed information about Drupal requirements, see "Requirements"
(http://drupal.org/requirements) in the Drupal Handbook.
Guidelines for setting up a server environment with a variety of operating
systems and in special cases are available in the Drupal handbook
(http://drupal.org/node/260).
- Patch #18641 by Morbus: # The INSTALL.txt no longer contains the SERVER CONFIGURATION block. These settings are now hardcoded into sites/default/settings.php, and are merely scary technical junk here. # The INSTALL.txt has been updated with the latest system requirements. A whole sentence was struck regarding differing versions of PHP for the OSs. # The INSTALL.txt contains URLs to MySQL and PostgreSQL. If we're including the URL for PHP in the same sentence, then there's no reason why we wouldn't include them for the database engines. What are the minimal requirements for the RDBMS? Those should be included here too. # The INSTALL.txt's OPTIONAL COMPONENTS has renamed to OPTIONAL REQUIREMENTS. The only difference between the meaning is the amount of user confusion. # The INSTALL.txt has a new CONTENTS OF THIS FILE, in hopes that people will more immediately notice that there are upgrade instructions at the bottom. # The INSTALL.txt had some potentially confusing lines adjusted, including further clarifications, standarding to "userid" (instead of using both userid and username interchangebly) and so on. # I've moved most of .htaccess php_value's to the ini_set system for /sites/. There are a few reasons for this, chiefly that it is centralizing all the PHP setting modifications to one place. But, this also clears up a few initial configuration issues: first, the user doesn't have to worry about whether they have Apache 1 or 2, and whether they need to change an IfModule line. Also, the running assumption is that these php_value's are /going to work by default anyways/, when the INSTALL.txt suggests otherwise (under OPTIONAL REQUIREMENTS, it talks about "the ability to use local .htaccess files", which suggests that "local .htaccess files" INCLUDING "mod_rewrite" are entirely optional.) Some variables, however, had to remain in .htaccess because they can't be overridden at runtime, but the amount was so small that duplicating them for both Apache 1 and Apache 2 possibilities is no longer a prohibitive concern. # There are two variables in .htaccess that I'm concerned about: track_vars, and allow_call_time_pass_reference. track_vars appears to be no longer necessary (as of 4.0.3, track_vars is always on, and my setting it here had no impact on the results of a phpinfo), and allow_call_time_pass_reference seems, at least here, to ONLY WORK if the .htaccess value is set to "1", and not "On" - meaning that Drupal installations are currently working correctly with its default value (off). According to the PHP docs, this feature is now deprecated. However, since both of these variables require further investigation, track_vars has been moved to settings.php, and allow_call_time_pass_reference has been "fixed" to a 1 (not 'On'). # Along with the changes above for sites/default/settings.php, I've also removed the spacing indent in the documentation, as well as many a few grammatical/punctuation changes here and there. I don't think the leading spacing is "right" according to the style guidelines, but maybe there's a special need for it. Correct me if I'm wrong.
2005-03-12 10:51:32 +00:00
OPTIONAL REQUIREMENTS
---------------------
- To use XML-based services such as the Blogger API and RSS syndication,
you will need PHP's XML extension. This extension is enabled by default.
- If you want support for clean URLs, you'll need mod_rewrite and the ability
to use local .htaccess files.
INSTALLATION
------------
1. DOWNLOAD DRUPAL AND OPTIONALLY A TRANSLATION
You can obtain the latest Drupal release from http://drupal.org/. The files
are in .tar.gz format and can be extracted using most compression tools. On a
typical Unix command line, use:
wget http://drupal.org/files/projects/drupal-x.x.tar.gz
tar -zxvf drupal-x.x.tar.gz
This will create a new directory drupal-x.x/ containing all Drupal files
and directories. Move the contents of that directory into a directory within
your web server's document root or your public HTML directory:
mv drupal-x.x/* drupal-x.x/.htaccess /var/www/html
If you would like to have the default English interface translated to a
different language, we have good news. You can install and use Drupal in
other languages from the start. Check whether a released package of the
language desired is available for this Drupal version at
http://drupal.org/project/Translations and download the package. Extract
the contents to the same directory where you extracted Drupal into.
2. GIVE PERMISSION TO DRUPAL TO BE ABLE TO CREATE THE CONFIGURATION FILE
Drupal comes with a default.settings.php file in the sites/default
directory. The installer will create a copy of this file filled with
the details you provide through the install process, in the same
directory. For Drupal to be able to create the file, you need to
give the web server write privileges to the sites/default directory:
chmod o+w default
3. CREATE THE DRUPAL DATABASE
Drupal requires access to a database in order to be installed. Your database
user will need sufficient privileges to run Drupal. Additional information
about privileges, and instructions to create a database using the command
line are available in INSTALL.mysql.txt (for MySQL) or INSTALL.pgsql.txt
(for PostgreSQL).
To create a database using PHPMyAdmin or a web-based control panel consult
the documentation or ask your webhost service provider.
Take note of the username, password, database name and hostname as you
create the database. You will enter these items in the install script.
4. RUN THE INSTALL SCRIPT
To run the install script point your browser to the base url of your website
(i.e. http://www.example.com).
You will be guided through several screens to set up the database,
create tables, add the first user account and provide basic web
site settings.
The install script will attempt to write-protect the sites/default
directory after creating the settings.php file. If you make manual
changes to that file later, be sure to protect it again after making
your modifications. Failure to remove write permissions to that file
is a security risk. Although the default location for the settings.php
file is at sites/default/settings.php, it may be in another location
if you use the multi-site setup, as explained below.
5. CONFIGURE DRUPAL
When the install script succeeds, you will be directed to the "Welcome"
page, and you will be logged in as the administrator already. Proceed with
the initial configuration steps suggested on the "Welcome" page.
If the default Drupal theme is not diplaying properly and links on the page
result in "Page Not Found" errors, try manually setting the $base_url variable
in the settings.php file if not already set. It's currently known that servers
running FastCGI can run into problems if the $base_url variable is left
commented out (see http://bugs.php.net/bug.php?id=19656).
Consider creating a "files" subdirectory in your Drupal installation
directory. This subdirectory stores files such as custom logos, user avatars,
and other media associated with your new site. The sub-directory requires
"read and write" permission by the Drupal server process. You can change
the name of this subdirectory at "administer > site configuration > file
system".
6. CRON TASKS
Many Drupal modules (such as the search functionality) have periodic tasks
that must be triggered by a cron job. To activate these tasks, call the cron
page by visiting http://www.example.com/cron.php --this will pass control to
the modules and the modules will decide if and what they must do.
Most systems support the crontab utility for scheduling tasks like this. The
following example crontab line will activate the cron tasks automatically on
the hour:
0 * * * * wget -O - -q -t 1 http://www.example.com/cron.php
More information about the cron scripts are available in the admin help pages
and in the Drupal handbook at drupal.org. Example scripts can be found in the
scripts/ directory.
DRUPAL ADMINISTRATION
---------------------
A new installation of Drupal defaults to a very basic configuration with only a
few active modules and minimal user access rights.
Use your administration panel to enable and configure services. For example:
General Settings Administer > Site configuration > Site information
Enable Modules Administer > Site building > Modules
Configure Themes Administer > Site building > Themes
Set User Permissions Administer > User management > Access control
For more information on configuration options, read the instructions which
accompany the different configuration settings and consult the various help
pages available in the administration panel.
- Patch #18641 by Morbus: # The INSTALL.txt no longer contains the SERVER CONFIGURATION block. These settings are now hardcoded into sites/default/settings.php, and are merely scary technical junk here. # The INSTALL.txt has been updated with the latest system requirements. A whole sentence was struck regarding differing versions of PHP for the OSs. # The INSTALL.txt contains URLs to MySQL and PostgreSQL. If we're including the URL for PHP in the same sentence, then there's no reason why we wouldn't include them for the database engines. What are the minimal requirements for the RDBMS? Those should be included here too. # The INSTALL.txt's OPTIONAL COMPONENTS has renamed to OPTIONAL REQUIREMENTS. The only difference between the meaning is the amount of user confusion. # The INSTALL.txt has a new CONTENTS OF THIS FILE, in hopes that people will more immediately notice that there are upgrade instructions at the bottom. # The INSTALL.txt had some potentially confusing lines adjusted, including further clarifications, standarding to "userid" (instead of using both userid and username interchangebly) and so on. # I've moved most of .htaccess php_value's to the ini_set system for /sites/. There are a few reasons for this, chiefly that it is centralizing all the PHP setting modifications to one place. But, this also clears up a few initial configuration issues: first, the user doesn't have to worry about whether they have Apache 1 or 2, and whether they need to change an IfModule line. Also, the running assumption is that these php_value's are /going to work by default anyways/, when the INSTALL.txt suggests otherwise (under OPTIONAL REQUIREMENTS, it talks about "the ability to use local .htaccess files", which suggests that "local .htaccess files" INCLUDING "mod_rewrite" are entirely optional.) Some variables, however, had to remain in .htaccess because they can't be overridden at runtime, but the amount was so small that duplicating them for both Apache 1 and Apache 2 possibilities is no longer a prohibitive concern. # There are two variables in .htaccess that I'm concerned about: track_vars, and allow_call_time_pass_reference. track_vars appears to be no longer necessary (as of 4.0.3, track_vars is always on, and my setting it here had no impact on the results of a phpinfo), and allow_call_time_pass_reference seems, at least here, to ONLY WORK if the .htaccess value is set to "1", and not "On" - meaning that Drupal installations are currently working correctly with its default value (off). According to the PHP docs, this feature is now deprecated. However, since both of these variables require further investigation, track_vars has been moved to settings.php, and allow_call_time_pass_reference has been "fixed" to a 1 (not 'On'). # Along with the changes above for sites/default/settings.php, I've also removed the spacing indent in the documentation, as well as many a few grammatical/punctuation changes here and there. I don't think the leading spacing is "right" according to the style guidelines, but maybe there's a special need for it. Correct me if I'm wrong.
2005-03-12 10:51:32 +00:00
Community-contributed modules and themes are available at http://drupal.org/.
CUSTOMIZING YOUR THEME(S)
-------------------------
Now that your installation is running, you will want to customize the look of
your site. Several sample themes are included and more can be downloaded from
drupal.org.
Simple customization of your theme can be done using only CSS. Further changes
require understanding the phptemplate engine that is part of Drupal. See
http://drupal.org/handbook/customization to find out more.
MULTISITE CONFIGURATION
-----------------------
A single Drupal installation can host several Drupal-powered sites, each with
its own individual configuration.
Additional site configurations are created in subdirectories within the 'sites'
directory. Each subdirectory must have a 'settings.php' file which specifies the
configuration settings. The easiest way to create additional sites is to copy
the 'default' directory and modify the 'settings.php' file as appropriate. The
new directory name is constructed from the site's URL. The configuration for
www.example.com could be in 'sites/example.com/settings.php' (note that 'www.'
should be omitted if users can access your site at http://example.com/).
Sites do not have to have a different domain. You can also use subdomains and
subdirectories for Drupal sites. For example, example.com, sub.example.com,
and sub.example.com/site3 can all be defined as independent Drupal sites. The
setup for a configuration such as this would look like the following:
sites/default/settings.php
sites/example.com/settings.php
sites/sub.example.com/settings.php
sites/sub.example.com.site3/settings.php
When searching for a site configuration (for example www.sub.example.com/site3),
Drupal will search for configuration files in the following order, using the
first configuration it finds:
sites/www.sub.example.com.site3/settings.php
sites/sub.example.com.site3/settings.php
sites/example.com.site3/settings.php
sites/www.sub.example.com/settings.php
sites/sub.example.com/settings.php
sites/example.com/settings.php
sites/default/settings.php
If you are installing on a non-standard port, the port number is treated as the
deepest subdomain. For example: http://www.example.com:8080/ could be loaded
from sites/8080.www.example.com/. The port number will be removed according to
the pattern above if no port-specific configuration is found, just like a real
subdomain.
Each site configuration can have its own site-specific modules and themes in
addition to those installed in the standard 'modules' and 'themes' directories.
To use site-specific modules or themes, simply create a 'modules' or 'themes'
directory within the site configuration directory. For example, if
sub.example.com has a custom theme and a custom module that should not be
accessible to other sites, the setup would look like this:
sites/sub.example.com/:
settings.php
themes/custom_theme
modules/custom_module
NOTE: for more information about multiple virtual hosts or the configuration
settings, consult the Drupal handbook at drupal.org.
MORE INFORMATION
----------------
For platform specific configuration issues and other installation and
administration assistance, please consult the Drupal handbook at
http://drupal.org/handbook. You can view the wide range of other support options
available at http://drupal.org/support.