Ot the thousands of available contributed modules, there are a few every site should have. One of these is "pathauto" which depends on "token"and "cleanurls".

As the user which owns the site:

drush dl token
drush enable token
drush dl pathauto
drush enable pathauto

The defaults are fine except "admin/build/path/pathauto". In the section URL aliases, check the box "Bulk Generate".

Of course, you need "drush" but that is another story.
 

The release of 6.15 and 5.21 prompted a review of local Drupal sites. We have a collection of 44, many experimental, some customer evaluations and a few "productive" sites. Fortunately, all our sites have a similar file structure and we can obtain a status report of all Drupal code with a few lines of code.

A transformational website to which we contributed modest mentoring.

I was induced to rethink web hosting while chasing Aegir - a  hosting management system for the Content Management System (CMS) Drupal. While you may crack open a book on the basis of its cover, It is the first few seconds of the reading experience that hook you into reading more. If that first few seconds is a repeat of the last experience, you may be inclined to say "I've read that book before" and put it away.

Note: the gremlins came back today. The sessions table had mushroomed in size. I had to repair it before I could empty it but life seems better now.

I found one of the web servers unresponsive on Wednesday morning. Worse, the router between my workstation and the web server was gasping. In a rash attempt to improve life on the router, I thoroughly trashed it. But that is another story.

Updates are not so bad.

I downloaded 5.19 and 6.13 from drupal.org to /root.

Then I extracted both files creating the directories /root/drupal-5.19 and /root/drupal-6.13

Immediately I renamed /root/drupal-5.19/sites/default/settings.php to settings.php.org. If you forget this step you will wish you had a backup of settings.php.

Then I "su" to the appropriate user; cd to public_html/domain_name and

cp -a /root/drupal-x.yy/* .

Diligence and hard work pays off in the long run but procrastination pays off immediately.

One of the disadvantages of experience is that you retain memories of past failures. Like hunting with Dick Cheney and upgrading operating systems. A former Mandrake Linux fan, I once destroyed a fledging managed hosting business by insisting on installing the "latest" version on a number of servers.

There are many reasons for running a copy of a Drupal website on a local machine among them backup, offline development or more likely a perverse desire to show that it can be done. The perversity is hightened by doing this on a Windows machine, in this case Windows XP. This case study is based on the real world user "varley" and the site "vekon.com". You may get your case to work with appropriate substitions.

Rather inadequately, I have explained the difference between a CMS website and a conventional website as a matter of who contributes content, a CMS encourages wider participation in the website creation process. But that understates the significance of collaboration and networking. For example one site featured at the recent DrupalCon in DC was OAN. It is just difficult to imagine Dreamweaver in the driver's seat.

Of the three "free" php opcode caching schemes APC, eAccelerator and Xcache, the latter had an installable package and appeared simplest to implement. I tried it on my local workstation first (always a good idea) and it came up with little difficulty.

apt-get install php5-xcache

Now generate the password.

echo -n "my_password" | md5sum -

Modify the username and password in /etc/php5/apache2/conf.d/xcache.ini

Hang the web code someplace easy to get at.