To use Google Analytics, you need to place some javascript on your website. A commonly asked question in forums is, “How do I add Google Analytics to my WordPress template?”

Where the Analytics Code Goes

When you sign up for Google Analytics, Google provides you with a short piece of javascript to place on your site. The code should look like this.

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-2894597-3");
pageTracker._initData();
pageTracker._trackPageview();
</script>

According to Google’s instructions, this needs to be placed at the very end of your site – just before the closing body tag. To do this, we need to find the closing body tag on the WordPress template.

Look In Footer.php

As we previously discovered, a WordPress template is made up of a series of files. Three basic files – header.php, sidebar.php, and footer.php – help build the components of the page.

If your WordPress template follows normal conventions, the closing body tag should be in the footer.php file.

Go to your themes directory of the WordPress installation, navigate to your current theme, and open footer.php. You should see something like this at the end.

<?php wp_footer(); ?>
</body>
</html>

Add a blank line before the closing body tag. Simply copy and paste the javascript code that Google provides on that blank line, save the file, and you’re good to go.

In order to maintain the meager search engine and referral traffic that the old pages had, I planned on using 301 Redirects. I figured that I would re-create each of the old articles (~10 total articles) on the new site and set up an individual 301 Redirect to send users and search engine spiders to the new location.

The problem, however, was that the standard .htaccess rewrite that WordPress uses was conflicting with the 301 Redirects. For some reason, they just weren’t working – so I turned to a PHP-based solution.

301 Redirects In htaccess

Normally, you can handle a 301 Redirect with a .htaccess file. You can do this with a single line in your .htaccess file.

redirect 301 /path/to/old/file.html http://newdomain.com/file.html

The first part “redirect 301″ indicates the type of redirect. This tells the browser (or the search engine spider) that the page has permanently moved to the new location. HTTP has several other options. The 302 Redirect, for example, indicates that the move is temporary.

The next two parts indicate the old path to the file and the URL of the new location.

Normally, that’s all there is to it. However, WordPress adds its own layer to the .htaccess file which makes your pretty URLs work. The URL that you request is really just a bunch of variables that tell WordPress what article to pull out of the database and display in the template.

Although you should be able to get the two to work together, I couldn’t. The server was ignoring my 301 Redirect and going directly to the other rewrite rules.

Using PHP to 301 Redirect a WordPress Page

The solution? PHP.

Creating a 301 Redirect in PHP is fairly simple. I’d read about it before, and just the other day I came across a brief article about it in one of my regular RSS feeds.

You use the header() function to send custom headers to the user’s browser. With these, you can tell the browser that you want to initiate a 301 Redirect. You can then tell the browser where to go to find the article.

header("HTTP/1.1 301 Moved Permanently");
header("Location: http://newdomain.com/article.html");

Simply replace the URL with the URL you want to redirect to.

Making It Work With WordPress

If you look in your site’s directory structure, you may realize that the path to your article doesn’t really exist.

Let’s say we want to redirect the article located at http://www.earn-web-cash.com/2008/03/20/useful-wordpress-plugins/. To use PHP, we’d need to create a PHP file to replace the article that is being redirected, and include the snippet of code above.

The problem is that the directory /2008/03/20/useful-wordpress-plugins/ doesn’t exist. Those are parameters sent to the WordPress script to fetch information out of the database.

To make this type of redirect work, we need to create this directory structure. Start at your root, and create the directory “2008.” Create a directory “03″ inside that. Create a directory “20″ inside that. Finally, create the directory “useful-wordpress-plugins” inside that.

You’ll notice that there is a trailing slash in the URL. In a normal directory structure, “useful-wordpress-plugins” is a directory, even though it would seem to represent the file where your article resides. To get the browser to access a PHP file at this location, we place an index.php file in that directory. Then, accessing the URL will automatically pull up index.php.

In short, create /2008/03/20/useful-wordpress-plugins/index.php, add the snippet of code above, and your redirect should work flawlessly.

This is a good way to move a few articles on a site to a new site. If you’re moving an entire site, you’d definitely want to look into using the .htaccess method, or creating a PHP file that dynamically chooses what page to redirect the user to. I only had to move 10 articles, so I created ten php files to do the work for me.

