Have you added the rel=”nofollow” attribute to your WordPress tag cloud? Here’s a YouTube video from Matt Cutts talking about the need to add the attribute to tag clouds, where he explains that passing PageRank through the tag cloud links is probably not the most efficient way to do things.

Unfortunately, the WordPress tag cloud is generated via a function call to wp_tag_cloud and, as a result, you cannot simply add the rel=”nofollow” attribute like you would a traditional link.

So, I did a bit of searching and stumbled across a nofollow tag plugin at SmartBlogTips.com that will take care of this for you.

That said, I’m not big on adding plugins if it’s just a few lines of code. So, for those of you interested in doing this without the plugin, you can add the following lines of code to your functions.php file:

function add_nofollow_tag($sLink) {
    return str_replace('<a href=', '<a rel="nofollow" href=', $sLink);
}
add_filter('wp_tag_cloud', 'add_nofollow_tag');

That’s it. Your WordPress tag cloud should now use the rel=”nofollow” attribute.

Thanks SmartBlogTips.com for the simple plugin!

Required Steps

I’ll cover these steps in more detail below, but this is a basic outline of what’s required to take advantage of the custom navigation menus in WordPress 3.0:

1. Define your custom nav menu in functions.php
2. Define a function that WordPress will call in the event a particular navigation menu does not exist
3. Create the navigation menus in the WordPress admin
4. Assign the newly-created navigation menus to their appropriate locations in the WordPress admin
5. Add function calls to display the navigation menus to your theme

Define Your Custom Navigation Menus

The first thing to do is let WordPress know about your new navigation menus and what you’d like to call them. So, open up functions.php and add something like the following:

add_action('after_setup_theme', 'my_after_setup_function');
function my_after_setup_function() {
/**
* The register_nav_menu function takes two parameters
* @param string $location This is the location you'll reference when you call this nav menu in your theme code
* @param string $description This is the description that will appear in the WordPress admin to help you assign a nav menu to the proper location
*/
register_nav_menu('Main Menu', 'The main site navigation menu');
register_nav_menu('Footer Nav', 'Footer navigation menu');
}

Pretty simple. In case you didn’t get it, the first parameter of register_nav_menu() is what you’ll specify in the function call to tell WordPress which nav menu to display. The second parameter is what WordPress will show you in the navigation menu admin panel that helps you assign newly-created nav menus to their proper locations.

Define an empty navigation menu function

My testing shows WordPress does some weird stuff if you register a navigation menu (as we did above), add the function call to display that navigation menu (as we’ll do below), but you don’t actually create the navigation menu in the WordPress admin. A perfect example of this might be if a client tells you he wants to add footer navigation at some point, but isn’t quite sure what he wants there just yet.

By defining a function to be run in the event a navigation menu is not created or assigned in the WordPress admin, you can future-proof things a bit.

Again, you’ll add this to your functions.php file. In this case, I’ll be returning an empty string, which is exactly what will be printed, but if you get creative, you might find a number of uses for this.

function default_nav_menu() {
return '';
}

Create the navigation menus in the WordPress admin

If you’ve read this far and you can’t figure this out you need a swift kick in the teeth, but here are a few things to remember:

• It doesn’t matter what you call your nav menu. Name it whatever you want.
• Can’t find a “home” link in the pages list? Try creating a custom item pointing to your site’s homepage
• I thought this list would be longer when I started it so here’s another bullet for you to chew on.

Assign the newly-created navigation menus to their proper locations

Remember the description parameter in the register_nav_menu functions we created earlier? Take a look at the panel that says “Theme locations” and you’ll see those descriptions above select boxes. Select the nav menu you want for each location and save it all.

Add function calls to display the navigation menus in your theme

Here’s the code to display the navigation menus. You’ll need to add this…you guessed it…where you want the navigation menu to appear:

<?php
wp_nav_menu( array( 'theme_location' => 'Main Menu', 'sort_column' => 'menu_order', 'container_class' => 'main_nav', 'menu_class' => 'main_nav_menu', 'fallback_cb' => 'default_nav_menu' ) );
?>

A few quick notes on this function:

• There are a lot of parameters you can use for this function. Check out the function reference here
• Notice that ‘theme_location’ is the same value we specified for the $location parameter in our register_nav_menu functions in functions.php
• Also notice that ‘fallback_cb’, or fallback callback, is the empty navigation menu function (default_nav_menu) we defined in functions.php

What about formatting?

Unfortunately, WordPress only gives you the option to output the navigation menu as an unordered list. For most cases that should be fine, but in my recent experience, I had to add those little vertical lines (you know, the pipe character) between each menu item to match an existing site design. So I used the str_replace function to address the issue:

