drupal/core/INSTALL.txt

411 lines
18 KiB
Plaintext
Raw Normal View History

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 and notes
* Optional server requirements
- 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
* Installation
* Reinstall
* Building and customizing your site
* Multisite configuration
* Multilingual 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
REQUIREMENTS AND NOTES
----------------------
Drupal requires:
- A web server with PHP support, for example:
- Apache 2.0 (or greater) (http://httpd.apache.org/).
- Nginx 1.1 (or greater) (http://nginx.com/).
- PHP 5.4.5 (or greater) (http://php.net/). For better security support it is
recommended to update to at least 5.5.21 or 5.6.5.
- One of the following databases:
- MySQL 5.5.3 (or greater) (http://www.mysql.com/).
- MariaDB 5.5.20 (or greater) (https://mariadb.org/). MariaDB is a fully
compatible drop-in replacement for MySQL.
- Percona Server 5.5.8 (or greater) (http://www.percona.com/). Percona
Server is a backwards-compatible replacement for MySQL.
- PostgreSQL 8.3 (or greater) (http://www.postgresql.org/).
- SQLite 3.4.2 (or greater) (http://www.sqlite.org/).
For more detailed information about Drupal requirements, including a list of
PHP extensions and configurations that are required, see "System requirements"
(https://www.drupal.org/requirements) in the Drupal.org online documentation.
For detailed information on how to configure a test server environment using a
variety of operating systems and web servers, see "Local server setup"
(https://www.drupal.org/node/157602) in the Drupal.org online documentation.
Note that all directories mentioned in this document are always relative to the
directory of your Drupal installation, and commands are meant to be run from
this directory (except for the initial commands that create that directory).
OPTIONAL SERVER REQUIREMENTS
----------------------------
- If you want to use Drupal's "Clean URLs" feature on an Apache web server, you
will need the mod_rewrite module and the ability to use local .htaccess
files. For Clean URLs support on IIS, see "Clean URLs with IIS"
(https://www.drupal.org/node/3854) in the Drupal.org online documentation.
- If you plan to use XML-based services such as RSS aggregation, you will need
PHP's XML extension. This extension is enabled by default on most PHP
installations.
- To serve gzip compressed CSS and JS files on an Apache web server, you will
need the mod_headers module and the ability to use local .htaccess files.
- Some Drupal functionality (e.g., checking whether Drupal and contributed
modules need updates, RSS aggregation, etc.) require that the web server be
able to go out to the web and download information. If you want to use this
functionality, you need to verify that your hosting provider or server
configuration allows the web server to initiate outbound connections. Most web
hosting setups allow this.
- PHP 5.5.21 provides features for improved security when used with MySQL. While
this is not required, it is highly encouraged to use PHP 5.5.21 or 5.6.5 and
above.
INSTALLATION
------------
1. Download and extract Drupal.
You can obtain the latest Drupal release from https://www.drupal.org -- the
files are available in .tar.gz and .zip formats and can be extracted using
most compression tools.
To download and extract the files, on a typical Unix/Linux command line, use
the following commands (assuming you want version x.y.z of Drupal in .tar.gz
format):
wget https://www.drupal.org/files/projects/drupal-x.y.z.tar.gz
tar -zxvf drupal-x.y.z.tar.gz
This will create a new directory drupal-x.y.z/ containing all Drupal files
and directories. Then, to move the contents of that directory into a
directory within your web server's document root or your public HTML
directory, continue with this command:
mv drupal-x.y.z/* drupal-x.y.z/.htaccess drupal-x.y.z/.csslintrc drupal-x.y.z/.editorconfig drupal-x.y.z/.eslintignore drupal-x.y.z/.eslintrc /path/to/your/installation
2. Create the Drupal database.
Because Drupal stores all site information in a database, the Drupal
installer will attempt to create this database for you. If you create the
database manually, you must grant Drupal certain database privileges (such as
the ability to create tables). For details, consult INSTALL.mysql.txt,
INSTALL.pgsql.txt, or INSTALL.sqlite.txt. You may also need to consult your
web hosting provider for instructions specific to your web host.
Take note of the username, password, database name, and hostname as you
create the database. You will enter this information during the install.
3. Run the install script.
To run the install script, point your browser to the base URL of your
website (e.g., http://www.example.com).
You will be guided through several screens to set up the database, add the
site maintenance account (the first user, also known as user/1), and provide
basic web site settings.
During installation, several files and directories need to be created, which
the install script will try to do automatically. However, on some hosting
environments, manual steps are required, and the install script will tell
you that it cannot proceed until you fix certain issues. This is normal and
does not indicate a problem with your server.
The most common steps you may need to perform are:
a. Missing files directory.
The install script will attempt to create a file storage directory in
the default location at sites/default/files (the location of the files
directory may be changed after Drupal is installed).
If auto-creation fails, you can make it work by changing permissions on
the sites/default directory so that the web server can create the files
directory within it for you. (If you are creating a multisite
installation, substitute the correct sites directory for sites/default;
see the Multisite Configuration section of this file, below.)
For example, on a Unix/Linux command line, you can grant everyone
(including the web server) permission to write to the sites/default
directory with this command:
chmod a+w sites/default
Be sure to set the permissions back after the installation is finished!
Sample command:
chmod go-w sites/default
Alternatively, instead of allowing the web server to create the files
directory for you as described above, you can create it yourself. Sample
commands from a Unix/Linux command line:
mkdir sites/default/files
chmod a+w sites/default/files
b. Missing settings file.
Drupal will try to automatically create settings.php and services.yml
files, which are normally in the directory sites/default (to avoid
problems when upgrading, Drupal is not packaged with this file). If
auto-creation of either file fails, you will need to create the file
yourself. Use the template sites/default/default.settings.php or
sites/default/default.services.yml respectively.
For example, on a Unix/Linux command line, you can make a copy of the
default.settings.php and default.services.yml files with the commands:
cp sites/default/default.settings.php sites/default/settings.php
cp sites/default/default.services.yml sites/default/services.yml
Next, grant write privileges to the file to everyone (including the web
server) with the command:
chmod a+w sites/default/settings.php
chmod a+w sites/default/services.yml
Be sure to set the permissions back after the installation is finished!
Sample command:
chmod go-w sites/default/settings.php
chmod go-w sites/default/services.yml
c. Write permissions after install.
The install script will attempt to write-protect the settings.php file and
the sites/default directory after saving your configuration. If this
fails, you will be notified, and you can do it manually. Sample commands
from a Unix/Linux command line:
chmod go-w sites/default/settings.php
chmod go-w sites/default/services.yml
chmod go-w sites/default
4. Verify that the site is working.
When the install script finishes, you will be logged in with the site
maintenance account on a "Welcome" page. If the default Drupal theme is not
displaying properly and links on the page result in "Page Not Found" errors,
you may be experiencing problems with clean URLs. Visit
https://www.drupal.org/getting-started/clean-urls to troubleshoot.
5. Change file system storage settings (optional).
The files directory created in step 4 is the default file system path used to
store all uploaded files, as well as some temporary files created by
Drupal. After installation, you can modify the file system path to store
uploaded files in a different location.
It is not necessary to modify this path, but you may wish to change it if:
- Your site runs multiple Drupal installations from a single codebase (modify
the file system path of each installation to a different directory so that
uploads do not overlap between installations).
- Your site runs on a number of web servers behind a load balancer or reverse
proxy (modify the file system path on each server to point to a shared file
repository).
- You want to restrict access to uploaded files.
To modify the file system path:
a. Ensure that the new location for the path exists and is writable by the
web server. For example, to create a new directory named uploads and grant
write permissions, use the following commands on a Unix/Linux command
line:
mkdir uploads
chmod a+w uploads
b. Navigate to Administration > Configuration > Media > File system, and
enter the desired path. Note that if you want to use private file storage,
you need to first enter the path for private files and save the
configuration, and then change the "Default download method" setting and
save again.
Changing the file system path after files have been uploaded may cause
unexpected problems on an existing site. If you modify the file system path
on an existing site, remember to copy all files from the original location
to the new location.
6. Revoke documentation file permissions (optional).
Some administrators suggest making the documentation files, especially
CHANGELOG.txt, non-readable so that the exact version of Drupal you are
running is slightly more difficult to determine. If you wish to implement
this optional security measure, from a Unix/Linux command line you can use
the following command:
chmod a-r CHANGELOG.txt
Note that the example only affects CHANGELOG.txt. To completely hide all
documentation files from public view, repeat this command for each of the
Drupal documentation files in the installation directory, substituting the
name of each file for CHANGELOG.txt in the example.
For more information on setting file permissions, see "Modifying Linux,
Unix, and Mac file permissions" (https://www.drupal.org/node/202483) or
"Modifying Windows file permissions" (https://www.drupal.org/node/202491) in
the Drupal.org online documentation.
7. Set up independent "cron" maintenance jobs.
Many Drupal modules have tasks that must be run periodically, including the
Search module (building and updating the index used for keyword searching),
the Aggregator module (retrieving feeds from other sites), and the System
module (performing routine maintenance and pruning of database tables). These
tasks are known as "cron maintenance tasks", named after the Unix/Linux
"cron" utility.
When you install Drupal, its built-in cron feature is enabled, which
automatically runs the cron tasks periodically, triggered by people visiting
pages of your site. You can configure the built-in cron feature by navigating
to Administration > Configuration > System > Cron.
It is also possible to run the cron tasks independent of site visits; this is
recommended for most sites. To do this, you will need to set up an automated
process to visit the page /cron on your site, which executes the cron
tasks.
The URL of the cron page requires a "cron key" to protect against
unauthorized access. Your site's cron key is automatically generated during
installation and is specific to your site. The full URL of the page, with the
cron key, is available in the "Cron maintenance tasks" section of the Status
report page at Administration > Reports > Status report.
As an example for how to set up this automated process, you can use the
crontab utility on Unix/Linux systems. The following crontab line uses the
wget command to visit the cron page, and runs each hour, on the hour:
0 * * * * wget -O - -q -t 1 http://example.com/cron/YOURKEY
Replace the text "http://example.com/cron/YOURKEY" in the example with the
full URL displayed under "Cron maintenance tasks" on the "Status report"
page.
More information about cron maintenance tasks is available at
https://www.drupal.org/cron, and sample cron shell scripts can be found in
the core/scripts/ directory. (Note that these scripts must be customized like
the above example, to add your site-specific cron key and domain name.)
REINSTALL
------------
Drupal can be reinstalled without downloading and extracting the Drupal release.
1. Drop all the tables in your database.
2. Remove everything in sites/default/files.
3. Remove sites/default/settings.php.
4. Follow the Installation Instructions above starting from Step 3 (Run the
install script).
BUILDING AND CUSTOMIZING YOUR SITE
----------------------------------
A new installation of Drupal defaults to a very basic configuration. To extend
your site, you use "modules" and "themes". A module is a plugin that adds
functionality to Drupal, while a theme changes the look of your site. The core
of Drupal provides several optional modules and themes, and you can download
more at https://www.drupal.org/project/project_module and
https://www.drupal.org/project/project_theme
Do not mix downloaded or custom modules and themes with Drupal's core modules
and themes. Drupal's modules and themes are located in the /core/modules and
/core/themes directories, while the modules and themes you add to Drupal are
normally placed in the /modules and /themes directories. If you run a multisite
installation, you can also place modules and themes in the site-specific
directories -- see the Multisite Configuration section, below.
Never edit Drupal's core modules and themes; instead, use the hooks available in
the Drupal API. To modify the behavior of Drupal, develop a module as described
at https://www.drupal.org/developing/modules. To modify the look of Drupal,
create a subtheme as described at https://www.drupal.org/node/2165673, or a
completely new theme as described at https://www.drupal.org/documentation/theme
MULTISITE CONFIGURATION
-----------------------
A single Drupal installation can host several Drupal-powered sites, each with
its own individual configuration.
For this to work you need the file sites/sites.php to exist. Make a copy of
the example.sites.php file:
$ cp sites/example.sites.php sites/sites.php
Additional site configurations are created in subdirectories within the 'sites'
directory. Each subdirectory must have a 'settings.php' file, which specifies
the configuration settings. The easiest way to create additional sites is to
copy file 'default.settings.php' from the 'sites/default' directory into the
new site directory with file name 'settings.php' and modify 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/).
$ cp sites/default/defaults.settings.php sites/example.com/settings.php
Sites do not have to have a different domain. You can also use subdomains and
subdirectories for Drupal sites. For example, example.com, sub.example.com, and
sub.example.com/site3 can all be defined as independent Drupal sites. The setup
for a configuration such as this would look like the following:
sites/default/settings.php
sites/example.com/settings.php
sites/sub.example.com/settings.php
sites/sub.example.com.site3/settings.php
When searching for a site configuration (for example www.sub.example.com/site3),
Drupal will search for configuration files in the following order, using the
first configuration it finds:
sites/www.sub.example.com.site3/settings.php
sites/sub.example.com.site3/settings.php
sites/example.com.site3/settings.php
sites/www.sub.example.com/settings.php
sites/sub.example.com/settings.php
sites/example.com/settings.php
sites/default/settings.php
If you are installing on a non-standard port, the port number is treated as the
deepest subdomain. For example: http://www.example.com:8080/ could be loaded
from sites/8080.www.example.com/. The port number will be removed according to
the pattern above if no port-specific configuration is found, just like a real
subdomain.
Each site configuration can have its own site-specific modules and themes in
addition to those installed in the standard 'modules' and 'themes' directories.
To use site-specific modules or themes, simply create a 'modules' or 'themes'
directory within the site configuration directory. For example, if
sub.example.com has a custom theme and a custom module that should not be
accessible to other sites, the setup would look like this:
sites/sub.example.com/
settings.php
themes/custom_theme
modules/custom_module
For more information about multiple virtual hosts or the configuration
settings, consult https://www.drupal.org/documentation/install/multi-site
For more information on configuring Drupal's file system path in a multisite
configuration, see step 6 above.
MULTILINGUAL CONFIGURATION
--------------------------
By default, Drupal is installed in one language, and further languages may be
installed later.
For detailed instructions, visit
https://www.drupal.org/documentation/multilingual