Maintaining Your Drupal Site ( Drupal 6 Introduction - Part 5)

/*--- holy mAcar00ns!! --- */

Quick and dirty notes for:

BUILDING ONLINE COMMUNITIES WITH DRUPAL, PHPBB, AND WORDPRESS, 2006 Douglass et al.
==================================================================================

Chapter 6 - Maintaining Your Site
==================================
cron program runs on unix-based machines -- so maybe that's why we can't get it to work in windows

we can run it manually just fine. but it hink actually scheduling it is probalby n ot possible in windows.

http://localhost/drupal/cron.php

that will run cron, because cron.php is in the root directory

basically you could run it manually without logging in apprenty. but the page doesn't reutrn anything ecept an empty page.

you MUST run chron periodically.

core modules rely on chron:
- aggregator
- drupal
- node
- pint
- poll
- search
- statistics
- watchdog

cron.php is publicly accessible and can be called, but it doesn' resul tin server overload because individual stuff is scheduled according to their own schedule. each task has its own schedule. only the first call ro cron.php will make all scheduled tasks run.

still if you want you can disable it from publicly accessibley by adding a driective to httpd.conf file see p187

when figuring how often, use he lowest frequency possible, yo can only do this if you know how often each scheduled task needs to run.

Poormanscron module -- will call cron based on site visitors, so depends on having visitors regulary

You need to call cron.php using soimeting like wget, lynx, curl, etc

just as we had done in media temple.

importnat to allow web server to handle request because it gives more information. dont' use php command line he says

There are two options for running CGI scripts with a cron:

1. You can execute a HTTP client via a cron job, and have it retrieve the URL of the cron script. Thus, the request is processed as if the cron script is opened in a browser. For example:

wget -O /dev/null http://yourdomain.com/your/cron-script.php 2>/dev/null

If you want to get verbose output of the cron execution, use:

wget -O - http://yourdomain.com/your/cron-script.php

2. You can run the script directly from the command line. For this to work, you have to invoke it with the php interpreter, like this:

/usr/bin/php -q /home/USERNAME/public_html/your/cron-script.php

Make sure you substitute USERNAME with your cPanel login name. Also, note that everything in this line is case sensitive.


so the example in the book is:

30 * * * /usr/bin/wget -q -0 /dev/null http://www.example.com/cron.php

it uses wget and discards the output. you have t put that into the crontab file. in linux,
crontab -e

that opens up the file and you just append that line and you're set.

mediatemple divorces us from that which is sort of unfortunate. and we have a limited number of cron jobs we can run in mediatemple.


ther eare cron for windows options:
http://cronw.sourceforge.net/
http://www.visualcron.com/
http://sourceforge.net/projects/pycron/

You can also try using windows task scheduler
http://drupal.org/node/31506


Running Multiple Drupal Sites
-------------------------
very interesting because you can have one drupal installation and run muiltlipe sites with it. that's hte idea behind having a sites folder where you store themes and modules, because for each site you have you can have a directory there. while also sharing the core drupal, which is very useful becuase otherwise you would have to update and manage many instances of drupal.


so your difft domains have to reoslve to the same documen troot. you can do it with apache and virtual hosts. so tha's what VH is about?

hosting companies use terms like ALIASED DOMAINS and PARKED DOMAINS to describe this configuration.

so i guess this is partially at least what MT has in mind. i think they use the term aliased domains

if your sites get sent to the sam document root, then you just need to configure drupal to load the configuration file.

virutal hosts or vhosts is what this is all about. confiruing apache to direct multiple domains to the same document root.

so the apache httpd.conf file is where it happens apaprently. where you set up vhosts.

example:

#subsitite your IP address
NameVirtualHost 111.22.33.444


DocumentRoot /absolute/path/to/drupal
ServerName yoursite.com



DocumentRoot /absolute/path/to/drupal
ServerName secondsite.com


if host doesn't let you edit httpd.conf then you just have tuse what system they have for setting up aliased/parked domains.

Sites Subdirectory
--------------
create subdirectiry in sites folder for each site you want to run with this installation. each bears name of domain. each has a separate settings.php file.

examples :
sites/default/settings.php
sites/domain.com/settings.php

to get settings.php in those directories. copy the one from default and modify it. change database settings, base url etc

also create af iles directoiry:

sites/domain.com/files to keep uploaded file separate fro mother sites

Also create modules and themes folders

site/domain.com/modules
site/domain.com/themes

Sharing Database
-------------------
use prefix if you want in same database. but same database is not recommended.

skipping most of thist stuff:
- sharing database
- sharing user information (user table)
- sharing spam tables
- sharing other tables

Making Backups
---------------
- never lose data
- always have mirror ready to replace site if it goes down

two things to back up:
- file system (uploaded files etc.)
- database

Database backups
------------
Options:
- dba module will use cron to do dumps and email it to you
- civicspace script see p201
- phpmyadmin
- mysql console

File System backups
----------
- program files, modules, themes are easy to backup
- uploaded files can grow to gargantuan sizes

options:
- filesystem backup module (emails you attachments)
- linux cp command
- -u flag will replace only if file is newer
- zip it up and then download it

Maintaining Test Site
---------------------
- copy files to subfolder or alternate document root (using vhost)
- create test database, import data
- update config sites

- best to clone production server
- use a subdomain and seprate document root (what about vhosts??0
- can also try subdirectory
- use localhost
- try to keep close as possible to production environment

Subdirectory method for test site
----------
- domain.com/test_site/
- password protect using http authentication or drupal securesite module
- copy site database
- copy files to subdirectory
- update config in settings.php
- $db_url
- $base_url

Updating Drupal
---------------
- maintain some kind of version control to make sure you track what changes you make
- also keep a SITE-CHANGELOG.txt to track
- record when you downloaded and installed drupal, difft modules, etc.
- test the update on a clone/mirror
- keep a full backup before any update

procedure
- replace files
- run update.php

that sounds like sort of primitive.

- make sure that your modules are also updated to the new version

- deactivate contributed modules before updating the core drupal site

if htey say remoave all old drupal files, they mean just what came with the original drupal download obviously.

acess update.php in browser

Support
----
use the drupal forums and #drupal-support

Labels: cms, drupal, drupal6

all your bases ar--