I've been playing around with Amazon S3 (an ever-expanding hard-drive in the sky that expands as you need it), and CloudFront (a system for distributing the content you store in S3, over the Web). It's worked well, but this morning I came across a limitation that's worth detailing for any other techies embarking on a similar project. This won't be über-technical, so if you're at all interested in cloud hosting but don't know all the ins and outs, no problem.

If you have a website or application that has a lot of images, JavaScript and CSS, you might find that the more you add, the slower your site is to load. That's because most web servers will only serve two or three files at a time, from the same domain. So if your HTML, CSS, images and scripts are all served from the same domain, your visitors' web servers can end up having to cue up several requests. Serving static content from another domain can help, especially if you're hosting those static files in the Cloud.

Twitter uses Amazon's storage for its avatar images, so that their servers don't have to get bogged down in the repetitive task of serving the same images many, many times over. So I thought I'd give it a go on my own site - 'cos if it breaks, no-one's really going to be too upset - so I could bring some of the knowledge back here. And so far it's worked pretty well.

In S3 you create "buckets" (folders at the root of your S3 account) that hold your content. I told my web server to work with one of those buckets as if it were a normal folder on that computer, so when I upload files through Django - or WordPress, or Drupal, or anything like that - the server actually sends them over to Amazon to serve them. It takes a bit longer to upload, but the benefits are greater in the longrun.

This works great for images, CSS and JavaScript, but not, it seems for web fonts.

Over the last 18 months or so we at Substrakt have played with a variety of ways to provide more than the usual set of available fonts (Arial/Helvetica, Times New Roman, Courier, and all the rest). sIFR, Cufón, and latterly - and most effectively - @font-face. Rather than a product, as such, this is a way of using legal, open fonts in a variety of formats for a variety of browsers. It's great, because even the oldest of browsers supports it, and it doesn't alter the page by adding SVG glyphs or inline Flash content. It's embeddable via CSS, and completely brilliant.

The problem, however, is that since Firefox 3.5, Mozilla have stopped allowing certain requests to be passed between domains. Flash has a similar system (using a crossdomain.xml file), and it wouldn't normally be a problem as the system that Firefox wants (a piece of information sent before the font arrives) can be provided by any web server.

However, Amazon CloudFront isn't a standard web server, and so doesn't allow the setting of HTTP headers that Firefox is looking for. And more unfortunately, Amazon aren't that fussed about adding it. This means that serving fonts via their service is currently not available. A real shame, and something I've started to nag Amazon about.

If you're looking to serve images, CSS and JavaScript via the Cloud to remove some of the heavy lifting from your server, I'd definitely recommend S3 and CloudFront. But if you're looking to move towards using the @font-face technique of embedding fonts, and you also want to serve those fonts via the Cloud, for the time being, you'll need to find another provider.

The latest incarnation of WordPress is out, bringing some cool features from WordPress.com that have existed for a while, over to self-hosted users.

We'll be upgrading our clients' websites very soon, but as this is not a security release, some of the urgency is lost. We're really excited about our clients getting their hands on some of the great new features, like internal linking (which makes linking to content within the site easier, as you can search for it and don't need to remember the address you want to link to), an admin bar which gives simple two-click access to the New Post page from anywhere within the frontend site, and big improvements to the CMS-like features which were introduced in earlier 3.x releases.

If you've got questions or concerns about this latest release of WordPress, please get in touch.

If you have to move a large site witha number of hierarchical categories from one WordPress installation to another, you may come across a problem we at Substrakt have faced quite a few times.

WordPress deals with hierarchical taxonomies like categories in a strange way. It not only stores the categories in the relevant taxonomy tables, along with parent IDs, it also stores an array of those parent-child relationships in the wp_options table.

The upshot of this is that, if you import a blog and you find that not all of the categories you've imported are appearing, fear not, chances are they've imported just fine, it's just that the category_children option within wp_options hasn't been updated.

When you setup a new site, you'll probably find the value of this option is something like “a:0:{}”. Problem with that is that WordPress recognises that it's an array of options, so doesn't bother to correct it. If however, you clear that value out of your database - using something like phpMyAdmin or the below SQL statement - you should find the next time you get a list of categories, the hierarchy will be displayed correct.

