Digging into WordPress » performance

6 .htaccess Tricks for Better WordPress SEO & Security

Jeff Starr — Sat, 19 Mar 2011 23:59:08 +0000

Here are six htacccess tricks that will help improve the security and SEO quality of your WordPress-powered site. We do this using .htaccess to establish canonical URLs for key peripheral files, such as your robots.txt, favicon.ico, and sitemap.xml files. Canonicalization keeps legitimate bots on track, eliminates malicious behavior, and ensures a better user-experience for everyone. On the menu:

Canonical robots.txt
Canonical Favicons
Canonical Sitemaps
Canonical Category, Tag & Search URLs
Canonical Feeds
Simpler Login URL

Before making changes..

The .htaccess code in this post is designed to work when placed in the web-accessible root .htaccess file of your domain. Before making any changes to this file, make a good backup and keep it on hand just in case. Working with .htaccess is nothing to be afraid of, but it’s critical to not make any mistakes in syntax, spelling, or anything that’s not a comment (#). If you forget a dot working with CSS, your design might look messed up. If you forget a dot working with .htaccess your server will return a 500 – Internal Server Error. If this happens, don’t panic, just upload your backup and everything will be fine.

1. Canonical robots.txt

Help bots and visitors find your robots.txt file no matter what. Given that the robots.txt file should always be located in the root directory, you would think that this wouldn’t be an issue. Unfortunately, bad bots and malicious scripts like to scan for robots.txt files everywhere. Fortunately, this .htaccess snippet eliminates the nonsense by directing any request for “robots.txt” to the actual file in your root directory. If you’re sick of seeing endless requests for nonexistent robots files, this code’s for you:

# CANONICAL ROBOTS.TXT

 RewriteBase /
 RewriteCond %{REQUEST_URI} !^/robots.txt$ [NC]
 RewriteCond %{REQUEST_URI} robots\.txt [NC]
 RewriteRule .* http://example.com/robots.txt [R=301,L]

To use this code, replace example.com with your own domain and include in your web-accessible root directory. These directives collectively redirect all requests for any “robots.txt” file, with the exception of the actual, root robots.txt file. If you need to whitelist a similarly named file, just include the following line beneath the first RewriteCond, replacing the path and file name with your own:

RewriteCond %{REQUEST_URI} !/wordpress/robots.txt$ [NC]

Alternate Method: Instead of using Apache’s rewrite module, we can do the same thing with less code using mod_alias:

RedirectMatch 301 ^/(.*)/robots\.txt http://example.com/robots.txt

Either method is effective, but mod_alias is optimal for typical sites with only one robots.txt file. If you have multiple robots.txt files, the mod_rewrite method will enable complete granular control from the root .htaccess file.

2. Canonical Favicons

Avatars, gravatars, and favicons are a big hit with malicious scanners. Evil scripts like to traverse your directory structure with requests for commonly used images such as the ubiquitous favicon.ico. So just as with robots.txt, we can stop the madness and redirect any request for “favicon.ico” to the actual file in your root directory.

# CANONICAL FAVICONS

 RewriteEngine On
 RewriteBase /
 RewriteCond %{REQUEST_URI} !^/favicon.ico$ [NC]
 RewriteCond %{REQUEST_URI} /favicon(s)?\.?(gif|ico|jpe?g?|png)?$ [NC]
 RewriteRule (.*) http://example.com/favicon.ico [R=301,L]

To use this code, replace example.com with your own domain and include in your web-accessible root directory. These directives collectively redirect all requests for any “favicon” or “favicons” with a .png, .gif, .ico, or .jpg extension. To prevent an infinite request loop, the code includes an exception for the actual, root “favicon.ico” file. If you need to whitelist a similarly named file, just include the following line beneath the first RewriteCond, replacing the path and file name with your own:

RewriteCond %{REQUEST_URI} !/images/favicons.png$ [NC]

3. Canonical Sitemaps

Just as idiotic bots can’t seem to find your robots and favicon files, so too are they clueless when it comes to finding your sitemap, even when declared in the robots.txt file. Nefarious bots will ignore your robots suggestions and hammer your site with ill-requests for nonexistent sitemaps. This malicious behavior chews up system resources and wastes bandwidth. To eliminate the waste while helping stupid bots find your sitemap, slip this into your root .htaccess:

# CANONICAL SITEMAPS

 RedirectMatch 301 /sitemap\.xml$ http://example.com/sitemap.xml
 RedirectMatch 301 /sitemap\.xml\.gz$ http://example.com/sitemap.xml.gz

To use this code, edit each rule with your own domains and file paths. The first rule redirects all requests for your regular, uncompressed sitemap, and the second rule redirects all requests for your compressed (gzipped) sitemap. These rules are independent of each other, so feel free to remove either to suit your needs.

4. Canonical Category, Tag, and Search URLs

Out of the box, WordPress returns a 404 – Not Found for the following URLs:

http://your-domain.tld/blog/tag/
http://your-domain.tld/blog/search/
http://your-domain.tld/blog/category/

These are commonly requested URLs that may be leaking valuable page rank. As explained previously, you can use the following slice of .htaccess to redirect these URLs to your home page (or anywhere else):

# CANONICAL URLs

 RedirectMatch 301 ^/tag/$      http://example.com/
 RedirectMatch 301 ^/search/$   http://example.com/
 RedirectMatch 301 ^/category/$ http://example.com/

To use, place the previous code into your root .htaccess file and replace each example.com with the desired redirect location. Alternately, if WordPress is installed in a subdirectory, use this code instead:

# CANONICAL URLs

 RedirectMatch 301 ^/blog/tag/$      http://example.com/
 RedirectMatch 301 ^/blog/search/$   http://example.com/
 RedirectMatch 301 ^/blog/category/$ http://example.com/

Again, edit the examples with your actual URLs. A good place to redirect any juice or traffic from these three URLs is the home page. Hopefully future versions of WordPress will handle these redirects internally, but until then, this bit of .htaccess is a simple and effective solution.

5. Canonical Feeds

WordPress generates many different feeds for your site. The default feed configuration works great, but it’s worth including in this post a couple of useful .htaccess tricks:

Set up canonical feed types (e.g., deliver only RSS2 feeds and redirect other formats)
Setup FeedBurner feeds and redirect associated feed requests

Each of these techniques are easily achieved with a little .htaccess. Better grab a beverage..

Set up canonical feeds

WordPress provides feeds in four different formats: Atom, RDF, RSS, and RSS2. This variety was useful in the past to accommodate different apps and devices, but these days I think it’s safe to say that most readers and devices can handle any format you throw at it. So instead of having 4x the feeds, you can consolidate your feeds into a single format:

# CANONICAL FEEDS

 RedirectMatch 301 /feed/(atom|rdf|rss|rss2)/?$ http://example.com/feed/
 RedirectMatch 301 /comments/feed/(atom|rdf|rss|rss2)/?$ http://example.com/comments/feed/

This code will redirect requests for alternate feed formats to your canonical choice for both main-content feed and all-comments feed. To use this code, replace both of the target URLs with your own and place in the web-accessible root directory.

Redirect feeds to FeedBurner

Redirecting feeds to FeedBurner is another useful .htaccess snippet to have in your tool belt. Here are two snippets to do the job – one for main-content and another for all-comments feeds:

# REDIRECT to FEEDBURNER

 RewriteCond %{REQUEST_URI} ^/feed/ [NC]
 RewriteCond %{HTTP_USER_AGENT} !(FeedBurner|FeedValidator) [NC]
 RewriteRule .* http://feeds.feedburner.com/mainContentFeed [L,R=302]

 RewriteCond %{REQUEST_URI} ^/comments/feed/ [NC]
 RewriteCond %{HTTP_USER_AGENT} !(FeedBurner|FeedValidator) [NC]
 RewriteRule .* http://feeds.feedburner.com/allCommentsFeed [L,R=302]

The first block redirects all requests for your main-content feed, and the second block handles your all-comments feed. So to use, just replace the mainContentFeed and allCommentsFeed with the URLs of your associated FeedBurner feeds. You may also redirect special category feeds by replicating the pattern with another block of code:

 RewriteCond %{REQUEST_URI} ^/category/wordpress/feed/ [NC]
 RewriteCond %{HTTP_USER_AGENT} !(FeedBurner|FeedValidator) [NC]
 RewriteRule .* http://feeds.feedburner.com/specialCategoryFeed [L,R=302]

As before, just replace the URL of your FeedBurner feed in the RewriteRule and test accordingly.

Lastly, a cool .htaccess trick for a better user-login experience. A single line of code placed in your root .htaccess file is all it takes:

RewriteRule ^login$ http://example.com/wp-login.php [NC,L]

Edit the example.com with the domain/path of your WordPress installation. Now instead of typing “wp-login.php”, we just type “login” and whoop, there it is.

You could also use RedirectMatch to enable a login URL switch:

RedirectMatch 301 \@admin http://example.com/wp-admin

The @ prevents the rule from bothering anything else, and RedirectMatch picks up on the switch from anywhere in the site, so regardless of what page you’re on, you just append “@admin” to the URL and you’re there. I use this trick at http://perishable.biz if you want to see it work. Check the comments of Chris’ original post for good discussion and some more great ideas.

Pimp your wp-config.php

Jeff Starr — Wed, 25 Aug 2010 18:52:39 +0000

Easily, the most important file in your WordPress installation is the wp-config.php file. It serves as your site’s base configuration file, controlling key aspects of WordPress’ functionality and enabling WordPress to do mission-critical stuff like connect to the database. Without wp-config.php, WordPress simply won’t work. So whenever you install WordPress, one of the first things to do is pimp your wp-config.php.

And it’s pretty easy too – just get your database credentials in place and you’re done. The other settings available in the wp-config.php file will work just fine using the default values, but there are some cool things you can do to customize functionality, tighten security, and improve performance. Once you get the basics of wp-config.php, you can really pimp it out to do some awesome stuff. We’ll break this down into four basic parts:

There is no wp-config.php..

When you first download WordPress, the wp-config.php file isn’t included. Instead, you get a file named “wp-config-sample.php” (located in the root install-directory) that contains everything you need. Just rename the file to “wp-config.php” and delete the wp-config-sample.php file from the server if it’s already there. Here is a visual:

With the wp-config.php file now ready to go, it’s time to protect it..

Protect wp-config.php

The first thing you want to do with wp-config.php is protect it. Here is a great way to secure the file using .htaccess:


	Order Allow,Deny
	Deny from all

This code should be placed in an .htaccess file located in the directory that contains your wp-config.php file.

Once the .htaccess file is in place, ensure that permissions are chmod 640 for both files. This setting returns a “403 Forbidden” error to all external requests. Combining proper file permissions with .htaccess protection is an excellent way to secure your wp-config.php.

Main Configuration Settings

Now that wp-config.php is secure, it’s time to add the required database information and then customize for optimum performance. This section covers the first four configuration settings that you’ll find already included in your wp-config.php. Then in the next section, we’ll explore some awesome techniques and really pimp things out.

1) Database credentials

