HTML (Right before the close body tag)

<div id="loading"></div>

CSS

#loading{
    position:fixed;
    z-index:999;
    top:0;
    left:0;
    width:100%;
    height: 100%;
    background:rgba(0,0,0,0.3);
}

JS

$(function(){
    $("#loading").spin({/* YOUR SPINNER OPTIONS */}).hide();
    $('#loading').ajaxStart(function(){ $(this).fadeIn(); });
    $('#loading').ajaxComplete(function(){ $(this).fadeOut(); });
});

And bam, loading spinner that fires on all your backbone ajax calls. Of course this will work with any jQuery ajax framework too.

Facebook URL Regex

protected function valid_facebook_url($field){
    if(!preg_match('/^(http\:\/\/|https\:\/\/)?(?:www\.)?facebook\.com\/(?:(?:\w\.)*#!\/)?(?:pages\/)?(?:[\w\-\.]*\/)*([\w\-\.]*)/', $field)){
        return false;
    }
    return true;
}

Twitter Username Regex

protected function valid_twitter_username($field){
    if(!preg_match('/^(\@)?[A-Za-z0-9_]+$/', $field)){
        return false;
    }
    return true;
}

Hope this helps, I’m not 100% sure on the regex stuff so if you have any better methods let me know!

WordPress 3.4 has a fucking cool new feature on the themes page. Next to each theme theres a preview or a customize link that pops up a new overlay that lets the user live edit their themes. Adding extra theme options has been constant a pain the arse since I started developing themes all those few years ago. To make things easier for myself I even created a theme admin plugin. I was never that happy with the plugin however and always too busy to make it work so the new theme customizer seems like a good timesaver for me and I decided to take a look at how to implement it.

The first thing I found was that as with all new WP features no-one has written any documentation for customising (Hey WP core developers, customise is spelled with a damn s!) it yet. All I could find was this description of the beta version. Also there doesn’t seem to be an API yet, it must be coming in a future release. However, there is an object called $wp_customize that you can add your custom theme settings to.

Getting Started

On loading up my starter theme in the preview I was suprised in seeing a half built menu already there. This is because WordPress is pulling the options for custom headers, backgrounds that you’ve added using the add_theme_support() function. It also pulls some core options like site title and displays them there.

Custom Options

Time for custom options. Going through the blog post I found I saw that the first thing you need to do is hook a function to the customize_register action like this:

function themename_customize_register($wp_customize){
    //STUFF IN HERE
}
add_action('customize_register', 'themename_customize_register');

All your custom options go into there.

Adding a Section

This is simple enough as far as I can tell. You add one using the following:

$wp_customize->add_section('themename_color_scheme', array(
    'title' => __('Color Scheme', 'themename'),
    'priority' => 120,
));

So you pass through a unique slug and an array of arguments to the add_section method. I’m not 100% sure of all the arguments to pass through in the array, all I passed was the title and the priority. The priority is where you want the section to appear in the menu order. 1 is on the top and 120 seems to be the bottom.

Adding options

There are two methods you need to call to add an option. One to tell WordPress that an option exists and one to display whatever input box it needs. This is similar how the add_option()/update_option()/get_option() API works and it should be because it uses those functions to save the settings as far as I can tell/be bothered to check.

The first option type I’m going to show you is a standard text input box then I’ll breeze through the other types. You need to first call the add_setting() method to tell WP that you wish to save some new data. You do that like this:

$wp_customize->add_setting('themename_theme_options[text_test]', array(
    'default'        => 'Arse!',
    'capability'     => 'edit_theme_options',
    'type'           => 'option',
));

Similar to the add_section() method you pass through a slug and an array of args. You need to pass through a unique slug to this as the first parameter and it also allows you to pass the slug as an array index. The advantages of this is all your options are then available in the template in the one array keeping things nice and neat. The args I’ve found are:

• Default: The default value for the input.
• Capability: This is the user role that is capable of editing these settings, I assume you would always set it to ‘edit_theme_options’.
• Type: The way you want to store the data in WordPress, you can set it to ‘option’ or ‘theme_mod’. I’ve always used option for saving theme preferences but if you prefer using theme mod then you can set it to save those here.

Next you want to display your option in your custom section:

$wp_customize->add_control('themename_text_test', array(
    'label'      => __('Text Test', 'themename'),
    'section'    => 'themename_color_scheme',
    'settings'   => 'themename_theme_options[text_test]',
));

Again this works similarly to add_setting() and add_section() you pass a unique slug (Don’t really know why here as it’s only used as the list item css id) and an array of args. Some of the args are used for every input and some differ depending on the input element you want to display. The universal ones are:

• label: The form items label.
• section: The section in which you want the form item to appear.
• type: The type of form item you want. These are text, radio, checkbox and select. And are standard form elements. Textareas and HTML5 input types aren’t supported.
• settings: This is the setting you want to use to save the values from the file input. You put in the unique slug of of the setting you want to use.
• choices: These are only needed for radio buttons and dropdowns and contain the different options you want to display.

You can also add options to the sections created by the WordPress core by passing their slug in the section arg. The ones I found are:

• Colors: colors
• Header Image: header_image
• Background Image: background_image
• Static Front Page: static_front_page
• Site Title & Tagline: title_tagline
• Navigation: nav

Standard Input Types

These are just standard form items.

Radio

$wp_customize->add_setting('themename_theme_options[color_scheme]', array(
    'default'        => 'value2',
    'capability'     => 'edit_theme_options',
    'type'           => 'option',
));

$wp_customize->add_control('themename_color_scheme', array(
    'label'      => __('Color Scheme', 'themename'),
    'section'    => 'themename_color_scheme',
    'settings'   => 'themename_theme_options[color_scheme]',
    'type'       => 'radio',
    'choices'    => array(
        'value1' => 'Choice 1',
        'value2' => 'Choice 2',
        'value3' => 'Choice 3',
    ),
));

Checkbox

To be honest, I think I’m missing something here. It’s acting a bit wonkey. Maybe it’s broken?

$wp_customize->add_setting('themename_theme_options[checkbox_test]', array(
    'capability' => 'edit_theme_options',
    'type'       => 'option',
));

$wp_customize->add_control('display_header_text', array(
    'settings' => 'themename_theme_options[checkbox_test]',
    'label'    => __('Display Header Text'),
    'section'  => 'themename_color_scheme',
    'type'     => 'checkbox',
));

Select Box

$wp_customize->add_setting('themename_theme_options[header_select]', array(
    'default'        => 'value2',
    'capability'     => 'edit_theme_options',
    'type'           => 'option',

));
$wp_customize->add_control( 'example_select_box', array(
    'settings' => 'themename_theme_options[header_select]',
    'label'   => 'Select Something:',
    'section' => 'themename_color_scheme',
    'type'    => 'select',
    'choices'    => array(
        'value1' => 'Choice 1',
        'value2' => 'Choice 2',
        'value3' => 'Choice 3',
    ),
));

Page Dropdown

This displays a list of your pages. I guess you could allow the user to set pages for something custom. It’s weird that this is in there but not a category dropdown option.

$wp_customize->add_setting('themename_theme_options[page_test]', array(
    'capability'     => 'edit_theme_options',
    'type'           => 'option',

));

$wp_customize->add_control('themename_page_test', array(
    'label'      => __('Page Test', 'themename'),
    'section'    => 'themename_color_scheme',
    'type'    => 'dropdown-pages',
    'settings'   => 'themename_theme_options[page_test]',
));

You can hack in a category dropdown like this however:

$categories = get_categories();
$cats = array();
$i = 0;
foreach($categories as $category){
    if($i==0){
        $default = $category->slug;
        $i++;
    }
    $cats[$category->slug] = $category->name;
}

