drupal

If you have lots of authenticated users, then you probably know that most of Drupal's caching is pretty much thrown out the window for logged in users. By default, when a user logs in, the user will stay logged in for 200000 seconds (that's just over 3 weeks!)

That equals 23 days that your Drupal website is probably working its ass off serving mostly dynamically generated pages. Instead, Drupal could simply be grabbing the page out of the page cache and handing it to an anonymous session whilst sipping margaritas in its spare time. (That's what I'd be doing with free cycles anyways.)

There's a cheap trick in Drupal 6 and 7 to reduce the number of authenticated users thereby reducing the load on your server. In the settings.php file (located in the /sites/default folder), there is a setting called session.cookie_lifetime. Change this to something a little more draconian such as 7200 (2 hours); enough time to post a comment or whatever and logout (or be forcibly logged out).

Obviously, this won't be practical for lots of sites but for some sites it can make a huge difference.

Happy Drupaling!

A while back I talked about doing development using the cron hook and how it was not very intuitive to use because if you have an error, it never gets displayed.

There is a handy module called Elysia Cron that allows you to have granular control over your cron jobs and how they are run. You can run functions in your module by clicking on them or set them to run at whatever intervals you want. All Drupal websites that have any sort of custom cron jobs need this module. Unfortunately, there is only a Drupal 6.x stable release right now.

So when you are creating a cron hook in your module, simply create a custom function that does whatever task you need to get done. You can then run this function manually in Elysia Cron to debug and make sure it produces the desired results. And then when its ready for prime time, you can call your custom function in Elysia Cron's configuration, or just add your custom function call in the cron hook function of your module and you are ready to rock.

I recently contracted out some work for a project I am working on in Drupal because it involved CSS, HTML and theming and quite frankly, my skills in that area suck. I used ODesk because I do some other data entry outsourcing there and it works quite well. Anyways, it was relatively easy to find a qualified person to do the work. Now the supposedly hard part, setting up a sandbox for a remote worker to access and do the work. This was a rush job that needed to get done yesterday so I needed something setup quickly.

Well luckily with Amazon EC2 and its nifty cloud, this turned out to be quite easy. I created a a micro instance in the US East (Virginia) region which costs a whopping 2 cents per hour (works out to about $15 / month). This can be decreased significantly by purchasing reserved instances. I used an EBS-backed instance so that I can start / stop it at will and not have it running if I don't need. I also assign a custom security group to it so I can add or drop custom firewall rules and it doesn't affect my other live instances. Finally, I use Ubuntu 10.04 LTS and Alestic's AMIs because its fast and simple to setup and run.

So now I have a running Ubuntu instance, now what? Well with a few simple commands, I can get a Drupal website up and running. Keep in mind this is a short term server that I need to focus on ease of use, not security so what I am doing would not be appropriate for anything else.

Copy authorized keys to root .ssh dir so I can login as root:
sudo cp ~/.ssh/authorized_keys /root/.ssh/

Now logout and SSH back in as root.

Update your Ubuntu instance:
apt-get update && apt-get -y upgrade

Install LAMP server:
tasksel install lamp-server

Edit your default site Apache configuration file with your favourite editor and point to your new htdocs dir (/home/htdocs):
pico /etc/apache2/sites-available/default

Enable mod rewrite for Drupal and reload Apache:
a2enmod rewrite
/etc/init.d/apache2 reload

Login to MySQL and create your database:
mysql -p
create database databasename

Now ssh to your live/development server and create a backup of your site with db to move to sandbox:
cd /home/htdocs
mysqldump -p databasename > db_date.sql
cd ..
tar .zcvf mywebsite.tar.gz htdocs/
rm htdocs/db_date.sql
scp mywebsite.tar.gz sandbox:/home/htdocs/


Now flip back to your sandbox and extract your tar file:

tar xfz mysqwebsite.tar.gz


Edit your Drupal settings file to point to database:

pico sites/default/settings.php


Load your database from the dump and delete the dump file:

mysql -p databasename < /home/htdocs/db_date.sql
rm /home/htdocs/db_date.sql


Now your website should be operational.

For quick access to your remote developer you can simply enable password security for your SSH daemon by changing PasswordAuthentication setting to Yes, assign a password for root and reloading SSH daemon:

pico /etc/ssh/sshd_config
passwd
/etc/init.d/sshd reload


Because most FTP clients support SFTP (FTP over SSH), your remote developer can now access your sandbox and you should be good to go.

Keep in mind that giving out root access is not ideal, nor is most of what I have talked about here good for security. In fact, it flies in the face of most best practice security measures that should be taken for any server. But if you need to get a server up and running fast for a remote worker to get stuff done quickly, it works and does the job.

Make sure you stop and/or terminate your instance as soon as you are done with it! Enjoy.

I have spent the past couple hours trying to debug a module that creates a bunch of content blocks on a Drupal 6 website. These blocks were set to BLOCK_CACHE_PER_PAGE setting but I changed them to BLOCK_NO_CACHE because I am implementing my own caching on them.

Well, turns out that even if you enable / disable your module and update your block admin page, Drupal never changes the block's cache setting. This is apparently not by design.

I will do a future post about implement custom caching in your modules in the future because I have learned a ton while completing gutting the caching that I did a year ago (which I did a very poor job of). Until then, I guess I chalk up the hours of frustration to "experience".

It seems you learn (or don't learn from past mistakes) every day. I was trying to do an upgrade tonight and just finished wrangling with the server for over an hour. It seems that Drupal 6.x really doesn't like it if you rename your theme directory and then create a new theme directory with the old name with your new files.

It caused all kinds of problems and eventually the web server starting throwing 503 service unavailable errors which will really make you scratch your head. I thought I was being smart by keeping a handy backup of the old theme directory in case something went wrong. Instead, it ended up just causing me a ton of headaches.

Once I realized the web server was fine and it was actually Drupal that was messed up, I simply started from scratch with my old Drupal installation. Then I deleted the theme folder and replaced it with the updated theme. Then I did a submit on the themes page (Site Building > Themes) and everything was fixed.

Wow, sometimes you just have to shake your head and laugh. I spent about an hour debugging a new web server trying to figure out why exim4 wasn't sending mail for the Drupal contact form. Well, it turns out it was the whole time and now I know way too much about Exim. The sender address was the same as the recipient so GMail was treating all my mail as spam. Shouldn't I have figured this out by simply looking at Exim's logs. Yeah, probably. I hate to be a super nerd but this is a classic example of PEBKAC - problem exists between keyboard and chair.