For a recent project I had to parse time tags both from WordPress and from an RSS feed. After some mucking about I found what I think is the optimal solution, so to save you some time I’ve put it all together for you.

Date stamp for WordPress using the <time> tag

WordPress can output the publishing date and time in pretty much any configuration you want. For the time tag to work you need the datetime variable to show the time in a specific format that looks like this:

2012-01-30T18:55:21+08:00

That’s year, month, date, time (international) and an optional time zone reference. I’m in Vancouver, Canada so that’s GMT+8 hours.

Using the get_the_date() function in WordPress you can get this time format and any other. In this case I wanted the format “Jan. 30, 2012″.

The end result:

<time class="entry-date" datetime="<?php echo get_the_date( 'c' ); ?>" pubdate><?php echo get_the_date('M. j, Y'); ?></time>

Date stamp when parsing RSS feeds using the <time> tag

For the project I also needed to parse an RSS feed and show the details of each item in an index page. RSS feeds output the date in a standardized format, but it is rather unsightly:

2012-01-30T23:00:00+00:00

I needed to get this parsed to match the example above. To do so I used a handy PHP function provided by Handy PHP called Reformat Date. This function uses the strtotime() PHP function to reformat dates into anything you want simply and easily.

First I added the function itself to the functions.php file in my theme like this (notice I append the name of the theme at the front of the function name to avoid any future clashes should WordPress decide to bake this feature in):

// Reformat date for RSS feed
function theme_reformat_date($date, $format){
// Function written by Marcus L. Griswold (vujsa)
// Can be found at http://www.handyphp.com
// Do not remove this header!
 
    $output = date($format, strtotime($date));
    return $output;
}

Second I grabbed the RSS feed using WordPress’ native RSS import function (I’ll write about that in a separate post but it’s pretty straight forward) and then I parsed the data.

Note: In an RSS feed the time is contained in each item under the handle pubdate so to get the raw time I use $item['pubdate'].

<time class="entry-date" datetime="<?php echo theme_reformat_date($item['pubdate'], 'c'); ?>" pubdate><?php echo theme_reformat_date($item['pubdate'], 'M. j, Y'); ?></time>

Note that the date has to be reformatted twice, once for machine readable output (‘c’) and once for the human readable output (‘M. j, Y’).

It may not sound like much, but this is big. As in you can make your own WordPress.com. In the cloud. With infinite scaleability and redundancy. Without managing your own server.

The Idea

As with many other WordPress developers one of my big challenges has always been hosting. You basically have two options: Host your clients independently on their respective shared hosting plans all over the web or host them on your own server. If you choose to host them on your own server you again have two options: Host them as separate WordPress installs or host them all under a WordPress Network (previously WordPress MU). By far the best option from a content management and administration point of view is the WordPress Networks option. But it came with some pretty brutal downsides: When hosting multiple sites under a WordPress Network you are basically calling one set of core files and one database from many sites at the same time. And though this is unproblematic if each of the sites get a couple of hundred visits a day it becomes a huge problem if you have say ten sites that each pull 10,000 visits an hour. Why? Because that amounts to 100,000 calls to the same core files and the same database. That kind of traffic requires a robust server and a big pipe.

The solution to this problem has been to host such networks on unreasonably large and powerful servers. You basically scale for the worst case scenario and pay for a lot of down time in between. An inefficient solution, and also a cumbersome one as these setups in most cases require constant server maintenance and upkeep. Not to mention the enormous headache of adding additional drives and servers should upscaling be necessary.

This is what the cloud was built for: Dynamic scaleability both in terms of bandwith, capacity and processing power. So the best solution for WordPress Networks must surely lie in the cloud somewhere.

There’s just one problem: The cloud is complicated. And that’s where Windows Azure comes in – at least it did for me.

I’m not a gardener

Though I consider myself proficient at web development and people have referred to me as a “WordPress Adept” I am by no means a server expert. Quite the contrary. I have only a superficial understanding of servers and server maintenance, and I have little interest in expanding my knowledge in this field. So though a cloud server would provide me with a garden in the cloud I have little interest in becoming a gardener. I just want it to work. And that’s what Windows Azure offers: A maintained garden where I could deploy my applications.

The problem of course was that Windows Azure runs a .NET framework and a SQL server, not the PHP framework and MySQL server required by WordPress runs on. What was needed was some sort of symbiosis. Which is what we’ve been working on for the last 6 months.

Make it Native

Previous attempts had been made to make WordPress run on Azure, and they did work, at least for short periods of time. The problem was that they created pseudo states within the Azure framework where the PHP application could run, but these pseudo states were not stable. What was needed was a way of making WordPress into a native Azure application. That way it would be persistent, properly scaleable, and could be managed like any other Azure application. But this had to be done without touching the core files within WordPress, otherwise future updates would become a nightmare and that would defeat the purpose of doing this in the first place.

The solution was to create a set of adjoining files that served as bridges or translators between WordPress and the foreign Azure environment. That way the administrator could swap out and upgrade core files within WordPress without breaking anything and also change the configurations of the application through the normal Azure interface. And after a lot of experimentation and tweaking it worked.

Domains for everyone

So now we had a persistent, upgradable installation of WordPress running in Network mode on Azure. The last hurdle, the one that would prove to me most challenging, was to achieve seamless domain remapping for the different network sites. Let me explain:

A WordPress Network can be set up in two ways: Sub-sites or Sub-directories. The former produces site URIs such as newsite.pinkandyellow.com while the latter produces URIs like pinkandyellow.com/newsite. The obvious problem with both is that they use the pinkandyellow.com domain as the root. Which won’t work if you intend to host other sites or client sites under your network.

Domain remapping allows you to point these sub-sites or sub-directories to a different domain, so instead of newsite.pinkandyellow.com you’d get newsite.com. This requires a WordPress plugin (of which there are several) because the remapping has to be done based on the core URL. I could go on ad nauseum about how this works but suffice it to say it only works with one of these plugins. Problem is none of these plugins worked with SQL servers. Instead they produced bizarre errors and messed everything up quite badly. For a long time. Until the lead developer Satish found a solution.

Your own personal garden in the blue cloud