$sNav = wp_nav_menu( array( 'theme_location' => 'Main Menu', 'sort_column' => 'menu_order', 'container_class' => 'main_nav', 'menu_class' => 'main_nav_menu', 'echo' => false, 'fallback_cb' => 'default_menu' ) );
$sNav = str_replace("</a></li>n<li ", "</a> |</li>n<li ", $sNav);
echo $sNav;

There might be a better way to do this but I prefer not to make things too complicated.

That’s it.

Wordpress 3.0 Navigation Menu

Get it here: WordPress $post Object Cheatsheet

It may not be immediately clear to some where a technique like this might come in handy. So I’m using a recent project as an example. This particular project was for a subsidiary of Milacron, one of Cincinnati’s most well-known manufacturing companies. Cimcool develops industrial fluids: additives, rust inhibitors and metalworking fluids are some of their major product lines and those product pages are what we’ll use for this tutorial.

Requirements

They already had a website but hired us to handle the SEO. Part of that process involved cleaning up the URL structure of the site by removing query strings from the URLs on product pages. The particular page I’m going to cover in this tutorial is this one. If you visit that link and click any of the categories listed on the left-hand side of the page you’ll see that you’re sent to a page that looks identical but has the category name in the URL. In fact, all of those pages are the same “MSDS-PIF” page served by WordPress, while the content shown on each of those pages is determined by a query string that is parsed from the last portion of the URL. This allows us to have keyword-rich URLs for the products categories without having to create separate WordPress pages for each category.

Problem

The biggest problem with getting this done in WordPress, as I alluded to in the last paragraph, is that even with pretty permalinks enabled, we would have had to create a new WordPress page with a unique template for each of those product categories. There were only 15 product categories at the time, so that wouldn’t be such a tedious task, until you consider the fact that it makes adding categories a bit of a hassle, in that we’d have to create a new WordPress page and page template anytime the company would need to add categories. While that would mean more billable hours for us, it wouldn’t be in the client’s best interest if it could be avoided.

The Solution

Thankfully, it could be avoided. Instead of creating a bunch of pages and their respective page templates every time new categories are added, we can use WordPress’ ability to specify custom rewrite rules to pass the query string as part of the URL and use a single page and page template to display all product categories.

The Process

The first step was to create a function to add variables to WordPress’ query string and then hook that function into the query_vars hook.

Next, we created a function to add rules to WordPress’ existing array of rewrite rules and hook that function into the rewrite_rules_array hook.

Finally, in the MSDS-PIF page template, we used the $wp_query object’s query_vars property to get the query string from the URL.

The Code

So let’s get down to the code. First we need to create a function to tell WordPress to keep track of our new query variables. This function goes in your theme’s functions.php file.

function add_query_vars($aVars) {
$aVars[] = "msds_pif_cat"; // represents the name of the product category as shown in the URL
return $aVars;
}

// hook add_query_vars function into query_vars
add_filter('query_vars', 'add_query_vars');

The above process is fairly simple. When the function is hooked into query_vars, WordPress passes the existing array of query variables to the function. We simply add “msds_pif_cat” as another query variable and send the array back to WordPress.

Now WordPress knows, in addition to it’s existing query variables, it should add one called “msds_pif_cat,” which we’ll use to store the product category name as specified in the URL.

However, this alone won’t do the trick. We also need to tell WordPress how to populate that query variable. In Cimcool’s case, we want the product category pages’ URLs to look like this: http://www.cimcool.com/msds-pif/category-name/. So, we need to tell WordPress that anytime it finds a URL matching that structure, to use the last portion, the category-name, to populate our new “msds_pif_cat” query variable. To do that we need to add a custom rewrite rule.

We accomplish this with another function in our theme’s functions.php file:

function add_rewrite_rules($aRules) {
$aNewRules = array('msds-pif/([^/]+)/?$' => 'index.php?pagename=msds-pif&msds_pif_cat=$matches[1]');
$aRules = $aNewRules + $aRules;
return $aRules;
}

// hook add_rewrite_rules function into rewrite_rules_array
add_filter('rewrite_rules_array', 'add_rewrite_rules');

The function is hooked into rewrite_rules_array, so WordPress passes the existing rewrite rules as an array to the function, which we then retrieve as $aRules.

We then add a new rule in the form of an array: array(‘msds-pif/([^/]+)/?$’ => ‘index.php?pagename=msds-pif&msds_pif_cat=$matches[1]‘)

This rule tells WordPress that anytime it finds a URL that includes “msds-pif/”, followed by anything other than a forward slash, followed by another (optional) forward slash, to capture the last portion of that URL (the part within the parenthesis), and serve the page found at “index.php?pagename=msds-pif&msds_pif_cat=$matches[1]“.

By default, WordPress will store the captured portion of the URL in an array called $matches. And so if we have a URL request like “http://www.cimcool.com/msds-pif/industrial-cleaners/”, WordPress will serve the page at “index.php?pagename=msds-pif&msds_pif_cat=industrial-cleaners”.

