2003-03-08 12:28:24 +00:00
|
|
|
// $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)
|
|
|
|
* More Information
|
|
|
|
|
2003-03-08 12:28:24 +00:00
|
|
|
REQUIREMENTS
|
|
|
|
------------
|
|
|
|
|
- More improvements by Morbus, Goba, TDobes et al:
Per TDobes' comments:
* INSTALL.txt corrected to use 4.3.3, not 4.33.
* .htaccess: removed allow_call_time_pass_reference. two confirmations that a) the setting was wrong in the first place, b) there were no adverse affects for the incorrect setting, c) the PHP docs say it is deprecated.
* .htaccess: removed short_open_tag. Running grep -r "<? " * across the entire directory tree of both core and contributions only brought up contributions and no core. I agree that the fuller form is better. The following contributions will need to be updated: modules/edit_template/edit_template.module, sandbox/garym/themes/marvin_2k/templates/page.tpl.php, sandbox/killes/compare.php, sandbox/paolino/import/click.php, themes/spreadfirefox/block.tpl.php. For error's sake, I also did a manual verification for "<?" (no space) across core and came up against nothing in addition to the above contribs.
Per Goba's comments:
* .htaccess: Moved session.auto_start back.
* sites/default/settings.php: Removed track_vars.
Per mailing list comments:
* INSTALL.txt: Added text about the files/ directory, creating it, and permissions.
* INSTALL.txt: Added an example of why Drupal requires cron (the search.module) in an attempt to justify why a crontab is a good, nay, required step.
And my own further analities:
* .htaccess: cleaned up some whitespace valleys (i hate 'em, hate 'em!) and fixed a few stray colons.
* settings.php: minor whitespace error.
2005-03-15 21:07:49 +00:00
|
|
|
Drupal requires a web server, PHP4 (4.3.3 or greater) or PHP5
|
- 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
|
|
|
(http://www.php.net/) and either MySQL (http://www.mysql.com/)
|
2006-03-24 18:09:57 +00:00
|
|
|
or PostgreSQL (http://www.postgresql.org/). Your database user
|
2006-04-17 20:48:26 +00:00
|
|
|
will also need sufficient privileges to run Drupal. Please
|
2006-03-24 18:09:57 +00:00
|
|
|
check the INSTALL.mysql.txt and INSTALL.pgsql.txt for more
|
|
|
|
detailed information.
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2006-05-01 09:34:19 +00:00
|
|
|
NOTE: the Apache web server and MySQL database are recommended;
|
2003-06-14 17:47:01 +00:00
|
|
|
other web server and database combinations such as IIS and PostgreSQL
|
2004-05-17 19:35:49 +00:00
|
|
|
are possible but tested to a lesser extent.
|
2003-03-08 12:28:24 +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
|
|
|
OPTIONAL REQUIREMENTS
|
|
|
|
---------------------
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2005-11-25 10:07:49 +00:00
|
|
|
- To use XML-based services such as the Blogger API, Jabber, and RSS
|
2005-01-13 16:15:49 +00:00
|
|
|
syndication, you will need PHP's XML extension. This extension is
|
2006-05-01 09:34:19 +00:00
|
|
|
enabled by default.
|
2003-03-08 12:28:24 +00:00
|
|
|
|
|
|
|
- If you want support for clean URLs, you'll need mod_rewrite and
|
|
|
|
the ability to use local .htaccess files. (More information can
|
|
|
|
be found in the Drupal handbook on drupal.org.)
|
|
|
|
|
|
|
|
INSTALLATION
|
|
|
|
------------
|
|
|
|
|
|
|
|
1. DOWNLOAD DRUPAL
|
|
|
|
|
2003-06-14 17:47:01 +00:00
|
|
|
You can obtain the latest Drupal release from http://drupal.org/.
|
2005-01-13 16:15:49 +00:00
|
|
|
The files are in .tar.gz format and can be extracted using most
|
|
|
|
compression tools. On a typical Unix command line, use:
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2005-04-23 05:07:08 +00:00
|
|
|
wget http://drupal.org/files/projects/drupal-x.x.x.tar.gz
|
2005-04-16 12:05:06 +00:00
|
|
|
tar -zxvf drupal-x.x.x.tar.gz
|
2003-03-08 12:28:24 +00:00
|
|
|
|
|
|
|
This will create a new directory drupal-x.x.x/ containing all
|
2005-01-13 16:15:49 +00:00
|
|
|
Drupal files and directories. Move the contents of that directory
|
2003-06-14 17:47:01 +00:00
|
|
|
into a directory within your web server's document root or your
|
2003-03-08 12:28:24 +00:00
|
|
|
public HTML directory:
|
|
|
|
|
2005-01-13 16:15:49 +00:00
|
|
|
mv drupal-x.x.x/* drupal-x.x.x/.htaccess /var/www/html
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2005-11-25 10:07:49 +00:00
|
|
|
2. CREATE AND PREPARE THE DRUPAL DATABASE
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2005-11-25 10:07:49 +00:00
|
|
|
Before you proceed to the next step you should know:
|
|
|
|
- "username" - the username for connecting to the database
|
|
|
|
- "password" - the password for that username
|
|
|
|
- "databasename" - the name of the database
|
2005-01-13 16:15:49 +00:00
|
|
|
|
2005-11-25 10:07:49 +00:00
|
|
|
Depending on the database of your choice, please read either
|
|
|
|
INSTALL.mysql.txt (for MySQL) or INSTALL.pgsql.txt (for PostgreSQL).
|
2005-11-25 10:11:59 +00:00
|
|
|
|
2005-11-25 10:07:49 +00:00
|
|
|
3. CONNECTING DRUPAL
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2004-11-24 22:44:01 +00:00
|
|
|
The default configuration can be found in the
|
|
|
|
'sites/default/settings.php' file within your Drupal installation.
|
2006-06-01 21:54:48 +00:00
|
|
|
Before you can run Drupal, you must set the database URL. Open the
|
|
|
|
configuration file and edit the $db_url line to match the database
|
2006-05-01 09:34:19 +00:00
|
|
|
defined in the previous step:
|
2005-01-14 15:31:01 +00:00
|
|
|
|
2005-11-25 10:11:59 +00:00
|
|
|
$db_url = "mysql://username:password@localhost/databasename";
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2005-11-25 10:07:49 +00:00
|
|
|
If you use PostgreSQL, change "mysql" to "pgsql" in the above line.
|
2005-11-25 10:11:59 +00:00
|
|
|
|
2004-11-24 22:44:01 +00:00
|
|
|
In addition, a single Drupal installation can host several
|
|
|
|
Drupal-powered sites, each with its own individual 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
|
|
|
If you don't need multiple Drupal sites, skip to the next section.
|
2004-11-24 22:44:01 +00:00
|
|
|
|
|
|
|
Additional site configurations are created in subdirectories within
|
- 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
|
|
|
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/).
|
2004-11-24 22:44:01 +00:00
|
|
|
|
2005-01-13 16:15:49 +00:00
|
|
|
Sites do not each have to have a different domain. You can use
|
|
|
|
subdomains and subdirectories for Drupal sites also. For example,
|
2004-11-24 22:44:01 +00:00
|
|
|
example.com, sub.example.com, and sub.example.com/site3 can all be
|
2005-01-13 16:15:49 +00:00
|
|
|
defined as independent Drupal sites. The setup for a configuration
|
2004-11-24 22:44:01 +00:00
|
|
|
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
|
- 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
|
|
|
files in the following order, using the first configuration it finds:
|
2004-11-24 22:44:01 +00:00
|
|
|
|
|
|
|
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
|
|
|
|
|
2005-11-21 16:24:41 +00:00
|
|
|
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.
|
2005-09-19 19:00:23 +00:00
|
|
|
|
2004-11-24 22:44:01 +00:00
|
|
|
Each site configuration can have its own site-specific modules and
|
|
|
|
themes that will be made available in addition to those installed
|
2005-01-13 16:15:49 +00:00
|
|
|
in the standard 'modules' and 'themes' directories. To use
|
2004-11-24 22:44:01 +00:00
|
|
|
site-specific modules or themes, simply create a 'modules' or
|
2005-01-13 16:15:49 +00:00
|
|
|
'themes' directory within the site configuration directory. For
|
2005-11-25 10:07:49 +00:00
|
|
|
example, if sub.example.com has a custom theme and a custom module
|
2004-11-24 22:44:01 +00:00
|
|
|
that should not be accessible to other sites, the setup would look
|
|
|
|
like this:
|
|
|
|
|
|
|
|
sites/sub.example.com/:
|
|
|
|
settings.php
|
- 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
|
|
|
themes/custom_theme
|
|
|
|
modules/custom_module
|
2004-11-24 22:44:01 +00:00
|
|
|
|
2003-03-08 12:28:24 +00:00
|
|
|
NOTE: for more information about multiple virtual hosts or the
|
|
|
|
configuration settings, consult the Drupal handbook at drupal.org.
|
|
|
|
|
2005-11-25 10:07:49 +00:00
|
|
|
4. CONFIGURE DRUPAL
|
2003-03-08 12:28:24 +00:00
|
|
|
|
- More improvements by Morbus, Goba, TDobes et al:
Per TDobes' comments:
* INSTALL.txt corrected to use 4.3.3, not 4.33.
* .htaccess: removed allow_call_time_pass_reference. two confirmations that a) the setting was wrong in the first place, b) there were no adverse affects for the incorrect setting, c) the PHP docs say it is deprecated.
* .htaccess: removed short_open_tag. Running grep -r "<? " * across the entire directory tree of both core and contributions only brought up contributions and no core. I agree that the fuller form is better. The following contributions will need to be updated: modules/edit_template/edit_template.module, sandbox/garym/themes/marvin_2k/templates/page.tpl.php, sandbox/killes/compare.php, sandbox/paolino/import/click.php, themes/spreadfirefox/block.tpl.php. For error's sake, I also did a manual verification for "<?" (no space) across core and came up against nothing in addition to the above contribs.
Per Goba's comments:
* .htaccess: Moved session.auto_start back.
* sites/default/settings.php: Removed track_vars.
Per mailing list comments:
* INSTALL.txt: Added text about the files/ directory, creating it, and permissions.
* INSTALL.txt: Added an example of why Drupal requires cron (the search.module) in an attempt to justify why a crontab is a good, nay, required step.
And my own further analities:
* .htaccess: cleaned up some whitespace valleys (i hate 'em, hate 'em!) and fixed a few stray colons.
* settings.php: minor whitespace error.
2005-03-15 21:07:49 +00:00
|
|
|
You should 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 > Settings > File system settings".
|
|
|
|
|
2006-06-01 21:54:48 +00:00
|
|
|
SECURITY NOTICE: Certain Apache configurations can be vulnerable
|
|
|
|
to a security exploit allowing arbitrary code execution. Drupal
|
|
|
|
will attempt to automatically create a .htaccess file in your
|
2006-05-26 09:21:10 +00:00
|
|
|
"files" directory to protect you. If you already have a .htaccess
|
2006-06-01 21:54:48 +00:00
|
|
|
file in that location, please add the following lines:
|
|
|
|
|
|
|
|
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
|
|
|
|
Options None
|
|
|
|
<IfModule mod_rewrite.c>
|
|
|
|
RewriteEngine off
|
|
|
|
</IfModule>
|
2006-05-25 01:33:53 +00:00
|
|
|
|
2003-03-08 12:28:24 +00:00
|
|
|
You can now launch your browser and point it to your Drupal site.
|
|
|
|
|
2005-01-13 16:15:49 +00:00
|
|
|
Create an account and login. The first account will automatically
|
- More improvements by Morbus, Goba, TDobes et al:
Per TDobes' comments:
* INSTALL.txt corrected to use 4.3.3, not 4.33.
* .htaccess: removed allow_call_time_pass_reference. two confirmations that a) the setting was wrong in the first place, b) there were no adverse affects for the incorrect setting, c) the PHP docs say it is deprecated.
* .htaccess: removed short_open_tag. Running grep -r "<? " * across the entire directory tree of both core and contributions only brought up contributions and no core. I agree that the fuller form is better. The following contributions will need to be updated: modules/edit_template/edit_template.module, sandbox/garym/themes/marvin_2k/templates/page.tpl.php, sandbox/killes/compare.php, sandbox/paolino/import/click.php, themes/spreadfirefox/block.tpl.php. For error's sake, I also did a manual verification for "<?" (no space) across core and came up against nothing in addition to the above contribs.
Per Goba's comments:
* .htaccess: Moved session.auto_start back.
* sites/default/settings.php: Removed track_vars.
Per mailing list comments:
* INSTALL.txt: Added text about the files/ directory, creating it, and permissions.
* INSTALL.txt: Added an example of why Drupal requires cron (the search.module) in an attempt to justify why a crontab is a good, nay, required step.
And my own further analities:
* .htaccess: cleaned up some whitespace valleys (i hate 'em, hate 'em!) and fixed a few stray colons.
* settings.php: minor whitespace error.
2005-03-15 21:07:49 +00:00
|
|
|
become the main administrator account with total control.
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2005-11-25 10:07:49 +00:00
|
|
|
5. CRON TASKS
|
2003-03-08 12:28:24 +00:00
|
|
|
|
- More improvements by Morbus, Goba, TDobes et al:
Per TDobes' comments:
* INSTALL.txt corrected to use 4.3.3, not 4.33.
* .htaccess: removed allow_call_time_pass_reference. two confirmations that a) the setting was wrong in the first place, b) there were no adverse affects for the incorrect setting, c) the PHP docs say it is deprecated.
* .htaccess: removed short_open_tag. Running grep -r "<? " * across the entire directory tree of both core and contributions only brought up contributions and no core. I agree that the fuller form is better. The following contributions will need to be updated: modules/edit_template/edit_template.module, sandbox/garym/themes/marvin_2k/templates/page.tpl.php, sandbox/killes/compare.php, sandbox/paolino/import/click.php, themes/spreadfirefox/block.tpl.php. For error's sake, I also did a manual verification for "<?" (no space) across core and came up against nothing in addition to the above contribs.
Per Goba's comments:
* .htaccess: Moved session.auto_start back.
* sites/default/settings.php: Removed track_vars.
Per mailing list comments:
* INSTALL.txt: Added text about the files/ directory, creating it, and permissions.
* INSTALL.txt: Added an example of why Drupal requires cron (the search.module) in an attempt to justify why a crontab is a good, nay, required step.
And my own further analities:
* .htaccess: cleaned up some whitespace valleys (i hate 'em, hate 'em!) and fixed a few stray colons.
* settings.php: minor whitespace error.
2005-03-15 21:07:49 +00:00
|
|
|
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.
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2005-01-13 16:15:49 +00:00
|
|
|
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:
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2005-04-01 15:30:35 +00:00
|
|
|
0 * * * * wget -O - -q http://www.example.com/cron.php
|
2003-03-08 12:28:24 +00:00
|
|
|
|
|
|
|
More information about the cron scripts are available in the admin
|
2005-01-13 16:15:49 +00:00
|
|
|
help pages and in the Drupal handbook at drupal.org. Example
|
2003-03-08 12:28:24 +00:00
|
|
|
scripts can be found in the scripts/ directory.
|
|
|
|
|
|
|
|
DRUPAL ADMINISTRATION
|
|
|
|
---------------------
|
|
|
|
|
2003-09-24 08:29:45 +00:00
|
|
|
Upon a new installation, your Drupal website defaults to a very basic
|
2006-05-01 09:34:19 +00:00
|
|
|
configuration with only a few active modules, one theme, and minimal
|
|
|
|
user access rights.
|
2003-09-24 08:29:45 +00:00
|
|
|
|
|
|
|
Use your administration panel to enable and configure services. For
|
- 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
|
|
|
example, set some general settings for your site with "Administer >
|
|
|
|
Settings". Enable modules via "Administer > Modules". User permissions
|
|
|
|
can be set with "Administer > Users > Configure > Permissions".
|
2003-09-24 08:29:45 +00:00
|
|
|
|
2006-06-01 21:54:48 +00:00
|
|
|
For more information on configuration options, read the
|
2003-09-24 08:29:45 +00:00
|
|
|
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/.
|
2003-03-08 12:28:24 +00:00
|
|
|
|
|
|
|
CUSTOMIZING YOUR THEME(S)
|
|
|
|
-------------------------
|
|
|
|
|
|
|
|
Now that your server is running, you will want to customize the look
|
2005-01-13 16:15:49 +00:00
|
|
|
of your site. Several sample themes are included in the Drupal
|
2003-03-08 12:28:24 +00:00
|
|
|
installation and more can be downloaded from drupal.org.
|
|
|
|
|
2006-05-01 09:34:19 +00:00
|
|
|
Simple customization of your theme can be done using only CSS. Further
|
|
|
|
changes require understanding the phptemplate engine that is now part
|
|
|
|
of Drupal. See http://drupal.org/handbook/customization to find out more.
|
2003-03-08 12:28:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
MORE INFORMATION
|
|
|
|
----------------
|
|
|
|
|
|
|
|
For platform specific configuration issues and other installation and
|
|
|
|
administration assistance, please consult the Drupal handbook at
|
2006-05-01 09:34:19 +00:00
|
|
|
http://drupal.org/handbook. You can view the wide range of other
|
|
|
|
support options available at http://drupal.org/support.
|