UPDATE wp_posts
SET post_content = REPLACE(post_content,'localhost/test','www.example.com'),
guid = REPLACE(guid,'localhost/test','www.example.com');
UPDATE wp_options
SET option_value = REPLACE(option_value,'localhost/test','www.example.com');

Yes, I'm probably crazy - I understand that situations where this would be applicable are only a few. That's because my "solution" will work well (without additional labor) only for "static" websites - no forms (including contact/comment forms). I'll list a few applicable situations at the bottom of this post.

1. Let's say you created the website and set it up under http://localhost/mywebsite. (If it is WordPress, you may need to change the relative references in your theme's css to absolute)
2. In your Linux terminal or Cygwin on your Windows machine, run the following wget command:

   wget --html-extension --recursive --page-requisites --progress=bar --mirror http://localhost/mywebsite

   This will generate an html file for every page of your website.

3. Once you have all the files, you will want to mass find-and-replace all instances of localhost/mywebsite to e.g. www.andrejciho.com. The script below is a powerful one. It finds and replace stuff inside of all files under a folder, no matter how deep inside the directory structure:

   find . -type f -exec sed -i 's/localhost\/mywebsite/www.andrejciho.com/g' {} \;

Possible applicable situations:

• University IT department gives a student government FrontPage access to a folder on their server, but no database access. The student government folks are good with WordPress.
• Your client demands that you migrate the website you made for them in WordPress to their IIS server.
• You want your server to exert as little energy as possible when serving your website.

My proposition is to set up a separate, development (DEV), instance of your website, under a separate URL, using its own database, and of course, separate file structure. In this environment, you can use the one-click install, try new plugins, perform and test theme modifications, etc. without the risk of breaking anything on your LIVE website.

The task this article wrestles with is trying to create an easy way to a) deploy your changes from DEV to LIVE environment, and b) to restore the LIVE environment to DEV to have the most current version for messing with. The scripts I show help me with semi-automating these tasks.

So to set up this DEV environment, you'll need…

• A dedicated subdomain. To make it easy to remember, you can set up dev.yoururl.com to be your DEV environment for your www.yoururl.com.
• A dedicated database

SCRIPT 1: Restores LIVE database (or its previously created dump) to DEV database.

#!/bin/bash

# Directory to be used for temp files created by this script
BTEMP_DIR=         # e.g. /home/andrej/.restore_temp
# If you are restoring from a previously created database dump
BACKUP_DIR=        # e.g. /mnt/hda7/db_dump

# Your database access credentials
BMYSQL_HOST=       # e.g. localhost or mysql.yoururl.com
BMYSQL_USER=       # e.g. andrej
BMYSQL_PWD=        # your password

# Source Database
BMYSQL_DBNAME=     # e.g. wordpressLIVE

# Target Database
BMYSQL_DBTARGET=   # e.g. wordpressDEV

# Script (.sql) to run after the database is restored
BPOST_RESTORE=     # e.g. /home/andrej/.scripts/post_live_to_dev.sql
# This script mentioned above can contain these two useful statements
# and possibly other
# UPDATE wp_posts
# SET post_content = REPLACE(post_content,'www.yoururl.com','dev.yoururl.com');
# UPDATE wp_options
# SET option_value = REPLACE(option_value,'www.yoururl.com','dev.yoururl.com');

#  Make sure output directory exists.
if [ ! -d $BTEMP_DIR ]; then
    mkdir -p $BTEMP_DIR
fi

If you are restoring from a previously generated backup as described in my post about nightly MySQL backups, add the following:

# gunzip and write contents of the db backup to a temporary sql_to_run.sql
cat $BACKUP_DIR/$BMYSQL_DBNAME.gz.0 | gunzip > $BTEMP_DIR/sql_to_run.sql 2>/dev/null

otherwise add the following:

# Dump (sounds scary, but really means export) database to a temp file
mysqldump --host=$BMYSQL_HOST --user=$BMYSQL_USER --pass=$BMYSQL_PWD --add-drop-table $BMYSQL_DBNAME | gzip > $BTEMP_DIR/$BMYSQL_DBNAME

# gunzip and write contents of the temp file to a temporary sql_to_run.sql file
cat $BTEMP_DIR/$BMYSQL_DBNAME | gunzip > $BTEMP_DIR/sql_to_run.sql 2>/dev/null

…and now everybody continue here:

# read from $BPOST_RESTORE file mentioned above and add to the end of
# the temporary sql_to_run.sql file
less $BPOST_RESTORE >> $BTEMP_DIR/sql_to_run.sql

# run the generated sql_to_run.sql file
mysql --host=$BMYSQL_HOST --user=$BMYSQL_USER --pass=$BMYSQL_PWD $BMYSQL_DBTARGET < $BTEMP_DIR/sql_to_run.sq

OK, the DEV database should be successfully restored to what the LIVE looks like.

SCRIPT 2: Make an identical copy of the LIVE file structure to DEV:

If you are restoring from a file backup described in my previous post, add the following:

#!/bin/bash
# your backup file
SOURCE_FILE=     # e.g. /mnt7/backup/www.yoururl.com.tgz.0
# your DEV folder
TARGET_DIR=      # e.g. /var/www/dev.yoururl.com

