Featured Stories

New Responsive WooCommerce theme Sooperstore released

Ok it's pretty embarrassing how long it's been since I posted a blog update here. My last update was early July saying that a new theme was on the way "within a week" if I recall correctly. Well fast forward a week or 8 and I'm happy to announce that Sooperstore has finally been released! We actually released another theme in...

Continue Reading

5 Stunning Responsive WordPress themes

While responsive web design is a relatively new phenomenon, the WordPress theme development ecosystem has exploded with a plethora of stunning responsive WordPress themes over the past few months. It's one of the things that I really love about the WordPress community - the speed at which theme developers themselves are so responsive :)...

Continue Reading

High Performance WordPress – Part 4

Alrighty folks, if you’ve been following along with the High Performance WordPress post series you will by now have experienced the awesomeness of a WordPress website running on nginx. If you’ve not been following along what are you waiting for? Go check out the following posts first: Part 1 - VPS Setup Part 2 -...

Continue Reading

High Performance WordPress Part 3

Hey folks I’m back with Part Three of the High Performance WordPress guide. If you’ve not done so already, be sure to check out Parts One and Part Two which will take you from a position of having no server to a fully configured VPS machine running the kickass nginx web server and mysql - or a LEMP environment as those in...

Continue Reading

Well Hello There!

Hey there thanks for stopping by! ThemesForge is all about WordPress Themes. We don’t make ’em - but we pretty much live ’em, breath ’em, review ’em, rant about ’em and hope to keep you the you the discerning reader fully up to date about what is going on in the WordPress themes ecosystem.

Latest ThemesForge News

Should Custom Post Types live outside of themes?

23 August 2011 comment icon2 | Categories: featured, opinion

Wow it’s nearly a month since my last post! My head is still buried in pixel pushing for some new WordPress themes I’m working on – one of which I hope to publicly release in September – more on that in the coming weeks. One thing that has struck me in a big way over the past few weeks of WordPress development is some of the inherent constraints of Custom Post Types. It is perhaps best explained with a very real example scenario that I’m sure happens all the time.

Take your typical WordPress theme consumer Bob and his wonderful Acme Theme 2010. NOTE: The actors and themes real names have been changed in this post to protect their anonymity 🙂

  • Bob has been happily using Acme Theme 2010 for the past year. Bob fell in love with Acme Theme’s wonderful Portfolio custom post type which allowed Bob to showcase his excellent photography portfolio. Bob has added a lot of custom post types over the past year. Hundreds in fact.
  • Now Bob is not necessarily that tech savvy. Sure he was able to figure out how to buy and install a commercial WordPress theme. It was pretty straightforward actually – WordPress theme installer FTW!
  • The Portfolio Custom Posts section immediately showed up after Bob installed Acme Theme 2010 and worked straight away. Bob was a very happy bunny.
  • Fast forward 12 months and Bob thinks Acme Theme 2010 is looking a bit stale. That grungy dark theme hasn’t aged well in 2011 and Bob thinks it’s time for a change.
  • Bob finds himself a pretty cool brand new FooCorp Reloaded 2011 style theme and thinks it’s wonderful. Sure Acme Theme 2010 has a pretty sweet portfolio feature but FooCorp Reloaded has all these nifty sliders and something called a Ken Burns effect that means Bob drops his 35 bucks for FooCorp Reloaded on the spot and heads on over to WordPress.
  • Bob can just about remember the theme install process and goes ahead and installs and activates FooCorp Reloaded 2011. Bob quickly checks the frontend and with a couple of new widgets and sliders setup everything is looking sweet. Bob heads back into WordPress and clicks on the Portfolio feature.
  • It’s empty.
  • Bob refreshes the screen. Still empty….Something is wrong.
  • Bob is now close to mild cardiac arrest. Has he just somehow lost over a years work! Ouch!!
  • Bob is now about to kick off a series of support requests with FooCorp and just about anyone he knows who knows anything about what the frick might have just happened his Portfolio collection.
Of course Bob will eventually figure out that his Portfolio is not gone. It’s just taking a break – along with Acme Theme 2010. And therein lies the problem folks. Right now, theme developers everywhere are flocking to develop some wonderful custom post type implementations that really significantly enhance the value of WordPress themes. And this should be broadly welcomed. But I think we’re on the cusp of a big problem. It won’t be long before we have lots of Bob’s hitting the exact same problem as the one described above. While I understand the value of having Custom Post Types tied into the mechanics of WordPress themes, I think there has to be a better way of doing this. Who else but Justin Tadlock should offer us perhaps the best way forward! Justin wrote a great post back in February ’11 describing the process of creating a custom functions plugin – and this to me sounds like the most sensible route forward for theme developers to prevent a problem before it starts. While this solution would have solved Bob’s problem – it does potentially make theme installation that bit more complicated for end users with only the very basic of WordPress skills. Maybe there should be a way of automatically registering a functions plugin as part of theme installation process (which could then be optionally uninstalled as part of the theme deactivation process). I’m interested what you folks think on this one and any other novel approaches people take to stop this being a problem.
As WordPress more and more becomes a serious CMS platform, data independence from look and feel is going to be become a necessity.

