chmod +x wp-backup

(assuming you saved it under the name wp-backup). After saving it edit the file with your favorite editor and set the 5 configuration variable to whatever is appropriate for you. BACKUP_DIR is the folder to save the local backups to. FTP_HOST, FTP_USER, FTP_PASS control the FTP host, username and password, respectively, for the remote backup server. FTP_BACKUP_DIR sets the folder on the FTP server to save the remote backup to.

Now that the initial configuration is done, all you need to do is execute the script and give the path to the blog as an argument. For example:

./wp-backup /home/someuser/myblog

And that it, the script will backup your files (excluding cache) and database to both a local and remote locations. This allows using the same script to backup multiple WordPress blogs, unlike the previous script which had to be modified for each blog.

And now the script itself:

#!/bin/bash
 
# Copyright 2008, 2010 Guy Rutenberg <http://www.guyrutenberg.com/contact-me>
# WordPress FTP backup 2.0
#
# Easily backup wordpress instances via ftp.
#
# Change Log:
# ===========
# 2.0:
#  - Auto-detect database settings.
#  - Exclude cache data from backups.
 
BACKUP_DIR=
FTP_HOST=
FTP_USER=
FTP_PASS=
FTP_BACKUP_DIR=
 
# end of configuration - you probably don't need to touch anything bellow
 
PROG=`basename "$0"`
print_usage () {
    echo "USAGE: ${PROG} [options] BLOG_ROOT"
    echo "Backup a WordPress blog"
}
 
print_help ()  {
    print_usage
    cat << EOF
 
Options:
    -h, --help          show this help message and exit
 
EOF
}
 
TEMP=`getopt -o h --long help -n "$PROG" -- "$@"`
if (($?)); then
    print_usage
    exit 1
fi
 
eval set -- "$TEMP"
 
while true ; do
    case "$1" in
        -h|--help) print_help; exit ;;
        --) shift; break;;
    esac
done
 
if [ -z "$1" ]
then
 print_usage > /dev/stderr
 exit 1
fi
 
BLOG_DIR=$1
DB_NAME=`echo "<?php require_once(\"${BLOG_DIR}/wp-config.php\"); echo DB_NAME;" | php`
DB_USER=`echo "<?php require_once(\"${BLOG_DIR}/wp-config.php\"); echo DB_USER;" | php`
DB_PASS=`echo "<?php require_once(\"${BLOG_DIR}/wp-config.php\"); echo DB_PASSWORD;" | php`
DB_HOST=`echo "<?php require_once(\"${BLOG_DIR}/wp-config.php\"); echo DB_HOST;" | php`
 
BLOG_DIR=`dirname "$BLOG_DIR"`/`basename "$BLOG_DIR"`
BACKUP_DIR=`dirname "$BACKUP_DIR"`/`basename "$BACKUP_DIR"`
 
echo -n "dumping database... "
DUMP_NAME=${DB_NAME}-$(date +%Y%m%d).sql.bz2
mysqldump --user=${DB_USER} --password=${DB_PASS} --host=${DB_HOST} \
 --databases ${DB_NAME} \
 | bzip2 -c > ${BACKUP_DIR}/${DUMP_NAME}
if [ "$?" -ne "0" ]; then
	echo "failed!"
	exit 1
fi
echo "done"
 
