Traceback (most recent call last):
File “./planet.py”, line 23, in ?
import planet
File “./planet/__init__.py”, line 23, in ?
from planet.truncate import _TruncateHTMLProcessor
File “./planet/truncate.py”, line 2, in ?
import textwrap
ImportError: No module named textwrap

After looking confused for a while, I talked to my local python guru, Stephen Granade, and he pointed something out to me: textwrap.py is a Python 2.3-era addition, so I probably had a Python environment issue. [My server has 2.2.x and 2.4.x installed. Silly cPanel.]

Armed with this knowledge, I futzed around for a while and figured out that my shell script was missing an invocation of the Python environment. I have updated it:

#!/bin/csh -f
cd /home/path/to/planet
/path/to/python/binary ./planet.py ./config.ini

Consult your system adminstrator if you don’t know /path/to/python/binary. If you’re the sysadmin and can’t find the Python binary, please ram your forehead into your desk repeatedly.

Thanks again, Stephen. I owe you a beer.

1. Make sure all your file permissions are right. Half of my hell yesterday was having done all the work as root but not having CHOWN’d and CHGRP’d as appropriate.
2. Use your shell script to change to the appopriate directory before invoking planet.py. I’d never really had to do that, as I’m still a babe in the shell-scripting woods. But if you go in, cd to the /path/to/your/planet.py, then invoke ./planet.py /path/relative/to/config.ini, you’ll be rockin’.

My shell script looks like:

#!/bin/csh -f
cd /home/path/to/planet
/path/to/python/binary ./planet.py ./config.ini

Now, I simplified things by putting config.ini and planet.py in the same folder. If you didn’t [for example, if you're using examples/basic/config.ini just for funsies], you’d just invoke ./planet.py ./path/examples/basic/config.ini.

Thanks, Sam, for pushing me over the edge to play with PlanetPlanet. Now it’s time to get the templates like I want them so I can start using it in production.

I was specifically having issues with a cached Google reference to an entry on GFMorris.com that, in a previous life, had a popup photo of my friend Samantha. Google had ‘samantha.jpg’ cached, but their incoming references to the photo are, somehow, borked. Unfortunately, Google still treats this as a valid incoming referral, probably because the photo itself hasn’t been taken down.

There must be 15 or 20 people a day who hit that image through images.google.com, and well, I was getting annoyed. So I made myself take the time to learn how to write a shell script to call a .sql script. What follows is the result of that.

.sql Script to Strip Unwanted Referrers

The .sql script is pretty straightforward: connect to the database, run a nice DELETE FROM command, then quit.

CONNECT [database];
DELETE FROM refer WHERE page = '[unwanted referrer]';
quit

Per my convention, items in [brackets] should be replaced by the end-user of the script.

If I had multiple pages that I wanted stripped, I’d just have multiple DELETE FROM commands.

Shell Script to Run the .sql Script

#!/bin/csh -f

# Log in to MySQL and run striprefer.sql.

mysql -hlocalhost -u[user] -p[password] < striprefer.sql

N.B.: This assumes that striprefer.sql and the attendant shell script—which I’ve named striprefer—are in the same directory. If they are not, you will need to reference that from the user root (e.g., ./sql-scripts/striprefer.sql).

You can’t have the shell script run the SQL commands, unfortunately. I found that out the hard way.

How I Use ./striprefer

I use a cron job to run this every hour. That’s probably overkill, but as I said, I’m using these scripts to stop an annoyance, so I’ll deal with the attendant overhead.

Below, any instance of a tilde [~] indicates /home/[username]/. Referencing to user root is key to this. You could change it to /home/[username]/ if you so chose.

#!/bin/csh -f

# Determine current date
setenv CURDATE date +%Y%m%d

# Backup all WP databases to compressed, dated file in home directory
mysqldump -q -e -hlocalhost -u[user] -p[pass] [database] | gzip - > ~/${CURDATE}_db-backup.sql.gz

# Backup WP files to compressed, dated file in home directory
cd ~/path/to/wp-files/
tar cf - . | gzip - > ~/${CURDATE}_files.tar.gz

Any data in [brackets] should be filled in, sans brackets.

This should sit in userroot, chmod’d to 755 to be executable.

You will get errors for all files in wp-uploads on the second TAR run for the backups. If you don’t want backups of your WP files but are more concerned about the backup of the database, remove everything from the last comment on down.

I personally get an email sent to me to verify that there were no errors in the running of the script. I also use FTP Voyager‘s scheduler to do a Move Down on the backups to a local machine. When I can get a RAID box running at home, I’ll be dumping it to that, since I trust RAID more than a single-point-of-failure HD machine.