DrupalGuide
Drupalbeta
I have a customer on the phone and don't know what to check
===== Drupal 6 =====
Drupal Version 6 is the most widely used at the time of this writing, with many customers anticipating a switch to Drupal 7.
Site configuration in Drupal 6
Go to Site Configuration (Administer > Site Configuration). Most options here are pretty self explanatory, but a few important ones to consider are:
* Error reporting
By default all errors are output to the log and screen. When your site is ready for production you should change this to just write errors to the log only.
* Input formats
Input formats are incredibly powerful and often missed configuration step early on. The default for most user accounts is Filtered HTML.
This is a list of tags allowed by normal users to use on your site. There is a very minimal default selection which you can change.
* Performance
During development, caching should be disabled (default). Once the site is ready for production you should set caching to normal.
Experiment with these settings to find what works best for your site.
* Site information
In addition to Site name, which was set during install, you can also add a slogan, mission, and footer. Other options include setting
a name for anonymous users and changing the default front page setting.
* Site maintenance
If you need to take your site offline for any reason, here you can do this and set a message as well. It is useful to know how to log
in once you have turned your site off-line for maintenance.
Drupal caching, speed and performance
For an initial, quick performance tuning, see on your site:
Administer > Site configuration > Performance
Options for page cache, CSS optimization, and (in core since Drupal 6.x) block cache, JavaScript optimization, standard optimization and database caching can be enough for many sites.
If better optimization is required, you might install one or two performance modules. For example, if the site is on a shared server, try Boost (static page caching for non-logged in visitors), complemented with Authcache -in CR's file or db mode- or Advanced Cache (for logged in members). If on a VPS or dedicated server, there are several suitable options: Boost (for example on a low RAM VPS), Authcache, Cache Router (which includes APC, Memcache...), Varnish, etc. Memcache and Varnish are also especially suitable when load-balancing multiple servers.
Managing site performance
Server tuning considerations
Analyzing your site's traffic and resource consumption
You wouldn't use another system administrators underwear. Neither should you use their performance configuration. Each site is unique and must be
tailored to address your sites traffic impact on four resources: bandwidth, CPU, memory, and disk input/output.
Profile your site's performance loading: bandwidth, anonymous page views (general reads), concurrent number of users (unique reads), concurrent
number of user posts (writes) are all important in building your sites profile.
PHP caches
Each time a PHP script is run to generate a webpage with Drupal, your web server must compile the PHP script into an executable format.
This results in an obvious amount of overhead each time a page is generated.
A PHP cache can be installed to save and re-use compiled PHP scripts, thus greatly reducing the amount of overhead required for Drupal to
display a web page. There are a number of PHP caches (aka accelerators) available, including:
* PHP Accelerator * After Burner * Zend Accelerator
Scalability Decision Tree
Here's a scaling tree. As you progress up the tree, you will find that time, money, maintenance, headaches will all increase.
This guide assumes that you have multiple fast and beefy Web and DB servers.
1. Enable MySQL Query Cache
2. Use a PHP cache
I found that using APC speeds up Drupal by a lot, 3 to 5 times the pages view per second. This was _literally_ a 5 minute install
(on FreeBSD) for a 300% to 500% performance improvement. I think at that point it was my dev servers SATA HDDs were the bottle neck.
It sits beside me and when I hit it with ab, I can hear the HDDs wrrrrr like crazy.
3. Use mod_gzip (or ob_compress or whatever it is in php, I prefer mod_gzip, or mod_deflate in Apache2)
The benefits of this are amazing, considering the minimal effort it takes to implement. If doesn't matter if it takes Drupal 0.002
seconds to generate a 40K of html, if it takes like 1 to 2 seconds for a client to download it (more if using a modem). mod_gzip
usually gives a 10% to 80% compression depending on the size of pages. Amazing results for 10 minutes of work.
To enable this feature, put the following code in your .htaccess file, if you are running with Apache 2 and mod_deflate enabled
# Enable file compression by MIME type
AddOutputFilterByType DEFLATE text/* application/javascript application/x-javascript application/rss+xml application/xml
4. Get a load balancer, or a reverse HTTP proxy (squid) to distribute the load
5. Use Memcache for storing Cache and Session tables
6. Do MySQL replication
7. Use a module to convert Drupal pages into Static Pages i.e. Boost
File system settings
http://drupal.org/node/15368
Drupal provides configuration settings to control whether, and how, users and administrators can upload files for use by Drupal.
The setup page for File system path or Directory and Download method can be accessed by going to:
Administer > Site configuration > File system
system path: http://example.com/admin/settings/file-system
The default Drupal setting for the File system path is sites/default/files. When you run across a text box in Drupal for specifying a
directory to store files, generally the root is sites/default/files. It is good to have all files going to the files directory or directories
within the files directory. Having your files in one place will make backups easier to accomplish.
The default Drupal Temporary directory is /tmp. This is where uploaded files will be stored during previews before saving.
The default Drupal Download method is Public - files are available using HTTP directly.
Note: Un-configured or improperly configured Drupal installations may display one or more error messages at the top of the
File system settings page, indicating that either the "Temporary directory" or "File system path" directories do not exist
and/or their permissions are not set properly. Simply create these directories and set their permissions so that Drupal can
write and read from the directory.
Drupal creates these directories for you in most cases. Generally you can create directories using FTP(file transfer protocol)
software such as Filezilla. To create a directory, connect to your server with FTP, navigate to the location needed, right click,
choose 'create directory' and give it a name. To set permissions for the directory, right click the directory and choose file permissions or properties.
System: cron and caching
The system module provides system-wide defaults for running jobs at particular times, storing (caching) web pages to improve efficiency, and performing other essential tasks. The module also keeps track of various preferences you give for how you want your system to behave.
Some of Drupal's modules require regularly scheduled actions. The statistics module periodically cleans up logfiles. The aggregator module periodically updates feeds.
In Drupal 6.x and earlier Ping periodically notifies services of new content on your site. In Drupal 6.x and later Update module checks for updates on the modules and
themes used in your site. Search periodically indexes your site's content. All of these services rely on cron.
Cron is not a part of Drupal 6.x and earlier. It's a scheduler that resides on your server and performs tasks (called "cron jobs") at intervals, which you specify. The jobs can run weekly, daily, hourly, or whatever you like. Drupal 7.x includes functionality to run cron from within Drupal itself but for performance reasons it's recommended to use the servers cron when possible
What you want to do is schedule a "cron job" that has a browser on your server regularly visit your "cron page." For instance, if your site were www.example.com your cron page would be http://www.example.com/cron.php. (This page is automatically set up for you when you install Drupal.) This regular visit to your cron page will help keep your system running smoothly.
For a modest personal site to which you post now and then, you might set up such a cron job to run once a day. For a more active site you'd likely want to run that job more often--perhaps every few hours or every hour.
With Linux or Unix you can schedule your cron jobs by setting up what's called a "crontab." (You might rely on helper programs like C-Panel to make setting up your cron jobs easier.)
For further guidance you can see Drupal's handbook page configuring cron jobs (or, if your server is running Windows, configuring Windows cron jobs). Your hosting company may also help guide you.
The system module's caching mechanism stores dynamically generated web pages in a cache--a stockpile--and reuses them. The pages on your site, rather than being never-changing sets of text and images, are all (or nearly all) likely to use elements pulled together "on the fly" from various parts of your database. Such pages are said to be "dynamically generated."
By caching such pages, the system module keeps them ready to use again, instead of having to create them again each time someone wants to view them. This way, displaying a page takes only one database query instead of several. Queries take time and system power, so caching lightens the load on your system and lets it respond more quickly.
Only pages requested by anonymous users are cached. To reduce server load and save bandwidth, the system module stores and sends cached pages compressed.
You can
* run your cron job manually at your site's cron page. Find links to both your cron.php and a cron inside Drupal in your Status report under Administer > Reports > Status Report * read about configuring cron jobs. * administer cache settings in Administer > Site configuration > Performance
Versions & Upgrading
http://drupal.org/documentation/upgrade/6/7 A number of customers are anticipating the release of Drupal 7; many are likely to want to upgrade.
Upgrading your Drupal installation
The process of upgrading to the latest version of Drupal can vary in difficulty depending on the complexity of your current installation. You can only upgrade from one version to the next version. For example you are trying to move from Drupal 5 to Drupal 7 you first need to upgrade to Drupal 6 before you upgrade to Drupal 7.
Pre-Upgrade Site Preparation
Backup Your Current Site
It is always highly recommended to backup your site before any update or upgrade.
A full backup consists of making copies of:
* all core Drupal files and folders * all contributed module files and folders * all contributed theme files and folders * all other files and assets that have been uploaded via your Drupal site (e.g. /files folder) * the Drupal database
For more information about backing up your Drupal site see http://drupal.org/node/22281
Update Your Site to the Latest Stable Release of Drupal 6.x
It is important for your current site to be updated to the latest stable release of Drupal 6.x prior to upgrade because point releases sometimes introduce
minor database schema changes. These changes will be expected to be in place by Drupal 7 when you upgrade.
For detailed information about updating your Drupal 6.x site see http://drupal.org/node/390448
Update Contributed Modules as Required
As part of the upgrade planning process you will have researched whether modules currently installed on your site will be available for Drupal 7.x.
Each module will have a slightly different upgrade path to a corresponding Drupal 7 version. In many cases you will be required to update the modules
on your site to their latest versions for Drupal 6.
Visit the project page for each of module installed on your site for instructions on how to update to the latest version. If you have the Update Status
module installed, it will provide you with links to the project page of each of your installed modules and can help you identify whether you have
completed all the required updates.
Upgrade Process
http://drupal.org/node/570162
About This Article
* Drupal version: Drupal 7.x * Page status: Needs updating * Last modified: January 20, 2011
Note: DO NOT run install.php at any time during an upgrade. It will empty your content from the database. Upgrade Steps
1. Backup your existing site and database.
2. Login as user 1.
3. # Place the site in "off-line" mode (Administer >> Site configuration >> Site maintenance).
4. Switch your site's theme to a default theme (Garland).
5. Disable all custom and contributed modules.
6. Remove the Drupal 6 files in the folder or subfolder on your computer
7. Copy the Drupal 7 files into the folder or subfolder on your computer
8. Re-Configure Your Installation
Copy your backed up "files" and "sites" directories to the Drupal
installation directory. If other system files such as .htaccess or
robots.txt were customized, re-create the modifications in the new
versions of the files using the backups taken in step #1.
quoted from upgrade.txt file
10. Empty your 'sites' folder
11. Run update.php (DO NOT RUN INSTALL.PHP). Point the browser to http://example.com/update.php
12. Running update.php at this time makes the necessary database changes to Drupal 7. Your contributed modules are not yet upgraded
13. Copy the Drupal 7 contributed modules and themes to your 'sites/all/modules' or 'sites/all/themes' folders as needed
14. Copy customized modules and themes in the correct place 'sites/all/modules' or 'sites/all/themes
15. Go to Administer → Sites Building → Modules and re-enable the modules
16. Re-Run update.php (DO NOT RUN INSTALL.PHP). Point the browser to http:// yourdomain/update.php
17. Running update.php at this time makes the database table updates needed by the modules
18. Re-activate your theme
Drupal 6 Modules Integrated into Drupal 7 Core
Below is a list of Drupal 6 contributed modules whose functionality now exists wholly or partially in Drupal 7 core. Modules that can be uninstalled from your D6 site prior to upgrade The functionality of these modules is in D7 core, and no major data migration needs to be performed. When upgrading from D6 to D7, you can remove the contributed D6 version from your 'sites' folder. After the upgrade, you may need to reconfigure your D7 settings to reestablish the preferences you had in your D6 site (For some modules with potentially large amounts of settings, we are enquiring with module maintainers on possibility of upgrade path).
* 404 Blocks * Absolute src * Admin:hover * Admin Role * Archive::Tar * AHAH helper * Autoload * Auto Menu Title * AutomaticMenu * Auto Menu * Block edit * Block Node Visibility * Canonical URL * Checkbox Validate * Comment Display * DBTNG * Documentation * Drupal Queue * Edit term * Elements * Element theme hook * File API * Filter Default * Image API * Image Cache * Image Field * Input Format Permissions * jQ * jQuery Cookie * jQuery Form Update * jQuery Plugin Handler (JQP) * jQuery plugin manager * jQuery UI * JS Alter * Login Security * Menuless Node Type * Menu Settings per Content Type * Node Preview by Content type * Parallel * Permissions API * Plugin Manager * Poor man's cron * Preview * RDF * Secure Password Hashes (phpass) * Shortlink * Simple CDN * Simpletest * Site Configuration Permissions * Storage API * Taxidermy * TinyMCE AHAH Integration * TinyMCE Drag and Drop Integration * Transaction * Upload element * Upload preview * URL alter * User Cancellation * User Default Filter * User Delete * Vertical Tabs * View unpublished * Vocabulary Permissions * Wysiwyg API CCK Integration
Drupal 6 Modules Requiring Data Migration
During core upgrade, you can leave the D6 module where it is. Before migrating data, you should first go through all the upgrade steps for core as described in your UPGRADE.txt, and then install the D7 contrib modules that will handle the migration.
* Content Construction Kit (CCK)
- There is a D7 contrib module to handle miscellaneous field functions - it includes the Content Migrate submodule to handle D6->D7 data migration.
Node and user references have been split off into theReferences module. Content permissions, fieldgroups and content copy will be hived off into their
own separate modules.
* Content Taxonomy - - Will need to migrate data: on the module page it says there will be an upgrade path provided.
* Date Timezone - This is a submodule of the Date module. Replacing the D6 version of the date module with the D7 version and performing any required
upgrades for that module will suffice here.
* Field Taxonomy - Will need to migrate data: so far, no indication on the module page of an upgrade path.
* Filefield/Imagefield - A preliminary version of an upgrade path is provided in the Content Migrate submodule of cck (see above).
* Image - the image nodes will need to be migrated to FieldAPI using Field Converter module. Some functionality (e.g. import) will still exist in
contrib in seperate modules.
* Taxonomy Delegate - may need to migrate delegation: so far, no indication on the module page of an upgrade path, although they are following D7 progress.
* Taxonomy Intro
- Will need to migrate introduction field: so far, no indication on the module page of an upgrade path.
* Term fields - Will need to migrate data: so far, no indication on the module page of an upgrade path.