How do you build WordPress themes?

29 July 2011 comment icon0 | Categories: featured, opinion

I’m knee deep building some new WordPress themes at the moment but am coming up for some air to throw out a question to all you WordPress theme building pros – How do YOU approach building WordPress themes?

When I first started building websites Geocities was the platform of choice for anyone who wanted a hosted platform for managing their website if they didn’t have a shared hosting account. If I remember correctly, most shared host accounts also offered about 20MB of disk space and writing a contact form in PHP3 was about as exotic as it got! WordPress wasn’t even a glint in Matt’s eye at that time 🙂

Things have changed quite a bit in the past decade but one thing that still fascinates me to this day is how people approach building websites in general. Now that WordPress is maturing into a really powerful publishing platform I’m sure lots of people are developing pretty slick and rapid approaches to building WordPress powered websites.

Here’s the thing.

At first glance making WordPress themes looks dead simple. And in one way it is. A bit like learning chopsticks on the piano. Stick me in front of a piano and I’m pretty sure I’ll figure that out in a couple of minutes. Does that make me a pianist? Of course not!  Can someone who has never built a WordPress theme hobble one together in a couple of hours from reading one of the countless tutorials online? They sure can! That’s the good news. Getting started is easy. I think it’s one of the biggest strengths and attractions to new designers and developers to the WordPress ecosystem – low low barriers to entry. Does that mean you can become a WordPress theme development expert overnight? Well just like the piano – not on your nelly! It’s these same low barriers to entry that have led us to the place where there are some downright awful, poorly coded, shoddy and downright dangerous WordPress themes out there. Sometimes this gives people the impression that WordPress itself is a shoddy piece of software – and nothing could be further from the truth. It also leads fans of competing open source publishing platforms to look down upon WordPress as a platform for newbies and hobbyists rather than a serious publishing platform for hardcore professional designers and developers. The truth is – it’s both. Just like the Piano is for those who aspire to playing nothing more than Chopsticks AND for those budding maestros who want to master the classics.

Given all this diversity, there’s lot of ways to go about building WordPress themes. A few obvious approaches I see:

  1. Fireworks/Photoshop->HTML/CSS/JS->Custom theme from scratch
  2. Fireworks/Photoshop->Theme Framework->CSS
  3. HTML/CSS/JS->Custom Theme (or framework)
  4. Theme Framework

Approach 1 (Fireworks/Photoshop->HTML/CSS/JS->Custom theme from scratch) would be the most conventional process that would have been prevalent in professional web agencies since the dawn of the web. For many agencies and freelancers it’s still the method of choice – especially when clients need to be involved in the creative process. This kind of approach is also time consuming. Very time consuming. Especially if you are building a custom theme from scratch. In my view, this approach is going to quickly die off in the coming months and years. I can see it happening already. Which brings us to approach 2.

Approach 2 (Fireworks/Photoshop->Theme Framework->CSS) is quickly accelerating as being the smartest way for getting WordPress sites built quickly and professionally. You still undertake the creative/UX process that is still the preserve of web agencies across the globe but you do so on the knowledge that you will be plugging in the output of that process into a predetermined WordPress theme framework.  This approach has lots of benefits. First you have some sensible defaults and constraints. Sometimes a blank canvas can be a bit scary when building a WordPress theme. With a framework you have something to start from. You’ll also benefit from a solid foundation for plugging a design into. There are still plenty of skeptics knocking around though. Some people just don’t get theme frameworks. They see it as being a little bit odd and not what they are used to at all. It’s worth persevering and coming breaking this mindset – trust me – the benefits are worth it.

Approaches 3 and 4 are pretty similar. Some talented developers and designers don’t need the comfort canvas of Design production applications like Fireworks and Photoshop – they just dive straight into coding up the theme right within the theme or theme framework itself. This approach does not work for me at all. I end up going around in circles and getting no where fast. I need my paint by numbers canvas from photoshop 🙂 I’d love to be able to do this though as I’d imagine my process for theme building would become much faster.

So how do you build your themes? I can’t wait to hear about how you approach theme design and development!

Why Shortcodes in WordPress themes suck

20 July 2011 comment icon2 | Categories: opinion

I’ve just spent the last couple of hours troubleshooting a WordPress problem for a client who uses a commercial WordPress theme. They are a recent new client who worked with a previous designer who selected the theme for them. I’m in the process of building their new site and said I’d help them out with any issues they have with their current site while I get the new one rocking and rolling.