There is one caveat to keep in mind. If your installation of WordPress uses the URL http://www.earn-web-cash.com/2008 to access the yearly archives, you’ll run into a problem. /2008 will now be an actual directory – so the server will try to serve up the directory. You’ll need to change your settings so that the archives are located in something like http://www.earn-web-cash.com/archives/2008.

One of the greatest features is the thousands of plug-ins available for WordPress. You can find a plug-in for just about anything you want to do – or if you have some PHP know-how, you can develop your own.

Here are five basic WordPress plug-ins that I’d recommend using for any project you start.

Akismet – Spam Protection

This plug-in comes pre-installed with WordPress – and there’s absolutely no reason you shouldn’t use it. All In One SEO Plug-In is just what it sounds like. It adds some extra functionality to tweak the SEO of each of your posts and pages.

For example, All In One will automatically generate a description meta tag based on your excerpt and it will automatically generate keywords based on your tags. You can also use this to modify the title element of each page. I’d say it’s a must have for optimizing your website.

Exec-PHP

Early on, I was looking for a way to execute PHP code inside a post. WordPress doesn’t have built-in support for this, so you need to find a plug in to do it.

There are dozens of plug-ins that attempted to implement this feature. Exec PHP is hands down the best that I’ve found. You simply add regular PHP tags to your post and the PHP code will be executed properly. I’ve never run into any bugs while using the plug-in, unlike some other plug-ins I’ve tested.

Per Post CSS and JS

Per Post CSS and JS allows you to attach individual stylesheets or javascript files to your posts or pages. This is great for changing the look of a specific page without creating an entirely new template. By attaching these files to individual posts, you cut down a lot on redundancy.

For example, let’s say you wrote a javascript file that you use in 10% of your posts. Why should it be attached to the other 90% of your posts?

I’ve also found it very useful for creating HTML/CSS/JS tutorials. I can place my sample code in external .css and .js files and have it attached properly to the page. This way I don’t have to write in-line styles to demonstrate functionality.

WP Unformatted

This simple plug-in removes all of the auto-formatting that WordPress adds to your posts. With WP Unformatted, you can add a custom field to your post to tell the plug-in to strip out all of that formatting.

For example, WordPress likes to wrap text in <p> tags. Sometimes – like with forms – this is entirely undesirable. It can mess up your carefully formatted (and syntactically correct) HTML.

By using WP Unformatted, you can add sophisticated mark up to your post content without worrying that WordPress will screw it up with random <p> and <br /> tags.

And Many More…

There are, of course, dozens of other useful plug-ins. I’ve used plenty of other plug-ins that I liked. However, these are the ones that I feel appeal to the widest audience.

No matter what you’re doing, you’ll probably find a use for spam filtering, individualized stylesheets, SEO, PHP, and clean formatting. I would never start another project without these plug-ins.

What else do you find useful?

WordPress templates have a decent amount of simple PHP mixed in, and you need to utilize a special file structure for the template to operate correctly. Before you dive into making a WordPress template, let’s look at the basic structure of a WordPress template compared to a normal website template.

Example Basic Website Template

A typical website consists of a few parts – the content, a header, and a footer. You may also have a sidebar for navigation and/or a horizontal menu bar. The typical markup for this type of template would look something like this.

<body>
<div id="header">
  ...  Header Stuff Here ...
</div>
<div id="content">
  ...  Main Content Here ...
</div>
<div id="sidebar">
  ...  This floats to a side ...
</div>
<div id="footer">
  ...  Footer Stuff Here ...
</div>

If you’ve learned some PHP, then you can include a series of PHP files to create your webpage template. Chances are your header, footer, and sidebar are the same for all or most of your pages – so it makes sense to create them one time each.

<?php include('header.php'); ?>
 
<div id="content">
  ...  Main Content Here ...
</div>
 
<?php include('sidebar.php'); ?>
 
<?php include('footer.php'); ?>

Nothing too complicated here. Just a simple, barebones template.

What Does a WordPress Template File Look Like?

Although the terminology is a bit different, a WordPress template has the same basic structure. Let’s look at a pared down version of the default template’s index.php file.

<?php get_header(); ?>
 