$wp_customize->add_setting('themename_theme_options[header_select]', array(
    'default'        => $default,
    'capability'     => 'edit_theme_options',
    'type'           => 'option',

));
$wp_customize->add_control( 'example_select_box', array(
    'settings' => 'themename_theme_options[header_select]',
    'label'   => 'Select Something:',
    'section' => 'themename_site_options',
    'type'    => 'select',
    'choices' => $cats,
));

Fancy Input Types

These are custom input types and use javascript to work. They also all vary slightly from the others in that a new object needs to be created for each control.

Image Upload

Image upload is a file input type and allows users to upload an image. Handy for letting them set their logo.

$wp_customize->add_setting('themename_theme_options[image_upload_test]', array(
    'default'           => 'image.jpg',
    'capability'        => 'edit_theme_options',
    'type'           => 'option',
));

$wp_customize->add_control( new WP_Customize_Image_Control($wp_customize, 'image_upload_test', array(
    'label'    => __('Image Upload Test', 'themename'),
    'section'  => 'themename_color_scheme',
    'settings' => 'themename_theme_options[image_upload_test]',
)));

File Upload

Adds a custom file input. Good for allowing the end user to upload files I guess. Maybe a custom favicon would use this?

$wp_customize->add_setting('themename_theme_options[upload_test]', array(
    'default'           => 'arse',
    'capability'        => 'edit_theme_options',
    'type'           => 'option',

));

$wp_customize->add_control( new WP_Customize_Upload_Control($wp_customize, 'upload_test', array(
    'label'    => __('Upload Test', 'themename'),
    'section'  => 'themename_color_scheme',
    'settings' => 'themename_theme_options[upload_test]',
)));

Color Picker

Displays a colour picker. Gives the user the option to destroy your theme with their bad taste. This input seems to have a hex colour callback for sanitizing the value.

$wp_customize->add_setting('themename_theme_options[link_color]', array(
    'default'           => '000',
    'sanitize_callback' => 'sanitize_hex_color',
    'capability'        => 'edit_theme_options',
    'type'           => 'option',

));

$wp_customize->add_control( new WP_Customize_Color_Control($wp_customize, 'link_color', array(
    'label'    => __('Link Color', 'themename'),
    'section'  => 'themename_color_scheme',
    'settings' => 'themename_theme_options[link_color]',
)));

Displaying these options in your theme.

Displaying this stuff is easy. Depending on if you set your setting_type() to option or theme_mod you can display it in the two following ways:

Option:

<?php $options = get_option('themename_theme_options'); echo $options['input_name']; ?>

Theme Mod:

<?php $options =  get_theme_mod('themename_theme_options'); echo $options['input_name']; ?>

In Closing

Thats as far as I got in a couple of hours research (fucking about), you can download a working gist of the examples that you can copy straight into your themes functions.php file below and have a fiddle with it yourself. Please feel free to correct whatever I have wrong up there as I made quite a few assumtions and have probably made a mistake or two.

Download the code

Update 30th June: Javascript!

Playing around with the customizer I just realized you have to use jQuery to do the live updates when a user changes options. It’s a bit hokey and I want to look into it a bit more. I’ll add that when I know it better.

Sign up for Github.

Go to Github and sign up for an account. This is pretty straightforward.

Fork the Proxy.

The proxy I’m using is a free open source one called Glype I’ve modified it a little for ease of use. To get these files all you have to do is make sure you’re logged into Github and go to here. You’ll see a list of the files and some other stuff. What you need to do is get a copy of these onto your own Github account. To do this just hit the ‘Fork’ button in the top right. This will copy the files from my Glype repository to yours. Take a note of the box with the repo URL in it, you’ll need that later.

Fig.1 The blue box is the fork button. Remember the location of the green boxes for later.

Sign up for Orchestra.

