Moral Combat: Video Games in our Culture vs. Anarchy Media’s WP Plugin

IE six has an incompatiblity with this post. If you get an error, go to the next page or try Maxthon2 or FireFox.

Doug Stewart had a good post about an upcoming video game documentary about the affect of video games in our culture. In this post, I show you that movie while demonstrating the use of a WordPress Multimedia plug in. You can also read about “Moral Combat” on the Apple Pro Video site (link).

WordPres 2.0.7 is Out the Door! Now you can use the upgrade tool!

This is when it pays off. All those who downloaded and tested the EasyWPUpgrade tool can now get their monies worth! All you need to do to upgrade is log in via tellnet and type the name of the upgrade script, and in seconds you’ll have your site upgraded. Of course, you can read all about the release on the Development site: here:

I was successfully able top update my five active sites, without a fuss.

Here’s a picture of the backup files it created (And yes, that file is 1.2gb in size. I do trust this for my live sites.)

Ooooo Ain

You can try EasyWPUpgrade for yourself and tell me all about your experience on the The Code Cave’s forum: Did you use the The Code Cave’s EasyWPUpgrade for WP 2.0.7?

I’ve updated to 2.0.7rc2. More testers are needed

Mark Jarquith has asked for help with testing RC2. He’s looking for specific testers.

To see if you are one of the ones he is looking for, save this text as something.php:



then open it up.

If the header shows “PHP Version 4.3” or anything less, and Server API shows CGI or FastCGI, PLEASE TEST!

If you find a variable called SERVER_SOFTWARE that shows you are running IIS, PLEASE TEST!

You can download the full package here:

If you are running 2.0.6 and would like only the changed files, you can download this file:
(Note that this file is relative to your blog directory and not to the root with a wordpress directory underneath it. It contains just three files. So just extract it, with paths to where your blog is installed.)

Here’s how to test:


To test feeds’ 304 Not Modified headers, I recommend getting the Live
HTTP Headers extension for Firefox:

A. Warming up:

1. Make sure that Firefox will display feeds (and not pipe them to
an external RSS viewer)
2. Disable any caching plugins on your site like WP-Cache
3. Upload the 2.0.7 files (no need to run an upgrade)
4. Clear your Firefox cache

B. Testing procedure:

1. Open up Live HTTP Headers (Tools > Live HTTP Headers)
2. Visit
3. Verify that the response header for /wp-rss2.php?test=123 is 200 OK
4. Clear the Live HTTP Headers output
5. Reload the feed
6. Verify that the response header for /wp-rss2.php?test=123 is 304
Not Modified

There should be no conflicting Status: header (that is, any Status
header should match the response code of the main HTTP response header).

NOTE: The ?test=123 part is just to make sure that your first request
isn’t already cached.

Next, try basic WordPress functions like logging in, writing an
entry, writing a page, and deleting a page.

Let me know how it goes. Please include PHP version, server, and
server API (e.g. PHP 5.2/Apache/FastCGI) If you’re unsure about your
headers, paste the Live HTTP Headers output in your response, or send
me your feed’s URL to check out.


Then report here, or on wp-testers if your feeds seem to be working correctly.


How to answer: I upgraded to 2.1 and my plugins don’t work…

I’m in the process of gathering a list of things to check in your plugins directory to see if your site will survive the 2.1 upgrade without blowing up. I might turn this into a “Ready to Upgrade Plugin” I’m sure it won’t ever be able to catch everything, but it just might make things go more smoothly for some. With 2.1 possibily coming out on Jan. 22, I don’t know how complete this will be, but it might be worth a shot…

The replacement of the Table* variables is a good place to start. Here’s an email I sent two days ago on the subject. A person had written for help to the hacker list. He had just upraded from WordPress 2.0.5 to 2.1 and suddenly was getting an error in an sql statement.

The SQL statement looked something like this: “select blah, blah, blah from , where

After a from statement, there is normally a table name. In this case the comma indicated there were two table names. He wanted to know if this could have been caused by the upgrade.

Here is how I responded:

Yes, there were separate variables that held the table names. They were depreciated in version 1.5 and the developers tried to get the word out for this. In the comments, the 1.5 code said that the variables would be around for a few more months:

// We’re going to need to keep this around for a few months
// even though we’re not using it internally

