Digging into WordPress » PHP

Displaying Theme Data with WordPress

Jeff Starr — Wed, 14 Dec 2011 18:36:29 +0000

A cool trick you can do with WordPress is display information directly from your theme’s style.css stylesheet. I recently used this on a site where the theme’s version number is used throughout the template to keep things current and consistent.

get_theme_data()

The function that makes it possible is called get_theme_data(), and it simply returns an array of information about any of your theme files. Here is how it’s used in your theme template:

So $theme_filename is required and should be the path and filename of your theme’s style.css file. There is no default value for this, so you need to ensure a proper value.

So what information can you display with get_theme_data()? The function returns an array of values that basically comprises the different meta items in your stylesheet. Here is a list of possible return values (all strings):

Name – theme name
Title – either theme name or linked theme name
URI – theme URI
Description – wptexturized version of the theme name
AuthorURI – theme author URI
Template – theme parent template, if exists
Version – theme version number
Status – theme status (default: publish)
Tags – theme tags
Author – author name or linked author name

Note that these return values are case-sensitive and will not work if the first letter is not capitalized.

Examples

The Codex provides this example for getting and displaying the theme Name and Author:

This should get you going.. just copy/paste into your theme template and indicate the theme name in that first line of code. Displaying other bits of theme data is matter of editing/replicating those last two lines.

Once you see how it works, you can do cool stuff with it, like display your theme’s version number sort of globally throughout your site. I’m using this technique to append version parameters to my stylesheet URLs, like so:

..and the output markup looks like this (notice the appended version parameter, ?v=1.3):

Because I am using multiple stylesheets, this method really saves a LOT of time trying to keep track of everything. Here is the theme_version() function that goes in your theme’s functions.php file:

// display version number
function theme_version() {
    $theme_name = 'xycss'; // customize with your theme name
    $theme_data = get_theme_data( get_theme_root() . '/' . $theme_name . '/style.css' );
    echo '?v=' . $theme_data['Version'];
}

And with a few modifications, you can also display your theme’s information in your posts and pages via shortcode:

// version number shortcode
function theme_version_shortcode() {
    $theme_name = 'xycss'; // customize with your theme name
    $theme_data = get_theme_data( get_theme_root() . '/' . $theme_name . '/style.css' );
    return $theme_data['Version'];
}
add_shortcode('theme_version', 'theme_version_shortcode');

With that second snippet in your functions.php file, displaying your theme info directly in pages is as easy as writing this:

[theme_version]

..and the output:

1.3

It’s pretty cool stuff, and I’m sure there’s tons more you can do with it too. If you know any tricks or tips, please share in the comments, Thanks :)

Import Feed, Display in Multiple Columns

Jeff Starr — Tue, 27 Sep 2011 16:24:49 +0000

Recently I worked on a project where a single RSS feed was imported and displayed in multiple columns on the web page. Certain pages display feed items in two columns, others in groups of three or more. This technique uses WordPress’ built-in fetch_feed functionality to parse external feeds, and a slice of PHP magic to display them in multiple columns. It’s flexible too, enabling any number of columns and feed items from anywhere in your theme/template files. For example, you could display any of the following:

10 feed items split into two columns of five
30 feed items split into three columns of 10
30 feed items split into five columns of six

Notice the pattern? The key to showing the same number of posts in each column is to set the total number of feed items as a multiple of the total number of columns. Before explaining how that works, let’s back up a bit and get fetch_feed() set up..

Setting up fetch_feed()

To display feeds in multiple columns, use WordPress’ fetch_feed function, set up like this anywhere in your theme template files:

init();
		$feed->set_output_encoding('UTF-8');	// set encoding
		$feed->handle_content_type();		// ensure encoding
		$feed->set_cache_duration(21600);	// six hours in seconds
		$limit = $feed->get_item_quantity(10);	// get 10 feed items
		$items = $feed->get_items(0, $limit);	// set array
	endif;
} ?>

There are three things to configure:

feed URL – replace http://example.com/feed/ with the feed URL
cache duration – change if needed, default is six hours (in seconds)
number of feed items – should be some multiple of the number of columns

So for example, getting 10 feed items would enable us to display 1, 2, 5, or 10 columns, with the same number of feed items in each column. So, to display a feed evenly across three columns, some multiple of three is required for the number of feed items. So that would be 3, 6, 9, 12, and so on – basically any number divisible three.

Read more about the other fetch_feed variables at the WordPress Codex.

Setting up array_slice()

Once fetch_feed() is set up, we have an array of $items containing our feed content. To display the items in multiple columns, we use PHP’s incredibly useful array_slice function, which enables us to extract slices of the feed array. The array_slice function accepts three basic parameters, the input array, offset, and length:

array_slice($array, $offset, $length);

Using the $items array generated from the fetch_feed() function, we calculate the other two array_slice variables depending on the total number of columns and feed items. So for the sake of simplicity, let’s say we want to display two columns each with five feed items. The PHP would look something like this:

// display first five feed items
$blocks = array_slice($items, 0, 5); // grab first five items from the array
foreach ($blocks as $block) {
	echo $block->get_title();
	echo $block->get_description();
}

// display next five feed items
$blocks = array_slice($items, 5, 10); // grab next five items from the array
foreach ($blocks as $block) {
	echo $block->get_title();
	echo $block->get_description();
}

Likewise, to display 30 feed items in three columns of 10 each, we would create three foreach loops using the following array_slice values:

$blocks = array_slice($items, 0, 10); // first column
$blocks = array_slice($items, 10, 20); // second column
$blocks = array_slice($items, 20, 30); // third column

As you can see, the key to displaying external feeds in multiple columns is configuring array_slice with the correct $offset and $length parameter values. Once you’ve got that dialed in, you’re ready to put it all together and make it happen.

Displaying feed items

Notice in the previous section that we use the following to display feed items in each column:

echo $block->get_title();
echo $block->get_description();

That’ll display the title and description for each feed item, but you can do much more than that. Here is a more elaborate example showing how different feed items may be included in the markup:


	get_title(); ?>
	
		get_date("l, F jS, Y"); ?>
		get_description(), 0, 200); // limit to 200 characters ?> 
		Continue reading

For each feed item in the loop, this snippet displays the following:

Title of the feed item, linked to the post URL
Content of the feed item, truncated to 200 characters
A “Continue reading” link, linked to the post URL
Each feed item is wrapped with

There is much more available for customizing your imported feeds, see the SimplePie documentation and more specifically the item-level data methods for all the details.

Putting it all together

Here is the final code for displaying external feed content in multiple columns:

init();
		$feed->set_output_encoding('UTF-8');	// set encoding
		$feed->handle_content_type();		// ensure encoding
		$feed->set_cache_duration(21600);	// six hours in seconds
		$limit = $feed->get_item_quantity(10);	// get 10 feed items
		$items = $feed->get_items(0, $limit);	// set array
	endif;
}