This allows us to capture that msds_pif_cat variable on the MSDS-PIF page template and vary the content depending upon the contents of that variable.

Getting the Query Variable

We can’t just use the $_GET superglobal to grab our msds_pif_cat query variable. Instead, we have to access the query_vars property of the $wp_query object.

So, on our MSDS-PIF page template, we’ll access that variable using the following code:

if(isset($wp_query->query_vars['msds_pif_cat'])) {
$sMsdsCat = urldecode($wp_query->query_vars['msds_pif_cat']);
}

Next steps

In our case, we then pull all products matching the category name as stored in the $sMsdsCat variable from the database and display them on the page. Obviously what you do with that variable is up to you and, from this point on, is no different than if you had used PHP’s $_GET superglobal to get a query variable on a non-WordPress page.

One thing I should mention here is that the rewrite_rules_array hook is called when you update or save your permalink structure, so after you make these changes, you’ll have to re-save permalinks to see the changes take effect.

More examples

Take a look at the Cimcool link above to see all this in action. For an example of using multiple custom query variables, have a look at Screen Innovations’ dealer locator, where we used a similar process to display dealers on the page for a given country, state and city using SEO-friendly URLs and without the need to create a hundred or so page templates.

Finally, check out the following resources for more information on URL rewriting in WordPress:
http://codex.wordpress.org/Function_Reference/WP_Query
http://www.prodeveloper.org/create-your-own-rewrite-rules-in-wordpress.html
http://www.seodenver.com/custom-rss-feed-in-wordpress/

What Are Custom Fields?

I realize some WordPress users may not even know what custom fields are so let me clarify. The custom field panel can be found on the New/Edit post screen under the conspicuous title, “Custom Fields.” That panel is rather cryptic if you’ve never used it before, but custom fields are really simple to use and incredibly useful. A perfect example of how they can be used is the header image for each post on this site.

The Custom Field Panel

As shown in this post’s header image, the custom fields panel has two form fields, one called “Name,” and the other “Value.” Name is how you’ll reference this custom field when accessing it in the code and the value is, well, whatever you want it to be. As an example, the post header images on this site use a name of “image” and a value of “post-image-name.jpg” (this image file name).

Depending on whether or not you’ve ever used custom fields before, your custom field panel may not look exactly like the one above. Instead you may see something more like this:

Enter a new custom field in WordPress

This allows you to enter a new custom field if you haven’t entered any before or if you already have existing custom fields and click the “Enter New” button as seen in this post’s header image.

Adding a New Custom Field

So now that we’re familiar with the custom field panel, let’s use it.

Since I’m currently working on a WordPress Real Estate blog, we’ll create a custom field to display the property address at the bottom of the page, but you can use this technique to add just about anything to a post.

Creating a Property Address Custom Field

So the first thing we want to do is type the name by which we want to refer to this custom field in the “name” field of the custom fields panel. In this case I’ll use “property_address”. You can actually use anything you want and it can even have spaces in it, although I prefer to avoid spaces, replacing them with underscores, just in case that changes in future WordPress releases.

Next we want to add the property address to the “value” field. Keep in mind that if you want to add any formatting inside the custom field (like line breaks for instance), you’ll have to add the HTML code directly to the field itself here because we’ll be pulling the data out of the field directly and WordPress won’t automatically add formatting like it will when writing the actual content for a post. An example of that can be seen toward the end of this post.

Here’s what it looks like before we save it:

Our new Custom Property Address Field

Now that we’ve entered the name and value, click the “Add Custom Field” button to apply our changes.

Now save/publish the post.

Editing Our Post Template to show the Property Address

Now that we’ve created our new property address custom field, we have to tell WordPress where we want that information displayed.

For this example, I’m going to add code to the single.php theme template to first check if that property address was entered for the post being shown, and then to display that address if it exists.

So, open up single.php and look for the code that displays the post content, which is something like this:

<?php the_content(); ?>

Your the_content() function may contain something inside the parentheses and that’s fine…we’re just looking for that line.

Now immediately after that line we want to add the following code:

<?php
$property_address = get_post_meta($post->ID, 'property_address', true);
if($property_address != '') echo "<strong>Property Address: </strong>" . $property_address;
?>

get_post_meta()

The first line of that code pulls the custom field with the name “property_address” and assigns it to the $propert_address variable using WordPress’ built-in get_post_meta() function.

That function takes up to three parameters: The first is the post ID number. Since we’re adding this code inside the loop, we can use $post->ID to get the post ID number. If you’re using this code outside of the loop, the $post object won’t be set so you’ll have to enter the ID number of the post you want to use here. The second parameter is the name of the custom field we want, in this case, “property_address”. And the third parameter tells WordPress to return the value of that custom field as a string, rather than inside an array.

