$wpdb->show_errors();

or any potential the failure happens silently

$wpdb->hide_errors();

with results of the SQL query coming back as blank and you can’t tell “nothing found” apart from “SQL error”.

I needed a better way to deal with SQL errors. PHP allows for throwing and catching exceptions (read more about it here) which I highly encourage all of us WordPress developers to get very familiar with if you aren’t already. I cooked up a simple plugin that basically extends the WPDB class redefining some select methods and allows me to capture the SQL errors for further processing.

Here’s how I can interact with this extended class in my plugins or theme files:

try {
    $transactions = $wpdb_e->get_results($query);
} catch (Exception $e) {
    // You can decide what to do with a SQL failure at this point, here are some ideas:
    if (WP_DEBUG) die($e->getMessage());
    echo 'We apologize but we were not able to retrieve your transactions';
    wp_mail('myname@mydomain.com', bloginfo('name') . ' has a SQL error', $e->getMessage());
}

if (empty($transactions))  echo 'You have no transactions as of yet';

But what do you do when you get a frantic client phone call reporting an issue on the live site? You can’t just enable WP_DEBUG for everybody and very likely break the site’s design as various error messages of sloppy plugin or WordPress’ core code might render.

Solution is simple: Enable WP_DEBUG just for you.

First, you’ll need to know your outgoing IP address. When I’m lazy I go to my friend Topher’s beautiful website which tells me my IP address.

Then edit your wp-config.php (CAREFUL) by replacing:

define('WP_DEBUG', false);

with

if ($_SERVER['REMOTE_ADDR'] == '123.123.123.123') {
	define('WP_DEBUG', true);	
} else {
	define('WP_DEBUG', false);
}

(don’t forget to replace 123.123.123.123 with your outgoing IP address)

By the way this is a great solution if you’re working from home or are tethering using your phone so that you are the only one coming from this IP address. If you’re in the same building with your client and try to debug the site without freaking out the CEO this might not be the best because odds are you and her are coming from the same IP address and she’ll see the same debug junk you do.

Please let me know if this was any helpful to you.

After spending some time on setting things up on my local box I uploaded it to a staging environment on our server and noticed a “mysql_real_escape_string() [function.mysql-real-escape-string]: Access denied for user: ‘nobody@localhost’” error.

If you look up mysql-real-escape-string in the php manual you’ll notice that the second and optional parameter is link_identifier (the db resource). The manual describes it as:

The MySQL connection. If the link identifier is not specified, the last link opened by mysql_connect() is assumed. If no such link is found, it will try to create one as if mysql_connect() was called with no arguments. If no connection is found or established, an E_WARNING level error is generated.

There might be another solution to the problem, for example changing a setting on the server, but if you don’t know how to change it or don’t have permissions to do so, you can modify code of Pods CMS so that anytime it calls mysql_real_escape_string it passes the link_identifier. Here is a patch I created.

It is quite simple. I created a folder in my Bookmarks Toolbar in Firefox and placed the bookmarks I use the most in it, as shown below:

The way to make this URL/blog independent is link to relative page, for example “Add New Post” points to post-new.php (which needs to point to www.andrejciho.com/wp-admin/post-new.php on this blog). The “relativeness” is done via javascript so the “Location” of the bookmark is:

javascript:window.location=’post-new.php’

So you can really roll your own bookmarks following the pattern above. The links in the

javascript:window.location=’post-new.php’
javascript:window.location=’edit.php’
javascript:window.location=’page-new.php’
javascript:window.location=’edit-pages.php’
javascript:window.location=’link-add.php’
javascript:window.location=’link-manager.php’
javascript:window.location=’plugins.php’

Note: These bookmarks only work once you are already logged in and within WordPress admin.

The only thing the code below does is that it enables the Excerpt field in the /wp-admin/page.php and saves it to the database. You still have to do the work of wiring it up into your template yourself. I might update it later.

<code>
<div id="postexcerpt" class="postbox <?php echo postbox_classes('postexcerpt', 'post'); ?>">
<div class="inside">
<textarea id="excerpt" cols="40" rows="4" name="excerpt"><?php echo $post-&gt;post_excerpt ?></textarea>
</div>
</code>

<code>
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');
</code>

Target Audience: Semi-advanced WordPress Implementors

License: GPL

Download placeholdersphp.txt (don’t forget to rename to placeholders.php or whatever)

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:
   

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

   
   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:
   

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

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.

<code>
#!/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
</code>

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

<code>

# 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

</code>

otherwise add the following:

<code>
# 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
</code>

…and now everybody continue here:

<code>
# 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
</code>

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:

<code>
#!/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
</code>

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

<code>
#!/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
</code>

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.