# Clean everything in the DEV folder
rm $TARGET_DIR/* -R   >/dev/null 2>&1
# Restore files from the backup file
tar xvzf $SOURCE_FILE -C $TARGET_DIR

If there is no file backup, just create a copy using rsync.

#!/bin/bash
# Path to your LIVE file structure
SOURCE_DIR =   # e.g. /var/www/www.yoururl.com
# Path to your DEV file structure
TARGET_DIR =   # e.g. /var/www/dev.yoururl.com

# create a mirror of LIVE on DEV (deleting DEV files)
rsync -a --delete --exclude "wp-config.php" --exclude "/cache/wp-cache-" $SOURCE_DIR/ $TARGET_DIR

IMPORTANT: After you restore your WordPress file system, make sure to edit your wp-config.php to reflect the correct database (DEV or LIVE). You may also have to regenerate permalinks in WordPress' interface under Options, Permalinks.

Messing with the above 2 scripts, you can run this both directions - DEV to LIVE and LIVE to DEV.

Comments and corrections are welcome.

As with majority of my posts, I offer nothing new or unique. This is just a script that has been useful to me and if you find it useful, my time and effort in writing this up have been validated.

#!/bin/sh

#Define your variables here:
SOURCE_DIR=     # e.g. /home/andrej/documents
TARGET_DIR=     # e.g. /mnt/hda7/docbackups
BACKUP_FILENAME=     # e.g. andrejdocs

#  Make sure output directory exists.
if [ ! -d $TARGET_DIR ]; then
    mkdir -p $TARGET_DIR
fi

#  Rotate backups
for j in  6 5 4 3 2 1 0; do
    for i in $TARGET_DIR/$BACKUP_FILENAME.tgz.$j; do
        if [ -e $i ]; then
            mv $i ${i/.$j/}.$(( $j + 1 ));
        fi
    done
done

cd $SOURCE_DIR
tar -cvzf $TARGET_DIR/$BACKUP_FILENAME.tgz.0 *

chmod 600 $TARGET_DIR/$BACKUP_FILENAME.tgz.0

In the Nightly MySQL Backup I briefly talk about how to use cron in scheduling scripts to run periodically.

Either way, after the other day, I did some research and found out how simple it was. So this post isn't really anything new, just a short compilation of what I found online.

(You will need shell access to the hosting server and your hosting company will need to allow you to run scripts and use cron.)

Backup Script

First you'll need a backup script that will dump (export, not destroy) the database. I found this one on www.debian-administration.org and really liked it because it keeps last seven backups - every time you run it, it adds a new backup and gets rid of the oldest one. I had to add the –host= part, because my hosting company has the databases spread across multiple servers. So here's what I have:

#!/bin/sh

#Define your variables here:
BACKUP_DIR=
BMYSQL_HOST=
BMYSQL_DBNAME=
BMYSQL_USER=
BMYSQL_PWD=

#  Make sure output directory exists.
if [ ! -d $BACKUP_DIR ]; then
    mkdir -p $BACKUP_DIR
fi

#  Rotate backups
for j in  6 5 4 3 2 1 0; do
    for i in $BACKUP_DIR/$BMYSQL_DBNAME.gz.$j; do
        if [ -e $i ]; then
            mv $i ${i/.$j/}.$(( $j + 1 ));
        fi
    done
done

mysqldump --host=$BMYSQL_HOST --user=$BMYSQL_USER --pass=$BMYSQL_PWD $BMYSQL_DBNAME | gzip > $BACKUP_DIR/$BMYSQL_DBNAME.gz.0

Once you have this script in place, make sure it has the right permissions - my hosting company requires this: -rwx–x— with the default group.

Schedule your script to run

I found this helpful wiki article at Dreamhost. So I did the following:

crontab -e

Borrowing from Dreamhost's Handy Crontab Header and adding a line that will run my script at 1:15am every day, this is what I have:

# minute (0-59),
# |      hour (0-23),
# |      |       day of the month (1-31),
# |      |       |       month of the year (1-12),
# |      |       |       |       day of the week (0-6 with 0=Sunday).
# |      |       |       |       |       commands
15       1       *       *       *       /home/path/to/your/script

Save the file (don't forget to leave the last line blank). To see if the file saved correctly, just list the crontab file by this command:

crontab -l

and you should see it printed on the screen. That's it!

1. Download the extension instead of directly installing it. (You know, right-click and Save Link As…)
2. Rename the extension from filename.xpi to filename.zip.
3. Unzip the extension, and open install.rdf for editing.
4. Change the em:maxVersion parameter value to include your version of Firefox, better yet, change it to 4.0 just to be safe.
5. Save the file, zip up the folder and rename the new filename.zip to filename.xpi.
6. To install it, open the filename.xpi file with firefox.

First of all I put up an announcement into the admin interface half-a-day in advance (could have done couple days) so that anyone who logs in knows it's coming. WordPress MultiUser has a neat action hook called admin_notices which you can call in a plugin. So I put together this simple one:

<?php
add_action('admin_notices','displayAnnouncement');
function displayAnnouncement() {
  $msg = '
    <div style="background: #ff0000;color: #000000;font-size: 12pt;">
      <p>your message goes here</p>
    </div>
  ';
  echo trim($msg);
}
?>

Then I created an offline page that all the visitors would be redirected to, while I was working on the site. I just created a folder called "offline", copied the main page's theme (CSS and images) and whipped up a nice .html document (no PHP) telling users that the site is temporarily unavailable due to maintenance.

After all the users knew not to log in and the offline page was ready for the public, it was time for the redirect. The beauty in the following few lines of code is that it redirected everyone BUT me - so I could use and test the site all I wanted without anyone seeing any ugly unprofessional errors. So here goes what I inserted at the top of index.php, wp-admin/admin.php (included in all the admin pages) and wp-login.php. If you have wp-signup.php enabled, I'd put it there too.

<?php
$ip = $_SERVER['REMOTE_ADDR'];
if ('xxx.xxx.xxx.xxx' <> $ip ) {
  header('Location: http://your-WPMU-url/offline/');
  wp_redirect('http://your-WPMU-url/offline/');
}
?>

*Replace the xxx.xxx.xxx.xxx with your IP address.
**I used the wp_redirect just to be sure it works - you know, in case some other headers get passed before the regular redirect.

Now I was ready for the upgrade and maintenance. (Just a note - if you plan to overwrite any of the files that contain your custom redirect during your maintenance/upgrade, don't forget to include the redirect in the new ones as well :-) - at least until you are done with the maintenance.)

• Before you start
• CAS modification
• Authentication
• Admin username
• Welcome email

Before you start

Download phpCAS and after extracting it, copy the folder esup-phpcas-x.x.xx/source/CAS into the ./wp-content/mu-plugins folder of your WPMU install so that the path to CAS.php is ./wp-content/mu-plugins/CAS/CAS.php.

Make sure, that you have access to your MySQL database either through phpMyAdmin or another similar tool or at least that you can execute queries through the command line.

CAS modification

In the CAS that you copied into your mu-plugins folder: Comment out the following section in the beginning of CAS/PGTStorate/pgt-db.php so that it looks like this:

/*
if (!class_exists('DB')) {
include_once('DB.php');
}
*/