Orchestra is a web hosting service that you can attach to a Github repository. Once it’s set up it will automatically take your files and deploy them as a live website. What you need to do is sign up for a free account which you can do here.

Set up the Free App.

Ok this is the most complicated bit, but its not so hard. Log in to Orchestra and go to ‘My Apps’ Then click the ‘Deploy a Free App’ button. This will give you a form to fill out. Here’s the fields explained:

• Name: The name of your app. Put whatever you like in there, it has to be unique though.
• Repo URL: This is the location of the Github repository you set up in step 2. Look at the green box in Fig.1.
• Git Branch: Just leave this as master.
• Index File: This needs to be index.php
• SSH Key: In order for Orchestra to communicate with your Github repository an SSH key needs to be set up. Think of it as a password shared between the 2 services. You set it up like this:
  1. Hit the generate SSH key button and it will make you a password.
  2. Copy this and go to your Github repository and click ‘Admin’.
  3. Click ‘Deploy Keys’ and ‘Add Deply Key’.
  4. Type Orchestra in the title and paste your generated key into the Key field.
  5. Go back to Orchestra and hit ‘Launch App’.

And thats it, your free personal proxy will now be working at http://whatevername.orchestra.io

If you work as part of a team it can get even more complicated. In my office we can have up to three people contributing on a job, each with their own local environment settings. Plus, depending on the needs of the client, there could be up to four server environments set up. Throw source control into the mix (and you really should be using source control) and you end up with a small headache just keeping track of whats going on.

In this post I’m documenting a method of working with WordPress and multiple environments but the same concepts can be applied across a range of other content management systems such as ExpressionEngine and Joomla or frameworks like CodeIgniter.

Fig 1. The different local and server environments.

Overview of the different environments

1. The development environment is for testing settings on your server. It helps to test for problems which would be server specific. This is only for you or your team, the client never sees it.
2. The preview environment is for allowing your client to preview the current work in progress without having to give them access to the source code.
3. Staging is for testing before deployment to production and is hosted on the clients servers. You put the site up here towards the end of the project when you are happy letting them have access to the source code. If you have an ongoing retainer with the client you might ditch the preview environment and only use this.
4. Production is the live environment. The site is deployed here when it has been fully tested and is ready to be seen by the world.

The problem with this setup and WordPress

The problem with the way WordPress is set up is that it has only one configuration file (wp-config.php) which allows you to specify your database details and a few other options for a single environment.

Say you’re finished working on a feature and you want to put it onto a preview site and allow the client to look at it. You create the webspace and deploy the latest revision from your source control. The wp-config file that gets uploaded to your preview server will still have the details for connecting to your local database meaning it won’t work. Changing these details to point to the servers database obviously means that then your local site won’t work. You can get around this by deploying, logging into the server through FTP and changing the settings manually but this isn’t really an ideal solution as theres still the chance it could be overwritten by accident through a future deployment.

Configuration differences across environments

1. Database configuration.
2. Error reporting, it should be turned on on development servers and off on preview, staging and production.
3. Robots need to be blocked from development, preview and staging environments. Having Google display links to your work in progress is not just embarassing, duplicate content will hurt your clients SEO.
4. Keeping unauthorised people from accessing the development and preview environments.

The Solution

Enter the solution, the multi-environment wp-config bootstrap. This is a custom file that replaces the wp-config file in your installation and helps you configure your different environments.

How it works:

This works by accessing the $_SERVER['SERVER_NAME'] variable which gives us the server name. The environments each have a unique URL which gives them their own unique itentifier that will allow us differentiate between them, something similar to this:

• Local: http://localhost/project (“localhost”)
• Development: http://dev.yoursite.com (“dev.”)
• Preview: http://preview.yoursite.com (“preview.”)
• Staging: http://stage.clientsite.com (“stage.”)
• Production: http://clientsite.com (none of the above, which is also unique!)

Then we define a constant variable giving us an easy way to check the environment throughout the application. This all works like this:

// Define Environments
$environments = array(
    'local' => '.local',
    'development' => '.dev',
    'staging' => 'stage.',
    'preview' => 'preview.',
);
// Get Server name
$server_name = $_SERVER['SERVER_NAME'];

foreach($environments AS $key => $env){
    if(strstr($server_name, $env)){
        define('ENVIRONMENT', $key);
        break;
    }
}

// If no environment is set default to production
if(!defined('ENVIRONMENT')) define('ENVIRONMENT', 'production');

Adding your database connection details

Now all we need to do to add the different database configuration details. I’m using a switch here but an if statement will work just as well.

// Define different DB connection details depending on environment
switch(ENVIRONMENT){
    case 'local':
        define('DB_NAME', 'bootstrap');
        define('DB_USER', 'root');
        define('DB_PASSWORD', 'root');
        define('DB_HOST', 'localhost');
        define('WP_DEBUG', true);
        define('WP_SITEURL', 'http://bootstrap.local/');
        define('WP_HOME', 'http://bootstrap.local/');
        break;

    case 'development':

        define('DB_NAME', 'bootstrap');
        define('DB_USER', 'root');
        define('DB_PASSWORD', 'root');
        define('DB_HOST', 'localhost');
        define('WP_DEBUG', true);
        break;

    case 'staging':

        define('DB_NAME', 'database_name_here');
        define('DB_USER', 'username_here');
        define('DB_PASSWORD', 'password_here');
        define('DB_HOST', 'localhost');
        break;

    case 'preview':

        define('DB_NAME', 'database_name_here');
        define('DB_USER', 'username_here');
        define('DB_PASSWORD', 'password_here');
        define('DB_HOST', 'localhost');
        break;
}

// If database isn't defined then it will be defined here.
// Put the details for your production environment in here.
if(!defined('DB_NAME'))define('DB_NAME', 'database_name_here');
if(!defined('DB_USER')) define('DB_USER', 'username_here');
if(!defined('DB_PASSWORD')) define('DB_PASSWORD', 'password_here');
if(!defined('DB_HOST')) define('DB_HOST', 'localhost');
if(!defined('DB_CHARSET')) define('DB_CHARSET', 'utf8');
if(!defined('DB_COLLATE')) define('DB_COLLATE', '');

You should create different databases for each environment. However, if you want to use the same database for multiple ones you can define the WP_SITEURL and WP_HOME constants for each one inside the switch. This will hardcode the site URL meaning all your links will work.

Just be careful because if for example you’re using the same database for development and preview, any changes you make to content in development will then be reflected in the preview.

You could also use the same database and customise the table prefix for the environments which would effectively add multiple WordPress installations to the one database.

Lastly it can be set it up to turn on debugging automatically for the local and development environments and off for the others making sure you never accidentally leave it on on your production site.

Other usage examples

Now that we have the ENVIRONMENT variable set up we can add a few handy functions to the theme.

is_production()

A function to check if the current environment is production or not. Add this into your themes functions.php file:

function is_production(){
    if(ENVIRONMENT == 'production'){
        return true;
    }else{
        return false;
    }
}

Using Less or Sass

If you like to use Less or Sass and only compile the CSS for the production you can add this snippet into your themes header:

<!--?php if(!is_production()): ?-->
<script type="text/javascript">// <![CDATA[
var less = { env: 'development' };
// ]]></script>
<script type="text/javascript" src="<?php bloginfo('template_directory'); ?>/assets/js/libs/less-1.3.0.min.js"></script>
<script charset="utf-8" type="text/javascript">// <![CDATA[
 less.watch();
// ]]></script>
<!--?php else: ?-->

<!--?php endif; ?-->

Just make sure you compile the CSS before deploying to production!

Making the site accessible to only logged in users

If you want to make sure only people who are logged in can see the site you can reirect all unlogged in requests to the WordPress login page. Handy for keeping clients from nosing around your development environment. Add this to functions.php:

function password_protected(){
    if(!is_user_logged_in() && (ENVIRONMENT == 'development' || ENVIRONMENT == 'staging')){
        wp_redirect(get_option('siteurl') .'/wp-login.php');
    }
}
add_action('template_redirect', 'password_protected');

Adding a cookie check

A simple way of adding a cookie check to your preview environment that only lets people with a preview cookie view it. The cookie is created by adding ?preview to the URL like this http://preview.yoursite.com?preview

function require_cookie(){
    if(isset($_GET['preview'])){
        setcookie('preview', 'yes', time()+36000, '/');
        header('Location: /');
        exit;
    }

    if(ENVIRONMENT == 'preview' && (!isset($_COOKIE['preview']) || $_COOKIE['preview'] != "yes")){
        wp_redirect( 'http://www.google.com', 302 );
        exit;
    }
}
add_action('init', 'require_cookie');

That will keep the general public out of the site while giving the client an easy way to preview it.

Blocking robots

As explained earlier, keeping crawlers out of your development, preview and staging sites is very important. You can make sure this is done automatically by adding the following snippet:

function robots_access(){
    if(is_production() && get_option('blog_public') == '0') update_option('blog_public', '1');
    if(!is_production() && get_option('blog_public') == '1') update_option('blog_public', '0');
}
add_action('init', 'robots_access');

And there you have it, a nice professional way to manage your WordPress sites across your environments. This was inspired by Michael Flanagan’s CodeIgniter setup and Leevi Grahams Config Bootstrap for ExpressionEngine. You can download the wp-config file by clicking the link below and if you have any suggestions please leave a comment.

Download from Github

/**
 * abandon_cart_button
 *
 * Prints a Jigoshop cart button
 *
 * @param  string $prefix
 * @param  string $suffix
 *
 */
if(!function_exists('abandon_cart_button') && class_exists('jigoshop_cart')){

    function abandon_cart_button($prefix = '', $suffix = ''){

        $cart_contents = jigoshop_cart::$cart_contents;

        $output = $prefix;

        if(!empty($cart_contents)){

            $cart_contents_count = jigoshop_cart::$cart_contents_count;

            $output .= $cart_contents_count;
            $output .= ($cart_contents_count == 1) ? ' Item - ' : ' Items - ';
            $output .= jigoshop_cart::get_cart_total();
            $output .= ' <a class="button" href="' .jigoshop_cart::get_cart_url() .'">View Cart</a>';

        }else{

            $output .= 'No Items';

        }

        $output .= $suffix;

        echo $output;
    }
}

And then put the following wherever you want the button to appear:

<?php if(function_exists('abandon_cart_button')) abandon_cart_button('<div id="cart_button">', '</div>'); ?>

The function takes 2 optional parameters, one for content before the output and one for content after. Enjoy.

SEO Ready Permalinks

Permalinks are the URL structure of your site. Setting this up properly allows you to add keywords into your URL. You can do this in your WordPress admin by going to Settings > Permalinks. There are a number of options but I suggest clicking “Custom Structure” and adding in:

/%postname%/

This will add your post titles into your URL and allow you to add SEO keywords to it. You can add other elements to it such as the date or the post id but make sure that your post name is in there too!

Meta Title

This is the most important tag on the whole page. Search engines weigh your keywords in here a whole lot more than any other element. There are some do’s and don’ts for this. Do build your theme in a way that will allow a user to use an SEO plugin to customise it for different posts. Don’t use a static description and even more important: Don’t make it the site name!

Meta Description

Your meta description has no weight on your SEO. What it does is gives Google a short description of the page to go underneath the link to your post on their search page. This should not be static. You should either build it to be handled with an SEO plugin or leave it out. “Leave it out?!” you say, “You must be crazy!” But think of it like this, Google knows when it’s scraping a WordPress site. It gets a little grumpy when it sees a static description, but when it doesn’t exist it takes a look into the body copy and pulls the description out of that. So as long as you have your keywords in your copy Google will find a relevant bit of text to go into that spot.