So it was with little trepidation that I dived into a problem the client was having with their homepage layout today. 2 hours later and I hate WordPress shortcodes. Don’t get me wrong, when used right WordPress shortcodes are a joy to behold. Contact Form 7 is an immediate case in point of where shortcodes work brilliantly. Need to add a contact form to a WordPress page? No problem, install Contact Form 7, setup your form and bang – drop the appropriate shortcode on your desired page – job done. For me this is what shortcodes were intended for – little simple hooks to link simple content items with plugin elements – bravo WordPress!

My new found hate for shortcodes is really a disdain for developers who abuse our little shortcode friends – it’s not the shortcodes fault you see – it’s how they’re now being thrown around like confetti for things they were never intended. Case in point – it would now appear that many commercial theme developers have completely lost the run of themselves and have start using shortcodes as the sole basis for laying out elements of WordPress themes like Homepages, Landing pages and so on.

This is wrong – plain and simple.

It’s a developer centric solution to a developers problem. In fact, I think it betrays the ease of use of WordPress and may give end users the impression that WordPress is way too complicated for them. While WordPress still has some way to go to improve usability of critical site management features like specific widgets on specific pages (Widget Logic is great but doesn’t work for your average WordPress user), it still does a pretty good job at delivering the goods right now for simple moving key content blocks around a webpage – if the theme developer has done their job right. I’m seeing a trend where shortcodes are becoming substitutes for widgets and page templates. Why does this drive me nuts? Well it simply means the end user now needs to go and learn a whole new form factor every time they want to setup a new website. The issue becomes exponentially worse when you consider that there is no overarching standards or guidelines for how shortcodes should be used for this purpose – meaning that every developer has their own way of implementing shortcodes for layout. While WordPress affords us wonderful levels of flexibility and many ways to skin the layout implementation cat – I would argue at this point that this is now hindering the theme development community rather than moving it forward.

Why do developers use shortcodes for layout purposes in the first place? My guess is it’s much easier and quicker for the developer than building custom widgets to control homepage layout elements. Wrong solution folks. Let’s work on making a much richer and intuitive mechanism for creating easy to use, reusable content widgets for things like Homepages, Landing Pages etc. I know that StudioPress have spent a lot of time adding nice little content widgets which do exactly this kind of thing. And are Page Templates all that difficult to create? Not in my experience! Plus I think users get that different pages have different templates intuitively. Throw in the flexibility of custom post types and custom fields/metaboxes and I see no reason why we need to continue down the road of Shortcode hell.

Leave those little gems doing what they do best and stop making me hate them.

WordPress Performance and Permalinks – quick tip

11 July 2011 comment icon7 | Categories: performance

Whoa it’s been nearly two weeks since I’ve posted on the blog. I’m up the walls busy at the moment working on developing some new WordPress themes for clients and our first public theme which should see the light of day before the middle of August. More on that a bit later in the month. We’ve also not forgotten about the High Performance WordPress post series – it’s just having to take a back seat for the moment – I promise to push out a few more on the series before the end of July! Anyway, last week we ran into some major performance problems with a clients WordPress powered website that I had to squeeze out a quick post to let you good folks know about the issue just in case it rears it’s ugly head.


Wonderful little inventions that let us have nice clean search engine friendly urls. From a backend UI perspective, the WordPress permalink implementation is excellent. But, once you start to have a lot of posts and pages on your site you WILL hit performance issues if you simply use /%postname%/ as your preferred permalink structure. The website in question had over 10,000 records in the posts table. Now the interesting thing was that there was nowhere near that many posts/pages actually on the website – more like a couple of hundred blog posts and about 1,400 pages. The balance of records in the posts table were actually WordPress revisions. There’s a lot of updates happening on the site at the moment and the posts table had gotten out of control. Never fear, this little simple query cleared out any old revisions from the posts table:


[codesyntax lang=”sql”]

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'


Credit to Lester for this nifty sql statement

As long as you maintain regular backups of your DB I see no reason to retain all your posts revisions on a long term basis. Some people might – I don’t. If performance is important to you (and it should be) then I advise keeping your posts table nice and lean by cleaning it up every few months. There’s also a nice little plugin for this if you’re that way inclined.

To keep the maintenance of your posts table low, you can also switch off revisions completely if they are overkill for your site. Just add the following to your wp-config.php:

[codesyntax lang=”php”]

define('WP_POST_REVISIONS', false );


So why is this important?

