Digging into WordPress » optimization

Optimizing WordPress Permalinks

Jeff Starr — Wed, 21 Jul 2010 08:45:19 +0000

Configuring your WordPress permalinks is simple and only takes a second, but understanding what they are and how they work is key to setting up the best permalink structure possible. Your site’s permalinks are like the street address for your site’s web pages. They help both people and robots understand your site’s structure and navigate its contents. There is no “one magic permalink recipe to rule them all,” but keeping a few tips in mind makes it easy to optimize your WordPress permalinks. This DiW article shows you how..

WordPress makes it so easy

WordPress gives you full control over your permalinks. First, you have control over the general structure of your permalinks. Navigate to Settings > Permalinks and you will see several options for configuring your permalinks:

This is where you configure the general structure of your permalinks, as seen here with green underline. The portion underlined in red is post/page-specific, and will vary depending on your individual posts and pages. For DigWP.com, we chose the “month and name” format, which creates the following permalinks according to page-view:

Pages → http://digwp.com/about/
Tag Archives → http://digwp.com/tag/permalinks/
Category Archives → http://digwp.com/category/seo/
Single Posts → http://digwp.com/2010/05/wordpress-json-api-plugin/

..and so on. The main thing that you want to optimize at this point is the structure of your single-post permalinks. We chose to include the year and month for our posts, but it has been argued that it is better to omit the date entirely, using a “Custom structure” like so:

/%postname%/

This simple structure will produce single-post permalinks that include only the post name:

http://digwp.com/wordpress-json-api-plugin/

Without the additional date information, this structure is definitely shorter and cleaner, but there may be performance issues involved with using the “name-only” permalink format. Perhaps a good trade-off is to include either the post ID or the year:

/%post_id%/%postname%/
/%year%/%postname%/

I think either of these formats is probably an optimal way to configure your permalinks, but you also want to consider the frequency with which you’ll be posting content. It may be beneficial to further organize/classify your posts by including the month and day as well.

Certain “experts” will tell you that including extraneous date information is bad for SEO. The thinking here is that shorter URLs correspond to a more “flat” directory structure, which may provide some SEO benefits. I think the key is to use what’s necessary and omit any extraneous information.

Post/page-specific permalink structures (slugs!)

Once you’ve defined the general permalink structure in the WordPress Admin, you now have full control over your post-specific and page-specific permalink structures (as seen in the above screenshot, red underline). The part of your permalinks that is specific to each page or post is set in the Write/Edit Post screen in the WordPress Admin.

As shown in the above screenshot, WordPress provides an “Edit” button that enables you to modify the post-specific portion of your permalinks:

This feature enables you to customize your post/page-specific permalinks (also known as a post “slug”) according to your current permalink optimization strategy. Here are a few examples of commonly employed “post-slug” strategies:

Don’t even worry about it: Just let WordPress generate the post-specific slug based on the post or page title. Pros: this is certainly the easiest method of creating permalinks because no thought or action is required. Cons: depending on your post title, you could get some pretty long permalinks that look awkward and sloppy.
Remove extraneous words, leave only keywords: I have seen lots of blogs do this. It basically involves using the permalink that WordPress generates based on your title, then going in and removing words like “the”, “and”, and “you”, as well as other pronouns and such. Basically the idea is to leave only keywords in your permalinks. This helps keep them short, focused, and optimized for the search engines.
Customize every permalink with optimized keywords: This is the most labor-intensive strategy, but also potentially the most lucrative in terms of return on investment. The idea here is to research or otherwise understand which keywords your page is going to rank for, and then crafting a post-specific permalink structure based on those keywords. I have seen cases where this is taken to such an extreme that the post slug is completely different than the original post title.

The same goes for both posts and pages, regardless of which method you choose. Personally, I employ a combination of the first two strategies, whereby I go in, write a title, and then look at it and see if there is anything that could be improved. Usually there are several words that need to go, and possibly a keyword or two is added or removed. It’s funny because I usually end up rewriting some of the post content after spending some time actually thinking about what to name it.

There is always a better title than the one you think should be used.

The take-home message here is that, by paying attention to post titles and permalinks, you benefit from improved relevancy and potential SEO advantage.

Think of your users

