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


27 February 2012 comment icon0 | Categories: performance

Apologies for the recent downtime folks – I took a trip into the wilderness the past week and had been experimenting with some fine tuning of my varnish/nginx config just before I left. I thought everything was sweet but turns out it wasn’t 🙁

Anyway, everything should now be back to normal. If it’s any consolation I’ve been fine tuning some aspects of the long awaited Varnish tutorial which should be online tomorrow evening.

Featured packed Jigoshop V1.0 released

01 February 2012 comment icon0 | Categories: plugins

It looks like the folks over at Jigoshop have not been slacking off in January with today’s announcement that Jigoshop V1.0 is out! Dan the team have clearly been listening to the community and have delivered in spades for V1.0.

Key highlights

  • Complete overhaul of the Products UI – This is a biggie – many WordPress based shop plugins often struggle with the plugin management UI. The best plugins strike a balance of maintaining the consistent design patterns recommended by the WordPress dev team while ensuring the specific use cases for the plugin are as simple as possible to complete. I think the Jigoshop team have done a top notch job on this front.
  • As someone who has not been paying a lot of attention to their blog these past few months because they’ve been knee deep in very complex Magento shipping and tax rules, I’m particularly looking forward to checking out the enhance tax and shipping business logic. (Sidenote for budding ecommerce developers – if you think getting your clients to get their product catalogue organised is the hardest part of an ecommerce product, it’s not. Tax. Shipping. That’s where the real fun is.
I’ve been a real fan of Jigoshop since it’s release last May and it’s fantastic to see so many people have jumped on board since then. I think 2012 will be a fantastic year for WordPress and eCommerce and Jigoshop is right in the middle of the things! Go check it out.

Happy New Year!

11 January 2012 comment icon0 | Categories: about

Wow can you believe is 2012 already? I want my hover board already 🙂 As is now a regular pattern, when it’s quiet here on the blog it normally means that I’m hectic with work and life. This time is no different! I was originally intending on running another 24 ways post series in December but a combination of deadlines and well Christmas vacation got in the way. I did manage to release a new WordPress theme called IPEO just before Christmas which you can buy over on Mojo Themes. I’m really happy with how it turned out and it’s been doing well since launch. More on that some other time. Coming up in the next few weeks I intend to finish off the extremely popular High Performance WordPress post series which took a hiatus along with me. So stay tuned WordPress fans for more WordPress goodies in 2012!


High Performance WordPress – Part 4

16 November 2011 comment icon20 | Categories: featured, performance, tutorials

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 – nginx/mysql setup
  • Part 3 – WordPress setup & tuning on nginx

Today we’re going to sqeeze even more performance out of your trusty little VPS by configuring and tuning an opcode cache for php.

What is an Opcode cache?

PHP differs from languages like Java and the .net framework in that it is an interpreted language meaning that each time you call a PHP script, the server must first read the contents of the script and compile the logic contained within to code that the operating system can understand (which is the Opcode bit). This is all fine and dandy if you’re running a low volume website with very simple non-memory intensive application logic. As soon as you start to use more complex PHP applications like WordPress and then throw in a bit of traffic things tend to get slower – quickly. A lot slower in fact.

All this “just in time” opcode compilation puts a lot of strain on your server in the form of memory usage.

Enter Opcode Cache

When setup correctly (and correct setup is key) an Opcode Cache can significantly speed things up nicely. In a nutshell an Opcode Cache will load, parse and compile your PHP requests once and load them into memory (or disk) for reuse. The advantages to this should be immediately obvious – your server will not need to process load, parse and compile the same PHP requests every single time they are called – saving precious RAM and CPU cycles – which can translate to significant page load speed improvements.

Common PHP Opcode Cache Options

With PHP becoming ever more popular over the past few years, lots of different Opcode caching options have emerged. Here are links to some of the more predominant options:

Which Opcode Cache is best?

I’ve played with all 3 of these extensively and I always come back to APC. APC will at some point come out of the box with future PHP releases. It was also the Opcode cache of choice for frickin Facebook for a long time. (Although I think Facebook now uses Hiphop exclusively which also comes with an implementation of APC).  You’ll see lots of debate about which one is best but APC is just dandy in my book and generally works really really well so let’s get on with the setup and configuration process.

APC Setup and Configuration

If you’ve been following along with our High Performance WordPress post series, the really good news is that I snuck in the APC installation back in Part 2. If you’ve not been following along – shame on you! The install process is still pretty straightforward:

apt-get install php-apc
service php5-fpm restart

To check and see if you’re already running APC, load your trusty phpinfo page and look for this:

APC Tuning

Sometimes just installing APC is “good enough” to get you up and running but you really should tune it for your specific website to avoid degrading your websites performance. Thankfully APC has a nice little script which helps us see what it is doing and in turns helps tune APC accordingly.

Log on to your shell account and grab a copy of the APC diagnostic script and drop it into your web root as follows:

cp /usr/share/doc/php-apc/apc.php.gz /srv/www/mydomain.com/public_html/
cd /srv/www/mydomain.com/public_html
gzip -d apc.php.gz

Go ahead and open apc.php (use nano apc.php) which should now be in your web root and set a strong password to enable the script. Then open mydomain.com/apc.php and you should see some lovely data like this:

Right now most of this will mean diddly squat – that’s ok! There are a few really really important things you need to fully understand to get the true benefits of APC.

  • Memory (apc.shm_size) Size – The single most important thing to understand about how APC works. In a nutshell, APC will store your compiled PHP to RAM (or mmap memory most likely on most distros now). The default size of the memory block allocated to APC is 32 MB. I find this generally to be too low for your typical WordPress website. I generally bump this up to 96M or even 128M to start with. You might be ok with 32M but I wouldn’t risk it – especially if you have a bit of memory to spare. On my trusty 512M Linode I have allocated 128M to APC alone without any issues. Why is apc.shm_size so important? Well, if you leave it at the default 32M and the cache is filled quickly, it will most likely hit 100% memory usage in a very short space of time, at which point APC will dump the complete contents of the cache! When this happens all new incoming PHP requests will be re-compiled by APC and this will cause a memory spike in itself on your server. Moreover, if you’re constantly hitting high percentiles of APC memory usage it is likely your cache will become quite fragmented which will cause a bit of a performance degradation. If after a week or two you find at you’re never using more than 50% of your memory allocation you can always dial it back down. Just remember that if you add another new and separate WordPress install to your server you’ll need to bump it back up again. I generally assign 56M per site on my servers to be safe.
  • Cache Hits & Misses – When a PHP request is served from your APC cache this is a HIT. When the PHP request must be loaded, parsed and compiled by PHP this is a MISS. When you first install APC and load your first few WordPress requests you will have more misses than hits – naturally as APC has never seen them before. But after a few more requests you’ll find your hits should start rising dramatically. Over time (after a day or two) virtually all PHP requests should be hits. For a typical stable WordPress website where you’re not chopping and change plugins, themes frequently, you should be getting high 90%’s for your hit ratio.

Once you understand these 2 fundamentals everything else after should be pretty straight forward. There is a lot of other fine tuning you can do to your APC install but your cache size and your hit ratio will be the main determinants of how effective APC is for your server.

I’ve included my typical APC config below. This config is used on a few nginx/php-fpm servers I’ve built out in the past couple of years that serve thousands of visitors per day with very healthy high 90%’s hit ratios and memory usage under 60% consistently.

To edit your APC config:

cd /etc/php5/conf.d/
nano apc.ini
apc.enabled = 1
apc.shm_segments = 1
apc.shm_size = 96
apc.optimization = 0
apc.num_files_hint = 4096
apc.ttl = 7200
apc.user_ttl = 7200
apc.gc_ttl = 0
apc.cache_by_default = 1
apc.filters = ""
apc.mmap_file_mask = "/tmp/apc.XXXXXX"
apc.slam_defense = 0
apc.file_update_protection = 2
apc.enable_cli = 0
apc.max_file_size = 10M
apc.stat = 1
apc.write_lock = 1
apc.report_autofilter = 0
apc.include_once_override = 0
;apc.rfc1867 = 0
;apc.rfc1867_prefix = "upload_"
;apc.rfc1867_name = "APC_UPLOAD_PROGRESS"
;apc.rfc1867_freq = 0
apc.localcache = 0
apc.localcache.size = 512
apc.coredump_unmap = 0
apc.stat_ctime = 0

If you’re interested in what each of these values is for look no further than the main APC Runtime configuration docs.

That’s is for Part 4! In Part 5, we’ll be adding the final big layer or super charging for your server when we walk you through the process of setting up a Varnish Cache server to sit in front of nginx. Part 6 will then bring everything together when I walk you through our testing tools of choice for benchmarking server performance.

In the meantime your homework for this week (I would have loved if they taught this shit in school!) should be to tune your APC run time configuration for optimal memory assignment.

See you next week!


High Performance WordPress Part 3

02 November 2011 comment icon32 | Categories: featured, performance

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 the know like to call it.

Today, we’ll proceed with setting up WordPress on our shiny new VPS server.

Create an nginx Virtual Host

First things first, let’s smarten up our nginx configuration to make things play nice with WordPress. I’ve learned to love nginx conf files. In the beginning it was a bit different from configuring Apache but once you get beyond this initial learning curve you realise nginx really is a very very clever little fellow that’s been really well designed.

nginx’s nerve centre can be found in /etc/nginx/

We’ll be spending most of our time in 3 place within this directory:

  • nginx.conf – the master nginx config file which contains global host configuration information
  • sites-available and sites-enabled – these 2 apache’esque directories control your virtual host website specific configuration files. Host config files are created in sites-available and symlinked back to sites-enabled – very similar to how Apache works. We’ll show you this in more detail very shortly.

Editing nginx.conf

I’m not going to go into massive detail on editing your overall nginx.conf in this tutorial. You’ll find tons of stuff in Google on this if you’re that way inclined. The default config works pretty well out of the box. The most important thing to ensure is that you have these 2 lines in your nginx.conf:

# Virtual Host Configs
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

These 2 lines simply tell nginx to also load any conf files found in these 2 locations when it is being started/reloaded. These is critical for the rest of this tutorial.

Create a home directory for your websites

For simplicity, I like to store my websites in /srv/www but this is pure personal preference. You choose a different location like /var/www or /home/site/www/ if you wish. For now let’s assume you’ll follow along with me.

mkdir -p /srv/www/engin.ex/public_html
mkdir -p /srv/www/engin.ex/logs

One directory will serve your content while the other is for your log files. Pretty simple eh?

Now let’s tell nginx about our new site location.

Creating an nginx virtual host for WordPress

Ok so let’s make an assumption that you wish to run WordPress on a domain of some sort (pretty safe assumption I would think!). Let’s go with engin.ex (see what I did there) as our dummy domain example. First we create a file called engin.ex in /etc/nginx/sites-available/

cd /etc/nginx/sites-available/
touch engin.ex

Now you’ll probably want to crack open your favourite text editor and copy/paste the following nginx config and tweak it for your domain name.

# W3TC config rules based on http://elivz.com/blog/single/wordpress_with_w3tc_on_nginx/
server {
    listen   80; ## listen for ipv4; this line is default and implied
    #listen   [::]:80 default ipv6only=on; ## listen for ipv6
    # Tell nginx to handle requests for the www.engin.ex domain
    server_name         www.engin.ex engin.ex;
    if ($host != 'engin.ex') {
    rewrite ^/(.*)     http://engin.ex/$1 permanent;
    index               index.php index.html index.htm;
    root                /srv/www/engin.ex/public_html;
    access_log          /srv/www/engin.ex/logs/access.log;
    error_log           /srv/www/engin.ex/logs/error.log;
    # Use gzip compression
    # gzip_static       on;  # Uncomment if you compiled Nginx using --with-http_gzip_static_module
    gzip                on;
    gzip_disable        "msie6";
    gzip_vary           on;
    gzip_proxied        any;
    gzip_comp_level     5;
    gzip_buffers        16 8k;
    gzip_http_version   1.0;
    gzip_types          text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript image/png image/gif image/jpeg;
    # Rewrite minified CSS and JS files
    rewrite ^/wp-content/w3tc/min/([a-f0-9]+)\/(.+)\.(include(\-(footer|body))?(-nb)?)\.[0-9]+\.(css|js)$ /wp-content/w3tc/min/index.php?tt=$1&gg=$2&g=$3&t=$7 last;
    # Set a variable to work around the lack of nested conditionals
    set $cache_uri $request_uri;
    # POST requests and urls with a query string should always go to PHP
    if ($request_method = POST) {
        set $cache_uri 'no cache';
    if ($query_string != "") {
        set $cache_uri 'no cache';
    # Don't cache uris containing the following segments
    if ($request_uri ~* "(\/wp-admin\/|\/xmlrpc.php|\/wp-(app|cron|login|register|mail)\.php|wp-.*\.php|index\.php|wp\-comments\-popup\.php|wp\-links\-opml\.php|wp\-locations\.php)") {
        set $cache_uri "no cache";
    # Don't use the cache for logged in users or recent commenters
    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp\-postpass|wordpress_logged_in") {
        set $cache_uri 'no cache';
    # similar to Apache Status - handy for quickly checking the health of nginx
    location /nginx_status {
    stub_status on;
    access_log off;
    allow all;
    # Use cached or actual file if they exists, otherwise pass request to WordPress
    location / {
        try_files /wp-content/w3tc/pgcache/$cache_uri/_index.html $uri $uri/ /index.php;
    # Cache static files for as long as possible - removed xml as an extension to avoid problems with Yoast WordPress SEO plugin which uses WP rewrite API.
    location ~* \.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
        try_files       $uri =404;
        expires         max;
        access_log      off;
    # Deny access to hidden files
    location ~* /\.ht {
        deny            all;
        access_log      off;
        log_not_found   off;
    # Pass PHP scripts on to PHP-FPM
    location ~* \.php$ {
        try_files       $uri /index.php;
        fastcgi_index   index.php;
        include         fastcgi_params;
        fastcgi_param   SCRIPT_FILENAME    $document_root$fastcgi_script_name;
        fastcgi_param   SCRIPT_NAME        $fastcgi_script_name;

Whoa that’s a lot of code! We’ll go into what this does in another post some time. For now, you can trust me that these config rules work pretty darn well on some high traffic WordPress websites. For now, the final step is your symlink back to sites-enabled:

ln -s /etc/nginx/sites-available/engin.ex /etc/nginx/sites-enabled/engin.ex
service nginx restart

In the config file above I would obviously substitute enign.ex for whatever your domain is of course! Don’t forget that step for your config. I’ve used this config example on a good few WordPress powered websites for the past year with no real issues. It’s pretty stable. Those of you paying attention will also have spotted that this config is also optimised for use with W3 Total Cache. More on that aswell a little bit later. For now, let’s get WordPress installed and up and running.

Install WordPress

Nothing majorly complicated here.

cd /srv/www/engin.ex/public_html
wget http://wordpress.org/latest.tar.gz
tar -zxvf latest.tar.gz
cp -rvf wordpress/* .
rm -R wordpress
rm latest.tar.gz

These few commands above will get you your WordPress source ready for a clean install. Just before we do that, let’s hop back across to phpMyAdmin and create a new DB for our WordPress install. I won’t go into details about how to do that here – tons of stuff online to help you with that. Also, now would be a good time to head back over to Part 2 if you’ve skipped the phpMyAdmin install earlier.

Oh I almost forgot, one more thing you should do is set permissions on your public_html to be writable by the www-data user. There’s definitely one or two more secure ways of setting permissions on your web root but they always tend to have a trade off of making plugin and image uploads a little bit tricky. For now, we’ll set this and we’ll come back to a little bit more secure setup a bit later.

chown -R www-data:www-data /srv/www/engin.ex/public_html

Right out of the gates this basically gives nginx permission to write files to your web root (nginx.conf sets the main system user account to use to be www-data, the same account Apache uses on Ubuntu). We’ll benefit from this straight away as the WordPress installer will be able to write your wp-config.php to the filesystem.

Whip up your browser and hit http://engin.ex/ – you should see the first screen of the WordPress install process. Complete the famous 5 minute install.

Tuning WordPress for nginx

Assuming you’ve made it this far you could stop right now and you’d have a pretty kickass nginx powered WordPress setup. But where would the fun be in that? Let’s crack on and soup up this server to be even more badass!

nginx and Permalinks

If you’re used to running WordPress on Apache, you’ll be definitely aware of what a .htaccess file is. Well, nginx doesn’t use .htaccess files. Everything is configured in your config file over in /etc/nginx/sites-available. But don’t fret – we included some nice WordPress rewrite rules earlier so go ahead and setup and switch on your favourite permalink config.

nginx Plugins for WordPress

Given nginx’s recent popularity a few plugins have started popping up in the community which help optimize WordPress for nginx environments which deserve a mention. One in particular is nginx Compatibility – This is a great little plugin and one I recommend as a must have. WordPress has some builtin functions to check for the presence of mod_rewrite which is an apache module used for url rewriting. Obviously nginx doesn’t have this module and when WordPress doesn’t detect it, there can be problems with your permalink structure. When this plugin is used it tricks WordPress into thinking mod_rewrite is present and any potential rewrite problems melt away.

Install W3 Total Cache

It would be a real shame to get this far in the guide and to not really turn your server into a traffic serving beast! W3 Total Cache (W3TC for short) will do just that. There are a handful of really really good caching plugins for WordPress. Other than W3TC, the other few I’ve used a lot are:

  • Super Cache – The grand daddy of WordPress caching plugins. It’s pretty damn good too. There’s not much to choose between Super Cache and W3 Total Cache. In fact many people prefer it to W3TC and have less trouble configuring it from scratch. It’s code is top notch which is to be expected given it’s written by top WordPress developer, Automattic employee and all round good guy Donncha O’Caoimh. It also plays nice with nginx once you’ve tweaked for your config accordingly. (Sidenote: we’re not covering an nginx Super Cache config today but if you’re interested Donncha himself provided one some time ago and a more recent one from Tim Purewhite which actually looks great – thanks for sharing Tim!.)
  • Quick Cache – This is new kid on the block and I’ve used it on a few WordPress powered websites running on Apache. I’ve not used it in anger on an nginx server yet. I do recall playing around with it and I don’t recall everything running smoothly but I didn’t delve further. But it works great on Apache and it’s gathering a lot of momentum recently.

Why I prefer W3 Total Cache

I’m not here to debate which caching plugin is better than the other. Tons of people quite frequently put together comparisons between this feature and that and spend more time than I ever could analysing the finer points of how many requests per second one plugin can serve over another. In reality there’s not much between all of the plugins mentioned here. I prefer W3TC simply because in my view pound for pound it gives provides the best all around feature set and performance of all these plugins in a VPS environment and it’s pretty simple to get working well with nginx. It also has support for Varnish cache purging and Opcode caching which we’ll be coming back to in Parts 4 and 5. That’s before we even mention the brain power behind this plugin. The frickin CTO of one of the busiest blogs on the planet Frederick Townes built W3TC from scratch so this plugin has had some serious road testing!

If you’re looking for a really detailed guide to W3 Total Cache do not look beyond Tentblogger’s incredibly detailed and totally awesome W3TC setup and configuration guide – thanks John!. You can safely ignore John’s permission and .htaccess settings as we’ve taken care of both earlier in this guide. But everything is pretty much bang on for a pretty well optimised W3TC setup. Go ahead and install W3TC and follow the Tentblogger setup guide.

If you’ve followed that tutorial carefully you shouldn’t have any issues. How can you check if it’s working? I would recommend starting with Disk enhanced caching for your page caching. In later tutorials we’ll get into Opcode caching. For now once you select enhanced Disk page caching and you browse to your website frontend (and you’re not logged into WordPress!) you should see some files getting written to /wp-content/w3tc/pgcache/ – make sure you click around a few pages and see that additional files and folders are being written to the disk. All good! Great – your initial W3TC config is complete. But what about our .htaccess rules I hear? Well the nginx config we setup earlier already has them built in! Your frontend should now be serving cached content and if you enable the W3TC page caching debug output you should see something like this in your websites source:

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/
Served from: www.engin.ex @ 2011-11-02 22:53:52 -->
<!-- W3 Total Cache: Page cache debug info:
Engine:             disk: enhanced
Cache key:          sample-page/_index.html_gzip
Caching:            enabled
Status:             cached
Creation Time:      0.044s
Header info:
Set-Cookie:         w3tc_referrer=http%3A%2F%2Fengin.ex%2F; path=/
X-Pingback:         http://engin.ex/xmlrpc.php
Content-Type:       text/html; charset=UTF-8
Last-Modified:      Wed, 02 Nov 2011 22:53:52 GMT
Vary:               Accept-Encoding, Cookie
X-Powered-By:       W3 Total Cache/
Content-Encoding:   gzip

I’d recommend switching off the debug once you’re happy everything is working correctly.

Take a deep breath and path yourself on the back.

That pretty much wraps up Part 3 – well done on making it this far! By now your new WordPress website is a finely tuned traffic munching animal. You’ll be ready to handle thousands more requests than a normal WordPress install running on Apache with no caching. In part 4 we’re going to venture further down the rabbit hole of High Performance WordPress tuning when we take a look at Opcode caching and how to stress test your new server. Feel free to raise any questions you have in the comments below and we’ll factor to them into future posts in the series!

High Performance WordPress – Part 2

26 October 2011 comment icon13 | Categories: featured, performance

So it’s taken much longer to push out Part 2 of the High Performance WordPress post series but it’s back and hopefully won’t have as big a gap for Part 3! Last time in Part 1 we got you as far as selecting a VPS host (still loving Linode!) and your OS selection (Ubuntu 10.10).
Today, we’re going to dive into getting your shiny new VPS machine up and running on the most kickass, hottest web server stack making big big waves in the WordPress community and further afield. First, let’s take a look at what we hope to achieve:

  • OS setup – Optimizing Ubuntu as a web server.
  • Web Server Setup – nginx setup and configuration – whoa – no Apache? Yup that’s right folks we’re hooking you up with the fastest web server on the planet!
  • DB Server Setup – Good ‘ol mysql will still be our data layer.

OS Setup

I’m a great believer in not reinventing the wheel. In addition to being a brilliant host, Linode also offer a fantastic Library which provides documentation for setting up just about every kind of hosted platform you could think of in their data centres. It should be safe to assume at this point that you’ve setup a Linode running Ubuntu 10.10 and you’ve been able to login to that server as root via the shell. Too much already? This tutorial is probably not for you. Maybe go play with your new Linode and go through the Linode Library to figure out basic shell commands before continuing with this guide.

For those still paying attention now would be a good time to configure your basic Ubuntu instance with some sensible defaults. This is where the Linode Library and the Linode Getting Started guide comes in dead handy – this System Admin basics guide is great for sorting things like your timezone and installing htop. Go do that first. DON’T install any web servers just yet. We’ll get to that shortly.

All done? A quick checklist of the most important things should have just done:

If you do have any problems be sure to hop on over to the Linode forums. There are some super smart really helpful people over there.
Let’s move on.

Web Server Setup

Why nginx?

Simply put – nginx rocks! Don’t get me wrong – I still love Apache. It’s been around forever and is still by far the most popular web server run WordPress. But Apache is a victim of it’s own success. Most common Apache deployments come with a LOT of baggage. Baggage that tends to not really matter for low traffic websites, but once you start to build your traffic levels it quickly becomes a bit of a dog unless you really understand how to tune it properly. It doesn’t help that the default Apache configuration is entirely inappropriate for modern VPS environments. nginx is a lightweight traffic handling powerhouse that is blisteringly fast with minimal configuration. The real beauty of nginx is just how much traffic you can throw at it on very modest low powered VPS machines. If you still don’t believe nginx is a viable alternative to Apache or Lightspeed or other new kids on the block like Cherokee, just take a look under the hood of WordPress.com (currently the 18th busiest website in the whole fricking world!) – which web server powers it? nginx. ‘Nuff said.

Install nginx

You’ll find a ton of tutorials online about how to install nginx. Personally, I’ve found this process as outlined on the nginx wiki is the most straightforward one. You’ll find lots of other tutorials suggesting installing it from source but to be honest with you if you’re not 100% comfortable with install packages from source already – now is not the time to start. The process I’ve described below will take you 5 minutes to complete and it won’t install a version of nginx that is horribly outdated (which the default ubuntu 10.10 packages are). We’ll also add a little twist to the install process which will become critical in a later part of the guide.

NOTE: If you attempt the nginx Ubuntu install commands, you’ll probably find that Ubuntu tells you that add-apt-repository is not installed. Go ahead and install that first by running:

apt-get install python-software-properties

After you have the python properties installed, go ahead and run the following:

sudo -s
add-apt-repository ppa:nginx/$nginx
apt-get update

Now normally, you would then simply run apt-get install nginx to complete the process. Well here is the little twist. We’re going to install a little gem which will make your life a little bit easier later on when we get to configuring caching servers. We’re going to install the nginx-extras PPA which contains the latest and greatest stable full version of the nginx web server and a whole load of other nginx extras and modules – (the full list of nginx extras contained in this package are here) meaning we won’t need to compile nginx from source later to add in common extras like HTTPRealIPModule (which will be very useful later when we configure our caching server Varnish). Hat tip to melon in the Linode forums.

So go ahead and install nginx with the extra goodies as follows:

apt-get install nginx-extras
service nginx restart

Assuming you’ve a nice clean install process you should now be able to fire up your browser and enter your machine IP/hostname and see a nice big “Welcome to nginx!” welcome message. Congrats you’re now up and running with the world’s fastest web server!

On Ubuntu, the following a basic nginx commands that you’ll get to know pretty quickly:

service nginx stop – Stop web server
service nginx start – Start web server
service nginx restart – well I think you’re getting the idea by now!
service nginx status

Install PHP

Next up is PHP. Again this is pretty simple. We’re going to install PHP-FPM (FastCGI Process Manager) instead of your vanilla PHP version. PHP-FPM is an alternative FastCGI implementation designed specifically to cater for websites with high volumes of traffic where granular control over process management becomes essential.

First off, we’re going to install a nice of valuable PHP modules during the main install process – PHP-FPM throws a tantrum on Maverick about a missing web root folder. It looks for a web root folder in /var/www/ (which Apache would normally create). To avoid seeing the error during the php install process, go ahead and create this directory:

 mkdir /var/www
 chown www-data:www-data /var/www

Now go ahead with the PHP install process:

 apt-get install php5-fpm php5-cgi php5-common php5-suhosin php-apc php5-mysql php5-dev php5-curl php5-gd php5-imagick php5-mcrypt php5-snmp

This will take a few minutes to run given the number of packages we’re installing in one go. Go read twitter for a few minutes.

Once the install is done, give everything a quick recycle to make sure all new settings kick in:

 service php5-fpm restart
 service nginx restart

You may get this error during the PHP restart:

[WARNING] [pool www] pm.start_servers is not set. It’s been set to 20.

To supress this warning, we’ll go ahead and set a number of processes for php to start with in  /etc/php5/fpm/pool.d/www.conf

pm = static
pm.max_children = 5

Don’t worry too much right now about what is going here. In a nutshell we’re setting a sensible default for how many php processes will be created on your small VPS. In the future as you become more familiar with how PHP-FPM processes are managed you can tweak this a lot more to tune it for your specific environment.

Go ahead and restart PHP-FPM (no need to restart nginx).

PHP5-FPM Hello World Test

Then to make sure everything is working as expected, we’ll create a simple “Hello World” php page to ensure nginx is communicating properly with your PHP Backend. The default nginx web root is in /usr/share/nginx/www

cd /usr/share/nginx/www
 touch hello.php
 nano hello.php
 <!--?php  phpinfo();  ?-->

Save the file (CTRL-X) and Y.

Before we load the page, there’s one more config change we need to make. We need to tell nginx to pass off any requests for files ending with *.php to be passed to the PHP-FPM backend. Thankfully nginx comes with some simple config rules which can just be uncommented to activate this immediately on the default web root.

cd /etc/nginx/sites-available/
 nano default

Scroll down and uncomment the following lines:

# pass the PHP scripts to FastCGI server listening on
 location ~ \.php$ {
 fastcgi_index index.php;
 include fastcgi_params;

Save the file and restart nginx.

Go to your browser and load http://myip/hello.php

You should see something like this:

Congratulations – you’ve just finished your basic nginx/php configuration!

We’ll be coming back to this in Part 3 when we start to setup new web roots for your main WordPress website and add in WordPress specific nginx config rules. For now though we’ll go ahead and get MySQL up and running.

Install MySQL

MySQL is very easy to get up and running on ubuntu. For this part of the guide, we’re essentially following this Linode guide.

apt-get install mysql-server mysql-client

Follow the on screen instructions (I think it’s just setting the root password from memory!)

Once the installer is done, run the MySQL hardening process to secure your installation:


It’s safe to assume you should follow the default prompts suggested on screen.

The Linode guide suggests further tweaks to the MySQL configuration file (my.cnf) to further tune MySQL for optimal performance in a low memory environment. These are definitely worth implementing.

Setup test database and user

Ok so now we’ve got MySQL up and running, let’s go ahead and test everything to ensure it all works as expected.

mysql -u root -p

Enter your MySQL root password (not your shell root password) when prompted:

create database testdb;
 grant all on testdb.* to 'testusr' identified by 'strongpassword';

(NOTE: don’t forget the dot after your database name – that’s not a typo.)

Assuming all goes well that pretty much confirms MySQL is installed and running correctly. Let’s setup phpMyAdmin to make db management a little easier!

Install phpMyAdmin

This one is pretty straightforward too.

 apt-get install phpmyadmin

You will be prompted to select a web server. Straight away you’ll notice there’s no nginx option! Never fear it’s safe to select Apache 🙂

Again follow the on screen instructions to complete the install.
Once the install is done we need to tell nginx about it. If you wished you could setup a dedicated virtual host like dbmgmt.mydomain.com but I prefer to run phpMyAdmin off my IP on a separate port which is a bit more secure and can be locked down at the firewall.

Let’s go ahead and do that now.
This is our first foray into nginx vhost setup aswell!
cd /etc/nginx/sites-available
touch phpmyadmin
nano phpmyadmin

Enter the following nginx config:

NOTE: Make sure you set correct values for:

listen: This should be the port you want to run the virtual host off – I’ve chosen 8084
server_name: This should be your public IP address. Everything else in the file should be fine as is.

 server {
listen   8084;
 server_name XX.XX.XX.XX;
access_log /var/log/nginx/localhost.access.log;
root   /usr/share/phpmyadmin;
 index  index.php;
location / {
 try_files $uri $uri/ @phpmyadmin;
location @phpmyadmin {
 fastcgi_param SCRIPT_FILENAME /usr/share/phpmyadmin/index.php;
 include /etc/nginx/fastcgi_params;
 fastcgi_param SCRIPT_NAME /index.php;
# pass the PHP scripts to FastCGI server listening on
 location ~ \.php$ {
 fastcgi_index  index.php;
 fastcgi_param  SCRIPT_FILENAME  /usr/share/phpmyadmin$fastcgi_script_name;
 include        fastcgi_params;

UPDATE: Once you save this file, you’ll also need to enable this new site. Thanks to Alex for spotting this omission!

ln -s /etc/nginx/sites-available/phpmyadmin /etc/nginx/sites-enabled/phpmyadmin

Save the file and restart nginx.

Go to http://myip:8084/

You should see the phpMyAdmin login screen. Go ahead and login with the root details creating during the install. And that’s phpMyAdmin installed!

Ok that’s it for Part 2 folks. We’ve covered a lot of ground today but we’re still only scratching the surface of our WordPress High Performance Guide. Part 3 will take us the full WordPress installation and configuration process for the nginx environment we have setup. Until next time!

In defense of themeforest

17 October 2011 comment icon0 | Categories: development, opinion

I’ve been keeping a close eye on a number of different theme marketplaces recently. As far as WordPress is concerned, to me there are 2 main marketplaces in the ecosystem today. The first and the biggest by some distance in my opinion is the juggernaut that is themeforest (part of envato). The second is the newer kid on the block Mojo Themes (disclosure: I currently sell themes with Mojo Themes). This isn’t a themeforest vs. Mojo Themes post – it wouldn’t be appropriate for me as I’m currently not a theme seller on themeforest. This is purely a post to dispel some common misconceptions about the quality of product available in said marketplaces.

If it was once true that many themes on the leading theme marketplaces were substandard – this is certainly not the case any more. In fact, it is my opinion that the quality of work being produced and sold on the marketplaces in the past few months is in many cases knocking the socks off many of the leading independent WordPress theme shops. This certainly wasn’t the case a year ago.

Here are some quick samples to wet your theme tastebuds.

Flashlight is simply amazing. It’s sometimes easy for those of us who spend a lot of time around WordPress just how much innovation is going on in the theme development space at the moment. There was a time not long ago where some of the world’s top web agencies would have struggled to implement a design executed with the imagination and creativity applied in themes like Flashlight – and that is even before considering putting a CMS behind it! Now you can spend 35 bucks and you’re immediately transforming your WordPress experience – easy to forget just how far WordPress has come!

Now this is usually the point where many marketplace detractors chime in with many of the following points:

  • marketplace themes are usually coded very poorly
  • you can never get support for themes purchased in marketplaces
  • themes are never updated/patched in marketplaces

MarketPlace code quality

I’ve checked out the code underneath a lot of the best selling themes on themeforest – while I wouldn’t agree with all the approaches taken by some theme authors to achieve some functionality (like excessive use of shortcodes – grrr!) the one thing you can say is that a LOT of time and care has gone into delivering a highly polished product. If you don’t believe me go grab a copy of any of the top selling themes on themeforest or Mojo Themes. It’s a great learning experience. Also Mojo Themes insist that all themes pass the auto checks in the theme check plugin during the approval process. Themeforest operate extremely strict approval processes now and a lot of decent looking themes get rejected on their first pass – a lot of times based initially on aesthetics but also based on pretty rigorous theme code reviews. See a great flowchart about Themeforest’s approval process. Themeforest and Mojo Themes also insist on theme documentation being provided for every theme.

MarketPlace Theme Support

This is also a bit of a misnomer. The top sellers on the theme marketplaces all provide some form of support – in many cases at a level that matches many of the theme membership only support forums charging monthly subs fees. The reality is that top theme sellers realise that strong support is necessary for survival in an incredibly competitive environment. Also, the general quality of documentation available has improved significantly in the past 12 months.

I challenge those who still hold a poor opinion of theme marketplaces to reconsider this opinion. The WordPress theme ecosystem is rapidly evolving. Envato and Mojo Themes have both done an excellent job in making sure that their marketplaces offer a top quality product to their end users. As a long time theme developer who is only now dipping their toes in selling themes via the marketplaces, let me assure you that these marketplaces are not the free for all they might once have been and things are now very different. Standards are rightly being enforced and this is good news for WordPress theme consumers everywhere.

Rooling: a new Commercial WordPress theme for law firms

10 October 2011 comment icon0 | Categories: commercial themes, featured, theme news

So this one has been a while coming. Today I shipped Rooling – a new commercial WordPress theme designed specifically for lawyers, law firms, attorneys, Lionel Hutz wannabes – you get the idea. I’ve spent the past few months building a pretty decent framework for my own custom WordPress themes. Nothing groundbreaking really, just pulling together lots of little code snippets from around the WordPress ecosystem. I’ve got it to a point that I’m very happy with the mechanics of how I put together themes and ensuring the code quality is on a par with the most well known theme shops out there. I intend following up with some further posts in the coming days about how Rooling was built so for now, on with the skinny on the theme itself!

About Rooling

I created the Rooling WordPress theme because there are just not enough WordPress themes designed specifically for law firms and businesses with a focus on legal services. Rooling is designed from the ground up to be perfect for any website that operates in the legal industry. Whether it’s a massive law firm or a small private firm, Rooling’s sharp and professional design will make your business stand out from the crowd. While optimized for corporate/legal firms, Rooling is a great theme for any corporate business website.

Key Theme Features at a glance

Rooling ticks all the boxes for what you expect from a modern best in class WordPress theme:

  • State of the art HTML5/CSS3 web standards including the HTML5 Boilerplate.
  • jQuery Homepage Slider – proudly promote unique selling points of your business right on the homepage.
  • Featured Content Widget – easy to use widget that let’s you feature key pages on your website.
  • Homepage Announcements Theme Option – have you got something important to flag to your customers and clients? Our Announcements theme option lets you quickly add a prominent message on your homepage.
  • Social Media Icons – display and link to your Facebook, Twitter and RSS feed from your homepage.
  • Fully widgetized Homepage – with 10 widget areas you can completely customize your homepage layout without any coding skills.
  • 4 Custom Widgets.
    • Featured Content Widget.
    • Latest Blog Posts Widget.
    • Latest Tweets.
    • Showcase/Portfolio Widget.
  • Showcase/Portfolio Custom Posts.
    • Showcase your proudest achievements using the Showcase/Portolio Custom Post type.
    • jQuery optimised Showcase landing page.
    • Display recent Showcase items on your homepage with the Latest Showcase/Portfolio widget.
  • Powerful unbranded Theme Admin Options Panel.
    • Tweak the look and feel of your website without any coding skills using the easy to use Theme Admin Options panel.
    • Switch on/off website logo and taglines.
    • Select different theme color schemes.
    • Switch on/off Homepage Announcements and Social Media icons.
  • 10 Page Templates.
  • Fully integrated with WordPress 3.0+ Menus.
  • jQuery sub menu dropdowns.
  • Optional sub (and sub sub) menus can be displayed on left/right column of pages.
  • Support for Breadcrumb NavXT plugin built-in!
  • Layered Fireworks PNG included.
  • Compliant in all major modern browsers.
  • Includes detailed step by step setup guide + documentation!

Find out more about the Rooling WordPress theme

WooCommerce launched by WooThemes

27 September 2011 comment icon0 | Categories: plugins, theme news

Wow a whole month with no posts! Sorry about that folks – you might think this means I’ve been hiding under a rock and not keeping up with whats going on with WordPress these days. Far from it – I’m still knee deep trying to ship a new WordPress theme which is taking forever with other customer commitments so blogging time has been the poor cousin of the family for a few weeks – all that should change real soon.

In the meantime WooThemes dropped a major announcement today which is worthy of a quick post. WooCommerce has just been released. Make no mistake – this is a big big day for WooThemes. The full release details can be found on the WooThemes blog post covering the release.

You might remember that WooThemes caused a lot of controversy back in August when some of the team behind Jigoshop joined WooThemes to work on a fork of Jigoshop which is what we see being released today as WooCommerce. In the interim Jigoshop has continued to grow and is very much alive and kicking as a project and is rapidly evolving into a fantastic eCommerce platform for WordPress.

So what’s changed since the fork?

Unfortunately I’ve not had a chance to look under the hood of the code just yet – I’m dying to but it will be a while yet before I have the time. In the meantime, the announcement highlights the following:

Since forking the previous Jigoshop codebase, we’ve made these notable additions / tweaks for the release of WooCommerce V1:

  • A revamped admin interface, which is more native to the WordPress dashboard & thus more familiar to the average WordPress user.
  • Improved reporting, with more stats, graphs and built-in support for Google Analytics e-commerce (goal) tracking.
  • New front-end features, including catalog sorting and built-in up-sells / cross-sells.
  • Revised coupon system complete with coupon expiry dates and usage limits.
  • Built-in HTML email templates.
  • Improved order management.
  • Simplified product data entry plus better product sorting / duplication within the WP dashboard.

Woo Community reaction

The blog post has over 70 comments as of writing and one thing is coming through very clearly from a lot of the comments posted to date. Some people are not happy at all about the pricing model being applied to themes and extensions for WooCommerce. First of all the core platform itself is free. Being a fork of Jigoshop, the Woo guys made it clear that the fork would be available via github for everyone to get their hands on – including Jigoshop should they wish to port changes back into their fork – true to their word – the WooCommerce github is up and running. But WooThemes have upset a lot of their club subscribers by not giving them access to WooCommerce extensions and themes. This is understandable given the marketing messages communicated to date for club subscriptions was about having access to ALL themes. Clearly WooCommerce is a completely different animal from a regular theme but I think WooThemes could of spent a bit more time planning how this new product (and it is a product) was brought to the market.  For example, the Theme Club page still refers to obtaining access to ALL themes in their collection. This is a little bit misleading. I’m sure Adii and the guys will sort this out over the coming days but a bit more time planning all this might have negated a lot of early confusion and frustration for their existing club members. It’s a bit of shame really given this is a pretty big deal for WooThemes. WooCommerce has been on the cards for quite a while and I think this is a big play for WooThemes. The potential user base for WooCommerce is big – very big. Personally I think WooCommerce should be spun off completely from the core Woothemes website. I think it does warrant a separate “club” for want of a better term and keeping it half under the WooThemes brand is only causing confusion and pissing off WooThemes customers.
All that said, I’m really looking forward to playing with WooCommerce and it’s fantastic to have so much innovation going on in the WordPress/eCommerce ecosystem at the moment. Adii and the rest of the Woo team will also be very concerned about any negative customer reaction (Adii has already responded to pricing model complaints) and I’m sure be swift to react and evolve the WooCommerce pricing model in the coming weeks where necessary.

Hello WooCommerce, Bye bye Jigoshop?

25 August 2011 comment icon17 | Categories: opinion, plugins, theme news

Hmm…this is an interesting one.  WooThemes have pulled off a pretty spectacular move today and forked Jigoshop (our favourite new WordPress eCommerce plugin) into WooCommerce, which will replace it’s heretofore unsuccessful attempts at creating a WooCommerce platform off their own bat. The possibly bigger news is not only have they forked Jigoshop but they’ve brought in the 2 main guys responsible for making it in the first place – Jay Koster & Mike Jolley from Jigowatt. This move by WooThemes raises all sorts of emotions.

Has this move effectively killed Jigoshop?

I’m sure Jigowatt will not be too pleased. In one swoop, WooThemes have forked their project and nabbed the 2 guys responsible for most of the work that has gone into it to date. Jigoshop has been to date a rip roaring success and is by miles the most polished eCommerce plugin for WordPress. But best of all for the WordPress ecosystem it was truly open source and free to download with Jigoshop looking to build a strong community around the core product. It looked to be on to a winner in a big way. I don’t care what anyone says, no one to date has really cracked eCommerce within WordPress and Jigoshop looked like a good bet to do so. WooThemes clearly realised this a long time ago too and have had ambitions to crack this too with previous attempts at making WooCommerce. Woo clearly has a massive community in it’s own right and is a firm proponent of the GPL – but you can’t help but feel the WordPress Community has lost something today. Let’s face it, GPL or no GPL, WooCommerce is going to be a commercial plugin. Don’t get me wrong, I’m not someone who believes that developers should invest their time and effort to create wonderful products for no financial return – quite the opposite actually. What I did/do love about Jigoshop was their approach to developing what one would hope to be a sustainable business model by offering additional commercial extensions and themes around a really solid core free product. I think they are really on to something with this but it could now be stillborn with the departure of the main minds behind the project. And that would be to the detriment of community and ecosystem as a whole. I would love to see WooThemes pick up the challenge from Jigoshop and pursue a similar approach but I don’t think it will happen. Maybe I’ll be proved wrong.

The crossroads of ethics, morals and capitalism?

As I’ve already alluded to, I have mixed emotions on this move. On one hand it’s a stellar bit of business from Adii and the Woothemes crew. I’m sure WooCommerce will take off like a rocket. More power to them – heck I’ll be using it if it turns out to be a more compelling offering than Jigoshop. I’m also glad that Mike & Jay get to keep working on developing and enhancing the plugin albeit under a different name. On the other hand, if you’re Jigowatt, you’re pretty pissed right about now. Clearly a lot of time has been invested into Jigoshop. While forking projects is at the heart of what the GPL is about, I firmly believe that the GPL can be easily abused and taken advantage of. The worst thing that could happen now would be for development of Jigoshop to stagnate and for WooCommerce to become a ‘closed’ platform. While the GPL will ensure that can never technically happen it doesn’t mean the Woo guys can throw a few barriers in the way. Heck just look at Google and Android. Yeah Android is open source right? It might be in name but in reality – it’s still a pretty closed platform. A comment by Adii on the announcement post goes a long way to easing my initial fears about the future of WooCommerce/Jigoshop. It would seem that a collaboration on a single codebase was proposed at one stage (which would be what I consider to be the overall scenario for the community as a whole) but this didn’t work out. Adii also states that Jigoshop are free to backport any enhancements that come about from WooCommerce. The fact that efforts were made to work on a single codebase must be applauded and recognised. Not everyone is happy with this announcement. I will be very interested to hear what the remaining Jigoshop team plan to do going forward. Maybe a bit of healthy competition between the two forks will ultimately lead to better products overall and more choice for the community.

One thing is for sure. We all want to see a rock solid, slick and professional eCommerce platform emerge for WordPress. This is a real problem that needs solving. I firmly believe that whatever platform that emerges as the plugin of choice will have to embody the core values of the WordPress community to be a long term success.