UPDATE wp_options SET option_value = '' WHERE option_name = 'category_children';

This happens because WordPress first checks to see if that value is an array. If it is, as I've mentioned, it'll take the value as read. If not - ie: if the value of that option is blank - it will rebuild the tree and resave the value. The next time you look at that value in your database, you should find something a bit more verbose.

Hope that helps. And if you're having any WordPress issues at all, get in touch with us and we'll see if we can help.

Jobs board for the West Midlands, Jobplot is the latest site to be hosted on Dolphy, the CMS that's been my labour of love since January. I took some inspiration from WordPress, but have tried to reflect the methodology of the Django framework - which the CMS is built on - rather than simply ape WordPress' workflow.

Unlike WordPress MU and 3, which host multiple sites under the same web server "space", with a few tweaks to server configurations, each Dolphy site - which is hosted alongside its sister sites and using the same database - occupies its own space in memory, which means if one falls over, it doesn't take everything else on the "network" with it.

But while that's been a core feature of the system almost from day one, what's newly added is the ability to upload fonts in various formats, and for them to be readily available to the site (so a developer only needs to reference them in CSS), a much tidier and easier-to-use admin interface with handy dropdown menus, more flexibility for extension developers, and the beginnings of a (small) ecommerce system.

I'm also working, when I get the time, on a way of leveraging WordPress' great enqueuing system, which means pages only reference bits of JavaScript and CSS when they're used, so the browser only downloads what it needs, when it needs it. Although the system can now "minify" (combine and compress) JavaScript and CSS and "lazy load" it (so that it loads once the important stuff, like the page content has loaded), it's been a bit rocky, and doesn't work well when developers need to make constant tweaks to frontend elements.

I've learned bags of stuff since I started building Dolphy, and am still learning now. And with Birmingham's biggest brain in programming (in the diminuitive form of [twitterer "chrisivens" "Chris Ivens"]) sat oppsite me, I'm picking up new skills to help improve, not only the CMS, but other projects written in Python, PHP and beyond.

The system's still young, and although it hosts a few of my own sites, it's still got its share of teething troubles, but as each new project comes along, we add more to the system and learn a whole boatload of new skills in the process.

But regardless of having a burgeoning but already robust CMS, there's still no substitute for using WordPress for quick builds, or when it absolutely fits the bill (as it so often does). But with Django, Drupal (on which Chris is an expert) and WordPress at our disposal, we've absolutely got the ability to pick the right tool for the right job.

Here endeth the gushing.

With the addition of custom post types, WordPress 3 can finally hold its own against its rivals in the CMS market. I've previously used custom fields a whole lot during projects to separate content and allow clients to manage this content a bit better, but thanks to custom post types we are now able to make adding content to a site a really simple process and the client no longer has to worry about which custom field they should be editing.

While I wouldn't say custom post types are an ideal way of labelling blog posts (this is what categories and taxonomies are for) they are ideal for giving you much more control over what content you can edit in a post.

Set up custom post types ¶

Setting up the custom post type couldnt have been easier. Crack open the functions.php file in your WordPress theme and add the following code:

add_action('init', 'work');
function work() {
	$args = array(
		'label' => __('Work'),
		'singular_label' => __('Work'),
		'public' => true,
		'show_ui' => true,
		'menu_position' => 5,
		'capability_type' => 'post',
		'hierarchical' => false,
		'rewrite' => true,
		'supports' => array('title', 'editor', 'thumbnail', 'page-attributes', 'excerpt')
	);
	register_post_type( 'work' , $args );
}

This is a pretty bloated example of adding a custom post type but there still isn't too much to take in. We have added the post type named "Work" and an array of arguments. There are lots of arguments added in this example but you can set up your custom post type with as many or as few as you like (view the full list of arguments at the WordPress Codex)

At this point you have just created your new custom post type as you can see below. This is its most basic form allowing you to create posts with a title field and a content area.

Display your single posts ¶

Next you will want to display the singular view of your custom post type on your website. The best way to do this is to create a new template in your theme. WordPress will usually use single.php to display your posts as default. To add a custom template in its most simple form, duplicate single.php and rename it with the name of your custom post type after the word single. For example, in my theme the custom post type is called work, so the name of the template is single-work.php. You can create a different template for every custom post type you create.