When visitors land on your page, does the URL make sense? Does it correlate with the page title? These are some of the things to think about while setting up the general structure and post-specific slugs for your permalinks. Look at the permalink and ask yourself if it makes complete sense based on what the user will be looking at on the page. If you get too carried away with optimization, a user may get a sense that something isn’t quite right. Perhaps the post title says something like:

The Best Name-Brand Shoes

..but then the post slug looks something like this:

http://example.com/nike-adidas-reebok-zip-converse-shoes/

Perhaps a weak example, but it serves to illustrate the semantic gap that may occur when over-thinking your permalinks.

Think of the search engines

After considering your users, think about what the search engines are going to see when they come crawling your pages. Does the permalink match the content of the page? If you aren’t bothering with changing or optimizing your post slugs, then the answer is probably yes because WordPress generates the slug from the post title.

Also, as mentioned previously, some have argued in favor of a more “flat” directory structure in order to improve the SEO value of your blog. Whether or not this is actually the case is up for discussion, but it always makes sense to keep things as simple and concise as possible. So when deciding on the general structure for your permalinks, ask yourself if you really need a directory structure that is over three levels deep, like this:

domain/
	2010/
	      01/
		  1/
			post-slug-1
			post-slug-2
			post-slug-3
		  2/
			post-slug-4
			post-slug-5
			post-slug-6
		  3/
			post-slug-7
			post-slug-8
			post-slug-9
	      .
	      .
	      .
	2011/
	2012/

That’s going to give you some long permalinks, especially if you just use the default WordPress-generated slugs. When you look at a permalink using “year/month/name” format, you are essentially creating a virtual folder structure with a subdirectory for each part of the permalink – the year represents a directory in which you have a bunch of directories for each month, and within each of those directories there could be as many as 31 subdirectories for each day of the month. Then, within each day of the month, you have the post file itself, which may involve further subdirectories when paging is used. It can get crazy pretty quickly, and even though these subdirectories only exist virtually, to a search spider, there is no practical difference between virtual directories that are deeply nested and actual directories that are deeply nested.

When deciding on your permalink structure, ask yourself if you really need the date built into your permalinks. If you are posting prolifically, then you may want to include the date to help keep things organized. Anything less than a few posts a week, and I would opt to go with something simpler, like maybe “year/post” or “id/post”, as mentioned above.

Another thing that needs considering is the notion of “evergreen content”, which generally refers to content that is intended to stay “fresh” or relevant forever. Regardless how silly this SEO idea happens to be, you may want to consider either omitting or including some sort of date information based on how easily you want the publication date to be recognized by your visitors. I.e., if you are trying to “hide” the post date in hopes that your content will rank for a longer period of time, then you should omit it from the general permalink structure. Conversely, if you aren’t that slimy and want to make it easy for people to know when the post was produced, then throw a year or year/month into the mix. Whatever!

Think simplicity

When it comes to organizing the content of your site, there is a fine balance between being well-organized and keeping things simple. For example, the simplest structure would involve all posts and pages directly under the root domain. Clean and simple, but as time goes on and your post count gets into the hundreds or thousands, it could be a drag trying to sort through everything in a flat directory structure. Thus, another reason why breaking things down into categories or dates may help your long-term organizational and maintenance strategy.

For the post-specific portion of the permalinks (the post slug), it is also wise to keep things simple, but not at the risk of duplicating post names. For example, if you are writing a post about jQuery, you might have a post slug that is simply “jquery”, but it’s not going to be very helpful. First, it probably will never rank for that term. Second, telling users that the article is about “jQuery” is about as useless as it gets for both people and machines. So although that would be the simplest permalink possible, it is your interest to specify a little more clearly the content of your post. It just makes everything easier when meaning is readily available from your permalinks.

Do it before posting

Once you hit the “Publish” button, there is one thing that you shouldn’t change: the post slug. After publishing a post, you can easily and without consequence go back and change the title, meta title, post content, and just about everything else. But as soon as you change that permalink, you will need to 301 redirect the former URL to the new one in order to avoid perpetual 404 errors now and in the future. But, if you do need to change the permalink after posting, here is a simple line of HTAccess to help you eliminate any potential 404 errors:

Redirect 301 /old-post-slug/ http://example.com/new-post-slug/

