Unlike most plugins, Super Cache doesn't start working as soon as you activate it. You have to configure it first. You'll see a red-outlined warning message on your plugin list until you set up caching or deactivate the plugin, as shown in Figure 11-2.

Figure 11-2. WP Super Cache activation

Basic Settings

Go to Settings

For most sites, Half On mode will be fine for daily use. You can always toggle the status later if you need to.

Figure 11-3. Main Super Cache settings

Next, you should probably turn on the option labeled Don't cache pages for logged in users. This will ensure that as you're making changes to the site, you can view them immediately without waiting for the cache to refresh.

The next option will rebuild the cache when you add a post or page. This will ensure that your visitors will see the new content immediately, but it will also slow things down for you and your other users. Every time you publish something, the entire cache will have to be regenerated, and that can take a significant amount of processing power if you have a large site. My recommendation is to try writing a few posts with this option on and see how it goes. If your site becomes unusably slow, turn it off! Your visitors will just have to wait for the old cached pages to expire (within the time limit you'll set in just a moment) before they see your new posts.

Normally, a post's cached page will be rebuilt every time someone adds a comment. However, if you get so many comments that this would be counterproductive, you can turn on the cache rebuild option. New files will still be generated, but if a new comment comes in while the page is being generated, the viewer will see the older copy.

Coarse file locking is no longer recommended but is still available for backward compatibility. This option locks cache files while they are being rebuilt, but Super Cache now uses temporary files during the rebuild process, and coarse file locking is obsolete.

I do not recommend listing the most recently cached pages unless your site traffic is nominal and you're curious as to how the plugin is operating.

I'll talk about the mobile support option in the next section. For now, choose among the options I've gone over and press Update status.

When the page refreshes, you should see a section listing the contents of the cache (Figure 11-4).

Figure 11-4. Super Cache contents

In this section, you can manually delete the cache. This is helpful when you've changed some of the settings in the first section and you'd like the changes to take effect before the cached pages expire.

Other Settings

Under Expiry Time & Garbage Collection, you can choose how long your cached pages will last before they should be rebuilt. The default setting is 3600 seconds (one hour). You can lower this, but keep in mind that garbage collection requires server resources, just as rebuilding pages does. You should experiment with different settings to strike a balance between these two processes that doesn't overly tax your server.

Figure 11-5. Accepted filenames and rejected URIs in WP Super Cache

In the Accepted Filenames and Rejected URIs section of the Super Cache settings (Figure 11-5), you can specify certain pages that should not be cached. The page type options should look familiar; they're identical to the conditional tags you saw in Chapter 7. Of these, I would recommend checking Feeds. You can leave the rest of these settings on their default values in most cases. You'll change them when you enable mobile support in the next section.

At the bottom of the Super Cache settings screen, you'll have the option to directly cache a single file (Figure 11-6). If you write a post or a page that you know will bring in untold numbers of readers, you can head off the impending performance crisis by caching the page not in the usual hidden cache location, but right in your blog directory. How does this work? The WordPress rewrite rules—all of them, including Super Cache's—are set up to rewrite URLs only if the requested file or directory does not exist on the server. Therefore, if you create a cached page in the location that matches the permalink, the cached file will trump all rewrite rules. Since the server doesn't have to look through all those rewrites, it will be a little faster at serving up that particular file. And when you're looking at thousands of requests coming in, "a little faster" multiplies quickly into some significant performance.

Figure 11-6. Directly caching a popular file in WP Super Cache

The final checkbox in the main set of Super Cache options turns on mobile support. This doesn't mean much unless you're also running a second plugin that provides a mobile version of your site. To demonstrate how this works, I'll walk you through setting up Super Cache to work with WPTouch, the plugin that provides mobile versions of all sites on wordpress.com.

The WPTouch settings screen has a multitude of options. I won't discuss them all here; the ones I'm interested in showing you are in the Advanced Options box. Highlight the user agent strings as shown in Figure 11-7, copy them, and then head back over to the Super Cache settings.

Figure 11-7. User agent strings in the WPTouch Advanced Options

First, in order to support WPTouch, you'll have to select Half On mode. Full On mode circumvents the user agent checking that allows mobile version plugins to work, so you'll have to use Half On mode if you want to use Super Cache alongside a mobile plugin. That's OK; for most sites, Half On is sufficient. Next, check off mobile device support and press Update Status.

Now that mobile device support is on, you need to prevent Super Cache from displaying the cached pages to mobile user agents. Scroll down and find the Rejected User Agents box, as shown in Figure 11-8. Paste the user agent strings you copied from the WPTouch settings screen and remove the commas, placing each user agent on its own line. Press Save UA Strings, and you've enabled mobile support.

Figure 11-8. Pasting the mobile user agents into the Super Cache list of rejected user agents

However, there's one more step you need to take: deleting the existing cache. Any time you change the Super Cache settings, you need to delete the cache so the cached pages will be rebuilt according to your new settings. Once you've saved the UA strings, scroll back up to the Cache Contents section and press Delete Cache.

WPTouch is not the only mobile version plugin by any means, but mobile support in Super Cache works essentially the same way with all the other plugins.

The Login Lockdown plugin helps protect you from brute force password attacks by disabling the login function for a range of IP addresses after several failed attempts in a short period of time, as shown in Figure 11-10. (Using the default settings, it will lock you out for an hour after you've failed to enter the right password three times in five minutes.) If you're the sort of person who continually forgets your password, this might not be the plugin for you! However, since guessing at administrative passwords is a common method of breaking into WordPress sites, I recommend that you pick a password you can remember and install this plugin.

Figure 11-10. An account locked out by the Login Lockdown plugin

You have a few options when it comes to SSL. You can force WordPress to use SSL for logins only, or you can use SSL for all administration sessions.

With the SSL login option, your username and password will be handled in a secure transaction. All your other traffic, including the authorization cookies you receive from WordPress, will be sent in the clear.

With SSL-only admin sessions, your username, password, and all your authorization cookies will be encrypted. While this is obviously somewhat more secure, it is slower. For most situations, SSL logins should be sufficient. The login option allows users to choose whether or not to use SSL for the entire admin session or just the login.

Listing 11-1 shows the two lines you may add to wp-config.php to enable SSL support. Choose just one of these!

// https for all admin sessions:
define('FORCE_SSL_ADMIN', true);

//https required for login; optional for the rest of the admin session:
define('FORCE_SSL_LOGIN', true);

The Admin SSL plugin has always been a popular choice for managing SSL options, but as of this writing it has not been updated to work with version 2.9.

There are a number of ways hackers could use your .htaccess file maliciously. They could use rewrite rules to redirect your visitors to a site other than yours, but that's the sort of thing you'd notice immediately, and it doesn't happen very often. A subtle attack is more likely. One particularly nasty hack involves writing a file full of spam links to a writeable subdirectory deep in the WordPress package, then using PHP's auto_prepend_file or auto_append_file directives to include that file in your theme's index.php file. At first, it looks like someone has mauled your theme, but in fact the theme files haven't changed at all. This is the sort of attack that can leave you chasing your tail for hours, unless you realize that .htaccess is a big point of vulnerability in your installation.

WordPress needs write access to your .htaccess file only to make changes to your permalink structure. If you are using WP Super Cache, the plugin also requires write access to add the cache rewrite rules to the file. However, in both cases, if WordPress cannot write to the file, it will print the necessary rules on the screen and ask you to update the file manually. Therefore, I recommend that you adjust permissions on .htaccess so that your user account is the only one allowed to write to it. On UNIX-based operating systems, you can use the chmod 744 command to make sure you can write to it while everyone else can read only.

You can also modify the .htaccess file itself to secure your wp-config.php file. Normally, any visitor requesting your configuration file will just see a blank page, since the file doesn't echo anything to the screen. However, this addition to .htaccess prevents unwanted users from viewing your config file at all.

While .htaccess is not generally accessible through a browser, either, you can apply the same technique to give it a little extra protection, as shown in Listing 11-3. It looks a little recursive, but it works!

<Files wp-config.php>
order allow,deny
deny from all
</Files>

<Files .htaccess>
order allow,deny
deny from all
</Files>

For more security-related modifications to .htaccess, visit www.josiahcole.com/2007/07/11/almost-perfect-htaccess-file-for-wordpress-blogs/.

Your configuration file contains your database username and password, so it's important to keep this file secure. If you are installing WordPress in your web root directory (such as public_html), you can move your wp-config.php file to the parent directory—one that isn't readable from a browser—without changing any settings, as shown in Figure 11-11. WordPress will automatically recognize the file's new location.

Figure 11-11. Placing wp-config.php outside the public web directory

If you would prefer not to have WordPress's files cluttering up your site's root directory, or you would prefer a nonstandard location for your admin files as a security precaution, you can install WordPress in a subdirectory while keeping your site visible at the original location. For example, you can install WordPress at mydomain.com/blog but have the site appear at mydomain.com.

First, install WordPress in the subdirectory as you normally would. Then move the main index.php file and your .htaccess file from that subdirectory into the parent directory. In your example, you would install WordPress in the blog directory, then move index.php and .htaccess into the web root directory.

Open index.php in a text editor and edit the path to wp-blog-header.php. Add your subdirectory to the file path. In this example, you're installing WordPress in the blog subdirectory, so your line would read require('./ blog /wp-blog-header.php'), Of course, you can replace 'blog' with anything you wish.

Now log in to the site at its new address: mydomain.com/blog/wp-admin. Go to Settings General and change your WordPress address to the new one: mydomain.com/blog. Leave the Blog address alone, and save your changes. See Figure 11-12 for an example.

Figure 11-12. Changing the WordPress address without changing the blog address

Once you've saved these options, you'll be logged out. You'll have to log back in at the new location (http://example.com/blog/wp-admin/).

You can move your wp-content folder elsewhere if you like or rename it to something else. However, there are a number of constants related to the wp-content and plugins directories. To make sure your plugins continue working correctly, you should define all of these constants in your wp-config.php file. Add the constant definitions anywhere in the configuration file, as shown in Listing 11-4.

define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/files'),
define('WP_CONTENT_URL', 'http://example.com/files'),
define('WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/files/plugins'),
define('WP_PLUGIN_URL', 'http://example.com/files/plugins'),
define('PLUGINDIR', $_SERVER['DOCUMENT_ROOT'] . '/files/plugins'),

Once you've made these changes, you also need to change the location of your uploads directory. You might recall seeing this setting in Chapter 3. Go to Settings Media and change the paths as shown in Figure 11-13.

Figure 11-13. Changing the upload paths in Settings Media

Since the default table prefix is well known, changing it is also a good step toward protecting your site from basic SQL injection attacks. If you installed WordPress with your host's one-click installer (like Fantastico), you might not have had a choice about the prefix; otherwise, the prefix is an option you chose when you filled in your database username and password (Figure 2-5).

Changing it after the fact requires you to modify the MySQL tables directly. How to accomplish this depends on what sort of database access your host allows you. I'll demonstrate using PHPMyAdmin, the most popular interface. If you don't have easy access to your database, you can try changing the prefix with the WP Security Scan plugin.

For each table in the database, click either the Browse or Structure icon, then choose Operations from the row of tabs across the top of the screen. You'll see a screen like Figure 11-14. In the Table Options group, you'll see a field where you can rename the table. Replace 'wp' with your new prefix and press the Go button.

Figure 11-14. Renaming a database table

Once you've changed the tables, you'll need to update wp-config.php to reflect the change. The relevant portion of the configuration file is shown in Listing 11-5.

/**
 * WordPress Database Table prefix.
 *
 * You can have multiple installations in one database if you give each a unique
 * prefix. Only numbers, letters, and underscores please!
 */
$table_prefix  = 'mysite_';

Changing the table prefix will not protect you from a determined hacker; it's basically security through obscurity. It will stop some SQL injection scripts that rely on the ubiquity of standard WordPress installations. Making yours just a little bit different from everyone else's helps. However, you should be prepared to restore your database from a clean backup if something does go wrong.

Keeping regular backups of your database is essential if you want to be able to restore your site after something has gone wrong. Your hosting provider might do this for you, but it's still a good idea to keep your own copies in case something catastrophic happens.

There are several plugins you can use to back up your database right from the WordPress administration screens. My favorite is WP-DB-Backup. Once you've installed it, you'll find a new Backup item under the Tools menu. On the plugin's screen, you'll see checkboxes for each of the tables in your WordPress database. A standard installation will look like Figure 11-15. If your plugins have added tables of their own, those will be shown in the column on the right, and you can choose which ones you want to include in the backup. If you have several installations of WordPress sharing a single database with different table prefixes, the tables with the other prefixes will also appear on the right.

To make a backup, simply check the tables you want to include, decide whether to include spam comments and post revisions, and choose your destination. If you save the backup to the server, a gzipped SQL file will be saved to the directory shown (a subdirectory of wp-content).

Figure 11-15. Backing up the database with the WP-DB-Backup plugin

Figure 11-16. Scheduling options with WP-DB-Backup plugin

The lower half of the plugin's option screen (Figure 11-16) lets you schedule regular backups. However, these backups must be emailed to you. Make sure the email account you enter here can handle a lot of attachments (unless you're diligent about deleting old copies when the new one comes in.) The compressed file is not all that large, but over time the size will add up.

To restore from one of these backups, you'll need some sort of interface to your MySQL database other than WordPress itself. If your host offers PHPMyAdmin, for example, you could go to the Import tab and upload your backup file. Check your host's documentation to see how you can import SQL files into your database.

Don't forget to back up your files, too. Your uploaded media files probably wouldn't be very easy to replace, and if you've made any changes to your theme, you'll need copies of those, too. In general, it's a good idea to keep backups of your entire wp-content directory. You can automate this process with a tool like rsync (samba.anu.edu.au/rsync/) if you're feeling geeky, but I just use my FTP client's synchronize feature to download an updated copy every time I log in to make a change.