The first and only required step is to add your database credentials. This should appear after the PHP comments near the top of the file:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'database_name_here');

/** MySQL database username */
define('DB_USER', 'username_here');

/** MySQL database password */
define('DB_PASSWORD', 'password_here');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

For most servers, you’ll need only the first three bits of information: database name, username and password. If WordPress can’t connect after that, then you may need to change the hostname to whatever your host tells you. Only fiddle with the last two items – charset and collate – if you have need and know what you’re doing.

2) Authentication Unique Keys and Salts

Next up is a section for key/salt definitions. By default it looks like this:

/**#@+
 * Authentication Unique Keys and Salts.
 *
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
 * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
 *
 * @since 2.6.0
 */
define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

/**#@-*/

The eight definitions should be replaced with values generated via the official WordPress.org secret-key service. Visit that link, refresh the page a few times, and paste the results into place, like so:

/**#@+
 * Authentication Unique Keys and Salts.
 *
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
 * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
 *
 * @since 2.6.0
 */
define('AUTH_KEY',         ')` 4yDGc w=*:l8@RD167k0+/+@+rgo(mI-x<_~.=WtCm[qD8<3S)TsR}K~bMLNT');
define('SECURE_AUTH_KEY',  'zO?htRkV.k[vBqn<+.,lorpObkc?@|Vi+8`w=A9,|FjPB&5`5|9<[&&WaUB.pwTS');
define('LOGGED_IN_KEY',    'jtr|J-/.-:6CVh*8h.~bNzc3^#A9@hB9G3E/fx/>k)pmTHbES5^Rq(+EINCW w>8');
define('NONCE_KEY',        'O2Vz+br+`6MqQVv1{-g}sy -CF8M/tldEyWV[W}dnebd7m$6.P,m+.G6Ec]{V@Kl');
define('AUTH_SALT',        '>x,, 8wMLIJCH}i94Ib+}~lR%r_))x@LU3~YJwCok++xaSVE@[My(zAg!Fpi4{NR');
define('SECURE_AUTH_SALT', '7[,gAJ#TQmsw:$!R-n-r%4l:wy`~w0U-6wO2lmG8l5Xg21$J59T$T~)(h5m<5`|/|dVN{j[80QMV60');