<div id="content" class="narrowcolumn">
  <?php if (have_posts()) : ?>
    <?php while (have_posts()) : the_post(); ?>
    <div class="post" id="post-<?php the_ID(); ?>">
      ... Post Info ...
    </div>
    <?php endwhile; ?>
  <?php endif; ?>
</div>
 
<?php get_sidebar(); ?>
 
<?php get_footer(); ?>

The bulk of the action here is in the “content” div. With PHP, WordPress checks to see if any posts were retrieved from the database. If they are, then it loops through the posts and outputs each one.

“Post Info” would be replaced by the markup you want to use for the actual post headings, information, and content.

The PHP function calls are similar to the include() calls in the earlier template. get_header() fetches the standard header info, get_sidebar() fetches the sidebar, and get_footer() fetches the footer. But where does WordPress find this information?

Special WordPress Template Files

WordPress uses some standard tempalte files to make these functions work.

For example, get_header() looks for the header.php file. It’s more or less a proxy call for include(‘header.php’). To make WordPress work properly, therefore, you should include all of your header information in header.php.

The same goes for get_footer() and footer.php as well as get_sidebar() and sidebar.php.

So, to begin designing a WordPress template or to convert a regular website template to a WordPress template, you need to worry about four basic files:

• header.php – the header div and information
• footer.php – the footer div and information
• sidebar.php – the sidebar div and information
• index.php – calls get_header(), get_footer(), and get_sidebar(), and contains the content div

There are some other special files as well, but this is enough to get started. Once you understand the basic structure of the template, you can look into customizing the information that is displayed for each post.

You can easily delay the release of your posts into the main indexes (front page, archives, “Recent Posts” list, etc). With a little bit of code, you can also restrict people from viewing the page before its appointed “Published” date.

Delaying Publication: Setting a Date

If all you want to do is delay the date and time that an article is “released” on your page’s index, you don’t have to do a whole lot of work.

Every article you post is “stamped” with a time by WordPress. When you hit the “Publish” button, it checks the current time on the server and attaches that to your post.

You may not have noticed, but there’s an option for you to edit this time while you are working on the article. For example, you could set the date back a week and backdate one of your posts. For our purposes, we’ll set the date ahead – and WordPress won’t display your post in any indexes until that date arrives.

In the “Write” section of your Dashboard, you should have a column of widgets on the righthand side (Categories, Discussion, Post Slug, etc). If you scroll down a bit, there should be one titled “Post Timestamp.” If you don’t see anything, click the “+” button in the title.

To set a custom release date, select “Edit Timestamp.” Then use the inputs to enter the date and time you want the article released. Voila – you’re done.

Restricting Access to the Page

For most people, this is good enough. Your readers aren’t going to be able to find the article without a link to it appearing on your front page or in your RSS feed.

However, if your readers do know the link to the page, somehow, they can still access it directly. If you want to prevent that, you’ll need to add a few lines of code to your template files.

We’re going to edit the “single.php” template file – the file responsible for formatting and displaying a single post. After the page retrieves the post, we’re going to perform a check to see if the published date of the article is in the future.

If it is, we’ll display an alternative message to tell the user the article isn’t published yet. Otherwise, the article will be displayed as normal.

Editing Single.php

Your template file probably doesn’t look exactly like mine, but there should be some very basic similarities.

If you open single.php, the page is displayed within “the loop.” It’s how every WordPress template works. The loop always begins with a line similar to this.

<?php while (have_posts()) : the_post(); ?>

This checks to see if a page was found in the database. If it was, it loads the page into memory and prepares to output it. The loop will eventually end with a line like this.

<?php endwhile; ?>

We’re going to create a new if statement and place it in between these two lines. The new template will look something like this.

<?php while (have_posts()) : the_post(); ?>
<?php if ($pubDate > time()) : ?>
  <h3>Article Not Published Yet</h3>
  <p>Sorry!  The article you request is not published 
    yet.  It should be available soon, so check back in a few days.</p>
<?php else : ?>
  ...  Regular post processing goes here ...
<?php endif; ?>
<?php endwhile; ?>

Creating the Conditional Statement

The only thing we have to do now is create a functioning conditional statement that checks to see if the published date of the article is in the past or the future.