So why are the number of records in your posts table important to your permalinks and performance? In a nutshell, the more records in your posts table, the longer WordPress takes to execute key queries to retrieve the data required to load every page and post on your site. If your site will only ever have 40-50 posts/pages you can probably stop reading now. Otherwise, you will want to read Otto’s very well explained post on why certain permalink structures are more harmful than others. Seriously read it now. No time to read it? Ok, basically WordPress keeps it’s rewrite rules nice, simple and elegant by using cascading specificity – a bit like CSS. When your permalink structure is something very general like /%postname%/ you are in effect overriding this cascade and WordPress handles it by switching to use more verbose page rewriting rules. The impact of this cannot be overstated on large WordPress websites. On a site with 1,000 pages, it basically kills a VPS server with 1GB of ram and a trickle of traffic. Get a sudden burst of traffic and you’re dead – that’s even with something like W3 Total Cache running. When I switched the permalink structure to something more specific like /%year%/%postname%/ (which was my preferred structure after lots of testing – and is Otto’s preferred structure too.) the impact was immediate. CPU and RAM usage fell back to what I would expect for a site like this. Switching back to /%postname%/ just to confirm this was definitely the problem took nearly 10 mins for WordPress to process the request – and an immediate CPU/RAM spike – not good.

I can’t believe I’ve never come across this before – it’s actually noted in the WordPress codex that starting a permalink structure with /%postname%/ is a bad idea from a performance perspective – it’s just kinda buried. Given that so many SEO’s stress the importance of using this exact permalink structure I think that WordPress should shout a bit more about this because it’s probably giving some people a very bad impression of WordPress performance for no reason. The really interesting thing is that this doesn’t impact on the permalink structure for pages which I was worried about from an SEO perspective. I thought I’d have to setup a crapload of 301 redirects for pages and I didn’t fancy telling the website owner that all their pages now had a year in the permalink structure. Thankfully the problem never manifested itself as pages don’t seem to be affected by the permalink rules you control via the WordPress backend. Sp, while the /%postname%/ structure will kill your pages load time, the rule is just for blog posts. Pages stay nice and friendly in the format “www.mydomain.com/page-title” In any event, I find that having a date in the permalink for blog posts is a really big help when trying to verify how useful any given page will be. I don’t do that here yet but will be switching this in the near future once I knock a few items off the existing todo list.

WordPress Deployment Options

23 June 2011 comment icon2 | Categories: development

Ok I’ve had enough – I NEED better options for deploying WordPress websites.

Right now I manage a LOT of WordPress websites – probably close to 40 sites – maybe more. In fact I’ve lost count!

Right now my development process goes something like this.

  1. Download latest and great WordPress stable version
  2. Build website locally – get everything looking sweet within a XAMPP instance on my Mac.
  3. Deploy website to a staging/test link – this is where the process gets messy. My deployment process at the moment is far from ideal and I’m sure it can be automated and streamlined. Anyway, this is what I currently do:
    1. Dumpy mysql DB .
    2. Zip local WordPress instance.
    3. Setup staging DB user/db.
    4. Import DB to staging server.
    5. FTP/SCP zip of WordPress instance. Unzip it on staging.
    6. Change wp-config.php DB connection details.
    7. Set WordPress permissions. (Normally running a dedicated php user pool under NGINX to avoid having to set world writable permissions and opening up nasty server security holes. See more in my nginx setup details.)
    8. Change a few paths in the DB to match staging URL.
    9. Login to WordPress.
    10. Install Search and Replace Plugin and run it to change all local paths to match staging paths. (This is a must have plugin for deployment!).
    11. Test on staging and ensure all paths are correct.

Problems with this process?

It’s too damn messy and long winded. There are too many paths in WordPress that are environment specific. If I recall from my Joomla development days, you never had to set more than one path in the Joomla config file when moving sites from server to server. The worst thing is that once I’m done on my staging version and want to move the site to production, I have to repeat the deployment steps above – this time going from staging to production. Then there’s things like environment specific files like .htaccess files, W3TC config options etc. You’ll also find the odd gem of a plugin that stores hardcoded paths in the DB that can’t be easily edited without lots of debugging to discover a hardwired path deep in some column in the DB. I love those plugins I do. As much as I love getting teeth pulled.

More deployment headaches

Let me complicate the situation even further. Let’s also assume that after the website goes live, the client (which is sometimes me!) wants some further development work completed. This might involve some new plugin installations, new custom post types, new widgets etc. – you get the idea. What now? Yes sure I can work away on my development instance on my local machine and get everything functionally tickety boo – but then it comes time to deploy to staging first for signoff and then finally into production. What are my options? Do I bring down a local copy of the live website – reset production paths back to local (which I do sometimes especially given the passage of time when maybe the client has added their own plugins [heaven forbid!]) or something else?

Then once I’m done making my updates – how do I deploy? Do I create a new staging instance (again repeating deployment steps) and finally another production instance (yip you guessed it – repeating deployment steps) or do I just separately go into the existing production instance and manually install new plugins directly in production (which could lead to production errors with minor plugin version differences etc.).

A Better WordPress Deployment Process