/**#@-*/

Don’t use the example keys shown here though – the whole idea is to specify unique phrases to improve security. And it’s totally fine to replace these keys at any time – the worst that will happen is that currently logged-in users will need to log in again.

At this point, we have our database credentials and secret keys all ready to go. Next we want to further improve security by specifying a unique database prefix.

3) WordPress Database Table prefix

WordPress is a huge target for malicious scripts, hacks, and spam. One of the best ways to secure your WordPress database is to change the default table prefix. The default value, as seen below, is “wp_”:

/**
 * 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  = 'wp_';

This works, but as the default value, it is heavily targeted by malicious scripts and bad bots. Changing it to something unique essentially immunizes it against automated attacks on anything prefixed with wp_. The more random and unique the better, like a password: “h7G3vcDEo3jDf_” would be a good example. Note that ending the string with an underscore or some other easily recognizable character is a good way to keep things readable and easy to use.

4) WordPress Localized Language

By default WordPress uses the English language, but you can use any available language by following these steps. As a part of that process, you’ll specify your language in this part of the wp-config.php file:

/**
 * WordPress Localized Language, defaults to English.
 *
 * Change this to localize WordPress.  A corresponding MO file for the chosen
 * language must be installed to wp-content/languages. For example, install
 * de.mo to wp-content/languages and set WPLANG to 'de' to enable German
 * language support.
 */