So it’s really very simple: we first call the redirect directive, declare it as status 301 (permanent), and then add the old slug followed by the new one. That line will redirect any requests for your previously “slugged” URL to your new URL. For more information on htaccess redirects, check here and here.

Think of the keywords

As discussed, a great way to create focused, relevant permalinks is to remove the fluff and include only the important keywords. Granted, Google et al may already discount simple words such as “if”, “and”, and “the”, but you may also have keywords for which you don’t necessarily want to rank. For example, if you published a post on why Batman is terrible at website design, you may wind up with a auto-generated post slug like this:

batman-sucks-at-website-design

The word “at” should probably go, leaving this:

batman-sucks-website-design

But you may want to rank primarily for the term “website-design”, while “batman” is merely anecdotal, used as example, or whatever. Chances are low that anybody is searching for “batman website design”, but you never know.

WordPress removes stuff too

It should also be noted that WordPress removes certain things from your post/page slugs as well. Namely, any punctuation that is included in your post titles will be removed when WordPress automatically generates the post slug. This is both a good thing and a bad thing, depending on how you look at it. There are certain characters that are not allowed in any URL, so WordPress is wise to remove them for you. On the downside, removal of punctuation and the use of hyphens as replacements for periods can leave you with some rather odd-looking permalinks. For example, when writing about the latest WordPress update, say version 3.1 specifically, writing this as your title:

Introducing WordPress 3.1

..will give you this as the default post slug:

/introducing-wordpress-3-1/

..which to me just looks incorrect, like somebody wasn’t paying attention. Moral of the story: even if you’re too lazy to optimize your permalink slugs, it is wise to be mindful of what’s going on with the auto-generated stuff. In this regard, the WordPress devs made an excellent decision when they decided to move the permalink edit box to just below the post title. I do think it could be a little longer though. Most of the time you need to scroll sideways a bit to see what the entire permalink is looking like.

WordPress short URLs

What about Twitter-friendly “shortlinks” for your posts? Generally even the shortest permalink is going to be too long for tweeting, posting, sharing, etc. There are many ways to create short links, but WordPress actually has two built-in ways to create and display short URLs. Let’s take a look at each:

First is the “old” way of doing it. By default, WordPress uses a query-string format for your URLs. As discussed throughout this article, most WordPress users opt for the “pretty” permalinks instead of going with the “ugly” default URLs. But even when permalinks are used, WordPress still understands the default query-string URL structure, so you can include short links in your posts by doing something like this:

ID; ?>

Shortlinks have become so common that WordPress 3.0 now includes a built-in template tag for this very purpose. All you need to display shortlinks in WordPress 3 and above is include the following code in your theme template file(s):

Either of these methods will output a link with the following URL structure:

http://example.com/?p=77

Also note that WordPress 3.0 now includes a shortlink in the section of your posts and pages, something like this:

This is in addition to the canoncial link tag that is also included in the section.

WordPress canonical links

WordPress canonical URLs are included in the section of your posts and pages. They look like this:

These canonical links help the search engines better understand the structure and content of your site. By including the canoncial element in your pages, you are telling Google et al which pages are the actual, canonical pages for your site. There are several cases where this is extremely helpful, namely:

Social media linking often involves shortlinks – specifying a canonical link helps ensure that all of the shortlinking is sorted out and that your actual page gets the credit
Shopping cart sites that feature lots of query-string URLs – when many links look practically identical, having a canonical link specified helps to sort things out
Guest posting and other duplicate content – when your content is featured (or scraped) in multiple places around the Web, it is nice to have a clear signal as to which case is canonical

You don’t need htaccess to make changes

What if you want to change the general structure of your permalinks? How do you go about doing that without losing your page rank while creating a mess of 404 errors? In older versions of WordPress, this was a real concern. Many folks began with full-date permalinks and then later realized they wanted cleaner, shorter, “dateless” permalinks instead. To do this back in the day, some HTAccess trickery was required to keep the old links from going nowhere.

Fortunately those days are long gone, as WordPress now automagically handles all the redirecting for you when making changes to the general structure of your permalinks (via the Settings > Permalinks options in the WordPress Admin). All you need to do is change the setting to whatever structure you would like and WordPress takes care of the rest. Just remember to backup your database and htaccess file before making any changes.