$tableposts = $wpdb->posts;
$tableusers = $wpdb->users;
$tablecategories = $wpdb->categories;
$tablepost2cat = $wpdb->post2cat;
$tablecomments = $wpdb->comments;
$tablelinks = $wpdb->links;
$tablelinkcategories = $wpdb->linkcategories;
$tableoptions = $wpdb->options;
$tablepostmeta = $wpdb->postmeta;

As you can see the preferred way to access this information is through the $wpdb->tablename method that was added to the (then) version 1.3 source code in the summer of 2004.

As it is now 2007, the 2.1 release is FINALLY removing these variables as the comments indicated would be done two years ago.

Please contact the author of those plugins and send them to this link:

That will help get them back on trac with the WordPress code.

And btw, the pun in the last line was intended, but no on seemed to catch it!

Hilarious – Because I put “Summer of 2004” and “release” in the post, adsense thinks I’m writing all about movies and is recommending DVDs when you view only this post…

EasyWPUpdate ver 2.0 RC 1 – Just in time for WordPress 2.0.7

Well I can’t call it the 5 second upgrade script any more… Since adding full file backups, and compressed database backups, from Windows desktop, through manual log in and launch of the update script, it took me ~15 seconds to update an active blog with a couple dozen posts and log all of the results to a html log. I’m fairly certain I could type my password faster and shave off a few seconds. The script itself, which now shows start and stop times, only took 2 seconds to do its work. The rest was connect and login time. Sometimes it took a whole 30 seconds for the process to complete, web and server usage being what it is, but either way, wow. I should say that I used this last night with all of the options turned on, creating file backups AND gzipped backups AND database backups AND an HTML log file AND adding extra verbosity AND updating my 6 WordPress blogs and it took a full 8.5 minutes. I had to actually minimize the window to get it out of my way…. Between that and typing in the script name at the shell prompt, I was exhausted!

When I think of how long it used to take me to update just my wife’s blog, I just have to shake my head. Each release was a many-night, if not many-week process till I had the spare time to concentrate on doing the whole thing right. And I had to look up the instructions on the database backup every time… I’m just so glad this script is done.

The basic functionality is now complete and I am calling this a RC 1 release. It still needs further testing (especially the MySQLDump stuff. Does everyone HAVE MySQLDump? Should I disable this feature by default?), but it is fairly stable now.

Here’s the basic functionality

#  You can use this program in several ways:  
#    * In the default mode to download the latest and greatest update,
#      make an uncompressed copy of your files, makes a compressed backup
#      of your database(s), distributes the file to any number of 
#      directories, and performs the web steps
#    * Configure it to make a online copy of your files you use for easy 
#      recovery AND a compressed copy that you can download.
#    * Add custom directories and backup MORE than just WP. 
#    * Configure it update from a local file each night and start with
#      a clean blog every morning.  
#    * Use it as a nightly backup script by disabling all other steps

I’ve made about a gazzilion improvements and took the advice of a dozen or more reviewers out there. I think the new script is much improved. I’m really pleased with how well the database backup stuff works. I change into each blog directory, read all of the connection information from the wp-config.php file and use that to connect to the database. (I’m fairly certain this will work well for most servers, but I’m a little worried that *nix gurus will not be using TCP to connect to their databases and I have that hard coded. You gurus should let me know if this is an issue in the comments for this post!) I also then query the tables names from the specified database using the prefix specified for the blog. This means that this process will work for ALL versions of WP and will not grab non-WP stuff like vBulletin tables. It also means that it works just as well if you have 1 blog per DB or ALL blogs in 1 DB. It doesn’t matter. The DB backup for Blog1 has ONLY the data for Blog1. That is better for security, size, time and opens a neat avenue for testers who want to restore their blog to a different database/databasename and then test a major upgrade running their full blog out of a different directory. I’ve structured the tarball backups to make this easy too. *SORRY* There I go into tech speak again, but it is neat stuff, that is normally totally hidden from view.

You can peruse the text version, EasyWPUpdate.txt, here: link

Like the new name? I think it is better. I put TCC in front of all of my plugins, but really there is no need here. And yes, the sample version has grown to 851 lines. That’s not ALL code of course. It is heavily documented and includes some HTML that will give you a nice webpage log for you to peruse after the process is done. You can see a sample log here: link.

Now, I had deliberately made that last post very intimidating. I wanted people to be wary of the script. Now, I have much more confidence in its ability and quality. I’ve learned a lot in the last week. From using procedures, to the trap function, to sed and MySQLDump, to basic shell coding practices. It was all fun and you get the benifit. Especially because there are three versions of WP in the pipeline: 2.0.7 (Very, Very Soon), 2.0.8 (in the works), 2.1 (Very Soon).