define ('WPLANG', '');

It’s pretty straightforward: if nothing is specified (as is seen here), English is used; otherwise, you include the .mo language file you are using for the translation.

Additional Tips and Tricks

Now that you’ve got the database connection, security keys, table prefix, and language definition dialed in you’re ready to rock. Most WordPress sites are in great shape at this point, but there is much more that we can do with wp-config.php to maximize performance and make our lives easier.

Pimping Post Revisions

Recent versions of WordPress provides a post-revisioning system that enables users to save different versions of their blog posts and even revert to previously saved versions if necessary. Regardless of how much you do or do not despise this amazingly awesome feature, here are a couple of configurational definitions that may prove useful for you:

// Limit the number of saved revisions
define('WP_POST_REVISIONS', 3); // any integer, but don't go crazy

// Disable the post-revisioning feature
define('WP_POST_REVISIONS', false); // kill the bloat

Specify the Autosave Interval

In a similar vein as the post-revisioning feature is WordPress’ actually useful Autosave functionality. By default, WordPress saves your work every 60 seconds, but you can totally modify this setting to whatever you want. Don’t get too crazy though, unless you want to stress-out your server ;)

define('AUTOSAVE_INTERVAL', 160); // in seconds, don't go nuts

Automated Trash

Since WordPress 2.9, we’ve had the “Trash” feature to help prevent accidents. So now instead of deleting stuff like posts and comments, you send them to the Trash. By default WordPress deletes the Trash every 30 days, but you can set it to whatever you want by adding a line like this to wp-config.php:

define('EMPTY_TRASH_DAYS', 7); // empty weekly

To ride bareback without the safety net, you can disable the Trash feature by specifying a zero value:

define('EMPTY_TRASH_DAYS', 0); // disable trash

By disabling Trash, you’ll be deleting stuff permanently the first time, just like way back in the day.

Automatic Database Repair

WordPress 2.9 also gave us automatic database repair, which enables you to repair and optimize your database even when not logged in. This functionality should be used on an as-needed basis by first adding the following snippet to wp-config.php:

define('WP_ALLOW_REPAIR', true);

With that in place, visit the following URL to open the “Database Repair” page:

http://example.com/wp-admin/maint/repair.php

There you’ll be able to optimize and repair your database without needing to log in to WordPress. Important: While you have WP_ALLOW_REPAIR set in wp-config.php, the Database Repair page is openly accessible by anyone who finds it. So definitely remove the line to disable the auto-repair functionality after you are done using it.

Block External Requests

If you need to prevent WordPress from making external requests, add this snippet to wp-config.php:

define('WP_HTTP_BLOCK_EXTERNAL', true);

This will prevent things from happening that normally happen, like updates, dashboard feeds, and data reporting. Fortunately, it’s easy to whitelist (allow access) anything that is needed. Here is an example where we grant access to pingomatic.com:

define('WP_ACCESSIBLE_HOSTS', 'rpc.pingomatic.com');

Blog Address and Site Address

By default, these two configurational definitions are not included in the wp-config.php file, but they may be added to improve performance. These two settings were introduced in WordPress version 2.2 and override the database value without actually changing them. Example:

define('WP_HOME', 'http://digwp.com'); // no trailing slash
define('WP_SITEURL', 'http://digwp.com');  // no trailing slash

These settings should match those specified in your WordPress Admin. Once you set them in wp-config.php, they will be “grayed-out” when displayed in the Admin.

Debugging WordPress

Since WordPress version 2.3.1, users have been able to display certain errors and warnings to help with the debugging of their site. As of WordPress version 2.5, enabling error reporting raises the reporting level to E_ALL and activates warnings for deprecated functions. By default (i.e., if no definition is specified in the wp-config.php file), error reporting is disabled.

define('WP_DEBUG', true); // debugging mode: 'true' = enable; 'false' = disable

Adding that snippet to wp-config.php tells WordPress to display warnings and error messages with your web pages. This functionality is extremely useful but infrequently used by plugin and theme developers. If you’ve never enabled debugging, you’re in for a surprise – lots of errors even with some of the most popular plugins.

Error Log Configuration

Here is an easy way to enable basic error logging for your WordPress-powered site. Create a file called php_error.log, make it server-writable, and place it in the directory of your choice. Then edit the path in the third line of the following code and place into your wp-config.php:

@ini_set('log_errors','On');
@ini_set('display_errors','Off');
@ini_set('error_log','/home/path/domain/logs/php_error.log');

Error logs are powerful tools for keeping an eye on things and expediently resolving issues. It’s awesome that WordPress makes this so easy. We cover this in greater depth along with a couple of other methods in this post.

Increase PHP Memory

If you are receiving error messages telling you that your “Allowed memory size of xxx bytes exhausted,” this setting may help resolve the issue. As of WordPress version 2.5, the WP_MEMORY_LIMIT definition enables you to specify the maximum amount of memory that may be used by PHP. Here are some examples:

define('WP_MEMORY_LIMIT', '64M');
define('WP_MEMORY_LIMIT', '96M');
define('WP_MEMORY_LIMIT', '128M');

By default, WordPress will automatically attempt to increase PHP memory up to 32MB, so this setting is only needed for values higher than 32MB. Note that some web hosts disable your ability to increase PHP memory, so you may need to ask (or beg) for them to do it.