Its just as easy to list these posts in any of your templates using a custom query such as in this basic example below:

<?php
query_posts("post_type=work");
while (have_posts()) : the_post(); ?>
    <a href="<?php the_permalink () ;?>"><?php the_title(); ?></a>
    <div><?php the_excerpt(); ?></div>
<?php endwhile; ?>

Expand upon the custom post types ¶

The name says it all really, CUSTOM post types. So surely you will want them to be customised and different to standard posts. This is where we can get creative and really polish the user experience.

In the example below I created several text fields and text areas in the Work custom post type. I wanted to allow to client to easily add job titles, client names, a box which would display client feedback and a section where they could embed Vimeo videos without having to fiddle about with custom fields.

To add a new text field into the backend of your custom post type modify the following code to suit your needs:

<?php
add_action("admin_init", "admin_init");
add_action('save_post', 'save_custom');

function admin_init(){
    add_meta_box("workInfo-meta", "Thumbnail", "meta_options", "work", "side", "low");
}

/* Thumbnail Field */

function meta_options() {
    global $post;
    $custom = get_post_custom($post->ID);
    $thumb = $custom["skt_thumb"][0]; ?>
    <input name="thumb" value="<?php echo $thumb; ?>" /> <?php
}

function save_custom() {
    global $post;
    update_post_meta($post->ID, "skt_thumb", $_POST["thumb"]);
}
?>

In the above example we have added a meta box into the admin area with a title of Thumbnail, positioned in the right hand side of the page in the backend. This custom field has a key of skt_thumb. For a full description of all of the parameters used in this string take a look at the WordPress Codex page

Using a standard get_meta_post we can call the data from theses custom fields into our template and display them beautifully!

There really is so much more to custom post types than what I have sketchily described here. They have opened up a whole new way of handling content in posts and hopefully you will play around with them and find loads of interesting ways to make WordPress work better for you and your clients. At Substrakt we're loving them and looking forward to putting them into practice in our new projects.

In the move to WordPress 3, I've discovered an interesting, hitherto unknown "feature" which, if you're building AJAX functionality into your themes or plugins, may cause a headache or two. It's an easy fix, once you're aware of the issue.

It seems any .php file which you refer to directly (like, say, ajax.php or dynamicscript.js.php) rather than using any URL rewriting (where URLs are routed through index.php) is given a 404 header, while the rest of the content stays in tact.

What this means is that, even though you can view the files in your web browser without issue, any AJAX calls will fail because the XML parser assumes the file doesn't exist. This is also the case if you include a <script> tag whose src attribute is set to a dynamically-generated file. You can view the file in your browser, but it will be ignored when referenced on a page.

The fix is simple, but varies depending on whether you're using AJAX or including a dynamic file via <script> or <link> tags. If using AJAX, you may be including the PHP script using <?php include... ?> or <?php require... ?> when the page first renders, then replacing the contents with something new when a button or link is clicked. Let's say you have a calendar widget which loads a list of events. You click the calendar, and the list magically updates showing the new list of events for that date, without the page refreshing. There, the list is included through <?php require... ?> and then replaced when the jQuery AJAX request returns a response.

In that instance, you have to tell the difference between the first time the script is rendered, and the second time, when it's called via AJAX.  You'll have your own way of doing that no doubt (a simple way is to include an extra querystring parameter, like "?ajax=1"), so what you'll need to do is include the following, only for AJAX responses (not the first time the page is rendered):

<?php header('HTTP/1.0 200 OK'); ?>

This has the effect of overriding WordPress' decision, forcing PHP to return a 200 header, which is understood by the browser as being the response "yes, this file does exist". (Thanks to Chris for working out the exact formulation of this statement.)

You can do exactly the same for dynamically generated JavaScript or CSS, without worrying about whether you're rendering for the first time, or partially via AJAX.

I've not found any documentation to support an explanation of this new behaviour, but as far as I can tell it's peculiar only to WordPress 3.x.

Hi. This is my first post here as a new employee of Substrakt so you're entirely forgiven if you have no idea who I am. I better introduce myself I guess.

I'm Chris, I'm a web developer and although I'm trying to shake the label of 'geek' it pretty much sums up what I do. Not an easy thing considering the remainder of this post.