The end result of all this is a simple solution that allows you to deploy WordPress Networks on Windows Azure as a native application. By doing this you can take advantage of every aspect of the cloud including scaleability, persistency, CDNs and redundancy. But most importantly you will no longer be paying for processing power and bandwidth you are not using. Because Azure is a scaleable environment your solution will breathe with traffic, expanding and contracting as visitor numbers go up and down. As a result your costs will be a true representation of actual use, not a worst case scenario approach.

There are other great benefits to this solution including the ability to remote desktop into the application itself for beta testing and quick resets should something go wrong. In fact there are more possibilities here than I am able to wrap my mind around and as we move forward with the project countless more will undoubtedly take shape.

For now the only thing that matters is that you can set up and deploy your own installation right now and give this new solution a spin for yourself.

In the coming months I’ll be posting a series of tutorials and articles on my own experiences running WordPress on Azure. The first one on how to create a single site installation went live a couple of weeks ago and will be updated as the deployment solution matures. To see a live example of WordPress running on Windows Azure you can head on over to PhotoPivot.com which currently runs on four extra small instances.

At first I thought it was a matter of removing the actions that called the plugin itself. I’ve done this in the past and it works for some plugins. I also found a code snippet here that seemed to show it working. That unfortunately was not the case. So I had to keep digging. Then I found this excellent article How to disable scripts and styles by Justin Tadlock that explained it all: I needed to de-register the scripts, not simply remove the function.

After digging through the plugin code I found the script calls and ended up with this code snippet in my functions.php file:

<?php 
 
// remove WP Geo JS/CSS from the nybank page
add_action( 'wp_print_scripts', 'vierderduer_deregister_javascript', 100 );
 
function vierderduer_deregister_javascript() {
 
	if (is_page_template('page-nybank.php')) {
 
		wp_deregister_script( 'googe_jsapi' );
		wp_deregister_script( 'jquery' );
		wp_deregister_script( 'googlemaps' );
		wp_deregister_script( 'wpgeo' );
		wp_deregister_script( 'wpgeotooltip' );
		wp_deregister_script( 'wpgeo-admin-post' );
 
	}
}
 
?>

As you can see I made the function conditional so it only kicks in when a specific page template is used. You can swap out that condition for any other condition for the same result. Bottom line is it works and now WP Geo works on every page, post and post type except pages that use the page-nybank.php template file.

UPDATE November 2, 2011: The WordPress on Azure scaffolder has been updated and a new and easier process has been introduced. In response this tutorial has been rewritten to reflect the new methods.

In this step-by-step tutorial I’ll take you through the process of publishing a single-site deployment of WordPress on Windows Azure. By “single-site deployment” I mean that you’ll be using WordPress as one single site. In contrast a Network deployment refers to a situation in which you’ll set up WordPress and then run multiple sites under it in a network.

A step-by-step tutorial on how to deploy WordPress Networks on Windows Azure will be posted in the near future.

What you’ll need

• Windows Azure account (get a free trial here)
• Windows Azure SDK (total pain to install so I suggest you use Web Platform Installer)
• FileSystemDurabilityPlugin
• Windows Azure SDK for PHP
• PHP
• WordPress on Windows Azure scaffolder tool
• Optional: The plugin(s) you want to use
• Optional: The theme(s) you want to use

The two last points are optional, but it’s always a good idea to install WordPress with the plugins and theme(s) you want to use right off the bat. It saves you a bit of time later on.

Note that the following assumes you have a Windows Azure subscription. If not, go to the Windows Azure website and get a free trial.

1. Setting up Azure

The first step in deploying WordPress on Windows Azure is to set up the necessary elements in the Windows Azure environment. This is all done through the Windows Azure Management Portal found at http://windows.azure.com. For the deployment you’ll need a new Hosted Service, dedicated Blob storage and a database.

1a. Create a new Hosted Service

Your WordPress deployment will live in a Hosted Service on Windows Azure. You can have multiple Hosted Services under one account. To set up a new Hosted Service log into the Windows Azure Management Portal and click the New Hosted Service button in the top left corner.

This opens the New Hosted Service dialog where you can define the different parameters of the hosted service as seen below:

Off the top you select what subscription you want the new Hosted Service to live under.

Next give it a name so you know what it’s about and enter a dedicated URL prefix for your application.

By default all Windows Azure applications have a URL that looks like http://something.cloudapp.net. You can change this by forwarding one of your own domains to this address. More on that later.

Under Choose a region or affinity group you define in what general geographic area the application will be used. Pick the region or affinity group that is closest to your users.

When setting up a new Hosted Service you can deploy an application immediately. But since we have yet to build a deployment, check Do not deploy and click OK.

Windows Azure now runs a process and when it is completed you should see your new Hosted Service on the list as seen below.

1b. Create a Storage Account (Blob storage)

We’ll be using a Blob Storage Account to host all the uploaded content as well as the plugins and themes so that if and when your Windows Azure deployment reboots or reimages you don’t loose all this content. To create a Storage Account click on the New Storage Account button in the top left corner.

This opens the Create New Storage Account dialog as seen below:

Again pick the subscription you want to host the storage under, enter a URL prefix and set the region or affinity group. Make sure to place the Storage Account in the same region or affinity group as the Hosted Service.

Windows Azure runs a process and when it is completed you should see your new Storage account on the list as seen below.

1c. Create a Database

The final step in the Windows Azure setup process is to create a database. This is where all the actual content of the WordPress site will live. This is a two step process: First you set up a new Database Server and then you set up a new database within it.

To create the new Database Server click the Database button on the lower left and click the huge Create New SQL Windows Azure Server button under Getting Started. Alternatively you can select the correct subscription and then click the Create button on the top toolbar. This opens the Create Server dialog. This is again a multi-step process.

First select the region (again, pick the same region you chose for the Hosted Service and Storage).

On the next screen set the username and password for the server. This is the info you’ll use to interact with the databases on the server so make sure you have a copy of it somewhere. You can edit it later but it’s a big pain.

The next step is interesting. You can assign custom IP addresses that are allowed to access your database directly. That’s not necessary in our case, but it could be in the future. For now just check the Allow other Windows Azure services to access this server box so WordPress can read and write to to the database. This will add a new rule with the IP range 0.0.0.0.