More info, tips and tricks for wp-config

For more information on the wp-config.php file, check out the WordPress Codex. We also have some awesome wp-config tricks and wp-config optimization tips for your WordPress enjoyment :)

Mastering WordPress Post-Revisioning and Auto-Save Features

Jeff Starr — Tue, 21 Jul 2009 06:06:25 +0000

Not everyone loves the post-revisioning feature of WordPress. In fact, some people can’t stand it. On the one hand, it’s nice to have a library of post-draft revisions to drudge through if you should ever make a mistake. On the other hand, multiple copies of every post is a great way to bloat your database with otherwise useless information.

Then, to complicate matters, WordPress’ auto-save functionality seems to have a mind of its own, at times interfering in the revisioning process even when post-revisioning has been disabled. Taken together, these post-revisioning and auto-save features have been known to confuse and frustrate WordPress users.

In this article, I explain how to take full control of WordPress’ version-revision and auto-save functionality. We’ll explore how these features work, why they don’t, when they clash, and how to stop the madness once and for all.

WordPress AutoSave Feature

WordPress implemented the AutoSave feature in version 2.1. Its function is to periodically (every 60 seconds by default) and automatically save your post while you work. Aside from the occasional hiccup, AutoSave works great and is a genuine benefit to most WordPress users. Unlike version revisioning, AutoSave does not create a new database entry for every save. Instead, a single database entry is created for each post and is updated with each AutoSave cycle. AutoSave isn’t perfect, however, and many folks find the time interval between saves either too brief or too long. Fortunately, WordPress makes it easy to modify the autosave interval with a simple configuration trick:

define('AUTOSAVE_INTERVAL', 300); // in seconds

Simply specify your desired autosave interval (in seconds) and add to your wp-config.php file to enjoy immediate results.

If you are one of the rare individuals who prefers to write without the autosave feature, here is an easy way to turn it off:

function disable_autosave() {
	wp_deregister_script('autosave');
}
add_action('wp_print_scripts','disable_autosave');

Just add that slice of code to your theme’s functions.php and say goodbye to Autosave!

WordPress Post Revisioning Feature

WordPress implemented Post Revisioning (aka Version Revisioning) in version 2.6. Its function is to record changes made to your documents by storing unique revisions in the database. While this feature may benefit a few users, it is widely understood that most WordPress users have no need for this level of functionality. In my humble opinion, the revisioning “feature” is overkill and completely excessive. It should have been left out of the core (i.e., released as a plugin) or there should be an Admin option to completely disable it. Post revisioning creates extraneous database content and, in my experience, functions inconsistently and unpredictably. Fortunately, there is an easy way to disable it by adding the following line to your wp-config.php file:

define('WP_POST_REVISIONS',false);

Or, if you prefer to keep the versioning functionality but limit the number of allowed revisions, add the following line to your wp-config.php file:

define('WP_POST_REVISIONS',3);

There is even a way to clean up your database by deleting all post-revision data. Andrei Neculau shows us how via this handy little SQL command:

DELETE a,b,c FROM wp_posts a 
LEFT JOIN wp_term_relationships b 
ON (a.ID = b.object_id) LEFT JOIN wp_postmeta c 
ON (a.ID = c.post_id) WHERE a.post_type = 'revision';

That magical query will nuke all post-revisions and associated meta-data from the database.

AutoSave + Versioning = Chaos?

So far, everything presented in this article is fairly straightforward. At this point, I would like to discuss a persistent post-reversioning issue that continues to rear its ugly head even when post revisioning is disabled via the previously prescribed method. Apparently, there is no way to disable WordPress’ post-revisioning functionality. It continues to work behind the scenes even after setting the WP_POST_REVISIONS variable to false in the configuration file.

Why do I say this? Because I have experienced the following series of events with several different WordPress installations:

Install WordPress
Disable Post-Revisioning
Write a post, save it, edit it
Notice a message that says something like this:

There is an autosave of this page that is more recent than the version below.

