function wp_magic_quotes() {
    // If already slashed, strip.
    if ( get_magic_quotes_gpc() ) {
        $_GET    = stripslashes_deep( $_GET    );
        $_POST   = stripslashes_deep( $_POST   );
        $_COOKIE = stripslashes_deep( $_COOKIE );
    }

    // Escape with wpdb.
    $_GET    = add_magic_quotes( $_GET    );
    $_POST   = add_magic_quotes( $_POST   );
    $_COOKIE = add_magic_quotes( $_COOKIE );
    $_SERVER = add_magic_quotes( $_SERVER );

    // Force REQUEST to be GET + POST.
    $_REQUEST = array_merge( $_GET, $_POST );
}

You might discover this if you’re dealing with POST data, have long vowed to never turn on the “magic_quotes_gpc” setting (which is deprecated in PHP 5.3 and removed in PHP 5.4) and are manually escaping data with specific-use functions such as mysqli_real_escape_string(), only to discover that items are being double-encoded and/or you are being forced to use stripslashes (or the WordPress-specific stripslashes_deep).

Despite the resulting frustration and surprise to many developers, WordPress has reasons for keeping this seemingly odd behavior, and you can read about this here and here. In short, WordPress is trying to protect its millions of users from the onslaught of basic vulnerabilities that removing this behavior would cause. These vulnerabilities would be exposed in its huge database of publicly contributed plugins of varying qualities; some plugins don’t properly escape outside data.

At some point, this will need to be resolved, but if you’ve run into this problem when developing something in WordPress, now you know the 7+ years of history behind it!

Google Web Fonts is a free alternative that currently has 501 open source fonts to choose from. It’s not the perfect solution, but it is compatible with most browsers (going back to Internet Explorer 6+ and Firefox 3.5+, for example) and very easy to install on a website.

1. Select a font or fonts to use on the Google Web Fonts site, such as Francois One:

2. Include the relevant Google stylesheet call:

<link href="http://fonts.googleapis.com/css?family=Francois+One" rel="stylesheet" type="text/css" />

or:

Include the relevant Google JavaScript call:

<script type="text/javascript">
  WebFontConfig = {
    google: { families: [ 'Francois+One::latin' ] }
  };
  (function() {
    var wf = document.createElement('script');
    wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
      '://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
    wf.type = 'text/javascript';
    wf.async = 'true';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(wf, s);
  })();
</script>

3. Use the font in your stylesheets as per normal:

#header h1 { font-family:"Francois One", "Century Gothic", "Trebuchet MS", "Arial Narrow", Arial, sans-serif; }

Note that you should always use a list of fonts to provide fallback options if the technology and/or fonts are not supported.

One of the drawbacks of Google Web Fonts is what is commonly called “flash of unstyled content” — for some visitors, site elements will show in a fallback font before the selected font style is applied.

mysqltuner is easy to install and use. You can download the Perl file or use an installer, such as yum (yum install mysqltuner) on Red Hat and CentOS.

Then, you can run perl mysqltuner.tpl or mysqltuner, follow the prompts for the database credentials, and wait for the results:

-------- Performance Metrics -------------------------------------------------
[--] Up for: 145d 4h 29m 13s (17M q [1.388 qps], 290K conn, TX: 100B, RX: 27B)
[--] Reads / Writes: 97% / 3%
[--] Total buffers: 168.0M global + 2.8M per thread (151 max threads)
[OK] Maximum possible memory usage: 583.2M (14% of installed RAM)
[OK] Slow queries: 0% (199/17M)
[OK] Highest usage of available connections: 8% (13/151)
[OK] Key buffer size / total MyISAM indexes: 8.0M/3.5M
[OK] Key buffer hit rate: 100.0% (120M cached / 13K reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (751 temp sorts / 2M sorts)
[!!] Joins performed without indexes: 922026
[!!] Temporary tables created on disk: 35% (1M on disk / 4M total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (400 open / 238K opened)
[OK] Open file limit used: 5% (58/1K)
[OK] Table locks acquired immediately: 99% (33M immediate / 33M locks)
[!!] InnoDB data size / buffer pool: 3.0G/128.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    query_cache_size (>= 8M)
    join_buffer_size (> 128.0K, or always use indexes with joins)
    tmp_table_size (> 16M)
    max_heap_table_size (> 16M)
    thread_cache_size (start at 4)
    table_cache (> 400)
    innodb_buffer_pool_size (>= 3G)

Then, modify the settings you are comfortable with (typically in /etc/my.cnf or directly in the MySQL console to make temporary changes) and restart MySQL if necessary. You can then run mysqltuner at any time again in the future to get up-to-date recommendations.

Version 3.0 of the Google Analytics API 3.0 implements the OAuth 2.0 protocol. Among the benefits of OAuth are the fact that applications don’t have to store user credential information, and that users can revoke an application’s permissions at any time. However, the OAuth authorization process can be a bit more involved compared to some other API approaches. Also, the Google documentation is a bit light in terms of summarizing the process for server-side data access.

This how-to will use PHP to make the server-side calls to the Google Analytics API, which returns information in the JSON format. The code examples assume that you have cURL for PHP installed, and that you are using PHP 5.2.0 or later in order to use the json_decode function to parse the Google responses.

The setup steps are as follows: We will first set up the application in the Google API console. Then we’ll authorize the application with a Google account that has access to your site’s data. Using the resulting authorization code, we’ll request a refresh token from Google.

From there, you can build the application part: The refresh token is used to get access tokens that are finally used to actually read the data from Google. The details of implementing the data for the widget will be left up to you.

Google API console setup

Log in to the Google API console with a Google account. Note that the account that you log in with here does not need to be the same account that has access to your site’s data.

At the top of the left menu, create a new API project in the dropdown list:

Once your new project is created, select the “Services” page from the left menu, and turn on the Google Analytics API:

Note that there are per-day query limits for each API service.

Select the “API Access” page from the left menu, then create a web application client.

The name of the web application client will be displayed to the user (you) later when you authorize the application.

You will need both the client ID and client secret later, used in a PHP script accessible at the redirect URI, which you can rename to add the “.php” suffix as necessary.

If you need to access data server-side when an authorized user is not logged in, the web application client is not sufficient. You also have to create a server API key, limited to the IP address(es) of your server(s):

Authorize the application

Next, you’ll have to authorize the application to access your Google Analytics data. Remember that the account that created the API application does not have to be the same account that has access to your site’s data.

To prompt the user (you) to authorize your application, you have to build the authorization URL. First, however, we should build a very basic script at the configured redirect URI. The first iteration of the script has this code at http://www.theblog.ca/oauth2callback.php:

<?php
    var_dump( $_REQUEST );
?>

This is simply going to output to your screen the raw data that is being sent to the script via either POST or GET parameters. It is not the complete script yet, but will be used for illustrative purposes.

To build the authorization URL (which is a set of GET parameters at the URL https://accounts.google.com/o/oauth2/auth), you’ll need the following information, which is as follows for our example application:

• Callback URL: http://www.theblog.ca/oauth2callback.php
• Client ID: 63311316168.apps.googleusercontent.com
• Client secret: _iXNRZ5zMj1beMTab0wA4lXC

You will also need to specify a response type (always “code”), the type of access you are requesting (“offline” since we are accessing the data in the background without user intervention), and a “scope” specific to Google Analytics. See the Google API OAuth 2.0 documentation for information on the URL parameters and the resulting response.

For our example application, the authorization URL is:

https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=63311316168.apps.googleusercontent.com
&redirect_uri=http://www.theblog.ca/oauth2callback.php&access_type=offline
&scope=https://www.googleapis.com/auth/analytics.readonly

Get the permanent refresh token

When you access the authorization URL, it should prompt the user (you) to allow the application to access the site data. Once you click the authorization button, you should be redirected to your authorization URL, which you will discover has the “code” GET parameter. You will have to use the value of that GET parameter to ask Google for the refresh token.

Our example uses cURL to build the refresh token request, whose URL uses a similar format to the authorization URL, posting a set of fields to https://accounts.google.com/o/oauth2/auth. According to the Google API OAuth 2.0 documentation, you’ll need the client ID, client secret, and redirect URI information from before, as well as the “code” and an extra field “grant_type”, which is always “authorization_code”.

In oauth2callback.php, use the following code:

<?php
if( isset( $_GET['code'] ) )
{
    $ch = curl_init();
    $timeout = 5;
    curl_setopt( $ch, CURLOPT_URL, 'https://accounts.google.com/o/oauth2/token' );
    curl_setopt( $ch, CURLOPT_POST, 1);
    curl_setopt( $ch, CURLOPT_POSTFIELDS, 'code=' . $_GET['code']. '&client_id=63311316168.apps.googleusercontent.com&client_secret=_iXNRZ5zMj1beMTab0wA4lXC&redirect_uri=http://www.theblog.ca/oauth2callback.php&grant_type=authorization_code');
    curl_setopt( $ch, CURLOPT_RETURNTRANSFER,1 );
    curl_setopt( $ch, CURLOPT_CONNECTTIMEOUT, $timeout );
    $data = curl_exec( $ch );
    curl_close( $ch );
    $result = json_decode( $data, true );
    var_dump( $result );
}
else
{
    var_dump( $_REQUEST, true );
}
?>

Note that we are once again using a quick and dirty “var_dump” to output the returned information on the screen. If you visit the same authorization URL in your browser once again, you should get redirected to the same URL as before, but this time showing the response from the extra request for the refresh token. This response should, of course, contain the refresh token.

One extra note: to see which applications you’ve authorized under a Google account, you can go to this URL: https://accounts.google.com/IssuedAuthSubTokens, where you can also revoke access, forcing the application(s) to ask for your authorization again.

Use the refresh token and access the data

The refresh token is the most important piece of information, as it is essentially the permanent key that you need to access the Google Analytics data. (It is permanent as long as the user account that authorized the application does not revoke access.) The more accurate description is that the refresh token is used to get a time-limited access token, and that the access token is used along with the API key you had set up, valid only for specific IP addresses, to access the data.

In our example, the refresh token is:
1/7DRzjcqm-ypH9By1FrY3T-l_oSW3KdklC0LJuZLk5Q0

The following example script is a framework for what you would use with your website, and assumes that you are running it periodically, about once an hour, and therefore you need to ask for a new access token every time. A Google Analytics access token typically has an expiry of just over 1 hour, and thus you can use it for more than 1 request within that hour.

The script gets the top 10 pages based on pageviews for the past 1 day.

<?php

// First, ask for an access token using the refresh token
$ch = curl_init();
$timeout = 5;
curl_setopt( $ch, CURLOPT_URL, 'https://accounts.google.com/o/oauth2/token' );
curl_setopt( $ch, CURLOPT_POST, 1);
curl_setopt( $ch, CURLOPT_POSTFIELDS, 'refresh_token=1/7DRzjcqm-ypH9By1FrY3T-l_oSW3KdklC0LJuZLk5Q0&client_id=63311316168.apps.googleusercontent.com&client_secret=_iXNRZ5zMj1beMTab0wA4lXC&grant_type=refresh_token');
curl_setopt( $ch, CURLOPT_RETURNTRANSFER,1 );
curl_setopt( $ch, CURLOPT_CONNECTTIMEOUT, $timeout );
$data = curl_exec( $ch );
curl_close( $ch );
$result = json_decode( $data, true );

/*
You should get a response like this in the result:
{
  "access_token":"1/fFBGRNJru1FQd44AzqT3Zg",
  "expires_in":3920,
  "token_type":"Bearer",
}

Then, you can use that access token to build queries (see http://code.google.com/apis/analytics/docs/gdata/gdataExplorer.html or http://code.google.com/apis/explorer/#_s=analytics&_v=v3 for examples):
*/

if( isset( $result['access_token'] ) )
{
    // Look up only the last day of visits
    $endDate = date( 'Y-m-d' );
    $startDate = date( 'Y-m-d', strtotime( '-1 day' ) );
    /*
        "ids" value comes from this URL in the last portion of the URL, after the "p": https://www.google.com/analytics/web/#dashboard/default/a381759w192893p9122283/
        Or use http://code.google.com/apis/analytics/docs/gdata/gdataExplorer.html to show the GA ID for each your Analytics accounts
        "key" is the API key that you'd set up in the Google APIs console, restricted to certain IP addresses
    */
    $url = 'https://www.googleapis.com/analytics/v3/data/ga?' . 'key=AIzaSyDyWgfb45VYfVYdVnmpH4JZCCRNas5P0SE&ids=ga:9122283&start-date=' . $startDate . '&end-date=' . $endDate . '&metrics=ga:pageviews&sort=-ga:pageviews&dimensions=ga:pagePath&max-results=10';
    $ch = curl_init();
    $timeout = 5;
    curl_setopt( $ch, CURLOPT_URL, $url );
    curl_setopt( $ch, CURLOPT_HTTPHEADER, array( 'Authorization: Bearer ' . $result['access_token'] ) );
    curl_setopt( $ch, CURLOPT_RETURNTRANSFER,1 );
    curl_setopt( $ch, CURLOPT_CONNECTTIMEOUT, $timeout );
    $data = curl_exec( $ch );
    curl_close( $ch );
    $mostViewedRaw = json_decode( $data, true );
    var_dump( $mostViewedRaw );
}
?>

From here, it is up to you to use the returned data in ways that best suit your needs and application. For example, for performance reasons and API call limitations, you might want to run the script only about once an hour, and store the results in a database table or a data structure specific to your content management system. You might also want to do some extra filtering on the Google Analytics results to only display certain types of pages (omitting the front page, for example). Note that the resulting Google Analytics data is simply output to the screen in our example so that you can see its structure and determine how to use it to suit your needs.

The important elements on the code-side for such functionality is to use the built-in WordPress “login_redirect” filter, and to store information on whether or not the user has gotten the “first login” treatment. There are a couple of possible approaches to store the information, either in a cookie or in the user’s meta information (stored in the WordPress database in the “wp_usermeta” table).

Here is some sample code you can use in your theme’s functions.php file or in a plugin:

Cookie-based solution

// Send new users to a special page
function redirectOnFirstLogin( $redirect_to, $requested_redirect_to, $user )
{
    // URL to redirect to
    $redirect_url = 'http://yoursite.com/firstloginpage';
    // How many times to redirect the user
    $num_redirects = 1;
    // Cookie-based solution: captures users who registered within the last n hours
    // The reason to set it as "last n hours" is so that if a user clears their cookies or logs in with a different browser,
    // they don't get this same redirect treatment long after they're already a registered user
    // 172800 seconds = 48 hours
    $message_period = 172800;

    // If they're on the login page, don't do anything
    if( !isset( $user->user_login ) )
    {
        return $redirect_to;
    }

    $key_name = 'redirect_on_first_login_' . $user->ID;
    
    if( strtotime( $user->user_registered ) > ( time() - $message_period )
        && ( !isset( $_COOKIE[$key_name] ) || intval( $_COOKIE[$key_name] ) < $num_redirects )
      )
    {
        if( isset( $_COOKIE[$key_name] ) )
        {
            $num_redirects = intval( $_COOKIE[$key_name] ) + 1;
        }
        setcookie( $key_name, $num_redirects, time() + $message_period, COOKIEPATH, COOKIE_DOMAIN );
        return $redirect_url;
    }
    else
    {
        return $redirect_to;
    }
}

add_filter( 'login_redirect', 'redirectOnFirstLogin', 10, 3 );

Download the cookie-based redirect on first login plugin

User meta table based solution

// Send new users to a special page
function redirectOnFirstLogin( $redirect_to, $requested_redirect_to, $user )
{
    // URL to redirect to
    $redirect_url = 'http://yoursite.com/firstloginpage';
    // How many times to redirect the user
    $num_redirects = 1;
    // If implementing this on an existing site, this is here so that existing users don't suddenly get the "first login" treatment
    // On a new site, you might remove this setting and the associated check
    // Alternative approach: run a script to assign the "already redirected" property to all existing users
    // Alternative approach: use a date-based check so that all registered users before a certain date are ignored
    // 172800 seconds = 48 hours
    $message_period = 172800;

    // If they're on the login page, don't do anything
    if( !isset( $user->user_login ) )
    {
        return $redirect_to;
    }

    $key_name = 'redirect_on_first_login';
    // Third parameter ensures that the result is a string
    $current_redirect_value = get_user_meta( $user->ID, $key_name, true );
    if( strtotime( $user->user_registered ) > ( time() - $message_period )
        && ( '' == $current_redirect_value || intval( $current_redirect_value ) < $num_redirects )
      )
    {
        if( '' != $current_redirect_value )
        {
            $num_redirects = intval( $current_redirect_value ) + 1;
        }
        update_user_meta( $user->ID, $key_name, $num_redirects );
        return $redirect_url;
    }
    else
    {
        return $redirect_to;
    }
}

add_filter( 'login_redirect', 'redirectOnFirstLogin', 10, 3 );

Download the user-meta based redirect on first login plugin

Some extra notes:

• The code can be modified so that you don't actually redirect the user anywhere different than normal users, but set the user meta information or cookie and read that data to show a special pop-up or box to the user.
• WordPress has some default limitations disallowing redirects to URLs outside of your site's domain. If you need to redirect users elsewhere, you'll have to add the URLs to the "allowed redirect" list with code similar to this.
• If you have more sophisticated login redirect needs, you can adapt the code as an extension to this fully-featured redirect plugin.

Here’s a quick and simple, do-it-yourself guide to overriding a canonical URL whenever you make use of a specifically named custom field. As of WordPress 3.3, the default function that handles the canonical URL feature is rel_canonical in wp-includes/link-template.php:

function rel_canonical() {
    if ( !is_singular() )
        return;

    global $wp_the_query;
    if ( !$id = $wp_the_query->get_queried_object_id() )
        return;

    $link = get_permalink( $id );
    echo "<link rel='canonical' href='$link' />\n";
}

To override this function, you have to build your own copy of it in your theme’s functions.php file (or in a plugin):

// A copy of rel_canonical but to allow an override on a custom tag
function rel_canonical_with_custom_tag_override()
{
    if( !is_singular() )
        return;

    global $wp_the_query;
    if( !$id = $wp_the_query->get_queried_object_id() )
        return;

    // check whether the current post has content in the "canonical_url" custom field
    $canonical_url = get_post_meta( $id, 'canonical_url', true );
    if( '' != $canonical_url )
    {
        // trailing slash functions copied from http://core.trac.wordpress.org/attachment/ticket/18660/canonical.6.patch
        $link = user_trailingslashit( trailingslashit( $canonical_url ) );
    }
    else
    {
        $link = get_permalink( $id );
    }
    echo "<link rel='canonical' href='" . esc_url( $link ) . "' />\n";
}

// remove the default WordPress canonical URL function
if( function_exists( 'rel_canonical' ) )
{
    remove_action( 'wp_head', 'rel_canonical' );
}
// replace the default WordPress canonical URL function with your own
add_action( 'wp_head', 'rel_canonical_with_custom_tag_override' );

Then, on any post or page on which you want to override the canonical URL, add a custom field with the name “canonical_url” and the full URL value that you want to use:

In the future, there could be a more efficient, “pluggable” way to accomplish this. The current way that WordPress handles this, you could end up with multiple plugins overriding the canonical URL feature, resulting in duplicate or clashing custom functions (as an example, the Simple:Press forum plugin has its own override function). There’s an open ticket on the topic of adding a filter in the rel_canonical function to make this process cleaner. Some of the example code above was taken from a patch in that ticket.

Among many features, it has a nice autocomplete feature…

… and quite a few layout options:

The “two page” layout option is what enables you to have a search field in, for example, the header or sidebar of your site, and have the results display in a dedicated page. Google will provide you with JavaScript code snippets for your particular site to insert for the search form and the results page, and these should work out of the box.

With the provided JavaScript code, Google will automatically create the search field and form within a table. In my case all I wanted was to enable autocomplete and also to have the input field and the search button on separate lines, which was not possible with the automatically-generated code, since it puts the input field and search button in adjacent table cells. There is some decent API documentation and an example proof of concept (which also adds a basic Google search logo to the field background, and clears it when the cursor enters the field), but neither showed a basic, documented example.

Here’s some barebones example code — for the search form only — if you’re using the two-page layout with autocomplete enabled and want to use an existing form instead of having Google generate it. The only thing that you would absolutely have to change is the first parameter in the “attachAutoCompletion” function: your_custom_search_id, which is the ID that Google gives you for your particular site’s search engine.

<form id="yoursite-search" action="/search">
    <input id="yoursite-search-field" name="q" type="text" />  
    <input type="submit" value="Search" />
</form>

<script src="http://www.google.ca/jsapi" type="text/javascript"></script>
<script type="text/javascript">
    google.load( 'search', '1' );
    
    // Run this once the Google search JavaScript has loaded
    google.setOnLoadCallback( function() {
        // This makes your input field support autocomplete
        // The first parameter is your account identifier with Google Search
        // The second parameter is the DOM element of your search input field, which you could also grab with jQuery
        // The third parameter is the ID of your search form, not the actual DOM element. This is required so that when a user clicks on a search suggestion, the form gets submitted automatically
        google.search.CustomSearchControl.attachAutoCompletion(
            'your_custom_search_id',
            document.getElementById( 'yoursite-search-field' ),
            'yoursite-search' );
    });
</script>

Extra developer note: if you’re trying to style the auto-complete result dropdown, it’s populated in a result table with class “gsc-completion-container” and individual suggestions in spans, so you can change the font size, colour, and so on with specific style rules overriding the defaults, such as:

.gsc-completion-container span { font-size: 12px; }

There are several things to consider when logging information to a file, including date-stamping, basic formatting, and maximum log file sizes combined with automatic file rotation (when the log file reaches a certain file size, it is renamed to something like logfile.txt.1 and a new logfile.txt is started). This makes the log activities traceable, easy to read, and manageable on the server.

eZ Publish, an open source, enterprise-grade content management framework, has a general purpose eZLog class that already handles file logging. I’ve very slightly modified it for use within WordPress. Here is an example plugin that logs password change requests (normally sent as e-mails to the site administrator) to a file: peters_file_logs.txt

You can easily re-purpose the eZLog class for your own needs. Its write method simply takes the message to be logged, the log file name, and the path to the log file:

$message = 'Logging this';
$logger = new eZLog();
$logFile = 'wp-logs.txt';
$logPath = WP_CONTENT_DIR;
$logger->write( $message, $logFile, $logPath );


The code above would produce something like the following on a new line in wp-content/wp-logs.txt each time it is run:

[ Aug 21 2010 12:21:07 ] Logging this


You can of course customize the messages logged to add relevant information such as who performed the action, on what page, and so on. You can also customize the maximum number of rotated log files to keep and the maximum size of a log file.

If you have a MySQL database, a simple mysqldump command can save the database as a file and you can potentially e-mail it to yourself if it’s small enough. With or without the dumped database file, you then have to back up the rest of the files. Dropbox is a creative solution, but an easier and more direct solution is to use Amazon’s Simple Storage Service, otherwise known as Amazon S3. S3 is a service that’s part of the much hyped cloud computing, a land of seemingly infinite data and virtualized resources. Amazon S3 is cheap, well-documented, robust, easy-to-use, and there are many good scripts to interface with S3. It is more than just a good backup option, but for this post I’ll only talk about it within the context of backups.

Amazon S3’s costs are pay-per-use / pay-as-you-go and are split into a few categories:

• Storage: starting at $0.15 per gigabyte
• Data transfer in: Free until November 1, 2010; usually starting at $0.10 per GB
• Data transfer out: starting at $0.15 per GB
• Put and similar requests: 0.01 per 1,000 requests (if you have lots of files this will be the initial input)

Account management in Amazon breaks this down really well into minute details. My blog is relatively small, as I’ve only accumulated about 100mb of files in 4 years and the database is less than 2mb compressed. My monthly cost for daily and weekly backups is less than 20 cents.

Here are a few ways to get the most out of using Amazon S3 for backups:

• Back up only what you need to. Most CMSs let you place all your modifications in one or only a few places. In the case of WordPress, if your entire site is contained in plugins, themes, and uploads, you might only need to back up the wp-content/ folder, since you could restore the rest of the site from a downloaded instance of WordPress.
• Look into some of S3’s extra features, such as versioning and access control by IP as discussed in its FAQ
• Although Amazon S3 claims to be designed to provide “99.999999999% durability and 99.99% availability of objects over a given year”, it could still fail at the same time that your server fails. To mitigate this already-small risk, you could back up to multiple S3 regions, or look at a supplementary backup service such as Rackspace Cloud Files
• To actually access the backed up files, you can use the web-based AWS Management Console to view and download files, make them publicly accessible if needed, create “buckets” (top-level folders, which you can store in different physical locations). One of the more useful tools is a Firefox plugin called S3Fox Organizer, which lets you do much of the same stuff in a familiar explorer-like, two-panel interface (where you can drag-and-drop between your local file system on the left and the remote files on the right):

If you need a step-by-step process to using Amazon S3 starting with the sign-up process, check out this post. Below are my notes on how to use the free s3sync and s3fs tools for the actual backup process. Both assume that you’ve already created a bucket via the AWS Management Console or S3Fox Organizer, although you can also use both tools to create buckets.

s3sync

s3sync is a script written in Ruby. Ruby is usually installed on Linux servers and is easy to install if needed.

There are 3 main steps to start using s3sync.

Download and extract the script

You can currently download the latest version of s3sync at:
http://s3.amazonaws.com/ServEdge_pub/s3sync/s3sync.tar.gz

Then, you can extract the file through your control panel or with a simple tar command:

tar -zxf s3sync.tar.gz

Create a configuration file

You’ll need to make a copy of the included s3config.yml.example file. It is very simple and has only two required lines:

aws_access_key_id: your_access_key_id
aws_secret_access_key: your_secret_access_key

You can get both the access key ID and the secret access key on your account when you sign in to Amazon Web Services. Go to Account > Security Credentials.

As for where to place the configuration file, take a look at s3config.rb. Line 15 shows:

confpath = ["#{ENV['S3CONF']}", "#{ENV['HOME']}/.s3conf", "/etc/s3conf"]

So you can either place the s3config.yml file in a self-defined environmental variable (if you have command line access); or in your user’s home directory (usually /home/yourusername/.s3conf/s3config.yml) or in etc/s3conf/s3config.yml. If all else fails, you can just edit s3config.rb and hardcode a path!

Run the script

Before you set up your full backup, you can test that your credentials and connection are working properly by listing the buckets on your account. The command is simply:

./s3cmd.rb listbuckets

Note that s3cmd.rb needs to have executable permissions. If you don’t have command line / shell access to your server, you likely have access to a control panel where you can set up a cron job to execute s3cmd.rb. Just make sure that the cron job either refers to the full path where s3cmd.rb sits, or that it first changes directory (cd) into the folder to which you’ve extracted s3sync.

If all is well, you can then run the full backup script and then set up a cron job to back up your files daily and weekly (or at whatever frequency you’d like).

/path/to/s3sync/s3sync.rb -r /path/to/your/site theblog:daily

The command would back up your site to an existing bucket “theblog” under a sub-folder “daily”.

s3sync can also do many other Amazon S3 management tasks. Check the well-detailed README file for more information.

s3fs

s3fs is a simple solution for VPS and dedicated servers that enables you to mount an Amazon S3 bucket via a local FUSE file system. You can thus access your backup and sync it more or less locally.

(A quick note to VPS users — first, make sure that FUSE has been installed on the hardware node of the VPS setup! Your hosting company will have to do this for you. Otherwise, you might struggle with errors that seem to be file permission related (“fuse: failed to open /dev/fuse: Permission denied”) but that are in fact not simply chmod, chown, or user group fixable!)

If needed, install the fuse, fuse-devel, and curl-devel packages on your server. If you’re on Red Hat, Fedora, or CentOS, you can make use of yum:

yum install fuse
yum install fuse-devel
yum install curl-devel

Then, download and extract the latest s3fs source files from the s3fs website. You’ll have to compile the source, but that’s usually a simple “make -f Makefile” command. Then, move the s3fs binary into /usr/bin and you’re ready to mount the Amazon S3 bucket!

/usr/bin/s3fs name_of_bucket -o accessKeyId=aaaa -o secretAccessKey=aaaa /mount_path


As noted in the above s3sync notes, you can get both the access key ID and the secret access key on your account when you sign in to Amazon Web Services. Go to Account > Security Credentials.

You can use the friendly rsync command to produce daily, weekly, or other frequency of backups:

rsync -av --delete /path/to/your/site/ /mount_path/daily


You can specify to WordPress that you want to use a particular SMTP server to send e-mail. Plugins such as the aptly named WP Mail SMTP enable you to specify this, including a username and password if required.

However, up to and including WordPress 2.9, if you send mail via SMTP, it does not allow you to e-mail multiple recipients in the “to” field. Most users don’t ever have to deal with this limitation, but if you’re using WordPress in one of several ways (such as with a collaboration workflow), this can cause frustration.

Luckily, the wp_mail() function can be overridden. Specifically, you want to replace this code:


// Set destination address
$phpmailer->AddAddress( $to );


With this:


// Set destination address(es)
// Accept either a comma-separated list or an array
$to = explode( ',', implode( ',', (array) $to ) );
foreach ( $to as $to_recipient ) {
    $phpmailer->AddAddress( trim( $to_recipient ) );
}


The best practice in such a case is to use a plugin so that whenever you upgrade WordPress, you won’t lose changes. Here is an example of such a plugin, which copies the default wp_mail() function and makes the change as detailed above. To install it, just rename the extension to “php”, put it in your WordPress plugins folder, and activate it.