So, I’ve made this post easier to read and the script easier to configure. I’ll do a full document later, but here are the basic steps to install this script:
1. Use Telnet or Putty to connect to your website and log into the shell
2. Type the following line:
3. Type the following line:
chmod +x EasyWPUpdate
4. Use an editor to change the values in Step 1 and save it again.
5. Run the script by typing:

That’s it. You will have just made backups of the files and database and updated all of your blogs. When 2.0.8 comes out, the process will be:
1. Log in
2. Type

And you are done.

Now, step 1 looks like this:

# ##################################################################
# Step 1. Tell the script where to find the blogs
# ##################################################################
# List all of your WordPress directories and urls here.
# Each Blog should have a BlogDir and a BlugURL.
# Each Blog should have its own number [1],[2],[3] etc
# Delete the ones you don’t need.



That isn’t that hard to change is it? Even in VI.

Some quick tips on editing the script
1. type
vi EasyWPUpdate
2. Hit i
3. Make your changes
4. Hit ESCAPE COLON W to save your changes (or skip this step to lose changes)
5. Hit ESCAPE COLON !Q to immediately quit

Also, if your root directory is accessible from the web, you might want to change the name of the script
mv EasyWPUpdate SomeSneakyName
to prevent unauthorized access.

If you ran the alpha 3 version of the script, you can copy and paste configuration over BUT!!!! you have to make the following changes:
The BlogDirs[] array has been renamed to BlogDir[]. Drop the “s” from all of those variables.

You should not need to copy the Common*Prefix variables over, but if you do, make sure to remove the trailing slash from the CommonRootPrefix variable.

I think that’s all you need to be aware of.

If you are a guru, please read through all 6 setup steps (and the rest too) there may be things you want to change.

I’ve also updated my Did That Help page and added a forum specficly for this script.

That might make discussions a little bit easier.

Well that’s about it. Let me know how it works. I’d like to get some good testing in before 2.0.7 comes out. I’ll also do some testing with updating to 2.1 so I am certain that will work well. I also need write instructions for the database recovery steps. The script has built in instructions if it blows up in the middle of updating the files. So, that is handled.

I’ll leave you with the change history and credits section from the script. Enjoy!

# History:
#    01/AUG/2006 – BL – Created
#    21/DEC/2006 – BL – Added multiple blog arrays 
#                       Added options at the top of the script
#    04/JAN/2007 – BL – Added File Backup routines
#                       Added web update
#                       Added tmp directory usage
#                       Added local source “freshen” option
#    11/JAN/2007 – BL – Added “steps” and further comments
#                       Added quotes around many vars to protect against spaces
#                       Changed TMPDIR-/tmp to TMPDIR:-/tmp
#                       Changed `pwd` != “$tmp” to `$pwd` != “$tmp”
#                       Added further error trapping around cd and cp routines
#                       Fixed file backup procedure, was adding extra layers
#                       Added ability to backup to tarball
#                       Added SQL backup procedure
#                       Fixed local file backup procedure
#                       Removed “Verbose” from cp to make messages clearer
#                       Added log to webpage for Joe.
#                       Fixed inconsistent use of trailing / in path variables
#                       Added status messages throughout
#                       Added recovery instructions in case of failure mid backup
#                       Added a list of directories to backup
#                       Added Credits section
# Credits – I want to thank all of the readers of, for
#   their testing of this script. I especially appreciated Michael, Maciek, 
#   Aaron and Joe for all of the helpful suggestions.  
#   A very special thanks goes out to goldfish on the FreeNode #sed channel                     
#   who will be PayPaled a Cafe Voltaire tomorrow.  I would have spent days
#   figuring out the RegEx for the SED commands.  Prec, also from #sed gave 
#   provided me with a working cr/lf stripper.  For bash, lhunath, jp-_ and the                     
#   whole crew at #bash on FreeNode gave great line by line suggestions.
#   They basically gave it a full code review!  None of this would have been 
#   possible without Advanced Bash-Scripting Guide. 20 days ago I didn’t know
#   what bash was.  Now I’ve written a powerful script with features I’ve not
#   seen anywhere else.  If you have any questions about the code in this 
#   script, you’ll find the answers here:&nbsp

WordPress Database Backup Script for Testing

Before I release the next version of the easy WordPress upgrade script, I would like to have some solid testing done specifically on the Database backup section.

Anyone familiar with backup up with MySQLDump and restoring from that backup is invited to try this script.