Optimizing WordPress Post Navigation

Jeff Starr — Mon, 14 Dec 2009 06:20:55 +0000

Implementing a solid set of navigational links for your WordPress site is one of the best ways to encourage visitors to stick around awhile and check out additional content. As discussed in our definitive guide to WordPress post navigation, there are essentially three different types of navigational tags for WordPress:

Index and archive navigation: posts_nav_link()
Index and archive navigation: previous_posts_link() and next_posts_link()
Single-view posts navigation: previous_post_link() and next_post_link()

Without repeating ourselves, suffice it to say that previous_posts_link and next_posts_link are perfect for setting up separate links for index, category, and archive pages. Likewise, previous_post_link and next_post_link are perfect for setting up separate links for single-view post navigation.

Now that we’re on the same page, so to speak, let’s look at how these tags are typically used and how to improve and optimize their functionality..

Improving the `next_posts_link` and `previous_posts_link` (for archive views)

Here are the archive/category navigation links as provided in the default theme that is packaged with WordPress:

Functionally, this setup works great — the previous-post link is displayed only when there are previous posts, and likewise the next-post link is displayed only when there are newer posts. As convenient as this is, it doesn’t help us with the accompanying markup used to display the links. Any CSS styles applied to the

s in our example will be displayed even when the links themselves aren’t displayed. This can result in several issues, including:

Padding and margins may prevent proper display when links are missing
Background images used to enhance the navigational links will still be displayed
Additional text and/or characters will still be displayed even when links absent
Use of any markup other than
s may result in validation errors when left empty

And we’re not just talking about the front page and last page here — any category, tag, search, date, or author archive will also display botched navigational elements and design flaws when previous and next posts are unavailable. Your main index may always have previous posts, but what about that guest author archive, 2005 archive, and search results? Such pages are frequently one of a kind. Even worse, by defualt, your Home page will never have a page after it, which means a broken navigational element right there on the most important page of your site. Not good.

The easiest way that I have found to prevent this from happening when the “next” link is not generated is to simply test the $paged variable for a value greater than 1:

 1) { ?>

By checking if there are more posts to display before calling the navigational code, this technique will prevent empty elements from wrinkling your home page and archive pages. Another way of doing this is shared by Eric Martin. Just place this snippet into your active theme’s functions.php file:

// return TRUE if more than one page exists
function show_posts_nav() {
	global $wp_query;
	return ($wp_query->max_num_pages > 1);
}

And then use the function to conditionally display navigational code in your archive.php and other archive-view template files:

Not sure if there is any benefit to adding the extra code in the functions.php file, but I thought I would share that technique with you as another possible solution (hey you never know).

Also, a great way to improve the functionality and presentation of your blog is to provide some alternate navigational elements to help keep things flowing and balanced on the front pages of your site. For example, at Perishable Press, if the “next” link isn’t displayed, I provide a link to my site Archives:

 1) { ?>

	
		
		
	



	
		
		Site Archives »

And of course, anything is possible here; the key is to keep things consistent, logical, and well-styled. Now let’s see how to improve navigational display for single-post views.

Improving the `next_post_link` and `previous_post_link` (for single views)

Fortunately, the situation is much improved for single-post navigation. By default, the next_post_link and previous_post_link provide parameters that enable us to avoid the “empty-element” syndrome. Let’s take a look at these parameters:

The format and link parameters enable us to do something like this:



	Previous entry: %link', '%title'); ?>
	Next entry: %link

', '%title'); ?>

Here we have replicated the markup in our previous examples, but have done so conditionally, such that the markup will only be displayed when the corresponding link is displayed, thereby enabling us to avoid empty elements when either the previous or next post-link is not displayed. As you can see, the single-post nav tags enable us to include the surrounding (X)HTML and text within the function itself. We can do similar tricks with the actual link title. Check out our definitive guide to post navigation for more information.

Conditional navigational display for single posts

Just as we did with the archive nav tags (next_posts_link and previous_posts_link), we can implement some conditional functionality to display alternate navigational links when viewing the first and last posts in any archive view. For example, if I also wanted to provide a link to my Site Archives when the “next” and/or “previous” links were not displayed, I could do so using the following code:



	Previous entry: %link', '%title'); ?>
	Site Archives'; 
	} ?>

	Next entry: %link', '%title'); ?>
	Site Archives'; 
	} ?>