Of course it would be remiss of me to go off on this rant without offering some ideas for how to make this process better. Don’t get me wrong – I bloody love WordPress. I’m sure half my issues above are down to my own lack of understanding about how WordPress or any PHP/MYSQL app can be deployed more effectively. I’ve played around with Rails a bit in the past and love the deployment options Rails provides for pushing web apps into production using the likes of Heroku. (I see PHP Fog and Cloud Control are tauted as equivalents for PHP apps – wonder if it plays nice with heavy duty WordPress instances.) I also use Subversion for version control on my Mac and the main repository is stored online. I’m sure some wizard has worked out a better way to deploy to production using SVN commands. Please tell me how! Maybe Automattic could extend VaultPress to become a WordPress Deployment Manager in a kickass Heroku-like manner. I think this would be massive time saver for a lot of people and agencies who work with WordPress every day. If someone else wants to write this let me know – I’ll be your first beta tester!

Is Capistrano the Answer?

I vaguely remember Capistrano from the few bits of Rails code I’ve dabbled with in the past. It looks like some folks have leveraged Capistrano and Git to good effect to help with WordPress deployment. Here’s some interesting resources for anyone interested in this approach:

Deploying WordPress to SliceHost using Capistano and Git

WordPress Deployment with Capistrano 2 and git

How do you deploy WordPress?

I realise deployment headaches are probably not an issue for a lot of WordPress users – but I can see this becoming more and more of an issue as WordPress users get more advanced with time and as more and more developers flock to the platform as WordPress becomes more like an application framework. I’d love for you to share your WordPress deployment processes and even your deployment horror stories!

Theme News Roundup – June 19

19 June 2011 comment icon0 | Categories: theme news

It’s been a while since I did a theme news roundup. Without further ado, here goes:

Responsive WordPress

Continuing our obsession with all things Responsive – WPMU has a nice showcase of Responsive WordPress sites and also has a list of free Responsive WordPress themes. Siobhan from WPMU also appears to share my obsession for Responsive web design as I just noticed another post from this week over on WPMU on how to optimise your WordPress site for the iPad.

Go check ’em out people – this is the future.

New WordPress Podcast

Studionashvegas has started an interesting new WordPress Podcast/Drivecast which features Mitch delivering the podcast on his daily commute – nice idea Mitch and I’m listening to the first episode as we type. Safe driving while you podcast!

WordPress Options

Tom O’Doherty has a really interesting insight into his thought process in what options to include in his recent WordPress theme release. Sitepoint also have a tutorial from Jeffrey Way on how to create a custom options page in WordPress. Sitepoint also appear to be sporting a nice new design.

So there you go people – some nice WordPress stuff for you to catch up on this Sunday afternoon – enjoy!

High Performance WordPress – Part 1

18 June 2011 comment icon18 | Categories: performance, theme news

Picture the scene. You’ve spent weeks and months working on your WordPress blog, carefully crafting some great blog posts about a subject that’s close to your heart. You’ve found or built a great WordPress theme that does a great job showcasing your content to the world. You’ve checked out countless Top 10 lists telling you about all the best plugins to use to make your blog the best blog it can be. You’re ready to take on the world. You slowly build a bit of a following to your site – building traffic day by day. A small trickle at first, maybe just a handful of visitors and not a single comment. But all the time you’re becoming a better writer. You get used to blogging. It becomes a habit. That trickle of users becomes a bit more steady and now you’re getting a bit more momentum. You’re traffic is still small but it’s growing all the time. Then one day you write a blog post that gets picked up by someone big and BAM! Traffic overload! It could be a write up by someone over at one of the big tech blogs like Mashable or Techcrunch. Or it could be a retweet from a major influencer in your market – or maybe both. All of a sudden you have a blog post that’s getting retweets and shares to beat the band. In a couple of hours you get more traffic than you’ve gotten in months – maybe more than you’ve ever gotten before. At first everything looks rosy. Just as you start to think about how you’re going to spend all those benjamins that will inevitably follow this new found deluge of traffic you notice something is up with your blog.

It’s not loading. Wait it is. Just realllly sloowwwwwlllyy. Weird. Everything was ok a few hours ago. You hit refresh. That little loading icon keeps on spinning. Weird 500 “a problem had occurred” errors start randomly appearing. It’s that damn webhost you convince yourself. Panic stricken about all those eyeballs who are invariably seeing that little loading icon while trying to access your words of wisdom you race to your web hosts live chat customer support. You tell them something is up with your blog and demand it to be fixed immediately. What they tell you breaks your heart. “There’s nothing wrong with our servers Sir. You’re running php scripts that are consuming too much memory on your account.” How can that be you wonder. After all you’re using one of the best shared hosting web hosts around who everyone told you is the best thing since sliced bread. You’re running the latest and greatest version of WordPress. Everything should be hunky dory you think. You’re left with the option of upgrading your account to a super duper expensive dedicated account to handle this influx of traffic – or worse still – your account being cancelled by your web host because you’re using excessive bandwidth. At this point you’re about ready to explode. All your hard work to build a following on your blog and finally get some recognition in the world has ended badly. Really badly. Your web host has let you down. WordPress has let you down. A lost opportunity.

