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)
|
|
|
|
* Upgrading
|
|
|
|
* 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/)
|
|
|
|
or PostgreSQL (http://www.postgresql.org/).
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2005-04-01 15:30:35 +00:00
|
|
|
NOTE: the Apache web server and MySQL database are strongly 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
|
|
|
|
|
|
|
- To use XML-based services such as the Blogger API, Jabber, RSS
|
2005-01-13 16:15:49 +00:00
|
|
|
syndication, you will need PHP's XML extension. This extension is
|
2003-03-08 12:28:24 +00:00
|
|
|
enabled by default in standard PHP4 installations.
|
|
|
|
|
|
|
|
- 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-01-13 16:15:49 +00:00
|
|
|
wget http://drupal.org/files/project/drupal-x.x.x.tgz
|
|
|
|
tar -zxvf drupal-x.x.x.tgz
|
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
|
|
|
|
|
|
|
2. CREATE THE DRUPAL DATABASE
|
|
|
|
|
2005-01-13 16:15:49 +00:00
|
|
|
This step is only necessary if you don't already have a database
|
- 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
|
|
|
set-up (e.g. by your host). If you control your databases through a
|
|
|
|
web-based control panel, check its documentation for creating databases,
|
|
|
|
as the following instructions are for the command-line only.
|
2005-01-13 16:15:49 +00:00
|
|
|
|
|
|
|
These instructions are for MySQL. If you are using another database,
|
|
|
|
check the database documentation. In the following examples,
|
- 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
|
|
|
'dba_user' is an example MySQL user which has the CREATE and GRANT
|
|
|
|
privileges. Use the appropriate user name for your system.
|
2003-06-14 17:47:01 +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
|
|
|
First, you must create a new database for your Drupal site
|
|
|
|
(here, 'drupal' is the name of the new database):
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2005-01-13 16:15:49 +00:00
|
|
|
mysqladmin -u dba_user -p create drupal
|
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
|
|
|
MySQL will prompt for the 'dba_user' database password and then create
|
2005-01-13 16:15:49 +00:00
|
|
|
the initial database files. Next you must login and set the access
|
2003-03-08 12:28:24 +00:00
|
|
|
database rights:
|
|
|
|
|
2005-01-13 16:15:49 +00:00
|
|
|
mysql -u dba_user -p
|
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
|
|
|
Again, you will be asked for the 'dba_user' database password.
|
|
|
|
At the MySQL prompt, enter following command:
|
2003-03-08 12:28:24 +00:00
|
|
|
|
|
|
|
GRANT ALL PRIVILEGES ON drupal.*
|
2003-06-14 17:47:01 +00:00
|
|
|
TO nobody@localhost IDENTIFIED BY 'password';
|
2003-03-08 12:28:24 +00:00
|
|
|
|
|
|
|
where
|
|
|
|
|
|
|
|
'drupal' is the name of your database
|
2005-04-14 18:34:31 +00:00
|
|
|
'nobody@localhost' is the username of your webserver MySQL account
|
2003-06-14 17:47:01 +00:00
|
|
|
'password' is the password required to log in as the MySQL user
|
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
|
|
|
If successful, MySQL will reply with:
|
2003-03-08 12:28:24 +00:00
|
|
|
|
|
|
|
Query OK, 0 rows affected
|
|
|
|
|
- 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
|
|
|
To activate the new permissions you must enter the command:
|
2003-03-08 12:28:24 +00:00
|
|
|
|
|
|
|
flush privileges;
|
|
|
|
|
|
|
|
and then enter '\q' to exit MySQL.
|
|
|
|
|
|
|
|
3. LOAD THE DRUPAL DATABASE SCHEME
|
|
|
|
|
- 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
|
|
|
Once you have a database, you must load the required tables into it.
|
2005-01-13 16:15:49 +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
|
|
|
If you use a web-based control panel, you should be able
|
|
|
|
to upload the file 'database.mysql' from Drupal's 'database'
|
2005-01-13 16:15:49 +00:00
|
|
|
directory and run it directly as SQL commands.
|
|
|
|
|
- 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
|
|
|
From the command line, use (again, replacing 'nobody' and
|
2005-04-14 18:34:31 +00:00
|
|
|
'drupal' with your MySQL username and name of your database):
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2005-01-13 16:15:49 +00:00
|
|
|
mysql -u nobody -p drupal < database/database.mysql
|
2003-03-08 12:28:24 +00:00
|
|
|
|
|
|
|
4. CONNECTING DRUPAL
|
|
|
|
|
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.
|
2003-06-14 17:47:01 +00:00
|
|
|
Before you can run Drupal, you must set the database URL and the
|
2005-01-13 16:15:49 +00:00
|
|
|
base URL to the web site. Open the configuration file and edit the
|
2003-06-14 17:47:01 +00:00
|
|
|
$db_url line to match the database defined in the previous steps:
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2005-04-14 18:34:31 +00:00
|
|
|
$db_url = "mysql://username:password@localhost/database";
|
2005-01-14 15:31:01 +00:00
|
|
|
|
2005-04-14 18:34:31 +00:00
|
|
|
where 'username', 'password', 'localhost' and 'database' are the
|
2005-01-13 16:15:49 +00:00
|
|
|
username, password, host and database name for your set up.
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2005-01-13 16:15:49 +00:00
|
|
|
Set $base_url to match the address to your Drupal site:
|
2003-06-14 17:47:01 +00:00
|
|
|
|
2004-01-14 06:28:59 +00:00
|
|
|
$base_url = "http://www.example.com";
|
2003-03-08 12:28:24 +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
|
|
|
|
|
|
|
|
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
|
2004-11-24 22:44:01 +00:00
|
|
|
example, if sub.example.dom 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
|
- 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.
|
|
|
|
|
|
|
|
5. CONFIGURE DRUPAL
|
|
|
|
|
- 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".
|
|
|
|
|
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
|
|
|
|
|
|
|
6. CRON TASKS
|
|
|
|
|
- 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
|
|
|
|
configuration with only a few active modules, one theme, and no user
|
|
|
|
access rights.
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
For more information on configuration options, read through 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/.
|
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.
|
|
|
|
|
- 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
|
|
|
Customizing each theme depends on the theme engine. In general, each theme
|
2003-03-08 12:28:24 +00:00
|
|
|
contains a PHP file themename.theme which defines a function header()
|
|
|
|
that can be changed to reference your own logos.
|
|
|
|
|
2005-01-23 22:51:17 +00:00
|
|
|
Most themes also contain stylesheets to tune the colors and layouts;
|
- 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
|
|
|
check the themes/ directory for READMEs describing each alternate theme.
|
2003-03-08 12:28:24 +00:00
|
|
|
|
2004-01-14 06:28:59 +00:00
|
|
|
UPGRADING
|
|
|
|
---------
|
|
|
|
|
|
|
|
1. Backup your database and Drupal directory - especially your
|
- 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
|
|
|
configuration file in 'sites/default/settings.php'.
|
2004-01-14 06:28:59 +00:00
|
|
|
|
|
|
|
2. Log on as the user with user ID 1.
|
|
|
|
|
- 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
|
|
|
3. Remove all the old Drupal files then unpack the new Drupal
|
|
|
|
files into the directory that you run Drupal from.
|
2004-01-14 06:28:59 +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
|
|
|
4. Modify the new configuration file to make sure
|
|
|
|
it has the latest and correct information.
|
2004-01-14 06:28:59 +00:00
|
|
|
|
|
|
|
5. Run update.php by visiting http://www.example.com/update.php.
|
|
|
|
|
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
|
2005-01-13 16:15:49 +00:00
|
|
|
http://drupal.org/. You can also find support at the Drupal support
|
2003-06-14 17:47:01 +00:00
|
|
|
forum or through the Drupal mailing lists.
|
2001-01-13 17:16:05 +00:00
|
|
|
|