Meta Keywords

These don’t really have any effect but the general consensus is that they can’t hurt. Some SEO “experts” will tell you that your competition will look at this to easily see what keywords you use but I think they’re just being paranoid.

Logo

A bit mistake that a lot of theme designers make with this is by putting the site name in a heading 1 tag and then use CSS Image replacement to add in the image of the logo. Do not do this. Heading 1 tags are for your page titles, if you put the site name/logo in a h1 then search engines see that as the most important heading on the page and every page has the exact same heading! Instead do it like this:

<div id="logo">SITE NAME</div>

And use your CSS image replacement. This will give your page a more semantic structure. And actually here’s a quick note on:

CSS Image Replacement

This is totally acceptable if for example you want to use images for your navigation. What CSS replacement allows us to do is write up semantic html then make it look shinier by replacing the text with images in CSS. Search engines will then be able to read the text in the links and the users get some nice buttons. Just don’t use it to stuff your markup with keywords or you’ll get penalised. And so onto another quick note on:

Navigation

Search engines use your navigation to find out site structure so make it as easy for the robots to scrape as possible. Be careful about using Javascript on it as it might make it hard for them to read.

Breadcrumbs

When building a theme you should add in support for a breadcrumbs plugin. Breadcrumbs are crucial for the internal linking on your site and help both users and search engines know where they are in relation to the homepage. You should also make sure that your categories, tags and other taxonomies are well named and include your keywords.

Page Heading

Every page should have a h1 tag. This is the second most important element on your page after the meta title. You should put your main keywords in here. Don’t make them too long though, I try to keep mine to less than 10 words.

Images

I like to use a featured image for posts and pages in my WordPress themes then display them in a nice prominent way on the page. It is important when adding these images to put a caption with your keywords into the alt tag on the image. You can do this when uploading the picture in the admin panel. Some people like to load the alt tag with keywords but this is not good practice and will end up getting you penalised.

Post Links

When linking to posts you should use the post title as the text for the link. Just the text will do if the list is in the sidebar but if it is a WordPress archive page you should add the excerpt too so each post has a description. Also when linking to the full post you should put the post title as the first link. If you want to have a read more button add it as a second link to the post and place it after the excerpt.

Sidebar

Your sidebar should always come after the body content in you site code. If you need to place it to the left of the content use CSS floating to achieve it. Remember, search engines rate the content closes to the top of the source as the most important content on your pages.

Content

This is pretty self explanatory. If you are writing about a topic you need to make sure you use the right keywords the right amount in the post content. This is called keyword density. Basically it’s the percentage amount your chosen keywords are used compared to the rest of the content. It should be over 1% but I try and go for around 3-4%.

Dynamic Content

As mentioned before, be careful with dynamic content. Search engines aren’t able to crawl Flash or content loaded with javascript so this won’t be picked up. A huge mistake people make is having a flash site with no alternative for search engines. Plus the content won’t load on an iPhone!

Semantic Code

And lastly, you need to keep your code as clean as possible. A nice light semantic page with no errors will make it much easier for your content to get crawled and found.

Clean code makes Google a happy, happy, hippopotamus.
Abban Dunne – 2011.

Lastly, lastly, remember these are only starting guidelines. SEO goes much deeper than just structuring your web pages correctly but this will give you a good start. If your WordPress theme follows these instructions and doesn’t make any of the obvious mistakes then I reckon you could definitely label it as an SEO ready theme. If you’re looking for a good plugin to handle some of the extra SEO functionality I highly recommend the WordPress SEO Plugin by Yoast.

If you have any suggestions or updates please leave them in the comments below.

chflags nohidden ~/Library

And bam, it’s back to normal.