The second line uses an if-statement to check if the $property_address variable contains anything besides an empty string. If there’s something there, we then echo “Property Address:” in bold, followed by the contents of the $property_address variable containing our property address.

The Final Result

The final result, using my free WordPress theme, This Just In!, looks like this:

Our custom field output beneath a post

That’s all there is to it.

Some things to remember about custom fields

You can use custom fields in this way for just about anything. You should remember that the custom field is pulled as plain text exactly as you entered it, so if we wanted to display the address on two lines, like it would be shown on a letter for example, we’d have to add <br /> tags into the custom field when creating it. You’ll probably want to output the custom field inside of a table in this case so that the second line of the address wraps below the first line properly. The code to display that would look something like this:

<?php
$property_address = get_post_meta($post->ID, 'property_address', true);
if($property_address != '') {
echo "<table>";
echo "<tr><td><strong>Property Address: </strong></td><td>" . $property_address . "</td></tr>";
echo "</table>";
}
?>

In this case, our custom field panel would look something like this:

HTML formatting in our custom field

And the final result would be something like this:

The final result with HTML formatting

More about custom fields

Smashing Magazine has a great post about other uses for custom fields if you’re interested in learning more.

I wrote an article a while back about using a static homepage for your WordPress blog. In that article I mentioned using a custom loop on this blog in the blog and tutorials sections. One problem you may run into when using a custom loop is that pagination doesn’t work like you’d expect it to.

In particular, you may notice that only the first page of posts are displayed no matter what page of posts you’re trying to view. I often use WordPress as a general purpose CMS in client projects and so I use a lot of custom loops and run into this issue a lot. Here’s the solution:

Update query_posts with the proper query vars

The solution to this problem is pretty simple. You need to tell WordPress to use the “paged” query variable in your custom loop, otherwise it’s ignored. If you’re using the query_posts function for your custom loop, the easiest way to do this is like so:

$paged = (get_query_var('paged')) ? get_query_var('paged') : 1;
query_posts('paged=' . $paged . '&cat=76'); // show posts in category 76 with pagination enabled

In this example, we first test to see if the “paged” query variable is set using the get_query_var function, which will return false if it’s not set. If it is set, we’ll set $paged equal to the value of that query variable and if not, we’ll set it equal to 1.

Then we initialize our custom loop using the query_posts function by setting “paged” equal to our $paged variable so that WordPress grabs the current page from the URL and displays the appropriate list of posts for that page.

I’m also looping through the posts in category #76 in this example, which is only there for illustrative purposes. That’s all there is to enabling pagination in custom WordPress loops.

Example of using multiple sidebars in WordPress

If you’ve been theming WordPress for a bit you may have come across the need for multiple sidebars, but you may have also realized that the default method of including a sidebar, using the get_sidebar() function, only allows you to include a single sidebar named sidebar.php (without using parameters). There’s one obvious way to include a sidebar and that’s by using a standard php include like so:

include('TEMPLATEPATH . '/right-sidebar.php';

This method works, but in the interest of keeping our code readable and simplifying the inclusion of multiple sidebars, there’s an easier way to do this and it’s incredibly simple.

Including sidebar-left.php and sidebar-right.php using get_sidebar

Let’s say we’ve got two sidebars, right and left, and we’ll name the files sidebar-right.php and sidebar-left.php respectively. To include those files, all we have to do is use the get_sidebar function but add parameters to each function call to tell WordPress which sidebar we want included where.

To include the file “sidebar-right.php” we’ll use:

get_sidebar('right');

And to include our other sidebar, “sidebar-left.php” we’ll use:

get_sidebar('left');

Likewise, if we want to include a third sidebar, sidebar-right-2.php for example, we’ll use:

get_sidebar('right-2');

Syntax of get_sidebar()

It’s that simple. The key to remember here is that, as commentator Rakeshkumar Mehta points out, the get_sidebar function prepends “sidebar- to the argument you feed it, so all your sidebar files should start with “sidebar-”. For example, to include a file named sidebar-newsidebar.php, use get_sidebar(‘newsidebar’), or to include a file named sidebar-my_right_sidebar.php, use get_sidebar(‘my_right_sidebar’).

By default, anyone can view a WordPress page and there are only a few obvious options to change that in the Write page panel. WordPress does afford you the ability to make pages and posts private or password-protected, but neither of those options accomplished what I needed for this particular project.

Private Pages

The problem with setting a page’s visibility to “Private” is that it is hidden from everyone except site editors and administrators. Private pages are hidden from all other registered users on your site, including not showing up in a pages list. I wanted my page to be visible in a list of pages (i.e. in the sidebar) to everyone who visited the site as well as in the main navigation. Then, when a user clicks to view the page I needed WordPress to check if that visitor was logged in and, if not, to display a notice that this page requires login. Because of these requirements, the “Private” visibility level didn’t suite my purpose.

Password Protected Pages

You can also password protect pages, but I didn’t want logged-in visitors to have to enter a password to view the page, so this option was out as well.

Unfortunately, there are no other options for protecting specific pages available in WordPress (without the use of a plugin) unless you’re willing to delve into the code a bit. That said, the task is a simple one and I’ll explain how I did it in the following tutorial.

Create a new page template

First of all, you can view an example of what we’ll accomplish in this tutorial at the homepage for the WordPress Mortgage Calculator Plugin. This is a site I helped develop with a friend of mine who is working on an Ajax-enabled mortgage calculator plugin for WordPress. Once at the site, click the “Download” menu item to see the effect in action.

1. The first step in requiring users to log in to view a page is to create a new page template by making a copy of your existing page.php template. I named mine “page_loggedin.php”.
2. Once you’ve done that you need to add a name to the template so that WordPress can recognize it as a new page template. Open the new file and add the following to the top (the template name can be anything you want. This is what you’ll select within the WordPress admin when creating your new page) :

   <?php
   /*
   Template Name: Logged-In Users Page
   */
   ?>

3. Next you’ll need to add code to check if the user is logged in and, if not, to display an appropriate message to the user. So add this code just beneath the template name code we added in step 2:

   <?php if(is_user_logged_in()):?>

4. Now go to the very bottom of the file and add the following code. This will call the wp_die() function to halt WordPress execution and display a notice to the visitor that he/she needs to first log in to view this page.

5. <?php else:
   wp_die('Sorry, you must first <a href="/wp-login.php">log in</a> to view this page. You can <a href="/wp-login.php?action=register">register free here</a>.');
   endif;?>

6. Save that new page template and upload it to your server.
7. That’s all the code we have to write. Next, create your new page and under “Page template,” select the new page template we just created.
8. Save your new page and that’s it. That page will now appear in any pages lists just like any other page on your site, but when a user who is not logged in clicks through, he/she will receive a notice similar to this:

Example of the message you get when trying to view a protected page

WordPress Favicon Example

First create the image

First of all, a favicon is really nothing more than a tiny png image with a .ico extension and sized to 16 pixels by 16 pixels (they can also be 32 by 32). So, the first thing you need to do is to create the image that you want to use; whatever you use, don’t make it too complex because small detail tend to get lost when resized to a tiny 16 by 16 pixels.

For example, on this site I used the little WordPress Hacker cartoon that sneakily peaks at you over the top of every page. I originally started to use the entire cartoon, hands and all, but that amount of detail turned out to be too much and you couldn’t quite tell what it was when resized to 16 by 16. So, I got rid of the hands and cropped the image to only include the top of the Hacker’s head with his trademark blonde mohawk.

If you want to draw your own favicon, Favicon.cc has a cool tool that lets you draw your own icon while the Favicon in the browser updates in real time to reflect your changes. It’ll even let you create animated favicons frame by frame. If you use this tool you can skip the next step as the tool will handle the conversion to .ico as well.

Next, convert your favicon to .ico format

Modern web browsers will generally let you get away with using a gif, png, or even a jpeg for your favicon, but to be compatible with older version of internet explorer, you’ll have to convert the image to .ico format.

In order to do that, you can also use the Favicon.cc website, only this time, click the “Import Image” button on the left side of the page and upload your image. The tool will convert your image to .ico format and let you download the final product.

Finally, add the favicon to your site

By default, most browsers will look for a favicon in your site’s root directory named favicon.ico. If you don’t have any problem with that, just upload the file to your site’s root directory, make sure it’s named favicon.ico, and you should be all set. Keep in mind, this file is cached by your browser, so you may not see it until you clear your cache…incidentally, I’ve also had issues with the favicon showing up even after clearing my cache, but that problem usually resolves itself within a few hours. If the icon isn’t recognized by default, you can follow the next step to be sure it gets picked up.

Now, what if you’re like me and want to keep your favicon with your WordPress theme files, or maybe your favicon isn’t being detected by your browser for some reason? In these cases, we need to tell the world where our favicon is. To do this you need to open up your theme file containing the site’s <head></head> section…in my case that’s header.php.

Then, assuming you save your favicon.ico file in your theme directory, add the following anywhere between the <head></head> tags.

<link rel="shortcut icon" href="<?php bloginfo('template_url'); ?>/favicon.ico" />

If you save your favicon.ico somewhere else, you’ll have to adjust the href attribute appropriately.

Make sure you clear your browser’s cache after making the change.

Final words of advice

If you save your favicon in a location other than your site’s root directory, you’ll have to add the above link to the short icon file inside the <head></head> tags of every page on the site. For most WordPress installs, this isn’t a problem since there is usually one header.php file containing the <head></head> tags that gets called on every page. Just keep that in mind, however, if you’ve got a different setup.

Also, along those same lines, you probably won’t see the favicon when you log into the WordPress admin because the admin uses a different header that your theme, so you either have to also add the link to your favicon to the admin head section or just put the favicon in your site’s root directory.

Personally, I like to save the favicon with my theme files and just copy it to the site’s root directory as well. This allows me to maintain the portability of my theme and I can easily move it to another server if need be without the risk of leaving my trusty favicon behind. Then, on the new server I’d just copy the favicon to the new site root. That also prevents the need to edit the core header files.

What we’re going to cover here is setting a static homepage and moving the blog page to a directory like /blog/.

This task isn’t too difficult, although, depending on how you set it up, it can be confusing as hell, so I’ll walk you through the simple way of getting it done. So let’s git ‘er done…Yeeehaw!

Setting up the Static Homepage

*All file references are to your theme files

1. First, back up your theme directory so you can roll back any changes if something goes awry.
2. Next, create a new file in your theme directory called homepage.php
3. Then open page.php and copy everything in it and paste it in the newly created homepage.php
4. At the very top of the newly created homepage.php file, add the following code:

   <?php
   /*
   Template Name: Homepage
   */
   ?>

   

   WordPress Static Homepage Template

5. Save homepage.php
6. Next, log in to WordPress and create a new page. Name it whatever you want…I named mine Homepage.
   

   Creating the static front page

7. While creating the page, change it’s Page Templateto “Homepage.”
   

   Selecting the home page template

8. Finish creating the page just like you would any other and then publish it.
9. Next, navigate to Settings > Reading in the WordPress admin.
10. Now, under the Front Page Displayssection, mark “A static page”, and select “Homepage” from the first dropdown. Leave the second dropdown alone for now.
    

    Setting the static front page settings

11. Click save changes and visit your blog homepage. You should see the newly created page as the homepage instead of the standard post loop.

So now we’ve got a static homepage, but our blog page is gone…that’s ok, we’re going to turn that back on and place it at the url, http://www.yourdomain.com/blog/.

Before we get started, make sure you have the pretty permalinks enabled, otherwise, your blog page won’t be at /blog/, but /?p=43 or something like that.

Setting up the New Blog Page

1. This is pretty simple. First, in the WordPress admin, create a new page and name it “Blog.” Don’t add any content or anything…all you really need is a title and to make sure that the page slug is “blog.”
   

   Creating the blog page

2. Publish that new page.
3. Go back to Settings > Reading in the WordPress admin and under the Front Page Displays section, in the second dropdown labeled “Posts page,” select “Blog.”
   

   Setting the blog page settings

4. Save changes.
5. Delete cache if you’re using a caching plugin.
6. Visit your homepage and make sure it’s still there.
7. Now visit http://www.yourdomain.com/blog/ and check out the blog page.

Some Things to Remember

When you go into Settings > Reading and set the “Blog page” to a particular page on your blog, WordPress automatically pulls the index.php file and uses that to display the content on that page, which is why we didn’t have to create a new template or anything for the blog page like we had to for the homepage.

Also, you can name those templates and page files whatever you want (I’d avoid home.php for the homepage file though as this will interfere with WP v2.1 and earlier). Just remember the name of the page template that you added to the top of the homepage.php file so you can select that as the page template when creating the homepage in the WordPress admin.

Also remember the actual titles you gave the home and blog pages when creating them in the WordPress admin so you can select the proper pages in the Settings > Reading section.

And finally, whatever page slug you give your blog page when creating it in the WordPress admin is the URL by which you’ll access it (assuming you’re using pretty permalinks). So, if you end up giving your blog page a page slug of “blog-home”, you’ll have to access your blog page at the url: http://www.yourdomain.com/blog-home/.

That should do it. Happy blogging!

If you’ve been keeping on top of your WordPress updates using the automatic upgrade feature, you may have run into a problem immediately after upgrading. A message that prevents access to any page on your blog, “Briefly unavailable for scheduled maintenance. Check back in a minute”. Even if you’ve already completed the upgrade, this message could still appear. It’s not a fun situation and, admittedly, I freaked out the first time I ran into that problem. Fortunately, your life as you know it isn’t over…there is salvation ahead, and it’s brain-dead simple.

Cause of the Maintenance Message

During an automatic upgrade, WordPress places a file in the blog root directory called “.maintenance” to prevent visitors from being confronted with ugly, broken pages during the upgrade process. That’s a great little built-in feature, but if the upgrade gets interrupted or fails for any reason, that file doesn’t get deleted and nobody, including you, can access your blog. No worries, this is (most likely) the simplest fix on Earth.

Removing the Maintenance Message

All you have to do is delete the .maintenance file from the blog root directory. Simple as it gets. After you’ve deleted the files you should be able to access the site just fine, but you may have to run the automatic upgrade again. How do you know if you should run it again? You’ll see a notification on the dashboard page that a new version of WordPress is available…same as you always see when a new upgrade is available. If you don’t see that message, you’re good to go.

Of course, this fix assumes the blog upgrade failure was really just a one-time occurence and not a symptom of a larger problem. If you’ve deleted the file and the automatic upgrade continues to fail, you’ve probably got a larger issue at hand, and that’s a topic far too long to cover in this article.

Two post recovery methods

So, the other day I deleted a post almost immediately after publishing it (although I’m convinced it was WordPress’ fault and not mine ). In the past I’ve been able to recover deleted posts using Archive.org, but that only works if the post has been published for long enough to be archived by Archive.org. If Google’s had time to index the post, I can search for it by title and site using the “site:sitename.com: post title” syntax, and clicking on the “Cached” link to pull up the copy of the page Google has cached on it’s servers as you can see below.

Checking Google's cache for a copy of the deleted post

Then I can just copy the text and republish the post. But again, this post was deleted almost immediately after publishing, so I had to find a different way.

Using the Firefox Cache to Recover a Post

Then it dawned on me that I had visited the post a few times while writing it and then once again after publishing, but before it got deleted, so Firefox would certainly have it cached…but how do I recover the post from the cache? Here’s how I did it.

1. I did a little searching and discovered you can access the Firefox cache by going to the address bar and typing “about:cache” without the quotes.
2. You should see three sections as shown here:


Viewing the Firefox Cache (about:cache)

3. You may need to search all three sections, but lets start with “Memory cache device” – click on the “List Cache Entries” link in that section
4. After that you’ll be faced with a [probably] huge list of all the URLs saved in the Firefox memory cache. Hit Ctrl + F and type the post slug you gave your original post. Here’s mine after searching for “top-wordpress-plugins”:


Searching the cache for "top-wordpress-plugins"

5. Once you’ve found the post, click on the URL and you’ll see another page full of what appears to be quite a bit of gibberish. Copy and paste the entire section, starting with what you see outlined in red below, into your text editor of choice, preferably one with Regular Expression search and replace functionality (take note of the right side of the image – it’s the HTML code for the page we’re looking to recover):


Firefox cache gives us HTML code + a bunch of stuff we don't need

6. Once you’ve got all that into your favorite text editor, you just need to get rid of all the extra stuff aside from your post content. I found it easiest to do this using Dreamweaver’s regular expression search and replace. I’m using Dreamweaver’s tool because other REGEX search and replace tools I’ve used just don’t seem to work right for me. Here’s the expression I used, which you can also see in the photo below: [0-9a-z]{8}:s*?([0-9a-z]{2}s*?){16}s


Using Dreamweaver's regular expression search and replace to clean up the recovered post

7. That allowed me to get rid of all the extraneous characters, but I was still left with my post HTML in a narrow column down the page, so I needed to fix that…I used another regular expression to get rid of all the extra line breaks, but I had to go into the code view to get this done (did I mention the last REGEX was run in Design view?). This time it looked like this: <br />


Removing the <br /> tags

8. Once that was done I ended up with the HTML code for my post nice and clean – albeit on one long wrapped line. From there I just found the post content, copied it, and then pasted it into the HTML editor for a new WordPress post.
9. And that’s it. It wasn’t easy, but at least I didn’t have to rewrite the entire post.

Conclusion

Is this the easiest method of recovering a post? Absolutely not! In fact, its a major hassle, and it’s certainly a last resort, but it’s better than rewriting that entire post you just spent a few hours on.

Why can’t I just post the new theme files for download here? Good question. I did that for the last release, but it only caused problems because I ended up with several versions out there, which turns out to be a tracking nightmare. Also, the WordPress.org has some specific requirements to get themes approved and it’s always possible to miss a thing or two, at which point you have to go back and make changes, increment the version number, and re-submit. So, I don’t want to release versions 1.4 and 2.4 only to have WordPress.org reject my submission, make corrrections, increment the version number, and then end up with four versions of the two themes out there that are all nearly identical. Again, tracking nightmare.

So, please be patient until those get approved. In the meantime, check out the changelogs for each theme below to see what’s new!

This Just In! v2.4 Changelog:

CHANGELOG - v2.4:
#[FIXED] - wrapped masthead in div and edited #masthead and h2#tagline styles to prevent things looking strange when the masthead and tagline take up more than 1 line
#[ADDED] - added <br /> before tags are output so they appear on new line
#[ADDED] - added background color and border to .wp-caption for image captions
#[REMOVED] - removed bottom border from p.wp-caption-text to prevent duplicate bottom border after .wp-caption border
#[CHANGED] - updated spacing and sizing on heading elements
#[CHANGED] - shrunk caption text from .8em to .7em and changed color to #777 to further differentiate captions from regular text
#[CHANGED] - updated pre and code tags
#[ADDED] - added default table styles
#[FIXED] - added bottom margin to first-level sidebar list items
#[FIXED] - added overflow: hidden; to #nav_menu selector to prevent nav tabs overflowing container at certain browser zoom levels
#[FIXED] - added !important to .aligncenter selector's margin-left and margin-right properties to fix problem with images in posts not aligning to center
#[CHANGED] - changed small.attr display property to block and margin-top property to -5px to tuck it in closer to headings
#[ADDED] - added styles for abbr, acronym, and pre selectors
#[ADDED] - added span.code selector for inline code styling
#[ADDED] - added <?php post_class(); ?> to post elements in loop on all templates for WordPress v2.7 post class support
#[ADDED] - added image.php template
#[ADDED] - added links.php template
#[ADDED] - added support for comment threading:
            - renamed comments.php to legacy.comments.php and created new comments.php file
            - added filter in functions.php to check if fancy comments function exists and display correct comments file
            - added "if ( is_singular() ) wp_enqueue_script( 'comment-reply' );" to header to support javascript functionality in comments
            - added <?php comment_id_fields(); ?> before </form> in comments
            - wrapped comment form in div id="respond"
            - replaced <h3 id="respond">Leave a Comment</h3> with <?php comment_form_title( 'Leave a Comment', 'Reply to %s' ); ?>
            - added <div id="cancel-comment-reply"><small>< ?php cancel_comment_reply_link() ?></small></div> just below that to show the cancel leave a comment button
#[CHANGED] - changed password protection check at top of comments file

Get Some! v1.4 Changelog:

CHANGELOG - v1.4:
#[FIXED] - fixed background image so it resized on shorter pages
#[FIXED] - edit header blog title and tagline to scale better
#[ADDED] - added <br /> before tags are output so they appear on new line
#[ADDED] - added background color and border to .wp-caption for image captions
#[REMOVED] - removed bottom border from p.wp-caption-text to prevent duplicate bottom border after .wp-caption border
#[CHANGED] - shrunk caption text from .8em to .7em and changed color to #777 to further differentiate captions from regular text
#[CHANGED] - updated pre and code tags
#[ADDED] - added default table styles
#[FIXED] - added bottom margin to first-level sidebar list items and fixed sidebar link spacing issue
#[FIXED] - added !important to .aligncenter selector's margin-left and margin-right properties to fix problem with images in posts not aligning to center
#[CHANGED] - changed small.attr display property to block and margin-top property to -2px to tuck it in closer to headings
#[ADDED] - added styles for abbr, acronym, and pre selectors
#[ADDED] - added span.code selector for inline code styling
#[CHANGED] - edited sizing on h1 and h2 tags
#[ADDED] - added conditional <?php post_class(); ?> in loop on all templates for v2.7 only (still supports old method)
#[ADDED] - added image.php template
#[ADDED] - added links.php template
#[CHANGED] - renamed comments.php to legacy.comments.php (legacy.comments.php will be called for version prior to 2.7)
#[ADDED] - added filter in functions.php to check if fancy comments function exists and display correct comments file
#[CHANGED] - changed password protection check at top of comments file
#[ADDED] - added "if ( is_singular() ) wp_enqueue_script( 'comment-reply' );" to header to support javascript functionality in comments
#[ADDED] - added <?php comment_id_fields(); ?> before </form> in comments
#[ADDED] - wrapped comment form in div id="respond"
#[ADDED] - replaced <h3 id="respond">Leave a Comment</h3> with <?php comment_form_title( 'Leave a Comment', 'Reply to %s' ); ?>
#[ADDED] - added <div id="cancel-comment-reply"><small>< ?php cancel_comment_reply_link() ?></small></div> form threaded comment cancel button
#[ADDED] - added threaded comment support

One of the best additions, in my humble opinion, is the integration of automatic upgrade into the core. In previous versions, even with the great Automatic Upgrade Plugin, the upgrade process wasn’t exactly automatic and required a good deal of human interaction. That gets to be a major hassle when you’ve got multiple installs of WordPress and updates are released every few months. I was really pleased to see that this new version integrates truly automatic upgrade without the need for a plugin or any human interaction other than clicking “Upgrade Automatically”.

I posted screenshots recently of a beta release of 2.7, which looks nearly identical to the final release. You can check out those WordPress 2.7 screenshots here. You can download the new WordPress version 2.7 here.

Also, if you’re currently using either of my free WordPress themes, I’m running behind on updating those. They should work just fine with 2.7, but I’m updating them to take advantage of some new features, as well as to clean up the code a bit. I’ll post an update as soon as I get those finished, which should be either today or tomorrow.