echo -n "Creating tarball... "
TAR_NAME=${BLOG_DIR##*/}-$(date +%Y%m%d).tar.bz2
tar -cjf ${BACKUP_DIR}/${BLOG_DIR##*/}-$(date +%Y%m%d).tar.bz2 --exclude cache ${BLOG_DIR}
if [ "$?" -ne "0" ]; then
	echo "failed!"
	exit 2
fi
echo "done"
 
echo -n "Uploading SQL dump and tarball to FTP... "
lftp -u ${FTP_USER},${FTP_PASS} ${FTP_HOST} <<EOF
cd "${FTP_BACKUP_DIR}"
put "${BACKUP_DIR}/${DUMP_NAME}"
put "${BACKUP_DIR}/${TAR_NAME}"
 
EOF
if [ "$?" -ne "0" ]; then
	echo "failed!"
	exit 3
fi
echo "done"

Porting this theme to RTL was the main catalysis for improving my cssrtl.py script. Beside translating the theme to Hebrew and making the necessary CSS adaptation to RTL, I had also to adopt the fonts used. The font selected by the author weren’t compatible with Hebrew, and the alternatives looked awful. So I’ve chose some other fonts from the same family to keep the overall look of the theme, but make it more Hebrew friendly.

You can see a live version of the theme in David Zadok’s site. The theme can be downloaded from here: fusion-rtl-2.6.zip [326.8kb]

I must add that as a user of the Sociable plugin, I’m more than satisfied. I probably won’t stop using the plugin just because of this issue, but it still seems to me like improper manners.

This script allows you to easily backup your WordPress blog to an FTP server. It’s actually a modification of my Wordpress Backup to Amazon S3 Script, but instead of saving the backup to Amazon S3 it uploads it to an FTP server. Another update is that now the SQL dump includes the database creation instructions so you don’t need to create it manually before restoring from the backup.

Although I’ve written it with WordPress in mind (to creates backups of my blog), it isn’t WordPress specific. It can be used to backup any website that consists of a MySQL database and files. I’ve successfully used it to backup MediaWiki installation.

#!/bin/bash
 
# (C) 2008 Guy Rutenberg
# This is a script that creates backups of my blog.
 
DB_NAME=guy_blog
DB_USER=******
DB_PASS=******
DB_HOST=localhost
 
BLOG_DIR=/home/guyru/guyrutenberg.com/
BACKUP_DIR=/home/guyru/backups/
 
FTP_HOST=88.198.42.4
FTP_USER=******
FTP_PASS=******
FTP_BACKUP_DIR=guyru/
 
# end of configuration - you probably don't need to touch anything bellow
BLOG_DIR=`dirname "$BLOG_DIR"`/`basename "$BLOG_DIR"`
BACKUP_DIR=`dirname "$BACKUP_DIR"`/`basename "$BACKUP_DIR"`
 
echo -n "dumping database... "
DUMP_NAME=${DB_NAME}-$(date +%Y%m%d).sql.bz2
mysqldump --user=${DB_USER} --password=${DB_PASS} --host=${DB_HOST} \
 --databases ${DB_NAME} \
 | bzip2 -c > ${BACKUP_DIR}/${DUMP_NAME}
if [ "$?" -ne "0" ]; then
	echo "failed!"
	exit 1
fi
echo "done"
 
echo -n "Creating tarball... "
TAR_NAME=${BLOG_DIR##*/}-$(date +%Y%m%d).tar.bz2
tar -cjf ${BACKUP_DIR}/${BLOG_DIR##*/}-$(date +%Y%m%d).tar.bz2 ${BLOG_DIR}
if [ "$?" -ne "0" ]; then
	echo "failed!"
	exit 2
fi
echo "done"
 
echo -n "Uploading SQL dump and tarball to FTP... "
lftp -u ${FTP_USER},${FTP_PASS} ${FTP_HOST} <<EOF
cd "${FTP_BACKUP_DIR}"
put "${BACKUP_DIR}/${DUMP_NAME}"
put "${BACKUP_DIR}/${TAR_NAME}"
 
EOF
if [ "$?" -ne "0" ]; then
	echo "failed!"
	exit 3
fi
echo "done"

The configuration is done using the variables in the beginning of the script (until the “end of configuration” line). They are pretty self explanatory, and you should adjust them for your site before using the script. If there are variables you don’t understand what they do, see the post about the previous script, and don’t hesitate to comment.

#!/bin/bash
 
# (C) 2008 Guy Rutenberg
# This is a script that creates backups of my blog.
 
DB_NAME=database_name
DB_USER=database_user
DB_PASS=****
DB_HOST=localhost
 
#no trailing slash
BLOG_DIR=/path/to/blog
BACKUP_DIR=/path/to/backups
S3BUCKET=s3://bucket-name/
 
# end of configuration - you probably don't need to touch anything bellow
DUMP_NAME=${DB_NAME}-$(date +%Y%m%d).sql.bz2
 
echo -n "dumping database... "
mysqldump --user=${DB_USER} --password=${DB_PASS} --host=${DB_HOST} ${DB_NAME} \
 | bzip2 -c > ${BACKUP_DIR}/${DUMP_NAME}
if [ "$?" -ne "0" ]; then
	echo "failed!"
	exit 1
fi
echo "done"
 
TAR_NAME=${BLOG_DIR##*/}-$(date +%Y%m%d).tar.bz2
echo -n "Creating tarball... "
tar -cjf ${BACKUP_DIR}/${BLOG_DIR##*/}-$(date +%Y%m%d).tar.bz2 ${BLOG_DIR}
if [ "$?" -ne "0" ]; then
	echo "failed!"
	exit 1
fi
echo "done"
 
echo -n "Uploading SQL dump to Amazon S3... "
s3cmd put ${BACKUP_DIR}/${DUMP_NAME} ${S3BUCKET}${DUMP_NAME}
if [ "$?" -ne "0" ]; then
	echo "failed!"
	exit 1
fi
echo "done"
 
echo -n "Uploading tarball to Amazon S3... "
s3cmd put ${BACKUP_DIR}/${TAR_NAME} ${S3BUCKET}${TAR_NAME}
if [ "$?" -ne "0" ]; then
	echo "failed!"
	exit 1
fi
echo "done"

As with the older Amazon S3 backup script, this one also required you to install the s3cmd package.

The first six variables:

• DB_NAME
• DB_USER
• DB_PASS
• DB_HOST
• BLOG_DIR
• BACKUP_DIR

Are the pretty self explanatory and have the same meaning as in the old script.

The script has one new variable: S3BUCKET. This should be set to the S3 bucket to which the backups should be saved. If you want to add some prefix to the backups files on S3 this is the place.

The script keeps the backups both in the local backup directory and the Amazon S3.

After setting up the server, I started moving the blog. Importing the files and the database was pretty straight forward. But when I thought every thing is ready and I transfered the domain to the new server I’ve found out that none of my inner pages are accessible. The reason, as it turned up pretty quickly, is that the Wordpress depends on Apache’s mod_rewrite to create the clean URLs (the so called permalinks). This actually posed two problems:

1. Wordpress depends on Apache’s mod_rewrite.
2. Wordpress used .htaccess files for the clean URLs configuration

Luckily, Lighttpd has its own mod_rewrite, however it operates a bit differently. The Wordpress generated .htaccess has the following lines:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

This rules tells Apache to check if the requested URL is a file or directory that exist on the server, otherwise append the requested URL to index.php. The last statement can be written in Lighttpd’s mod_rewrite syntax as

"^/(.+)/?$" => "/index.php/$1"

If we only use this rule, the posts will load up fine, but all static files will not be available, that includes CSS files and images which isn’t desired. Apache handles this by checking if the requested URL exist as a file or directory. Unfortunately Lighttpd’s mod_rewrite has no way to check if a file exists. I’ve found out that a possible workaround for this is to use mod_magent which allows to embed LUA code in Lighttpd, and use it to check if files exist and handle the clean URLs. This seemed to me an overkill, and as some people noted it has some performance hit which I wanted to avoid.

I’ve figured out that I shouldn’t just translate the rewrite rules, instead I need to adapt them. In Apache we check if a file exist in order to be able to serve the static files. The directories are checked so the server would be able to list them. The problem is now to achieve those objectives in Lighttpd. First we don’t really need to allow the directories to be listed (actually I’ve planed to block this option in my blog a long time ago). So the rule about the directories can be fully ignored. All the static files that need to be served have an extension, this includes all the files I’ve uploaded. We note that Wordpress generated permalinks never have a dot (‘.’) in their URLs. So we can exploit this behavior to achieve our goal. The following condition uses regular expressions to check if a given url has an extension, and if so serves it.

"^/(.*)\.(.+)$" => "$0"

The only difference from the Apache configuration is that the web-server itself returns the 404 message when a requested file is missing, instead of passing it to Wordpress and letting it return the error.

To sum everything up, our mod_rewrite configuration should look like this:

url.rewrite = (
	"^/(.*)\.(.+)$" => "$0",
	"^/(.+)/?$" => "/index.php/$1"
)

As I noted before (the second problem), there is no equivalent to .htaccess files in Lighttpd. So this configuration has to go directly into the main configuration file in /etc/lighttpd/lighttpd.conf (or where it exists in your server). Make sure you’ve enabled mod_rewrite, as this is required. You can enable it by putting the following line some where above the block.

server.modules += ("mod_rewrite")

If you have multiple sites hosted, you should use include the url.rewrite block inside a conditional statement. For example my configuration looks like this

$HTTP["host"] =~ "(www.)?guyrutenberg.com" {
	url.rewrite = (
		"^/(.*)\.(.+)$" => "$0",
		"^/(.+)/?$" => "/index.php/$1"
	)
 
	[...other unrelated configurations...]
}

And I've enabled the mod_rewrite at the top of the /etc/lighttpd/lighttpd.conf file.

This workaround works well, as you can read this post now. If you run into problems, or have any question about why or how I did soemthing, don't hesitate to comment.

#!/bin/bash
 
# (C) 2008 Guy Rutenberg - http://www.guyrutenberg.com
# This is a script that creates backups of blogs.
 
DB_NAME=guy_blog
DB_USER=guy_root
DB_PASS=****
DB_HOST=localhost
 
#no trailing slash
BLOG_DIR=/home/guyru/guyrutenberg.com
BACKUP_DIR=/home/guyru/backups
 
 
echo -n "dumping database... "
mysqldump --user=${DB_USER} --password=${DB_PASS} --host=${DB_HOST} ${DB_NAME} \
 | bzip2 -c > ${BACKUP_DIR}/${DB_NAME}-$(date +%Y%m%d).sql.bz2
if [ "$?" -ne "0" ]; then
	echo -e "\nmysqldump failed!"
	exit 1
fi
echo "done"
 
 
echo -n "Creating tarball... "
tar -cjf ${BACKUP_DIR}/${BLOG_DIR##*/}-$(date +%Y%m%d).tar.bz2 ${BLOG_DIR}
if [ "$?" -ne "0" ]; then
	echo -e "\ntarball creation failed!"
	exit 1
fi
echo "done"

Copy the above code and save it to a file called backup-blog. Before you can use it there are some configurations to be done. At the beginning of the script (right after the copyright notice), you will find some variable you need to set.

The first set of variables is the database configuration. Set DB_NAME to the name of your database, DB_USER to your database username, DB_PASS to the user’s password and DB_HOST to the hostname of the database server. For most users the DB_HOST should be set for localhost (but some users need to specify a different value here).

The next variable is BLOG_DIR. Set it to the full path of the directory where you installed WordPress. BACKUP_DIR should be set to the full path of the directory you to keep the backups in, make sure the user which will run the script has write access to it. Notice that both paths shouldn’t end with a trailing ‘/’ (slash).

Now that the configuration is over, make the script executable:
chmod +x backup-blog
Now you can test that everything works ok by running the script: ./backup-blog. If the script failed for some reason make sure your configuration is correct.

The next step is to automate the backup process using cron. Run crontab -e to add an entry to the backup script. Append the following line to the crontab:
30 1 * * 4 /path/to/backup-blog
This will run the script automatically for you once a week, on 01:30 AM every Friday. Be sure to check up the backup folder from time to time to make sure everything is running smooth.

Note that while the script was originally intended to create backups of WordPress blogs it can also be used to backup any kind of website that needs both files and database backups, like MediaWiki, Drupal, or almost any kind of CMS and blogging platform.

<!-- ocadia theme credits, downloaded from wpthemesfree.com -->
<u id="ocadia" style="display: none">Buy some <a href="http://detoxbuddy.com/categories/191.html">marijuana drug testing</a> products</u>

Ocadia is the name of theme I’m using, so I guessed the hidden link came from there. I was partially right. The code indeed resided in the index.php file of the theme, but as I later found out, the theme had nothing to do with that. I removed link and the comment immediately, and went to see if the it was distributed this way from Beccary (the author of the theme.

I’ve downloaded the theme again and inspected its files. There was no spam link, and no mention of the WPthemesfree site. I was happy to know that the theme is benign. I remembered I got it directly from the author’s site, and couldn’t remember if I’ve ever visited WPthemesfree’s site. I’ve glanced at the code of all the plugins I had installed to see if I pick anything suspicious, but nothing came up. Anyhow, I had a lot of things to do that day, so I sort of let things go.

A day later, I decided to look again at the HTML source of the blog, and to my horror, I discovered the link came back. This time I’ve decided to get to the root of the problem and stop this from happening again. I keep a backup of all the original packages for everything I install on the web server, including themes. I looked in the original package I’ve downloaded when I installed the Ocadia theme, and it was clean. At this point I was sure the link didn’t came from it. I’ve greped the whole source-tree of the blog for wpthemefree and detox, but I came up with nothing.

The next step was to google for the spam link itself. I've came up with a number of Wordpres blog, that had the same spam message hidden, like my blog had. I've checked their installed plugins and themes, and I've found out that our blogs didn't have any plugins or themes in common. This reassured me that the link didn't came from something I've installed.

At this point I realized that the spammer used some kind of security vulnerability in the Wordpress that I'm using (2.2.2) to inject the code to my theme files. This has much riskier potential, as in the same way they code inject arbitrary PHP code that will be executed by the web server.

I've came up with the solution to lock theme files for writing, only leaving a read permission. This allows Wordpress to use them, but it has the downside of disabling the option to edit them from the dashboard. This turned out to be a good fix, as the link didn't came back again. Upgrading the Wordpress version could also be a good solution (it's something I think it's time I should do).

The conclusion from this should be is that one should lock all the PHP files, that don't need to be updated, for writing and only leave them with read permission. This precaution can also help protect you from other kinds of PHP injections that can happen.

I've contacted the authors of some of the blogs I found to be infected with the spam links, and I hope they will solve it too.