Here we are using the get_adjacent_post function to determine whether or not there is a post before/after the current post. This enables us to conditionally display some sort of fallback navigation in the first- and last-post case. The get_adjacent_post tag accepts the following parameters:

$in_same_cat – specifies whether or not the adjacent post should be in the same category
$excluded_categories – a comma-delimited list of categories for which the adjacent post should not belong
$previous – specifies whether the previous post should be displayed

That does it for the single-post views. Let’s wrap things up with a way to consolidate and streamline the single and archive navigational methods..

Optimize your theme’s navigational code

Finally, here is a nice way to clean up your theme files and source code. The first step is to streamline production by getting more fine-grained with includes. This basically means that you can clean things up and save time/effort by moving your navigational code to its own file, named something like “navigation.php” or similar. You would then remove your nav code from your other template files and consolidate them all into that one location. You would then include navigation.php in any theme file where you want the navigation section to appear:

This technique makes maintaining and modifying your code a breeze. And, you can even streamline things further by using some conditional logic to display either archive or single navigation depending on the current page being viewed:



	
		Previous entry: %link', '%title'); ?>
		Next entry: %link', '%title'); ?>

This is a great way of staying organized and reducing your workload during theme development and maintenance.

Wrap up

The tips and tricks in this article will help you create a consistent, logical, and design-friendly set of navigational links for your next theme design. In the process, you can also streamline production by consolidating your code into a single file and using conditional logic to deliver the appropriate code.

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.

WordPress Configuration Tricks

Jeff Starr — Mon, 29 Jun 2009 14:53:51 +0000

Many WordPress users know the wp-config.php file as the key to the WordPress database. It is where you set the database name, username, password, and location. You know the one:

The wp-config.php file contains the information required for WordPress to connect to the database

But what many users don’t know is that the wp-config.php file may be used to specify a wide variety of configurational settings, enabling you to improve the functionality, performance, and security of your WordPress-powered site. In this article, I share as many of these configurational tricks as I have been able to collect over the years. This guide covers everything in the WordPress Codex, as well some additional tricks that you probably haven’t seen before. If you know of any other WordPress configuration tricks, share them in the comments and I will add them to the post.

Database Credentials *

This set of four configurational definitions are required for WordPress to connect to the database:

define('DB_NAME', 'database-name');
define('DB_USER', 'database-username');
define('DB_PASSWORD', 'database-password');
define('DB_HOST', 'localhost');

Database name, username, and password should be readily available to you during database creation, but the DB_HOST value may be more difficult to acquire. Most commonly, this value is simply “localhost”, but if that doesn’t work, here are a few other values to try:

1and1 Hosting — db12345678
DreamHost — mysql.example.com
GoDaddy — h41mysql52.secureserver.net
ICDSoft — localhost:/tmp/mysql5.sock
MediaTemple (GS) — internal-db.s44441.gridserver.com
Pair Networks — dbnnnx.pair.com
Yahoo — mysql

You can even specify an alternate port for your database server. Here are two examples:

define('DB_HOST', 'localhost:1234');
define('DB_HOST', 'mysql.domain.tld:1234');

Another cool trick is to detect the database server value automatically:

define('DB_HOST', $_ENV{DATABASE_SERVER});

If all of these fail, or if you are still having problems, consult your hosting provider for assistance.

Database Character Set and Collation *

As of WordPress version 2.2, you may specify a character set for your MySQL database tables. Generally, there is no reason to change the default character-set value of UTF-8, which is usually perfect because it supports all languages. Note that you should only use this definition if it already exists in your wp-config.php file. Here is the default (and recommended) setting:

define('DB_CHARSET', 'utf8');

WordPress version 2.2 also enables you to specify the collation, which is the sort order of your database character set. Setting the collation is generally handled automatically by MySQL according to the character set, which is enabled by leaving the collation value blank as done in the default setting for this definition. Note that you should only use this definition if it already exists in your wp-config.php file. Here is the default (and recommended) setting:

define('DB_COLLATE', '');

Security Keys *