I suggest you have a known good backup of the DB in case any thing goes wrong.

This file is meant to be run from your blog’s directory and will get all of the information it needs from the wp-config file. That’s really the part I want to test. This script will display your database and password information on the screen. Please verify that it matches what you have in wp-config.php. It then uses that information to get a dynamic list of the tables in your database having the prefix you specified in wp-config. Then MySQLDump is used to export ONLY those files from the database.

So, you have a targeted database backup that is agnostic to the version of WP that you are using. It will work on WP 2.1 or 1.2 (assuming there were no major wp-config format changes). It will even withstand minor changes to the way the info is stored in wp-config.php.

So I hope it is resiliant.

The easy way to test is to:
1. Telnet to your system (having verified you have a good backup of the DB already)
2. Cd to your root WP directory containing wp-config
3. Execute the following wget:
4. Give yourself execution permission
chmod +x wpbackup4testing
5. Call the script

Then just look for the file named SQLDump.gz

Nothing in the public areas of your folder is safe. Google will find it. Then your passwords and everything else are theirs for the download. Do not keep DB backups online.

The code looks like this:

# WordPress Backup script from
# This is the incomplete testing version. The final version will be better.
# Go find it from
# Brian Layman
# Jan 11 2007
RANDOM=$$$(date +%N)
echo “DFName: $Dumpfile”
DB_NAME=$(sed -n “/define(‘DB_NAME’, ‘/s/.*, ‘\([^’]*\).*/\1/p” wp-config.php)
DB_USER=$(sed -n “/define(‘DB_USER’, ‘/s/.*, ‘\([^’]*\).*/\1/p” wp-config.php)
DB_PASSWORD=$(sed -n “/define(‘DB_PASSWORD’, ‘/s/.*, ‘\([^’]*\).*/\1/p” wp-config.php)
DB_HOST=$(sed -n “/define(‘DB_HOST’, ‘/s/.*, ‘\([^’]*\).*/\1/p” wp-config.php)
TABLE_PREFIX=$(sed -n “/\$table_prefix = ‘/s/.*= ‘\([^’]*\).*/\1/p” wp-config.php)

echo “Gathering information:”
echo “DB_NAME: $DB_NAME”
echo “DB_USER: $DB_USER”
echo “DB_HOST: $DB_HOST”
mysql $DB_NAME –port=3306 –protocol=TCP –host=$DB_HOST –user=$DB_USER –password=$DB_PASSWORD -e”show tables like ‘$TABLE_PREFIX%'”>TableNamesForSQLDump.txt
WPTables=$(sed -e “/^\($TABLE_PREFIX[^ ]*\).*/!d;s//\1/” -e :b -e “N;s/\n/ /;bb” TableNamesForSQLDump.txt)
echo “WPTables: $WPTables”
echo “Performing backup”
(mysqldump –opt –port=3306 –protocol=TCP –host=$DB_HOST –user=$DB_USER –password=$DB_PASSWORD $DB_NAME $WPTables | gzip > $Dumpfile)||{
echo “SQL Dump Failed”
exit 999
echo “Backup successful. Please examine file $Dumpfile”

5 Second WordPress Upgrade Script – Status & Question

THIS ARTICLE IS OUT DATED. Please see: for the current release.

Well I’ve gotten some good feed back from all of you. And I want to say Thanks!

I do have a new version of the script that has some improvements.

  • Fixed extra directory levels in the backup

  • Improved use of quotes

  • Local file location did not untar the file

  • Removed “verbose” from cp to make messages clearer

  • $CommonRootPrefix no longer requires trailing ‘/’


  • Added a list of directories to backup

  • Changed long backup section into a loop of the directories

  • Changed to tmp directory before performing wgets

  • Added a few more update steps for forward compatiblity

  • Added SQL backup code

  • Added Zip of backups

I’m doing local testing on these changes and will probably release this more publicly Wednesday or Thursday.

In the mean time, I would like to ask for your help.

What is the most optimized version of this line that we can come up with:

grep “define(‘DB_NAME’, ‘” wp-config.php|sed -e ‘s/define(.DB_NAME….//g’|sed -e ‘s/.); .. The name of the database//g’

That line, run from any blog directory, returns the DB_Name in a way I can pass it to MYSQLDump. It is neither, pretty, nor optimized, nor resiliant.

What is the most optimized way YOU can think of to write that bash statement?


SED problem is solved. Thanks to GoldFish on the #SED channel of FreeNode.