I can see how the timestamp on an autosave may conflict with the actual post during post editing, but when the database is examined after receiving this message, multiple post revisions are usually found. Apparently, WordPress is still saving post revisions behind the scenes even when revisioning has been disabled. With revisioning disabled, an option to compare reversions will never be shown explicitly, but the comparative functionality continues to operate. Further, there is no way to examine a list of the unintended post revisions. They exist in the database, but not in the Admin area. Thus, to see and compare these revisions, you need to do it manually. Here is a recipe for doing so:

Log into a database interface like phpMyAdmin
Run the following SQL query:

SELECT * FROM `wp_posts` WHERE post_type = "revision"

If this query returns results, WordPress has been saving revisions without your consent. To delete these revisions and all of their post data, see the method prescribed above. To see and compare different revisions in the WordPress Admin before taking action, continue with the following steps (screenshot provided for clarity):

Post ID columns as seen via phpMyAdmin

Determine the original post ID for each set of revisions
Determine the revision post ID of each individual revision
For each set of revisions that you would like to compare, enter the following URL in your browser’s address bar:

http://domain.tld/wp-admin/revision.php?action=diff&right=X&left=Y

Edit the domain to match your own, and then replace “X” and “Y” with the revision post IDs of any two revisions you would like to compare (order does not seem to matter).

Repeat these steps to compare as many revisions as is necessary. To view an individual revision, edit the following code with the ID of the desired revision and enter it into your browser’s address bar:

http://domain.tld/wp-admin/revision.php?revision=N

Once you have evaluated your autosaved revisions, they may be safely deleted, either all at once via the SQL query provided above, or else individually by simply clicking the delete button (the red “x” in phpMyAdmin) next to each revision in the wp_posts table.

Share your experience

I’m curious to know what other WordPress users think of the post-revisioning and auto-save features. Do you use them, and if so, how are they beneficial? Have you ever experienced unexpected or unexplainable behavior while writing a post while using post-revisioning functionality? It would also be interesting to find out how many people think the post-revisioning feature should have been included in the WordPress core.

Optimize WordPress Performance with the wp-config.phpÂ File

Jeff Starr — Wed, 08 Jul 2009 07:16:58 +0000

As you may recall, there are a ton of configuration tricks available for the WordPress wp-config.php file. So many in fact, that I think many people may have missed some of the choice definitions aimed at optimizing WordPress performance. In this post, we’ll explore the best ways to improve your site’s performance with WordPress’ wp-config.php file.

Hardcode your Blog Address and Site Address

Every time your site references your Blog Address or Site Address via WordPress template tags, a query must be made to your database. Update: apparently, the database is only queried for these values for each page load, not for every use of a template tag (thanks to Nathan Rice for the clarification). This happens more often than you may realize, as there are a number of template tags and parameters that access this information:

— Returns the URL of your site
— Returns the URL of your blog
— Displays the URL of your site
— Displays the URL of your blog

These tags display or return the associated information about your blog based on the information supplied in the General Settings panel in the WordPress Admin (Settings > General). Once entered in the Admin, your Blog Address and Site Address information is stored in the WordPress database and must be queried for every instance of each of the above template tags (and probably others as well). This may not seem like much, but the net effect on performance can be significant.

Fortunately, WordPress provides a way to eliminate these unnecessary database queries by enabling us to hardcode the values directly into the PHP construct. By defining the WP_HOME and WP_SITEURL constants in your site’s wp-config.php file, you can boost performance by reducing the number of queries made to your WordPress database. The following two definitions were introduced in WordPress version 2.2 and override the database values without actually changing them (note that you should not include a trailing slash at the end of either URL):

define('WP_HOME', 'http://digwp.com'); // blog url
define('WP_SITEURL', 'http://digwp.com'); // site url

Note that these settings should match those specified in your WordPress Admin. Also, once these values are defined in the configuration file, they will be “greyed out” in the Admin General Settings panel. Removal of the definitions will restore your ability to edit them via the Admin panel.

Hardcode your Template Path and Stylesheet Path