Then you wake suddenly and realise it was all just a REALLY bad nightmare. Phew! Thankfully you had read this post series a few weeks before and were smart enough to get yourself a truly kickass web host and a WordPress configuration capable of handling hundreds of thousands of visitors every day without much of a blip on your server – and without paying an absolute fortune to do so. Huzzah!

Enter the High Performance WordPress Guide

Ok, so this is a bit of an exaggerated intro, but website owners running WordPress are faced with this nightmarish scenario every day. I’m writing this post series for a few reasons:

  • to help you setup the best possible hosting environment for your WordPress based website/blog/soapbox,
  • to help you prepare for a spike in traffic to your website, and, most importantly
  • to help you avoid the nightmare scenario above.

Not all blogs will experience a massive spike in traffic. And that’s ok. For those who do experience it – well done! It’s a bit like winning the content lottery. You won’t make a million dollars from a traffic spike (unless you get a REALLY REALLY REALLY big traffic spike and you’ve got some seriously shit hot ad networks or some shit hot product!). Let’s assume for now the content lottery is enough of a reward for you. You’re being rewarded for your writing and for that you should be delighted. A spike in traffic to your website is something that you should be able to rejoice in – not have a panic attack. It’s should be something that gives your website a shot in the arm – not a killer blow.

The facts are very simple. If you operate a self hosted WordPress website on a shared hosting platform, chances are that should your website explode in popularity all of a sudden, you could be faced with the nightmare scenario we’ve just described. WordPress is great – but it’s not configured and optimised for scale out of the box.

The reality is that even if you think you’re website will never have thousands of visitors a day right now – the beauty of the web means that it could have – on any given day – at any given time – and if you’re serious about your blog, you should be prepared for it to happen.

In fact we’ve developed lots of verbs to describe the experience of getting a ton of new traffic – slashdotted, Digged, Reddited and even Fireballed more recently.

This is what the High Performance WordPress Guide is all about. Your WordPress setup will go from zero to hero if you follow our weekly tutorials on how to configure the best damn WordPress setup that a little bit of time and the smallest amount of money possible will get you. So let’s dive in with Part 1.

Part 1 – Web Host Selection

The web hosting business is vast. There are literally thousands of options. You can spend days, weeks and months evaluating what’s best to meet your needs. Let’s short circuit that process. Why? Well I’ve spent those days, weeks, months AND years using dozens of different providers who all claimed to be the best.

Bye Bye Shared Hosting!

We’re going to significantly reduce the number of potential hosting vendors by removing ALL shared hosting options. Why? Simply put, shared hosts will never give you the flexibility you need to tune and configure a server for optimal WordPress performance. Yes you will be able to install some or all of the big WordPress caching plugins but after that your hands will be pretty much tied. Caching plugins will only go so far. Don’t get me wrong – shared hosting is a great option for some websites. If you’re running a personal blog or really small business website where downtime will not adversely impact on your business then fire away with shared hosting. But pretty much the rest of this guide will not be for you. Our starting assumption here is that you’re happy to move away from a shared hosting environment to a Virtual Private Server (VPS).

Virtualise me Baby!

While VPS servers are not a new technology, they have become more accessible in recent years as the cost per month becomes closer to what people are used to paying for shared hosting. As a result, the number of VPS providers is exploding at the moment. Chances are if you’re using a shared host at the moment, they may have a VPS option. Let me save you some time by identifying what I think are the best VPS providers for WordPress hosting.


Linode is our top recommendation for low cost blisteringly fast VPS servers. I don’t look beyond them for any of my hosting needs anymore. For the purposes of this post series, I will be assuming you select Linode as your hosting environment. If you don’t trust my judgement. No problemo – make your own decision on what you think is best. Three things stand out for me with Linode:

  • World class customer support – I’ve frequently had fairly complex support tickets responded to within a minute or two with clear instructions as to how to solve my problem. My support tickets have never been about site uptime either. In fact, I’ve had some servers with 100% uptime for over 7 months since I started using Linode.
  • Support Community – There is a great support forum with many active power users who are on hand to offer their assistance and expertise when it comes to highly specialised queries about performance tuning.
  • Cost – the entry level Linode plan – Linode 512 – is $19.95 per month. This is probably a few dollars more than what you’re paying for with a shared host. But believe me, it’s totally worth it. The Linode 512 plan is what we’ll be assuming you’re using for this post series.