if ($limit == 0) { 
	echo 'RSS Feed currently unavailable.'; 
} else {
	// display first five feed items
	$blocks = array_slice($items, 0, 5);
	foreach ($blocks as $block) { ?>
		
			get_title(); ?>
			
				get_date("l, F jS, Y"); ?>
				get_description(), 0, 200); ?> 
				Continue reading
			
		
	

	// display next five feed items
	$blocks = array_slice($items, 5, 10);
	foreach ($blocks as $block) { ?>
		
			get_title(); ?>
			
				get_date("l, F jS, Y"); ?>
				get_description(), 0, 200); ?> 
				Continue reading

As-is, this code displays two columns of five feed items each. Using the techniques and info presented in this article, it’s possible to configure this code to display any number of feed items in any number of columns. This code works when placed in just about any theme template file that makes sense. Probably best when placed outside of the WordPress post loop.

Note that we also verify the feed is available before trying to display anything. After setting up fetch_feed(), we inject the following PHP logic:

if ($limit == 0) { 
	echo 'RSS Feed currently unavailable.'; 
} else {
	// display first five feed items
	// display next five feed items
}

This ensures that no empty markup tags are echoed to the browser if/when the feed is unavailable. It happens, so checking is a good move.

Instant Summary

Using array_slice() together with fetch_feed(), it’s possible to display any number of feed items in any number of columns. This provides much design flexibility for your project.

3 Ways to Reset the WordPress Loop

Jeff Starr — Mon, 12 Sep 2011 16:28:23 +0000

WordPress does an excellent job of keeping track of what’s happening with the loop, but once you start customizing parameters and setting up multiple loops, it’s a good idea to explicitly reset them using one of three WordPress template tags. In this DiW post, we’ll explore these techniques to get a better understanding of when and how to use them in your WordPress themes.

wp_reset_postdata()

First up we have wp_reset_postdata, which restores the global $post variable to the current post in the main query. This is useful when using WP_Query to customize loops or create multiple loops on the same page. It looks like this:

This tag is nice and simple – it accepts no parameters and returns no values. It simply resets the post data after a custom query. So for example, let’s say we have a custom WP_Query loop in our theme’s header.php file, something like this:

$random_post = new WP_query(); 
$random_post->query('cat=3&showposts=1&orderby=rand'); 
while ($random_post->have_posts()) : $random_post->the_post(); 

	ID, 'featured', true); ?>">

endwhile;

This would display a random post in the header, but it will also change the main query object for any other loops on the page. Without the original query data available, the main posts loop contained in, say, index.php may produce unexpected results. Fortunately, we can use wp_reset_postdata to restore the query object to its original state.

To use wp_reset_postdata, just place after your custom loop(s). Here is our previous example with wp_reset_postdata to reset the loop:

$random_post = new WP_query(); 
$random_post->query('cat=3&showposts=1&orderby=rand'); 
while ($random_post->have_posts()) : $random_post->the_post(); 

	ID, 'featured', true); ?>">

endwhile;
wp_reset_postdata();

When to use: best used after custom or multiple loops created with WP_Query.

wp_reset_query()

Next up we have the wp_reset_query function, which resets the query used with custom loops. It’s a simple function that accepts no parameters and returns no values. It looks like this:

Specifically, this function was created to prevent issues with query_posts, as indicated for the function in the wp-includes/query.php file:

/**
 * Destroy the previous query and set up a new query.
 *
 * This should be used after {@link query_posts()} and before another {@link
 * query_posts()}. This will remove obscure bugs that occur when the previous
 * wp_query object is not destroyed properly before another is set up.
 *
 * @since 2.3.0
 * @uses $wp_query
 */

Looking at the wp_reset_query function in query.php, we see that it uses the adjacent wp_reset_postdata function to restore the global $post variable to the current post in the main query:

// destroy and reset the query
function wp_reset_query() {
	unset($GLOBALS['wp_query']);
	$GLOBALS['wp_query'] =& $GLOBALS['wp_the_query'];
	wp_reset_postdata(); // <-- RESET QUERY
}

// restore the query
function wp_reset_postdata() {
	global $wp_query;
	if ( !empty($wp_query->post) ) {
		$GLOBALS['post'] = $wp_query->post;
		setup_postdata($wp_query->post);
	}
}

So both wp_reset_query() and wp_reset_postdata() reset the query object by restoring the global $post variable, but wp_reset_query takes it a step further and actually destroys the previous query before doing so. This is important when using query_posts(), as seen in the following example:

When to use: best used after a query_posts loop to reset things after a custom query.

rewind_posts()

Last but not least, we have the rewind_posts function, which basically does what it says: rewinds the loop so you can re-use the same query. The function accepts no parameters, returns no values, and looks like this when used in your theme files:

So to understand when to use rewind_posts(), let’s say we want to use the same query in two different locations on the page. We want to display post titles in the first loop and post content in the second loop. To re-use the same posts, we include rewind_posts after the first loop, like so:

if (have_posts()) : while (have_posts()) : the_post(); ?>