(Otherwise you'll see errors.)

Authentication

Make a backup copy of your current ./wp-login.php and replace the content of the original file with my wp-login.php.

Make a backup copy of your current ./wp-content/mu-plugins/pluggable.php and replace it with my pluggable.php. Edit the file and modify the CASloginURL and CASlogoutURL variables based on your setup.

Admin username

Most likely your username in your CAS user directory is not 'admin'. At least mine wasn't. In order for you to be able to log in to your WPMU install, you'll have to edit the users table (wp_users) to change the username (user_login) of admin (ID = 1) to your CAS user directory username.

Since your username is no longer 'admin', WPMU may not consider you a site administrator (administrator of the site and all blogs). If this is the case, you will have to modify the function is_site_admin() in ./wp-includes/wpmu-functions.php to include the following clause:

$userid = get_current_user_id();
if ($userid == 1) return true;

What this will accomplish is that the person with userid = 1 (the person who installed WPMU) is considered a site admin regardless of their username.

Once you are the site admin again, you can add more users to have the same permissions in the Site Admin | Options section of the WPMU control panel / dash board. If that still doesn't give them site admin permissions, you can hardcode their username in the same is_site_admin() function, although I would not recommend that. You would just insert some thing like this inside the is_site_admin() function:

if ($user_login === 'a12345') {return true;}

Welcome email

When you create a new blog in the site admin area, an email is sent to the new user created at the same time. The email contains a random password generated by WordPress - a password that will not work, because you are using CAS instead of the WordPress authentication. So in order to avoid any confusion, you'll have to change the text of this Welcome email. Even though it may seem that the place you could edit that text is in the site admin area, the text is actually hard-coded into a php file. So to make the change you'll have to edit it there.

Copy the function wp_new_user_notification from ./wp-includes/pluggable.php and insert it into ./wp-content/mu-plugins/pluggable.php at the end of the file. The functions in pluggable.php in wp-includes are preceded by
if ( !function_exists) (meaning if it was already defined earlier) because you can first define them in pluggable.php in mu-plugins which gets executed earlier in the sequence.

All that to say: if you want to modify a function that's in ./wp-includes/pluggable.php, you are best off to copy it to ./wp-content/mu-plugins/pluggable.php first and modify it there so that you have as many of your WPMU modifications in one place - the mu-plugins folder - as possible.

But back to our wp_new_user_notification function. Now that it's in ./wp-content/mu-plugins/pluggable.php, modify the line that says:

$message .= sprintf(__('Password: %s'), $plaintext_pass) . "\r\n";

to say something like:

$message .= sprintf(__('Password: (use your domain password)'), $plaintext_pass) . "\r\n";

That should be it. If you discover other things that may have to be addresses due to the integration, please let me know so that I can add them here for everyone to benefit from.

If you make any improvements, I kindly ask that you send them to me as a courtesy.