Other VPS recommendations

  • Slicehost – Great alternative to Linode. Slightly more expensive. They have a great support community too and a great Library of articles. Rackspace (who own Slicehost) look to be in the process of rolling Slicehost back into Rackspace Cloud which is a crazy decision if you ask me and puts the long term health of Slicehost into question.
  • Amazon EC2 – It’s hard to ignore Amazon as a really good option for WordPress VPS hosting. Some of the world’s most popular websites are running on EC2. Amazon also have some of the smartest engineers in the world leading the Cloud Computing revolution. There’s also the added benefit of a Free Usage Tier for new users which gives you 12 months free limited resource usage on the EC2 platform. More than enough time to experiment with a VPS/cloud environment before you make the jump if you like that sort of thing. Amazon have had their troubles of late with a massive outage and the lack of live chat/phone support is always a disadvantage for me.
  • Rackspace Cloud – Some people hate Rackspace Cloud – others swear by it. I have a number of clients who I manage Rackspace Clouds on their behalf. Their control panel needs some serious work to bring it in line with the ease of use of Linode. (in fact they should just use the Slicehost one that they already own!) The standout features for Rackspace Cloud are the excellent support services they offer. Paying that little extra for the option of live chat and phone support will be important for some.
  • VPS.net – I’ve included VPS.net despite having grave reservations about their tech platforms of late. About 12 months ago, I loved VPS.net. I had all my big sites running there. Many key influencers in the WordPress community run big big sites on VPS.net like Joost, WooThemes and Chris Pearson use VPS.net and for that reason alone you might want to check them out. But for now I’ve lost confidence in their service and can’t recommend them at this time. Why put them on this so? Chances are if you’ve been doing VPS research you’ve probably come across glowing reviews of VPS.net from the last 12-24 months – I just want to give people a heads up as to what their service has been like the last 3-4 months in 2011.

So in summary, save yourself hours of research and just go with Linode. Now let’s move on your server selection and setup.

Server OS and Location Selection

There’s a few things we need to decide on that are pretty fundamental to our server setup right at the start.

Account Plan Selection

Available Linode plans.

We firmly believe that less is more. We’re going to get ourselves a shiny new VPS with just 512MB of RAM to start us off. 512MB will keep us disciplined and show us just how much traffic you can throw at an entry level VPS account once you’re running the right kind of web server and caching config.

Location Selection

Choosing a datacenter for your Linode.

Geographical location is an important consideration for your overall website speed. As a general rule of thumb you should pick a server location that is closest to the biggest chunk of your users. Linode offer 5 locations around the globe. 3 in the US, 1 in the UK and 1 in Canada. If you’re unsure which location to go with, I’d select Newark, New Jersey as it’s a good central location for both sides of the Atlantic.

Operating System (OS) Selection

I’m not a Linux expert by any stretch of the imagination but I have used RedHat, CentOS and Ubuntu quite a lot over the past decade. For me, Ubuntu has a lot going for it in terms of ease of use for a Linux newbie. Therefore, Ubuntu is what I’m recommending you select as your operating system for your new server. For the purpose of this tutorial series I’ve installed and configured the 32 bit flavour of Ubuntu 10.10 (Maverick Meerkat). Why 32 bit and not 64 bit? Well we’re only using 512MB of RAM and apparently the 32 bit flavour of Ubuntu works better on servers with lower RAM. If you’re intending on rolling out a server with 2GB+ of RAM then the 64 bit version is definitely the way to go. As of the time of writing 11.04 is in the wild but I’ve not experimented with it yet so I don’t recommend you do either.  Some people might also suggest you use 10.04 rather than 10.10 because 10.04 is an LTS release. In my experience there’s not much difference between them and 10.10 is very stable – plus you’ll get newer packages out of the box. Go with 10.10.

What’s next?

So if you’ve gotten this far you’re probably wondering what’s next. If this is your first time operating a VPS account I strongly suggest your read over the wonderful tutorials in the Linode Library – in particular the Getting Started tutorial. In Part 2 we’re going to dive straight into our LEMP configuration and get your nginx powered web server up and running in no time. So sit tight sports fans and see you soon!

Classy new free HTML5 WordPress theme from Smashing Magazine

08 June 2011 comment icon0 | Categories: theme news

Every now and again Smashing Magazine release a free WordPress theme. Normally with free WordPress themes, I approach them with limited expectations. After all the theme is free – there’s got to be limitations right? Surely it can’t be on a par with the level of quality we expect from commercial theme shops? Well, not so with Smashing Mag themes. Time and time again they hire some of the best theme developers to produce fantastic quality WordPress themes that meet and often surpass the quality of that which are sold commercially.

Today’s new release is no exception. In fact it’s got me quite excited. Yoko is a free WordPress theme produced by Elma and Manuel from Elmastudio. Why has this theme got me excited?

A few highlights

  • Responsive design
  • Responsive design
  • um…. Responsive design