So, while wp_reset_query and wp_reset_postdata reset the entire query object, rewind_posts simply resets the post count, as seen for the function in the wp-includes/query.php file:

// rewind the posts and reset post index
function rewind_posts() {
	$this->current_post = -1;
	if ( $this->post_count > 0 ) {
		$this->post = $this->posts[0];
	}
}

When to use: best for re-using the same query on the same page.

5-second summary

Quick summary for future reference:

wp_reset_postdata() -> best used after custom or multiple loops created with WP_Query
wp_reset_query() -> best used after a query_posts loop to reset a custom query
rewind_posts() -> best for re-using the same query on the same page

I hope this is a useful round-up of when & how to reset/rewind the WordPress loop. Note that the WP Codex information on these functions is kinda thin, so feel free to share any tips or examples in the comments.

Create an Articles-Only Feed

Jeff Starr — Wed, 24 Aug 2011 15:33:10 +0000

WordPress makes it easy to publish content in any number of categories, with any number of tags, and with any type of custom post format. So for example, in addition to full articles, you could also offer screencasts, links, side posts, tweets, and all sorts of other peripheral content. Complementary material may work great for visitors surfing around your site, but including all of that extra stuff in your RSS feed dilutes the potency of your main articles. The idea here is that your visitors will subscribe to the more focused content.

In this post, we create a custom, “articles-only” feed for visitors who want to subscribe to the main content only, without all the side stuff. The technique is actually pretty flexible, and works great to create just about any type of custom WordPress feed content. It’s pretty easy to do, requiring a whopping two steps to make it happen..

Step 1: Create the custom page template

Go to your theme directory and create a new PHP file named article-feed.php. Then add the following code (don’t worry it’s actually not that bad):

';
?>


>

	<?php bloginfo_rss('name'); wp_title_rss(); ?> - Article Feed
	
	
	
	
	
	
	
	
	
	

	
		<?php the_title_rss(); ?>
		
		
		
		

		


		]]>


		]]>
	post_content ) > 0 ) : ?>

		]]>
	

		]]>

This is basically just a typical WordPress feed template, but with some extra query action to make it do what we want. In the first few lines of code, we specify how many posts to display, which categories to include, and whether to display full posts or excerpts:

$numposts = 10; // number of posts in feed
$posts = query_posts('showposts='.$numposts.'&cat=3');
$more = 1;

Using this default code, the custom feed will show 10 posts from category 3. And with $more set to 1, the full article will be included in the feed. This is where you customize your new feed to include whatever you want. So for example, if we post articles in three different categories, say with IDs of 1, 2, and 3, we would modify our code to look like this:

$numposts = 10; // number of posts in feed
$posts = query_posts('showposts='.$numposts.'&cat=1,2,3');
$more = 1;

The query_posts function is quite flexible and provides all of the parameters needed to set up just about any customized feed content. You can exclude/include categories, display specific types of posts, change the number of posts displayed, and so much more. For a full list of options, check out query_posts at the WordPress Codex.

Step 2: Create the custom Page in the WP Admin

Once you have the custom Page Template uploaded to your server, log into the WordPress Admin and visit the “Add New Page” screen (Pages > Add New). Create a new page named “Articles-Only Feed” (or whatever), and select the newly added “articles” page template from the drop-down menu:

While you’re there in the Admin creating this new custom-feed page, take a moment to be mindful of the feed URL and title, which may be set to whatever works best:

Once everything is ready, finish it up by publishing the page to your site. Then check that your new feed is working by visiting the URL of the new page you just created in the WP Admin. Here at DigWP.com, our articles-only feed is available at http://digwp.com/articles/.

Wrap-up + additional resources

In addition to the easy-breezy two-step custom-feed tutorial in this post, here are some additional resources that are sort of related to this general topic:

How to Redirect Logged-In Users

Jeff Starr — Mon, 08 Aug 2011 17:18:38 +0000