As of WordPress 2.7, there are four security keys available that are designed to insure better cookie encryption. These keys work silently in the background and should be as random and complicated as possible (no, you will never need to remember them). The easiest way to generate these keys is to do it automatically at the WordPress.org secret-key service. Simply visit that link and copy/paste the results into your wp-config.php file. Note that these keys may be changed anytime, and doing so will invalidate all of your users’ existing cookies so that they will have to re-login to your site.

define('AUTH_KEY', ':dr+%/5V4sAUG-gg%aS*v;&xGhd%{YV)p:Qi?jXLq,6L9v\"6C89NH?ui{*3\\(t09mumL/fF');

Database Prefix *

The database prefix setting is particularly useful for increasing the security of your site and for housing multiple WordPress installations in a single database. By changing the default value of “wp_” to something randomly unique, you mitigate commonly targeted attack vectors and improve the overall security of your site. Here is the default setting:

$table_prefix  = 'wp_';

There are tons of crackers out there probing sites for this default database prefix. Changing it to something like “x777_” is a good way to avoid these types of targeted attacks.

You can also use this setting to install multiple instances of WordPress using the same database. Simply specify a unique database prefix for each installation:

$table_prefix  = 'wp1_'; // first blog
$table_prefix  = 'wp2_'; // second blog
$table_prefix  = 'wp3_'; // third blog

Language Settings *

WordPress makes it possible to specify a language-translation file and its associated directory. The language translation file is assumed to be of the “.mo” variety, and its default location (if no explicit path is specified) is assumed to be wp-content/languages (first) and then wp-includes/languages (second). Here is the default setting:

define('WPLANG', '');
define('LANGDIR', '');

Directory Settings *

Technically not something that you should need to mess with, the default wp-config.php file contains a few lines that specify the absolute path and include the settings file. I include them here for the sake of completeness:

/** WordPress absolute path to the Wordpress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

Blog Address and Site Address

Now we’re getting to some of the cool stuff. By default, these two configurational definitions are not included in the wp-config.php file, but they should be added to improve performance. These two settings were introduced in WordPress version 2.2 and override the database value without actually changing them. Adding these two definitions in your site’s wp-config.php file reduces the number of database queries and thus improves site performance. These settings should match those specified in your WordPress Admin. Here is an example (note that you should not include a trailing slash at the end of either URL):

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

A cool trick is to set these values dynamically by using the global server variable:

define('WP_HOME', 'http://'.$_SERVER['HTTP_HOST'].'/path/to/wordpress');
define('WP_SITEURL', 'http://'.$_SERVER['HTTP_HOST'].'/path/to/wordpress');

Template Path and Stylesheet Path

As with the predefined constants for blog address and site address (see previous section), you can also boost performance by eliminating database queries for the template path and stylesheet path for your site. Here are the default values for these two definitions:

define('TEMPLATEPATH', get_template_directory());
define('STYLESHEETPATH', get_stylesheet_directory());

As is, these two definitions are still querying the database, but we can eliminate these extraneous queries by hardcoding the values into place:

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

Disable Cache and Cache Expiration

These two options apply to older versions of WordPress that are still using the default object-based caching mechanism. The first definition enables you to enable or disable the cache, while the second definition enables you to specify the cache expiration time.

Enable the cache

define('WP_CACHE', true);      // enable the cache
define('ENABLE_CACHE', true);  // enable the cache
define('CACHE_EXPIRATION_TIME', 3600); // in seconds

Disable the cache

define('WP_CACHE', false);     // disable the cache
define('DISABLE_CACHE', true); // disable the cache

Specify Cookie Domain

There are several reasons why you want to specify a cookie domain for your site. A common example involves preventing cookies from being sent with requests for static content on subdomains. In this case, you would use this definition to tell WordPress to send cookies only to your non-static domain. This could be a significant performance boost. Here are some examples of setting various cookie path and cookie domain information:

define('COOKIE_DOMAIN', '.digwp.com'); // don't omit the leading '.'
define('COOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_option('home').'/'));
define('SITECOOKIEPATH', preg_replace('|https?://[^/]+|i', '', get_option('siteurl').'/'));
define('PLUGINS_COOKIE_PATH', preg_replace('|https?://[^/]+|i', '', WP_PLUGIN_URL));
define('ADMIN_COOKIE_PATH', SITECOOKIEPATH.'wp-admin');

Override File Permissions

If your web host’s default file permissions are too restrictive, adding these definitions to your WordPress configuration file may help resolve the issue. Note that you don’t need the quotes around the permission values. Here is an example:

define('FS_CHMOD_FILE', 0755);
define('FS_CHMOD_DIR', 0755);

View All Defined Constants

Need to view all predefined constants? Good news, this PHP function will return an array of all currently defined constants:

print_r(@get_defined_constants());

Custom User and Usermeta Tables

What about custom user and usermeta tables? Yep, you can do that too, with the following definitions:

define('CUSTOM_USER_TABLE', $table_prefix.'my_users');
define('CUSTOM_USER_META_TABLE', $table_prefix.'my_usermeta');

FTP/SSH Constants

This set of configurational definitions is designed to help users locate and utilize FTP/SSH connections. Here is a example set of predefined constants for FTP/SSH updates:

define('FS_METHOD', 'ftpext'); // forces the filesystem method: "direct", "ssh", "ftpext", or "ftpsockets"
define('FTP_BASE', '/path/to/wordpress/'); // absolute path to root installation directory
define('FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/'); // absolute path to "wp-content" directory
define('FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/'); // absolute path to "wp-plugins" directory
define('FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub'); // absolute path to your SSH public key
define('FTP_PRIVKEY', '/home/username/.ssh/id_rsa'); // absolute path to your SSH private key
define('FTP_USER', 'username'); // either your FTP or SSH username
define('FTP_PASS', 'password'); // password for FTP_USER username
define('FTP_HOST', 'ftp.domain.tld:21'); // hostname:port combo for your SSH/FTP server

Moving Your wp-content directory

As of WordPress version 2.6, you may change the default location of the wp-content directory. There are several good reasons for doing this, including enhancement of site security and facilitation of FTP updates. Here are some examples:

// full local path of current directory (no trailing slash)
define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'].'/path/wp-content'); 

// full URI of current directory (no trailing slash)
define('WP_CONTENT_URL', 'http://domain.tld/path/wp-content');

You may also further specify a custom path for your plugins directory. This may help with compatibility issues with certain plugins:

// full local path of current directory (no trailing slash)
define('WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'].'/path/wp-content/plugins'); 

// full URI of current directory (no trailing slash)
define('WP_PLUGIN_URL', 'http://domain.tld/path/wp-content/plugins');

Dealing with 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 get too crazy

Disable the post-revisioning feature

define('WP_POST_REVISIONS', false);

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

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); // enable debugging mode
define('WP_DEBUG', false); // disable debugging mode (default)

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 file:

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

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. 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 beg for them to do it. Here are some examples:

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

Save and Display Database Queries for Analysis

This technique is perfect for saving database queries and displaying the information for subsequent analysis. The process saves each query, its associated function, and its total execution time. This information is saved as an array and may be displayed on any theme template page. To do this, first add the following directive to your wp-config.php file:

define('SAVEQUERIES', true);

Then, in the footer of your active theme, place the following code:

// display the query array for admin only
if (current_user_can('level_10')) {
	global $wpdb;
	echo "";
	print_r($wpdb->queries);
	echo "";
}

Here is a single-line version of this function:

"; print_r($wpdb->queries); echo "

"; } ?>

Control Proxy Access

Since WordPress 2.8, the configuration file may be used to define constants involved with blocking, allowing and filtering access to specific hosts from behind a proxy server. For example, if you host your WordPress site on an intranet network, you may prevent access to all external hosts and only allow requests from localhost and your blog using the first definition below. You may also allow specific hosts access with a comma-separated list of allowed hostnames, as demonstrated in the third definition below. Note that you should allow api.wordpress.org access to ensure proper functionality of core files and plugins.

define('WP_HTTP_BLOCK_EXTERNAL', true);  // block external requests
define('WP_HTTP_BLOCK_EXTERNAL', false); // allow external requests
define('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org'); // whitelist hosts

Whew! I’m wiped. Time for a little break :)

* Included in the default wp-config.php file (as of WordPress version 2.8)

Translations of this article

WordPress Configuration Tricks in Brazilian Portuguese by TÃ¡rcioZemel