Non-profit volunteer drupal admin seeking assistance

I have taken so much from the community to date, it is about time I gave some back so here goes.

The first bit of advice I have is to go onto the main Drupal Website and read the Drupal Handbook, it will answer many of your questions. To cut to the chase, navigate to /admin/report/status and look for anything red (I'll assume that whatever theme you are using for administration will display red for bad and green for good) -- follow any instructions.

If you are not already doing so, you can use cron to run http://www.example.com/drupal-site/cron.php as often as you see fit. My own cron script (almost) is:
www-data /usr/bin/wget -O - -q -t 1 --http-user=gvadmin --http-password=XXXXXXX http://administer.gatevillage.com/cron.php?cron_key=XXXXXXXXXX

I set it to run every 10 minutes -- note that administer.gatevillage.com is an internal box distinct from the main web farm, but that isn't necessary for small sites. Note also that for the "cron_key" to work (it is a security feature) you need to install a new module for cron here is a list of candidates my personal choice is Elysia Cron but then I have more than some familiarity with all things unixy and I like the extra features this provides. YMMV.

.... this takes care of all the official Drupal code, including any contrib modules and themes, anything else is custom code (and probably shouldn't be on a site like you elude to in my opinion).

When a module update is available, drupal will let you know (with notifications set for security and/or non-security related updates as to your taste). The procedure is to download the new version, untar the contents somewhere safe (like /tmp) and check the directory for any README.txt or INSTALL.txt files -- it is good practice to always to this step but usually it is a NOP still sometimes there are extra steps, particularly if you had been using Beta code and moved to a Release Candidate...I've many dozens of modules are only once or twice have I required extra steps.

Step 2: ON YOUR UP-TO-DATE TEST SERVER ... untar the module into /sites/all/modules -- it should overwrite an existing module with new code. Then run http://yourtestserver.example.com/update.php -- this will perform any database updates required by the upgraded module ---- NOTE WELL the comment to backup your DB, if there is any danger step involved it is here. Of course, it probably doesn't matter on your test server.

Step 3: QA -- check for activity as the admin user, as an authenticated user, and as an anonymous user; check /admin/reports/dblog for any errors

Step 4: put you main site in offline mode /admin/settings/site-maintenance

Step 5: repeat steps 2 and 3 on your main server. I'll assume you do not have a web farm (that will complicate things a bit but just remember that update.php should only be run once but can safely be run when there is nothing to do -- Drupal is pretty forgiving that way actually, but should only be run once is good advice just the same.

Step 6: done, don't forget to put the site back online .

Things get a bit more complicated for a major update to Drupal core --- essentially core updates require the disabling of contrib modules then the same sort of untaring as above except that it is from the root drupal directory. Once the upgrade is complete then you re-enable the contrib modules (many of which will require an upgrade as well).

Best practice says do things one module at a time, but that is cumbersome if you have a lot of modules -- I have successfully upgraded over 1/2 dozen modules simultaneously but I am religious about steps 2 and 3!

Probably more than you were expecting but less than you need to know, still I hope you find this useful. Please do yourself the favour to read the Handbooks, they are quite useful.

President & CEO, Global Alliance of Trusted Experts

That's a pretty good set of steps! One suggestion is that Step #2 wouldn't remove any files deleted from the previous version. So, before untarring the module it's a good idea to move the old version out of the way.

You should only need to disable contributed modules when updating Drupal core when going between major versions; Drupal 5->6, for example. For point upgrades, there's no reason to do that unless you run into trouble while testing.

Also, the steps are tailored for Drupal 6, though they mostly apply to Drupal 5. For example, the URL for the watchdog log is different in Drupal 5, and "update status" is a contributed module for Drupal 5, and not included in Drupal itself.

This sort of question is perfect for our upcoming meeting (http://groups.drupal.org/node/24395), so if you're in the area come on out!