WordPress provides a variety of ways to redirect logged-in users. In this DiW post, we explain each of these methods along with some useful tips and tricks along the way. These techniques enable you to redirect logged-in users to internal pages, external pages, and even return them to the current page.

wp_redirect

The wp_redirect function is for redirecting all users to any absolute URI. Absolute URIs are basically full URLs and look like this:

http://digwp.com/book/
http://digwp.com/wp-content/blog-images/redirecting-users.jpg
ftp://example.com/transfer/

To redirect users with wp_redirect, place the following PHP snippet in your theme file:

The parameters for wp_redirect are two in number:

$location = The absolute URI to which the user will be redirected. No default.
$status = The status code to use. For example, 301, 302, etc. The default is 302.

You can use template tags for the $location parameter, for example:

To use a status code other than the default 302, specify it like so:

That code will send the user to example.com along with status code 301 (Moved Permanently). The default 302 should be used for temporary redirects. Learn more about status codes.

auth_redirect

Next up, we have auth_redirect, which is a “simple function that requires that the user be logged in before they can access a page.” So for example, let’s say you have a “downloads” page that’s meant for logged-in users only. To prevent unauthorized access, we would add the following code to the top of the downloads page template:

This extremely useful function checks whether or not the current user is logged in, and redirects them to the Login Page if not. By default, the user will be redirected back to the page from whence they came (e.g., the downloads page). Currently this function accepts no parameters, but having something like $location would make it even more awesome ;)

wp_logout_url

The wp_logout_url function returns the URL of your site’s Logout Page. But it can also redirect the user to any URL using the $redirect parameter, like so:

$redirect parameter is a string containing the redirect URL. Here are some examples:


Logout


Logout


Logout

The automatic logout link is great, but the subsequent redirect is a super-useful tool that we use in our custom login/register tutorial.

is_user_logged_in

Lastly we have the is_user_logged_in function, which technically doesn’t do any redirecting, but enables you to check if the user is logged in. Here is a simple example that should work in any theme template file:

The is_user_logged_in function returns TRUE or FALSE, depending on the user’s status. So to display custom content to logged in users, you could do something like this:



	Welcome, registered user!



	Welcome, visitor!

And you can mix-n-match is_user_logged_in with other template tags and PHP snippets to return more refined results. For example, we can serve custom content based on logged status and location:

This example demonstrates the flexibility of WordPress conditional tags and how is_user_logged_in throws another layer of control to the mix.

Note about auth_redirect and is_user_logged_in

As discussed here, auth_redirect currently seems to be acting kinda weird, where the post-login redirect isn’t working. Instead of returning the user to the current page after login, the user always ends up back at the Login Page. It looks like the auth_redirect function isn’t recognizing the new “logged-in” user status, and so it just keeps sending the user back to login.php.

So until this is fixed, there is a simple workaround which involves combining auth_redirect with is_user_logged_in to do what auth_redirect should be doing. All that’s required is the following snippet of code placed at the top of your theme template:

With this technique, auth_redirect executes only if the user is NOT logged in. So yeah it’s a hack, but it works great and should continue working if/when auth_redirect is fixed.

Graphing Blog Comments Over Time

Chris Coyier — Sat, 30 Apr 2011 17:19:45 +0000

One of my other blocks, CSS-Tricks, has been around a number of years now. There are nearly 1,400 unique pages of content almost all of which have a comment thread. I had a feeling that in the last four years, despite fairly steady growth in traffic and subscribers, that the number of comments per post has dropped. But how to prove it? I don’t know of a way to easily see that data.

So I built a way to visualize the number of comments per post! I’m sure all you WordPress smarties have some better fancier way to do this, but this is how I did it.

In a nutshell: write a custom query to loop through all your posts and get the number of comments. So combining those two things, I thought I’d just make a 1px wide element with a height relative to how many comments that post has.

Step 1: Figure out the maximum number of comments

This will help us set the scale. The post with the maximum number of with have a line with 100% height, and it scales down from there. It’s easy to figure out the maximum number of comments after you looped through all the posts, but we actually need that information before we even start the loop so we can set the height during the loop.