To do that, we’ll use a few functions – get_the_time (a WordPress function to get the post’s timestamp), strtotime (a PHP function to convert a date string to a timestamp), and time (a php function to get the current tie).

get_the_time doesn’t return the actual time stamp – it returns a formatted date string, like “March 9, 2008, 11:13:35.” You can specify how it’s formatted, just like you would with PHP’s date function.

To get the timestamp, we’re going to format the time string in a special way so that strtotime() can convert it back to a full timestamp (preserving the exact time the article should be published). Then we compare that timestamp to the system time and see if the date has passed or not.

Use this if statement in the code above, and you should be good to go.

<?php if (strtotime(get_the_time('F j, Y, H:i:s')) > time()) : ?>

If you time delay an article and someone tries to access the article directly, they will now see your alternate message. You should of course personalize that to something appropriate for your site.

You can also apply the same concept to “Pages” in WordPress. You’ll need to edit the page.php template file and insert the same snippet of code there.

What are you waiting for? Go write some articles for the future.

If you wanted to make custom queries, you could certainly do that by diving straight into the database. However, WordPress comes with some built in functions for helping you query the database and display the results. By using these template tags, you can add custom loops in your template to display other post information.

Looking At the Main Loop

If you look in any of your templates, you’ll see a loop similar to the one below. This basic loop just loops through all the articles, outputs the title and content.

<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
<h2><?php the_title(); ?></h2>
<div><?php the_content(); ?></div>
<?php endwhile; ?>
<?php endif; ?>

WordPress has a nasty habit of using that weird while/if syntax, where things aren’t enclosed in brackets. Aside from the weird sytnax, this is a very simple while loop.

First, if (have_posts()) checks to see if there is any data in the queue to be outputted. If there is, it starts a while loop that uses the same check – have_posts() – to see if it should continue.

The thing that moves this along is the_post(). This loads the next post in the result set into memory and prepares it for outputting.

The next few lines do our basic output. the_title() is the template tag for outputting the title of the current article, while the_content() outputs the text of the article.

Finally, we wrap up the while loop and the if statement. If there were more articles in the queue (like on an index/archive page), it would loop through for each article.

Where Do the Articles Come From?

When you load a page in WordPress, you use a query string. The most basic one would be index.php?p=5. That tells WordPress to load the article where the post id is 5.

You may not realize it if you’re using pretty URLs, but every URL you request on your blog has one of these query strings built-in. It tells WordPress to load a list of articles (for an archive, category, or index) or to simply load one article or page.

There’s nothing stopping you from utilizing this process for other purposes, though. Rather than simply looping through the result-set created by the query string, you can use the query_posts() function to create your own custom queries – and then loop through them.

Example Please…?

Here’s how it works. You call query_posts() with a query string. That loads the database results and prepares for the loop. Then, you loop through like we did above to output information on the articles.

Let’s say you want to fetch the latest article that was tagged with both “foo” and “bar.” Here’s how you do it.

query_posts("tag=foo+bar&showposts=1");
//  Create the loop here

We passed two parameters here. “tag=foo+bar” tells WordPress to fetch articles that have both of those tags. “showposts=1″ tells WordPress to only fetch one article. By default, they’re sorted by date and time, so we automatically fetch the latest one.

You Don’t Always Need Plug-ins

This is such a great tool because it lets you avoid using some basic plug-ins. Plug-ins essentially help you perform these extra queries – like the latest posts, similar posts, etc. But they can also be restricting if they don’t do exactly what you want.

By using query_posts() to fetch your own information, you can get WordPress to do exactly what you want.

For example, let’s say you write movie reviews and you want to display the latest ones in your sidebar. Rather than look for a plug-in that displays exactly what you want it to, you can tag all of your movie reviews with “Movie Review” and query for those specific posts.

Then you can easily create the output you want, rather than the output someone else designed.

This is just a taste of what you can do with query_posts() and custom loops in WordPress. You’ll need to try it out for yourself to fully understand it, and I’d suggest you take a look at the documentation on query_posts() for a list of parameters and the documentation on template tags for a full list of output tags.

Good luck!

As others have pointed out, this can be counter-productive. People don’t like to read articles that have just one Digg – they seem unpopular.