We don’t see enough responsive WordPress themes. 2011 looks like it’s turning out to be the year that the Responsive web design movement really takes off. Ethan Marcotte’s milestone A List Apart article over a year ago resurrected many of the principles of what we used to refer to as “liquid” web design over a decade ago and gave us a whole new shiny box of tips and techniques on how to ensure our websites render appropriately and respond differently for different web browsing devices. Well Ethan has not let go of this topic and just launched a brilliant book on the subject of responsive web design yesterday. I bought the book within 5 minutes of it launching and gave it a really quick flick yesterday. It’s a brilliant book and I encourage everyone who has an interest in building modern WordPress themes in 2011 to get it immediately.

In the meantime, you should go get your hands on the Yoko theme and look at how Ellen and Manuel have approached implementing responsive techniques in WordPress theme design.

Well done to Ellen, Manuel and Smashing Magazine for continuing to raise the bar for free WordPress themes!

New free WordPress eCommerce plugin JigoShop released – jaw drops

31 May 2011 comment icon19 | Categories: featured, theme news

Jigoshop from Jay Koster and the rest of the Jigowatt team shipped it’s first public beta today. Jigoshop is a free eCommerce plugin for WordPress. As someone who has played with just about every eCommerce plugin for WordPress, and who does a lot of work with other eCommerce platforms like Magento, OpenCart and Prestashop, I couldn’t wait to take Jigoshop for a spin. WordPress eCommerce plugins to date have always come up short in key areas like UI design, core Admin UI integration and at best were just ok – and a worst a maddening heap of crap.

I’ve just spent the last hour playing with Jigoshop.

Well let me tell you boys and girls – eCommerce for WordPress don’t suck no more! Jigoshop is a joy to behold – right from the initial install through to getting a test order through the cart. You can literally have this thing up and running and taking orders in about 10-15 mins tops.

Here’s a quick run down of why I think in one single public beta release, Jigoshop is the best eCommerce plugin, beating off competing plugins like Shopp and WP-eCommerce.

  • Attention to detail – It’s clear that Jay and the team have spent countless on the small details of Jigoshop – the level of detail and care taken to craft an incredibly user friendly and efficient admin UI is immediately obvious. Believe me this doesn’t happen by accident and this alone sets Jigoshop apart. The use of core WordPress data standards for custom post types and custom taxonomies is comforting as this will ensure the longevity of this plugin.
  • Frontend UI standards – I installed Jigoshop on a clean 3.1.3 WP install running TwentyTen. Things looks pretty good without touching a single custom css class. Jigoshop also have a premium theme coming down stream very soon which can be seen via the Jigoshop demo and it incorporates the best responsive design I’ve seen to date for an eCommerce website – WordPress plugin or no plugin. Exceptionally good stuff.
  • Product Management – The UI for product management is simply kickass. I really like the option of setting up global attributes but also having the ability to add unique attributes for individual products.
  • General Settings – There is a higly configurable settings section letting you control things like sensible defaults for SKU logic, Allowed Countries, Guest Checkout, Localisation of Weight, Currency, excellent Coupon options and Stock management logic.

I’ll be actively giving the guys some feedback for future versions but here’s some things I think Jigoshop can improve on in the future:

  • Shipping Options – Very few open source cart platforms have cracked the complex shipping requirements that many global exporters require. I would encourage the Jigoshop team to check out how shipping is handled in OpenCart – it’s the best I’ve found. Zone based shipping rates are extremely important for exporters – just think of those shipping charges for bulky goods going around the world!
  • Payment Gateways – Jigoshop comes out of the box with Paypal standard, Cheque Payment and Moneybookers. I’m sure the guys are on it but the more sophisticated Paypal integrations will be important for future versions.
  • Some label tweaks in the Admin UI – While 99% of the UI is perfect already – there are some admin labels that need refinement to be 100% obvious to first time users – I’m nitpicking now 🙂

I’ve only just scratched the surface of Jigoshop and I’m already sold. What’s more insane is that the plugin is free! If this post is coming across a little fan boyish – fuck it I don’t care! I’m a Jigoshop fanboy 🙂 I will be using this as my eCommerce plugin of choice from now on.

Roots HTML 5 WordPress Theme – First Look

30 May 2011 comment icon3 | Categories: theme news

So I’ve been dabbling in a bit of HTML5 of late and have been reviewing how things have progressed in the WordPress development community with HTML5 themes in the past few months. Previously we looked at the Toolbox theme and the reasons why you should start using HTML5 in your theme development.

There’s a few very interesting HTML5 themes starting to pop up for WordPress and we particularly like themes based on the HTML5 Boilerplate project, including:

But the one that really stood out is the Roots Theme which is the brain child of Ben Word.

Roots is somewhat unique amongst these HTML Boilerplate themes in that it goes a lot further than providing a Boilerplate integration into WordPress. Roots does more – much more in fact.