In a similar vein, we may further optimize performance by eliminating database queries for your site’s Template Path and Stylesheet Path. These two variables are defined based on the intrinsic structure of the WordPress installation as well as the name of the currently active theme. Many WordPress themes employ the following template tags to determine the values of these two variables:

— Returns the URL of the stylesheet directory of the active theme
— Returns the URL of the active theme’s directory
— Displays the URL of the stylesheet directory of the active theme
— Displays the URL of the active theme’s directory
— Returns the stylesheet directory path for the current theme
— Returns the absolute path for the template directory of the current theme

These tags function by assuming a standard directory structure for the WordPress installation (i.e., /wp-content/themes/) and then query the database for the value of the current active theme.

As with the predefined constants for Blog Address and Site Address (see previous section), you can also boost performance by eliminating database queries for your site’s Template Path and Stylesheet Path. The following two definitions were introduced in WordPress version 2.2 and override the database values without actually changing them (note that you should not include a trailing slash at the end of either URL):

define('TEMPLATEPATH', '/absolute/path/to/wp-content/themes/H5');
define('STYLESHEETPATH', '/absolute/path/to/wp-content/themes/H5');

Note that hardcoding these values will disable your ability to switch themes successfully via the WordPress Admin (Appearance > Themes). To do so, simply remove these two definitions, make the switch, and then edit them with the name of the new theme.

Define your four Salt Values

In my article, WordPress Configuration Tricks, I discuss the four security keys that were introduced in WordPress version 2.7. These four keys work silently in the background and protect your site by enhancing cookie encryption. The values for these four keys should be as random and complicated as possible, and are easily and automatically generated at the WordPress.org secret-key service. These predefined keys are placed into your wp-config.php file and may be changed at any time (thereby nullifying your visitors’ old cookies):

define('AUTH_KEY',        '#Sl2}YZFq~~.g=3HT 4+_;l7;#N~e]5._J!u*Y=qvFNhi(E{B9p% }+>rnh8t~Bl');
define('SECURE_AUTH_KEY', 'G/Huwa6Ri6zkkEqz (~*J$O8M72pe>+YrdW|+N_s2*qD%rM,;jF1%c3M!vQ>2`{i');
define('LOGGED_IN_KEY',   'r/N1ssKv7Vxnd2Oj!O3oP+/-[}eSboXBt=(%T`.N7aA%}I%|-):[&@D`r>:Rk_R#');
define('NONCE_KEY',       '~1 -@]b]LMEPzbv#)d1Cz(.7_KHVyP@UG[J&31_r5aC0WAWxpvGF;a^-@YnWt7x@');

Used in conjunction with these four definitions are four corresponding “salt” values. Ideally, these four salt values are as complex and random as the their four encryption-key counterparts. If the salt is not defined elsewhere, WordPress will query the database to generate their values. These generated values are then stored in the WordPress database and must be queried for every use of the encryption keys. Obviously, eliminating these database queries will serve us well in boosting the performance of our WordPress-powered sites. Thanks to the heads up from Peter van der Does, we now know that these four salt constants also may be defined in the wp-config.php file. Here is an example:

define('AUTH_SALT',        '>#m3m?hTy0Lg{|CYc5uuED{^f7)+hEbnh(E,<* 3:7DFcc$)SJS|=Tw^};@ti$714f:-zxjC');
define('LOGGED_IN_SALT',   ':-HRrr}>(+!tTZ/H$');

Exactly how do these salt values interact with their corresponding security keys? As Peter explains in his comment:

The NONCE_KEY, for example is used by the functions wp_nonce_field and check_admin_referer. The strings passed on by these functions are used to create a unique hash. The function used is to create this hash is hash_hmac and the key for this function is the NONCE_KEY + NONCE_SALT.

The bottom line here is that, by including these four salt definitions alongside your four security keys, you can improve site performance by eliminating extraneous database queries. You can even use the same secret-key service to generate the random data (just remember to only copy the salt values and not the entire block of code). And, as with the security-key definitions, the salt values may be changed at any time.