So here’s a solution: use the Conditional “Digg This” WordPress Plugin to only show the Digg Badge for articles that have a certain number of Diggs.

Why Shouldn’t You Show the Digg Badge on Every Article?

It’s easy enough to plaster the Digg Badge in your template or use a plug-in to add it to every post. Most of your posts aren’t going to be popular though. You’ll get at most one or two Diggs… nothing to write home about.

When a user opens your article, he or she might be impressed by “100 Diggs.” He or she definitely won’t be impressed by “1 Digg.” That’s a hint that your article wasn’t anything special – so why should the reader keep going?

Using the Plugin to Only Show the Badge on Popular Articles

The Conditional Digg This plug-in was designed to address this issue.

All you need to do is download the source code, upload it to your plugins directory, unpack the tar.gz, and click “Activate.” You don’t need to modify any settings or insert anything into your template. It’s all automated.

How Does It Work?

The basic concept behind the plugin is this:

• Load a story in your WordPress Blog
• Check the Digg API to see how many diggs the article has
• If the article has 10 or more diggs, show the badge…
• Otherwise, leave it alone.

Originally, I coded the plug-in to use a php function to access the API and check the number of Diggs each article had as it loaded. This worked perfectly – but it took a while. Sometimes, the API is slow to respond. If the API took 8 seconds to spit back a response, that meant your page would take 8 extra seconds to load up.

Even if the API was responding quickly, this was a problem for the front page and category pages. At best, the API takes about .25 to .5 seconds to respond – and with 10-15 checks on a page… you’re still waiting a good long time for the page to load.

Load First, Check the API Later

The solution I came up with was to use some nifty AJAX to perform the API checking behind the scenes.

The plug-in creates an AJAX request for each article. It sends information to a php script which accesses the Digg API behind the scenes. The page loads up instantly and AJAX will quietly do its thing. When the response is ready, it’ll change the page to include the Digg This badge if necessary.

So, the next time you want to display a “Digg This” badge on your article, think about how many diggs your article has already. Or, use the Conditional “Digg This” WordPress Plugin to automatically add a badge to your popular articles.

I only realized today – while testing something else – that the plugin had been firing off warning messages because of an oversight in the code. Warning messages annoy me, so I decided to fix it up.

Where’s the Error?

The plug-in consists of one file – per-post-css.php.

Towards the end of the function per_post_css_js, the script loops through any retrieved CSS and JS files. During these loops, the link tags are added to the head element of the page.

Here’s the line that deals with CSS stylesheets.

foreach ($array_css as $css){ 
  print("\t<style type=\"text/css\" media=\"screen\"> @import url(". $css ."); </style>\n");
}

Notice anything potentially wrong here? What happens if there are no custom CSS files attached to your page?

Foreach looks for an array ($array_css). If a value is passed to foreach that is not an array, it’ll fire off a warning – and that’s just what it did.

The fix is simple enough. Before attempting to iterate the loop, first check to see that $array_css (and later $array_js) is in fact an array.

if (is_array($array_css)) {
	foreach ($array_css as $css){ 
		print("\t<style type=\"text/css\" media=\"screen\"> @import url(". $css ."); </style>\n");
	}
}

It’s a minor problem that creates some inconsequential warnings… but it annoyed me so I fixed it. If you have display_errors turned off in PHP (which I usually do) you won’t notice the problem either.

Per Post CSS and JS Updated Source Code

In the plug-in file, the homepage is listed as http://www.flog.co.nz. Oddly enough, I didn’t see a reference to the script on the page anymore, although the author still updates the page.

When I searched for a new copy of Per Post CSS and JS, I found a listing in a WP Plugin Directory – which pointed to an old post on flog.co.nz. That post and the link to the source code are both dead now. Perhaps they were cleaned up to make room for new content.

Regardless, I’m going to re-post the source code for the Per Post CSS and JS WP Plugin here to keep it available.

Kudos and thanks to the original author, Adam Burmister.

However, after some thought I became concerned that ten sitewide external links might be a bit of a drain on my pagerank. If only I could add “rel=nofollow” to all those links. But there’s no option in the RSS Widget to do that.