Fortunately WordPress keeps the “comment_count” for each post in the the database. So we can write a query that will return the post with the most comments and then extract that number into a variable.

$query = "SELECT comment_count FROM " . $wpdb->posts . " WHERE post_type = 'post' && post_status = 'publish' ORDER BY comment_count DESC LIMIT 1";
$results = $wpdb->get_results($query);
$maxComments = $results[0]->comment_count;

Step 2: Loop through every single post

All posts, from the first published to the latest published.

query_posts('posts_per_page=-1&order=ASC');

while (have_posts() ) : the_post();
  // output one line of graph
endwhile;

Step 3: Output a line for the graph

Each line of the graph is going to be an anchor link, just so you can click it to go to that post should you wish. We’ll make those links inline-block, so we can set a height and width. This is the basics of the CSS:

#chart { 
  padding: 100px 0; 
  height: 400px; 
  text-align: center; 
}
#chart > a { 
  width: 1px;
  background: red;  
  vertical-align: bottom; 
  text-decoration: none;
}
#chart > a:hover {
  background: black;
}

Now within the loop, we’ll output those links (lines of the graph):

$numComments = get_comments_number();
$heightPercentage = (($numComments / $maxComments) * 100);

echo "";
echo "$numComments";
echo "";

Step 4: A little more…

There are a couple more parts to this, like listing out the first and last year at the start and end of the chart (for context) and positioning the span with the number of comments at the top of the graph so you can view numbers on rollover.

I’m going to embed the code as a GitHub Gist here, so it’s easy to keep updated once all you smarties tell me all the stuff I’m doing wrong. This is built as a page template:

The Graphs!

Here’s the Google Analytics chart of CSS-Tricks since launch:

And here’s the comment graph we just built:

Kinda interesting. The charts definitely don’t follow each other like I would think they might. This isn’t enough data to infer why that is. You could say social media sites like Twitter have swallowed up some of comment activity. You could also say maybe the quality of the posts have gone down and inspire less comments. Who knows.

Here is Digging Into WordPress’s graph:

Share! Share!

I’d love it, especially if you have a blog that’s been around a year or more, if you snagged this page template and linked up your own graph (or screenshot it) and posted it in the comments.

Maybe with a bunch of blogs graphs we could identify some trends.

Display Total Number of Blogroll Bookmarks

Jeff Starr — Thu, 04 Nov 2010 16:32:56 +0000

Quick WordPress tip for you today! A reader recently asked about displaying the total number of blogroll bookmarks on their site. This sounds simple enough but not everyone meddles with code these days, so here is a nice PHP snippet that will do the job:

get_var("SELECT COUNT(*) FROM $wpdb->links WHERE link_visible = 'Y'");
if (0 < $numlinks) $numlinks = number_format($numlinks); ?>

Place that in your theme file and then customize the output by placing wherever you would like to display the results.

A perfect example of this code in use can be seen at this random bookmark site.

Speed Up Your Blogging with WordPress Shortcodes

Jeff Starr — Thu, 23 Sep 2010 16:16:02 +0000

Save time by replacing your most commonly typed words and phrases with WordPress shortcodes. For example, if you are frequently typing your blog’s URL, you could place the following code your theme’s functions.php file:

function shortURL() {
	return 'http://your-site.com/';
}
add_shortcode('myurl', 'shortURL');

Now whenever you write a post in “HTML-mode”, you can include your blog’s URL at breakneck speed by simply typing “[myurl]”. Works great in WordPress 2.5 or better.

Shortcodes for your favorite links
To create a shortcode for your favorite links, we need to include the href attribute information as well as the anchor text for the link itself. We can do this by placing this function in your theme’s functions.php file:

function shortLink($atts, $content = null) {
	extract(shortcode_atts(array(
		"href" => 'http://default-website.com' // default URL
	), $atts));
	return ''.$content.'';
}
add_shortcode('link', 'shortLink');

Then, when creating a post, emulate the following format to include any links you wish:

[link href="http://your-site.com/"]Your Website![/link]

..which will output the following code:

Your Website!

When the href attribute is removed from the shortcode, the default URL will be used. You may specify the default URL in the third line of the function (see comment). This makes it easy to add a complete link to your site on the fly by simply typing:

[link]Your Website![/link]

One of the nice things about using shortcodes instead of hard-coded links is that you can easily change the default URL without breaking anything.

WordPress Security Keys

Jeff Starr — Wed, 08 Sep 2010 07:42:37 +0000

In our recent post on pimping the wp-config.php file, we explain that using strong Security Keys is an important part of securing your WordPress installation. In this post, we want to zoom-in on Security Keys and look at what they are, how they work, and how to use them to greatly improve the security of your site.

Eight keys, one file, one step..

In a nutshell, WordPress Security Keys refer to four authentication keys and four hashing salts (random bits of data) that work together to add an extra layer of security to your cookies and passwords. Security Keys exist as single-line definitions in your WordPress configuration file, the honorable wp-config.php.

WordPress Security Keys work OK out-of-the-box, but require a bit of customization to make them super-strong. As of WordPress 3.0, there are eight security keys, introduced in the following versions:

WordPress 2.6: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY
WordPress 2.7: NONCE_KEY
WordPress 3.0: AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT, NONCE_SALT

These eight Security Keys are located in your wp-config.php file just after the database credentials. They have their own little section that 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');

/**#@-*/

As it says in the code comments, you want to replace these default keys with long sequences (60+) of random/unique characters. Each key needs to be completely random and different from the others. You can either do this manually or visit the online secret-key service for automatic key-generation. When you visit the key service, you’ll get something similar to this:

define('AUTH_KEY',         'pK/7r(|,BK+X=|dzrK}Y|ttP%+8u<$so#|`zUrA*RIxNSfgo$-w|UrQ#)RR8+DEz');
define('SECURE_AUTH_KEY',  ')|IL/>/**t|;6/z,LMC3xs>X5#+,?>ZH#>2F8ik|LziZhk+YogW76i>qHV-P5d<{Q3tRh5D2|XKHpbD-I@(51Rd2W|Z#7');
define('NONCE_KEY',        'SPD.R?ynL?qf|NXW#n(jO%kmz=]_+n|DiHrN549u>Ea{v!${-9lhoZ#.z7k(85n:');
define('AUTH_SALT',        '|6f>K{-aje<b+| dr(mY??KSkZe[dOmuoAu|qla<4q]>=EY;6&-YXt#:],T<)0FJuc9FdwtG');
define('LOGGED_IN_SALT',   '*8u:v_n,-L`FJ+qyE*fm`kzw|G%m!B^J|!8?]kK?,#5vO2#*f~PL=|tw?Chg+{o)');
define('NONCE_SALT',       '7+%dZ!tcm{2K+l(JPL7d<-B;.Jb7Cx.lj%9xQ|(ftY*|1+Qgl6q*m%L,n<.8?WXI');

Just copy/paste the entire block of code and replace the eight default keys with the eight random keys. With this step complete, your WordPress Security Keys are providing strong security for your site’s cookies and passwords. Of course, there are many other ways to optimize your wp-config.php file if you enjoy that sort of thing ;)

Some Notes on WordPress Security Keys and Salts

So far we need to remember only one thing: replace the default Security Keys with random ones. Simple yes, but there are a few additional things to keep in mind when setting your keys:

Security Keys may be changed (or added) at any time
Any logged-in users will need to log in again after changing your keys
The default set of eight Security Keys is also available in the wp-config-sample.php file
Never reveal your Security Keys to anyone – never post them online

Also keep in mind that wp-config.php is normally not modified when updating WordPress. The wp-config-sample.php is replaced, so you can use it for reference if needed. If you’re running WordPress 3.0 and see fewer than eight security keys, it’s totally safe to replace what you have with a complete set. Other than logged-in users needing to log in again, your more-secure WordPress installation will roll on without skipping a beat.

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