For those of you not interested in codey stuff I'll see you in my next post. For the few still reading, I'll be talking about WordPress clean urls.

I've been having a bit of a headache with WordPress this week as it kept killing a server. I think I have finally cracked it but even if this isn't the root cause, it's something that really needs to be addressed.

It boils down to the structure of the urls for the posts. The standard 'clean' url that is used is something like this: http://www.example.com/2010/08/06/some-post-name which is fine for blogs and other date based posts.

Unfortunately not all sites built with WordPress are designed to be blogs. Some are general corporate sites, some are ecommerce led. These and many more WordPress based sites would do well to have a url similar to this: http://www.example.com/some-post-name

This has some serious repercussions on speed though. I'm testing this on a site with 590 posts in the wp_posts table. Only 143 of these are published posts. The rest are drafts.

I split the serialised version of the rewrite rules by semi-colons to get a measure of how big it is in human terms. The first url version with all the dates in works out at about 144 lines of data. The second version which is simpler for a person to write but harder to check for takes up about 2270 lines.

That's a lot more data to parse and hold in memory. I'm working on an elegant solution to this problem but right now and for the sake of the server, it's date based urls all the way.

Apologies to our client for not spotting this sooner but hopefully this post will help someone else with a similar problem quicker than it took me to find the culprit.

If you run a WordPress MU "network" (or even a single site on the MU platform) and you're thinking of upgrading, here's a few things to bear in mind.

There is no "WordPress MU 3.0". Since 3.0, WordPress and its MU branch are one and the same, so if you're not automatically upgrading, just download the latest version of WordPress and replace everything in your old site with these new files, except for the /wp-content directory.

Delete /wp-content/blogs.php. This file is no longer needed, so you can get rid of it (you'll see a warning in the admin area until the file is removed).

Update your .htaccess file. There isn't a lot of documentation about this, but when you delete the /wp-content/blogs.php file, any media you've uploaded to your specific sites using the WordPress media uploader, won't work, because the URL rewriting rules stored in .htaccess are now out-of-date. Replace the content of your .htaccess file with the following:

# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

# END WordPress

Code courtesy of a WordPress forum post.

Remember this is just a guide, and if you're not familiar with setting up and working with the innards of WordPress sites, get a developer in or ask us to give you a hand.

Here's a simple plugin produced in record time, and implementing our best practices, which prevents users from registering for an account on a WordPress site without first accepting a set of Terms and Conditions, which can be defined on a standard WordPress page.

This easy-to-implement plugin adds a tickbox to the registration form. If that box is not ticked, the registration won't go ahead. And the great news is, it works with plugins like Customize your Community, which can completely reformat the standard registration form.

It's in its absolute infancy, so please take note of the notice at the bottom. If you like it, find it useful or have any suggestions on how we can improve it, drop us a comment.

Download the plugin

This source code is provided "as is", with no warranties, and confers no rights.

We like to keep our code neat. Who doesn't? But when building WordPress plugins it can be easy to fall into negative patterns which lead to hard-to-read, or even buggy code. For instance, if two plugins call a function called "get_user_info" for example, a conflict will occur.

So we're working on a set of best pracitces for developing our plugins. This means applying Object Oriented Programming principles - which aren't fully integrated into PHP and WordPress, but are usable to an extent - to build structured, sensible code that deals in "objects".

So we start by putting the main bulk of our code in a class, say PluginClass, and hooking into WordPress' functionality with code like this:

class PluginClass {
	public function __construct() {
		add_action('admin_menu', array(&$this, 'admin_menu'));
	}
	
	public function admin_menu() {
		// Our function for adding to the WordPress dashboard menu
	}
}

Because we've enclosed our admin_menu function in a class, it doesn't matter if another plugin uses the same function name.

We further separate user-interface elements like settings pages from the code. This is quite alien in WordPress, which often advocates putting chunks of PHP code in HTML templates. By keeping fragments of pages in another folder and referring to them in our PluginClass object, we can structure our code to make it much more readable and adaptable.

There's lots more we're doing, and this set of practices is growing with each new plugin we develop, but this will give you a brief of what we're aiming at. If you want to know any more or you've got a better idea, drop us a comment!