When you click Finish, Windows Azure will create the new database server. When it’s done it will appear with a weird computer generated name on your server list as below.

With the database server set up you can now create a database for WordPress. To do this select the new database server and click the Create Database button on the top menu. This opens the Create Database dialog seen below.

In the dialog give the database a name (this is the name you’ll call from the WordPress config file, define the type (edition) of database you want (the options are Web and Business of which I use Web) and set the maximum size. If you’re running a single install WordPress site I’d be flabbergasted if you ever managed to get the database up to 1GB so stick with that.

Click OK and Windows Azure creates the database. You’ll notice that there are two databases in the server, one called Master and the one you created. This is as it should be. You can manage, drop and mess with the database you created all you want but you should leave Master alone.

2. Preparing your computer for the build

Before creating your WordPress on Windows Azure deployment package you need to install the Windows Azure SDK, the File System Durability Plugin and the Windows Azure SDK for PHP. The Windows Azure SDK is necessary for your computer to be able to build an Windows Azure deployment package. The File System Durability Plugin does exactly what it says – ensures file system durability. This is necessary because in Windows Azure you can spin up and down several instances of the same site and we have to make sure the instances are identical all the time. The Windows Azure SDK for PHP contains the functions necessary to build custom Windows Azure deployments that depend on PHP.

The easiest way to install the Windows Azure SDK is to download Web Platform Installer, search for “Azure SDK” and install it using the tool. Web Platform Installer will do all the heavy lifting and configurations for you in one clean sweep. If you really want to you can also install the Windows Azure SDK manually but I’m going to warn you up front that it’s a pain unless you are very familiar with IIS and other Windows obscura.

To install the File System Durability Plugin download the zip file from Github and extract it into the Windows Azure SDK plugins folder found at:

C:\Program Files\Windows Azure SDK\v1.x\bin\plugins

Finally to install Windows Azure SDK for PHP simply download it and place the contents of the trunk folder somewhere on your computer. I created a folder called “Windows-Azure-SDK-for-PHP” in my Program Files folder for this. For what we are doing the SDK for PHP requires no installation, it just has to live on your computer in a place you can remember. If you want it to be a permanent feature on your computer you can follow the instructions at this site for a more advanced install.

3. Creating the WordPress on Windows Azure scaffolding

The following assumes you have already installed Windows Azure SDK, the FileSystemDurabilityPlugin, Windows Azure SDK for PHP and PHP.

With Windows Azure set up it’s time to create the WordPress deployment package. This is done using a “scaffolding” tool created specifically for this purpose. The tool is baked into the Windows Azure SDK for PHP. The basic idea of the scaffolding tool is that it builds the framework in which we will build and configure the final deployment package. Once the scaffolding is created we can configure and add content such as plugins and themes to the WordPress core before deploying it.

To make this process as easy as possible the Microsoft Interoperability Team has created a complete solution for us, available from Github. Download the entire package where you want to do the setup for your deployment and let’s get started.

The actual building of the scaffolder will be done in Command Line (Start -> CMD) in Administrator mode. You can start it from the Start Menu (remember to right-click and select Run as Administrator).

Before running the scaffolder command you need to include the Windows Azure SDK for PHP in the system environment. This can be done by tweaking your system settings, but if you want a quick and easy way that leaves your system settings alone you can just configure it for the current open command line window using this command:

SET PATH=%PATH%;c:\PHP;C:\Program Files\Windows Azure SDK for PHP\bin

(The above assumes PHP is installed in the PHP folder on C: drive and the Windows Azure SDK for PHP is installed in the Windows Azure SDK for PHP folder under Program Files. Your command may be different depending on where you installed PHP and Windows Azure SDK for PHP.)

With the system settings changed it’s time to run the scaffolder. You can do this manually or you can use the convenient new build.bat batch file that will run the entire process for you. In command line type:

build.bat

If you’ve kept all your ducks in a row up until this point the scaffolder will now run and you’ll see a bunch of prompts in the command line window. The scaffolder sets up the entire environment you need to get WordPress to run on Windows Azure, downloads the latest version of WordPress automatically and adds a couple of very important WordPress plugins to boot. Pretty nifty.

When the command completes you’ll have a new folder called “build” in the same folder where build.bat was located. The build folder in turn contains three files: ServiceConfiguration.cscfg, WordPress.cspkg and WordPress.phar in addition to a folder called WordPress.

4. Configuring the WordPress for deployment

With the scaffolding built it’s time to configure WordPress. If you’ve ever worked published a WordPress site before you know that you need to plug in database access info and other data in the wp-config.php file before deployment for the site to hook onto the database. In the case of WordPress on Windows Azure however, that information is placed in an Windows Azure configuration file and the wp-config.php file queries this configuration file for the details. This allows you to change the configuration of the WordPress installation on the fly through the Windows Azure deployment configuration panel rather than having to redeploy every time you want to change something. The file in question is found in the build folder and is called ServiceConfiguration.cscfg. Open ServiceConfiguration.cscfg in a text editor and make the following changes as outlined below:

Database info

DB_NAME is the name you set for the database, in my case “PhotoPivotDB”

DB_USER is your Windows Azure username combined with an @ and the name of the database server as assigned by Windows Azure. The full user name looks like this: “mor10@k3b1ogbnc7″

DB_PASSWORD is the password you defined when setting up the server.

DB_HOST is the host name of the server combined with .database.windows.net, so for example k3b1ogbnc7.database.core.windows.net

Security keys

With the new build.bat file the security keys are automatically generated so you no longer have to worry about them unless you want to add more complicated encryption.

FileSystemDurabilityPlugin settings

This section relates to the FileSystemDurabilityPlugin. Here you provide the access info to the Blob storage you set up earlier:

StorageAccountName is the name you gave your storage, in my case ppwpstorage

StorageAccountPrimaryKey you get by going to the Windows Azure portal, clicking Hosted Services, Storage Accounts & CDN, selecting your storage and clicking the Primary Access Key button on the top right hand corner:

This opens a dialog from which you can copy the access key. It ends with two equal signs (==)

Leave everything else as it is.

5. Create the Deployment Package

The core setup is now complete and we are ready to create the deployment package. If you want to add any custom plugins or themes to your deployment, this is the time to do so. You find the plugins and themes folders under the \build\WordPress\WebRole\wp-content\ folder where you can add them by simply dropping them in. This is also where you add new or changed files when you are going to redeploy.

To ensure that WordPress can send administrator emails I recommend you download and add the WP Mail SMTP plugin. As Windows Azure does not have a native email server you need to use an external SMTP server to handle WordPress’ emails. This is further covered at the end of the article but since you’ll want the mail function to work you will save time by adding the plugin now so it’s part of your deployment package.

Creating the package is the final step before deploying to Windows Azure. Like with the scaffolder, the packager is run in comman line. First, navigate to the build folder where you find the WordPress.phar file. Then run the as follows:

package create -in=".\WordPress" -out=".\package" -dev=false

The process runs and you should end up with a new folder called package with two files: WordPress.cspkg (named after the export folder) and ServiceConfiguration.cscfg.

6. Deploying the Package

To deploy the package log in to the Windows Azure Portal, go to Hosted Services, Storage & CDN, click Hosted Services and select the hosted service you created earlier.

Next click the New Production Deployment button in the upper left corner. This opens the Create a new Deployment dialog:

Give your deployment a name and point the Package location to your WordPress.cspkg file and Configuration file to ServiceConfiguration.cscfg, both in the package folder.

Click OK and if everything is correct you’ll get a warning like the one below. Click OK and the package will be uploaded and deployed. Because the build file will be at least 15mb in size this may take a bit of time.

Once the package is uploaded you have to wait for Windows Azure to do its thing. This can take quite a long time (I’ve seen it take over an hour!) You just have to be patient and wait for it to do its thing.

7. Setting up WordPress on Windows Azure

If everything went as planned you should see the Deployment, Role and Instance of your deployment change to Ready. If so you can click on the deployment and you’ll get the DNS name you set in step 1a (http://something.cloudapp.net). Visit this address and you’ll get the standard WordPress setup screen.

Here you fill out all the standard stuff like Site title, username, password and an email address. Before clicking Install WordPress, make sure you remember your username and password! As Windows Azure doesn’t have an email server WordPress will not send you an email with your username and password nor will it do so if you click the “I forgot my password button”, so be careful.

After hitting Install WordPress the application is installed as normal and you get to the login screen. From here we have to do a couple of extra things before we’re all set to go:

7a. Set up Windows Azure Storage for WordPress

WordPress normally stores all uploads in the wp-content/uploads folder and this works fine on a normal server. But Windows Azure is a virtual server environment so things don’t work the same way. This is especially true when it comes to uploads. Because your WordPress instance (or instances) on Windows Azure live on a virtual server that can be reset and re-imaged, the WordPress on Windows Azure solution has to create synced copies of the wp-content folder in Blob storage so that all instances are identical and resets are not destructive. That means if you have a ton of images or other files on your site, these will be constantly passed back and forth between your instances and Blob, and that will become costly.

To get around the problem the WordPress.phar file ships with an extra plugin called Windows Azure Storage for WordPress. This plugin allows you to use Blob storage to save media in your installation.

Before activating the plugin you need to assign a container in your Blob storage for your uploads. The easiest way to do this is to use a tool like CloudXplorer and set it up manually.

To activate go to Plugins and activate Windows Azure Storage for WordPress.

Then go to Settings and select Windows Azure. This takes you to the configuration page for the Windows Azure Storage for WordPress plugin.

Here you need to plug in the storage account name and the access key for the storage account. I use the same storage as for WordPress itself so I just copy the info out of my ServiceConfiguration.cscfg file and paste it in. If you want to you can set up separate storage as well but it seems excessive.

If you want to you can define an alternate CNAME for your storage (by default the domain for your Blob storage is http://YourAccountName.blob.core.windows.net/) and even set up proxy server info. I’ll leave that for you to decide.

Lastly remember to check the Use Windows Azure Storage for default upload box.

With everything set click Save changes and the plugin will connect to your storage.

At this point the Default Storage Container filed will be populated with whatever storage containers are available in Blob storage. Pick the container you set up for your uploads using CloudXplorer and click Save changes again.

Now you should be ready to go. Just to make sure, go to Media, upload an image and make sure it works and that the URL points to Blob storage.

7b. Set up an external SMTP server

The final compulsory step in setting up WordPress on Windows Azure is to set up an alternate SMTP server for the application so it can send emails to you and others. This is important because WordPress uses emails to communicate with you about things you need to know such as new user registrations, new comments and most importantly how to retrieve your username and password when you forget.

Setting up an SMTP server can be done using any one of a number of plugins. We use the WP Mail SMTP plugin by Callum MacDonald on PhotoPivot.com and it works splendidly. The setup of this plugin is self-explanatory and should need no further elaboration except to say you can use any number of different free SMTP servers to do so including GMail, Hotmail and others.

8. Extra Credit: Domain redirect

Now you have a fully functional WordPress site running on Azure on the domain name http://yourchosenname.cloudapp.net. That may not be what you had in mind. Fortunately redirecting a domain to Windows Azure is very easy. There are two steps involved:

1. Use a CNAME redirect to point your existing domain to the Windows Azure domain (so www.yourdomain.com points to yourchosenname.cloudapp.net)
2. In WordPress go to Settings -> General and change WordPress address (URL) and Site address (URL) to your new domain name.

These have to be done in order and you should not change the WordPress settings until your domain fully redirects to WordPress, otherwise you won’t be able to visit your site.

Appendix: Caveats

Plugin support

Though running WordPress on Windows Azure is cool, there are some drawbacks, the most important of which is that not everything works as expected. WordPress itself will run fine, but many plugins cause weird problems or don’t work at all. This is especially true for a lot of form plugins. The reason for this is that WordPress on Azure uses SQL Azure even though WordPress is meant to run on MySQL. Needless to say this causes some rather bizarre problems not experienced elsewhere. That said this is a minor concern and one that can be resolved with some clever coding

Service resets

Due to the nature of Windows Azure, the system will sometimes reset. There is no warning when this happens and you don’t know how long it’s going to last. The way around this is to create several instances of your site. That way when one goes down the other one stays up.

Bleeding edge means weird problems

Running WordPress on Windows Azure is an interesting experience. Having created hundreds of WordPress sites on many different servers I can tell you I’ve experienced things on Windows Azure I’ve never seen before, and a lot of it I can’t explain. However most of these issues have been worked out and what we have now is a stable and solid release. Even so I must warn that by doing this you are entering into the world of extreme bleeding edge scenarios so expect the unexpected!

Good luck and report back!

Now you have the complete algorithm to get WordPress up and running on Windows Azure. The only thing left is to try it for yourself. And once you’re up, report back in the comments below and tell the world how it went, what happened and if you ran into any weirdness along the way. I’d love to hear from you and see what you’re doing so don’t be a stranger! You may also want to check out the Github forums for the scaffolding tool to see what other people are doing with this solution.

The problem arises when you want to create custom page templates. Previously all you needed to do was copy the page.php file and make the changes you wanted in the loop. But with the new system copying the page.php file alone won’t let you make any changes to the loop, just the overall structure (header, sidebar, footer etc). To make changes to the loop you have to either copy the loop code out of loop-page.php and into your custom page template or use a conditional statement along with the is_page_template() function in the loop-page.php file to detect that a custom page template is being used and then make the changes. The video above demonstrates both approaches.

What I like about this feature is that it runs of non-intrusive meta tags and JavaScript so that although it only works in IE9, it doesn’t interfere with other browsers. It becomes a value added experience for IE9 users but it doesn’t take anything away from people who do not use IE9 or don’t have Windows 7 as their operating system. Progressive enhancement I believe they call it

Last Saturday I did an hour long demo of this feature and how to build it into a WordPress site. The example in question was this very site and now I’m going to show you how you can make  your own WordPress site pinnable too.

Pinned Sites and why they matter

So what is a Pinned Site in IE9? The idea is simple: You open a site in IE9, grab the tab for that site and pull it down to your Windows 7 task bar. If the site is pinnable it will dock onto the taskbar with a custom icon like you see in the grab above. When the user then clicks the icon, a custom IE9 window will open just for this site. The size and even element colour of that window can be defined by the site owner. The result is that the website becomes more like a native application on the computer and this in turn leads to increased stick time (49% for the Huffington Post), more exposure and higher returning visitor rates. Whether you like IE9 or think it’s the worst thing since sushi falvoured gum the reality is site owners will benefit from this functionality. But I digress.

Making your site pinnable

To set up basic pinned site functionality you need a high quality favicon and access to your theme files. If you have both you’re good to go.

Because the pinned icons on the taskbar are larger than the regular ones I recommend using X-Icon Editor (free online tool) to generate the icon and create it for all four standard sizes (64×64, 32×32, 24×24 and 12×12). I also recommend creating it from a high quality and high contrast PNG file so it looks nice regardless of the background.

Once  you have the favicon.ico file save it to your current theme folder so it lives alongside index.php and all the other files. Once that’s done it’s time to crack open header.php in your theme folder and get to work.

To get the favicon to work add the following code right before the end head tag:

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

Assuming you placed the favicon.ico file in the root of your theme folder this will automatically add it as a favicon for all browsers, even really old ones. Note that if you already have a link with rel set to shortcut icon like this you’ll create a mess. You should only have one favicon link in your theme, but most WordPress themes including TwentyTen don’t have one so you should be fine.

Next, to make the site pinnable we’re going to add five meta tags directly underneath:

<meta name="application-name" content="Your Site Name" />
<meta name="msapplication-tooltip" content="Tooltip message" />
<meta name="msapplication-starturl" content="http://www.YourSite.com" />
<meta name="msapplication-window" content="width=600;height=600" />
<meta name="msapplication-navbutton-color" content="#colour" />

The above code is pretty self explanatory. Just swap out the content values with your own preference. The msapplication-window tag controls the size of the custom IE9 window that opens when you click the button.. The msapplication-navbutton-color tag controls the colour of the navigation buttons in the window as in the image above.

With the favicon code and these five meta tags included in your header your site will be pinnable. That really is all there is to it. But you can do a lot more!

Adding Jump Lists

If you look at the image to the right you’ll see there are two custom links in the jump list (right-click on the icon) for my pinned site under Tasks: Code of Ethics and Mor10 on Twitter. These are generated with an additional custom meta tag as below:

<meta name="msapplication-task" content="name=Link Name;action-uri=http://www.YourSite.com/YourLink.html;icon-uri=http://www.YourSite.com/custom.ico"/>

Again it’s pretty straight forward: You just insert your own content and links in the name, action-uri and icon-uri variables and you’re good to go. I placed all my custom icons in the images folder under my theme and used a dynamic link for them. For the Twitter link my meta tag looked like this:

<meta name="msapplication-task" content="name=Mor10 on Twitter;action-uri=http://www.twitter.com/mor10;icon-uri=<?php echo get_bloginfo('template_url') ?>/images/twitter.ico"/>

Adding dynamic Custom Jump Lists displaying the latest 5 WordPress posts

Adding static links is all well and good, but the Pinned Sites functionality also allows you to add custom Jump Lists. This is done through JavaScript. The basic function, which is still static, looks like this:

<script language="javascript">
	function AddJumpList()	{
		try	{
			if (window.external.msIsSiteMode())	{
				window.external.msSiteModeCreateJumplist("Custom Jumplist Title");
 
				window.external.msSiteModeAddJumpListItem("Title", "http://www.YourSite.com/link", "http://www.YourSite.com/custom.ico");
 
				window.external.msSiteModeShowJumplist();
			}
		}
		catch (error)
		{
		}
	}
	AddJumpList();
</script>

Unlike the meta tags before this is straight up JavaScript which means all browsers will try to run it even if they don’t support the function. For this reason I’ve added a conditional feature detection script that makes sure the browser supports msIsSiteMode before running it.

To add new items in the Custom Jump List you just copy and paste the window.external.msSiteModeAddJumpListItem() function and change the title, link and icon attributes.

But that’s just static lists. For this feature to be meaningful it needs to have dynamic lists that show the most recent posts from the site, right? For that we’re going to use some hard coded PHP and a custom WordPress loop to create the jump list items dynamically. That loop looks like this:

<?php
	$featuredPosts = new WP_Query();
	$featuredPosts->query("showposts=5");
 
	while ($featuredPosts->have_posts()) : $featuredPosts->the_post(); ?>
		window.external.msSiteModeAddJumpListItem("<?php the_title(); ?>", "<?php the_permalink() ?>", "http://www.YourSite.com/custom.ico");
 
<?php endwhile; ?>

As you can see it’s a simple WP_query that calls the 5 most recent posts and then uses the title and permalink attributes to populate the jumplist. Just to state the obvious: You can use any query you want to poll any content you want here. You don’t have to stick with my boring loop.

With this custom loop inserted the full Dynamic Custom Jump List function looks like this:

<script language="javascript">
	function AddJumpList()	{
		try	{
			if (window.external.msIsSiteMode())	{
				window.external.msSiteModeCreateJumplist("New Posts");
 
				<?php
					$featuredPosts = new WP_Query();
					$featuredPosts->query("showposts=5");
 
					while ($featuredPosts->have_posts()) : $featuredPosts->the_post(); ?>
						window.external.msSiteModeAddJumpListItem("<?php the_title(); ?>", "<?php the_permalink() ?>", "<?php echo get_bloginfo('template_url') ?>/images/news.ico");
 
					<?php endwhile; ?>
 
				window.external.msSiteModeShowJumplist();
			}
		}
		catch (error)
		{
		}
	}
 
	AddJumpList();
</script>

Assuming you have an icon named news.ico in the images folder under your current theme this code produces a dynamic custom jump list displaying the titles of your five most recent posts, each with an icon, that points directly to that post.

Cool? I think so. Now pin my site and add the functionality to your own!

Last night (March 16th) Twitter and WordPress forums exploded with people receiving error messages when trying to access their WordPress stats through the WordPress.com stats plugin. This happened to me too: When trying to access my stats I got this nice uninformative error message:

Your WordPress.com account, xxxxx is not authorized to view the stats of this blog.

I did a little digging and found out that the WordPress.com Stats plugin has been replaced by the Jetpack plugin (or rather, the WordPress.com Stats functionality has been baked into the Jetpack plugin) and a simple way of getting the stats up and running again was to simply install the plugin, activate it and link it up to my WordPress.com account.

WordPress.com goodies come to self-hosted WordPress.org sites

Before I start ranting let me just say that the new Jetpack plugin is what I would consider a must-have for self-hosted WordPress sites. Not only does it have the WordPress.com Stats built in but it also comes with a whole menagerie of other features that come standard with WordPress.com sites but previously had to be installed separately in self-hosted sites. These are:

• WordPress.com Stats
• Twitter Widget
• Gravatar Hovercards
• WP.me Shortlinks
• Sharedaddy
• LaTeX
• After the Deadline
• Shortcode Embeds

Some of these features including Stats and Sharedaddy are plugins I’ve already recommended, and the others are pretty useful too (especially After the Deadline which is an integrated spell- and grammar check tool). To learn more about the features and what they do go to Jetpack.me and check them out.

The great thing about the Jetpack plugin is that it consolidates a bunch of features that previously required separate plugins and installs to work. And judging by the open “Coming Soon” boxes at the bottom of the plugin page I’m guessing more stuff will be added shortly. The Jetpack plugin runs off cloud services which means some of the functionality lives in the cloud and not on your computer, in other words the plugin can be updated externally to add more functionality to your site without you having to run the manual update. Which is great. Well, sort of at least.

Cloud computing is what we are moving towards, and for integrated services like WordPress.com Stats it makes a lot of sense. The question here is what the underlying reasoning is and where this will take us. That’s where my rant comes in.

How about a little warning, eh?

There are two things that irk me about this whole situation: First off, no warning or information was issued about the disabling of WordPress.com Stats which lead to (and is still leading to) a lot of panicked posts and confused people. This could easily habe been remedied with a simple post or warning saying “Oh, btw we are disabling WordPress.com Stats and supplanting it for the Jetpack plugin so if you want your stats you have to install it” and they have done this, at least in part, by adding a “We’re working on it” message to the error displayed in the old Stats window. But it still leaves me wondering what actually happened here. Well, not actually wondering. More like speculating.

You see, I think this is actually part of a larger plan (WARNING: The following is pure speculation on my part and may very well be complete rubbish):

Logging into your WordPress.com account right now you’ll notice your API key doesn’t exist any more. The only API key available is the one you can purchase from Akismet. Yes, I said purchase. If you’ve been running Akismet on your WordPress site for a long time you may not know this but as of some time early last year Akismet went from being a free service to being a paid service. However, for those who had activated the plugin before the switch using the general WordPress.com API key Akismet still worked for free. And and even after the change you could circumvent the payment option by using your WordPress.com Stats API key as your Akismet API key and still get the same services for free. I think you see where I’m going with this.

From what I can tell the WordPress.com Stats plugin stopped working because the WordPress.com API key was disabled. I’m venturing a guess that this was done to force people to finally buy a proper Akismet key. Unfortunately WordPress.com Stats was an unexpected victim, which is why we haven’t heard any official word on what’s going on here yet.

Like I said before, this is all speculation on my part and I hope we hear some official explanation sooner rather than later, but at least it makes all the pieces fit. I have no problem with WordPress.com Stats being replaced with Jetpack nor do I have a problem with Akismet being a paid service (though I think it’s way too expensive), but the way this has unfolded is not very open nor transparent and needs some polishing. You can’t just kille a hugely popular plugin without telling people first.

My second issue with the move is that not everyone wants everything in the Jetpack. A lot of people like to keep everything separated and firewalled. I’m guessing that Automattic wants to move towards more integrated solutions like Jetpack to serve up lots of functionality in small packages. Which is great as long as it doesn’t push away the individual pieces. Right now, unless something is changed and WordPress.com Stats goes live again, you have to install Jetpack to get your stats, and that means you’ll now have multiple pluings running the same function if you have any of the other things like Sharedaddy installed. It’s a hassle because you’ll have to disable these doubles. Granted Jetpack picks up the settings from the old plugin, but it’s still not as clean as it should be.

Let us in on what’s going on!

The bottom line here is pretty clear: To Automattic, let us know what’s going on. If you want us to ditch WordPress.com Stats for Jetpack, just tell us. If WordPress.com Stats is coming back online, tell us that. And please explain what happened in the interim. Also, if you are disabling WordPress.com stats (and other plugins?) to be replaced by Jetpack, put a nice big warning in the plugin pages for those plugins so people know what’s going on and don’t start posting panicked messages in the forum. Transparency is key.

“Published X Days Ago”

The first function I’ll feature is a small script that spits out a text telling the viewer how long ago a post was posted. I actually needed this script for a countdown so mine is a fair bit longer, but it can be used to create a Twitter-like time stamp just as easily.

To achieve this we’ll be using two functions, date() and get_the_time(). The former is a bona fide PHP function that grabs the current local time from the server while the latter is a WordPress function that grabs the time of publishing for the post.

It doesn’t take a genius to figure out how we’re going to use these two: Taking the current time and subtracting the published time will give you the time difference, in other words how long ago the post was published. The challenge is that you need to get the right time formats to actually output a rational result.

Getting the right kind of time

You’d think that if you want to count how many days ago a post was posted you could just grab the dates and count backwards. But that’s actually pretty hard because it relies on the counting mechanism knowing what day of the month it is and how many days each month has etc etc. A better solution is to grab a unified time value that doesn’t change in the same arbitrary way. Luckily programmers found this problem and its solution a long long time ago. It is called the the Unix Epoch and is the time, in seconds, since January 1, 1970 00:00:00 GMT). To get this value for each of our functions we simply add in the format string “U” like this:

date('U'); // outputs the current date and time in Unix Epoch terms
get_the_time('U'); // outputs the publishing date and time in Unix Epoch terms

Making the time make sense

Problem is this produces a weird long number like 6250458. This is the number of seconds since the article was published. We want the number of days, so we need to do some math.

If you have seconds and you want to make days you first have to divide them by 60 to make minutes, then divide it by 60 again to make hours and then finally divide it by 24 to make days. For 86399 out of every 86400 seconds of the day this will produce an integer (number with a comma) but we want whole numbers. So we utilize an extra function called round() that rounds out the number for us.

Putting it together

With that we have all the components we need to get the number of days since published. In PHP form the function looks like this:

<?php 
	$days = round((date('U') - get_the_time('U')) / (60*60*24)); 
	echo "Published " . $days . " days ago";
?>

This will output the number of days since published sandwhiched between the words “Published” and “days ago”. But what about the first day, when the number is zero, or the second day when the number is one? “Published 0 days ago” and “Publised 1 days ago” looks kind of sloppy, no? Well, it’s easy to fix with some conditional statements:

<?php 
	$days = round((date('U') - get_the_time('U')) / (60*60*24));
	if ($days==0) {
		echo "Published today"; 
	}
	elseif ($days==1) {
		echo "Published yesterday"; 
	}
	else {
		echo "Published" . $days . " days ago";
	} 
?>

All these conditional statements do is ask “if the number of days is 0, say “Published today”, if the nuber is 1, say “Published yesterda” and for all other cases say “Published X days ago”.

Copy this piece of code anywhere in your theme files within the WordPress Loop and it’ll spit out a published x days ago timestamp on your posts.

Easy as Pi.

Why a WordCamp for Developers?

Vanessa and I have been running the Vancouver WordPress Meetup for the last 9 months and the overwhelming response we’ve gotten is that people want to learn more about web development with WordPress as a platform. They also want to know more about related technologies, future developments and things like user experience design and information architecture.

So far the only WordPress focussed conferences have been regular WordCamps. But although these conferences are great for bloggers and people who work with WordPress, their focus tends to be more on blogging and basic publishing and less on hard core development and other related topics. Because WordPress has grown from a solid blogging platform to a full fledged CMS we felt it’s time we put on a conference focusing on the people who use WordPress to build stunning, functional and ground breaking websites. Thus WordCamp:Developers was created.

What Can I Expect From WordCamp:Developers?

Like I said the focus of WordCamp:Developers will be on topics that are relevant to people who work with WordPress as a development platform every day. Right now we are scouring the continent looking for the best and brightest speakers with expertise in advanced WordPress development, Information Architecture, user experience design, security, eCommerce and so on. Based on feedback and trends in the community we are also looking for speakers to focus on new technologies like HTML5 and CSS3 as well as integrated technologies like JavaScript and AJAX.

The goal of WordCamp:Developers is to provide a platform for the advancement of WordPress as a serious Content Management System and start a discussion about how we, as web developers, can use WordPress to make the web a better, more functional and more attractive space for everyone.

If you are an expert in any of the fields listed above or anything else related or relevant to WordPress development or if you know someone who is, go fill out the speaker submission form or get in touch with us through the website ASAP.

The deadline for speaker submissions is February 28th so get crackin!

Tickets, Venue and Volunteers

We are in the process of rolling out ticket sales for WordCamp:Developers. We were going to release tickets this week but some very generous sponsors have just come onboard and with their contributions we are able to push down the prices and make the event more accessible so we need to crunch the numbers again to ensure we give all our attendees the most bang for their bucks.

We are releasing a total of 200 attendee tickets for the event. Our 12 main speakers will be added on top of that number, and if you buy a ticket and then get selected as a speaker we will put your ticket back in the general pool for someone else to pick up.

WordCamp:Developers will be held at the SFU Harbour Centre in downtown Vancouver. The event will feature two main tracks, UX (Focus on Designers) and DEV (Focus on Developers) as well as an ad-hoc (un-conference) room where attendees can pitch 20 minute talks on the day of the event. We are booking a total of 12 speakers, 6 for each of the main rooms, and ensuring that each talk will be on its own topic so attendees get the most out of the event.

As part of admission all attendees will be served a great lunch in a room overlooking the harbour and we’ll have coffee, snacks and other goodies throughout the day.

This event, like all WordCamps, is a not-for-profit volunteer based innitiative and we are looking for volunteers to help both for organization and day-of management. If you’re interested in playing a part in WordCamp:Developers get in touch with us through the website.

Sponsorships and Swag

As I mentioned earlier this event could not have happened without the generous support of our sponsors. We already have a couple of big companies on board (TBA) but we are still looking for more sponsors to make this event as great as it can be. On that note I have to mention the Microsoft Canada team that is putting on the open source conference Make Web Not War and Vancouver Open Source Week. I spoke at Make Web Not War in Montreal last year and I can honestly say it is one of, if not the best conference I’ve been to. And the Vancouver edition, slated for May 6th and 7th, proves to be even better!

If you or your company is interested in being a partner please check out our sponsorship page for all the details.

Based on feedback from other events we are trying to make WordCamp:Developers as green as possible. As part of that we are being very counscious about what kind of swag we will be handing out to attendees, speakers and volunteers. To that end the focus of all our swag will be on usability. As in we will only hand out things our attendees can use and have a use for. That means if you or your company have a product, virtual or physical, that you feel would be of use to web developers, we want to talk to you. Get in touch with us through the website and we’ll get the conversation started.

Consider This Your Personal Invitation

WordCamp:Developers is a WordPress conference for developers, by developers and we put it together because we know developers like us want a place where they can talk shop. Consider this your personal invite to the conference, to attend, to speak, to sponsor, to volunteer. WordPress is an open source platform that is changing the world and we want everyone to be part of the revolution. So mark your calendars, get the word out and let’s make WordCamp:Developers and Open Source Week amazing!

Replace Site Title with a Linked Image

This is my number one pet peeve. When people visit a site they intuitively expect the logo or header image to be a link back to the home page, and it should be. When it’s not they (and I) get annoyed. Making your header image link back to your home page is not hard. All you have to do is wrap the header image code in a simple anchor tag that leads back to your root URL and you’re good to go. For simplicity the code looks like this:

<a title="&lt;?php get_bloginfo( 'name' ); ?&gt;" rel="home" href="&lt;?php echo home_url( '/' ); ?&gt;">
 
… the image code …
 
</a>

For a more in-depth explanation check out the tutorial Twentyten Header Image as Home Button.

Enable WordPress 3 Custom Menus

The WordPress 3 custom menu function is built into the TwentyTen theme and most newer themes, but older themes usually just have hard-coded menus. Adding WP 3 custom menus to a theme is not hard though. It requires a function call in the functions.php file and a template tag in the template file of your choice (usually header.php and/or footer.php). Here’s that code:

In functions.php:

register_nav_menus(
        array(
                'menuName' =>__('Menu Name'),
                ' primary' =>__('Primary Menu'),
                '2ndMenu' =>__('2nd Menu'),
        )
);

Where menuName is the identifying slug for WordPress and Menu Name is the actual displayed name in WordPress Admin.

To display a menu you can either call it based on the slug:

<?php 
        wp_nav_menu(array(
                'theme_location' => 'primary'
        )); 
?>

… or the name defined in the Menus admin area:

<?php 
        wp_nav_menu(array(
                 'name' => 'Menu Name'
        )); 
?>

Menus Outside the Box

Menus don’t have to be regular boring one or two word one-line elements. Because WordPress allows HTML in the Navigation Label you can add more interesting designs like we did on the 12×12 Vancouver Photo Marathon site. On this site we added a simple span tag around the text that displays under the menu heading and then used CSS to change how it displays. Sorry, no code examples – it’s just straight up CSS and out of context it makes no sense.

WordPress 3 Custom Background Images and Colours

The TwentyTen theme introduced a very cool custom background function built right into the admin interface (under Appearance -> Background). This is not a function found in TwentyTen but a core function found in WordPress. That means you can activate it in any theme. All you have to do is call it from the functions.php file:

add_custom_background();

The function injects CSS style code right into the HTML pages which means it’ll override your theme CSS file no matter what. That in turn is why it’ll work on any theme as long as you run WordPress 3.0 or higher.

Adding Featured Image (post-thumbnail) Functionality

Featured images are great, if you know how to use them. They also do way more than just displaying thumbnails (which is why I think the function should be renamed). To activate the function add the following code to your functions.php file:

add_theme_support( 'post-thumbnails' );

This will add the function to you Admin panel. To display the featured image (in the size you want) in your theme use one of the following functions:

<?php the_post_thumbnail(); ?>

Variations:

<?php the_post_thumbnail('thumbnail'); ?>
<?php the_post_thumbnail('medium'); ?>
<?php the_post_thumbnail('large'); ?>
<?php the_post_thumbnail(array(nnn,nnn)); ?>

Custom Page Templates

Custom page templates allow you to individualize the look of different pages on your site. They can be used to create custom front pages, differentiated legal pages or even custom query pages that pull in posts from multiple categories.

A custom page template is basically a regular page template with a commented out tag at the very top that looks like this:

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

Custom Category Templates

Custom category templates can be used to create differentiated category index sections in a site. Some good examples are the Reeltime Videoworks show reel page and testimonials page and Design Schooled Kids’ press page.

A custom category template can be made in one of two ways. Either create a file with the name category-ID.php where ID is the ID number of the category or category-slug.php where slug is the slug for the category. These files will automatically become the category tempaltes for the defined categories.

Custom Header, Sidebar and Footer

You can also create custom headers, sidebars and footers sort of the same way. You make and call them the same way. For example if you want a custom header you create a new header file called header-custom.php and then call it using the standard get_header() function with a small difference:

<?php get_header('custom'); ?>

where ‘custom’ can be anything.

Better Context Links

One of the things that bug me about standard WordPress themes is that they display links to the next and previous posts in the single post view. These links don’t really provide a lot of value. Instead you should be displaying the two latest posts from the current category. So I made a small theme add-in you can dump into your theme for some better context. The add-in adds links to the two latest posts in the current category including the title, publishing date and short description. To install it download the related.php file here (right-click and choose “Save As” – it’s a straight up php file), add it to your theme directory and call it using the following code in your single.php file:

<?php get_template_part('related'); ?>

That’s all you have to do.