Well, I decided to dive in and fix it myself.

Where the RSS Feed Widget is Located

This is actually a very simple hack to the WordPress source files. You’ll need to edit two lines of the file, upload it, and you should be good to go.

The file we’re looking for is “widgets.php” – it should be located in the wp-includes folder. This holds all the functions related to creating widgets and it also holds the standard widgets available in the Dashboard.

We need to scroll down, find the “RSS Feed Widget,” find where the links are created, and add “rel=’nofollow’” to those anchor tags.

Hack It Up – Add Some Code

The function we’re looking for should be around line 935 – titled “wp_widget_rss.” Once you’ve found the function, look for this line – it should be around 965.

$title = "<a class='rsswidget' href='$url' title='" . 
  attribute_escape(__('Syndicate this content')) ."'><img 
  style='background:orange;color:white;border:none;' 
  width='14' height='14' src='$icon' alt='RSS' /></a> 
  <a class='rsswidget' href='$link' title='$desc'>$title</a>";

This creates the “RSS Icon” link to the original feed. There’s a second link in there that makes the link for the title of the RSS feed. To make these nofollow, simply add the phrase rel='nofollow' right after the <a. Be sure to use single quotes around the nofollow – or else you’ll break the PHP statement and cause an error.

When complete, it should look like this. Notice that we’re adding rel=’nofollow’ in two places.

$title = "<a rel='nofollow' class='rsswidget' href='$url' title='" . 
  attribute_escape(__('Syndicate this content')) ."'><img 
  style='background:orange;color:white;border:none;' 
  width='14' height='14' src='$icon' alt='RSS' /></a> 
  <a rel='nofollow' class='rsswidget' href='$link' title='$desc'>$title</a>";

Now scroll down a bit more to roughly line 990. The line we’re looking for creates the individual links to the articles. You should see this bit of code.

echo "<li><a class='rsswidget' href='$link'
  title='$desc'>$title</a>$summary</li>";

Again, add rel='nofollow' right after the <a. The result should look like this.

echo "<li><a rel='nofollow' class='rsswidget' href='$link'
  title='$desc'>$title</a>$summary</li>";

Upload the File

That’s it. Those two small changes should make your RSS Widgets nofollow from now on – preserving your pagerank.

Simply upload the file to the server (be sure to replace the old wp-includes/widgets.php) and reload your site.

If you run into an error, double check that you used single quotes around the ‘nofollow.’ The PHP string is started with a double quote (“), so if you place a double-quote there you’ll prematurely end the string – and cause a parse error.

Unfortunately, this isn’t a built in function of WordPress. Fortunately, you can add this functionality with a plugin.

Headspace

I originally accomplished this with the Headspace plugin.

Headspace is an all in one SEO plugin for WordPress. It’s major function is to allow you to add custom titles, tags, and meta descriptions to your WordPress posts. This should help with your SEO and SERP.

An added bonus is that you can add individual CSS stylesheets and JS scripts to each page. There’s an extra field in the writing page where you can add either of these two options.

This part of Headspace worked great. However, I was having trouble getting the other SEO functions to work. I was assigning descriptions and titles, but no meta tags were being generated.

Replacing Headspace

To fix that problem, I de-activated Headspace and got the All In One SEO Pack WordPress Plugin. It worked great, but that’s another post altogether.

I didn’t realize until after I had deactivated Headspace that I had also deactivated the custom CSS on a few posts/pages. I checked the pages and low-and-behold the custom CSS didn’t exist anymore.

I didn’t want to re-active Headspace just for this function, so I went off in search of a better solution.

Per Post CSS and Javascript

I eventually stumbled on this very simple plugin – Per Post CSS and JS.

It’s only a few short lines. It uses the custom fields function of WordPress to add the custom link tags. You define a CSS or JS field for a post, enter the URL, and the plug-in adds a link tag to the head section of your page.

It’s quite simple, and if I didn’t find a suitable script I was going to make one myself. However, this works perfectly well and I don’t think I could really expand on it (except maybe creating the CSS and JS fields on the writing screen, instead of using the custom fields) – so I doubt I’ll be writing my own plug-in anytime soon.

When it’s possible, re-use. Then focus your energy on things you need to do yourself.