WordPress Defaults

A Default Kinda Guy – Installing TwentySixteen

This year’s WordPress release schedule puts the next major release around the end of the year. In that release will come the new default theme – TwentySixteen. The development version is up on GitHub for you to test and contribute if your inclined.

On this site I’ve been a default theme user. When I started I used TwentyFifteen and wrote a couple of thoughts. Now that the development version of next years default is available I couldn’t resist giving it a try.

There’s a few ways that you could get this installed on your site. The easiest may be to download the zip from Github and upload it to your site. Alternatively you could clone it to your site with git clone or use WP-CLI to install and activate it for you.

Cloning The Theme into Your Site

Navigate to the themes directory on your site – /wp-content/themes/ – and run the clone command:

git clone

Updating the theme as it develops is easy by running git pull from the theme directory.

Installing a theme From Github via WP-CLI

From anywhere in the WordPress installation you can run the theme install command, pass it a theme-slug or a url to a zip file and it’ll install it in the correct location.

wp theme install

add --activate at the end of the command to activate it right away and --force if you want to suppress any warnings about overwrites.

Note: If you install the theme like this it’ll be located in the twentysixteen-master folder instaed of the twentysixteen folder.

Contributing to the Next Default Theme

You can contribute to the theme and shape its development moving forward by creating issues and pull requests in the GitHub repo.

You will need to know a little bit about using git to contribute but it’s nothing really complicated. You should be able to find out everything you need to know by taking a look at my WordPress and Git Workflow post.

If you’re interested in contributing you should also check out the file in the repo.

Development Tools

Automate All The things With Grunt

I’ve recently become a fan of Grunt. It’s a JavaScript task runner that get installed within a project to handle jobs for the project. For me it’s extremely useful for a whole range of things – even in just a short 2 weeks I’ve got so much more value from using it than I ever expected.

If you’re a developer of any kind then Grunt is something that you could probably benefit from using. The reason? This is the reason they give on their homepage:

In one word: automation.

On it’s own Grunt doesn’t do a lot – it runs tasks but you need to define those tasks for it to be useful.

Tasks are defined by plugins installed alongside Grunt. There’s already thousands of plugins created that do many of the things that you might need (4,403 of them at time of writing). Many of them are officially maintained by the team at Grunt, so you can guarantee a decent level of support or documentation will be available.

Grunt for WordPress Development

I mostly work on WordPress projects. PHP, JavaScript, HTML and CSS is what I deal with daily. Grunt has MANY tasks available for working with those. There’s 2 specific things that are extremely useful.


Linting is the process of parsing your code and making sure it complies with a set of predefined rules. It can parse for errors as well as coding standards and all of the major code types used in WordPress can be linted with readily available tools.

Being notified of errors in code as they are introduced can save many hours of debugging.

Combine + Minify

Making sure you have comments in your files so you know what’s happening at a given point is good practice. It’s also good practice to serve optimized files to users – in as few requests and bytes as possible.

Combining your styles and scripts reduces the amount of requests needed and eliminates any overheads associated with additional requests. Minfying them as well will make sure you’re sending only the data that you need.

Making sure your images are optimized or compressed as well can save a lot of unnecessary transfer. You can have Grunt handle that for you too.

Watching for Changes

Since automation is the name of the game you can make use of the Watch task. It watches for changes to your files and when it detects them goes ahead and runs certain tasks. As a starting point watching your styles and scripts for changes then recompiling them could save you hours of time to spend on doing more useful things in your project.


Re-evaluating the Use of Certain Domains

I have many domain names. So do most other web developers. Some of them serve production sites, others are used for testing and some even get used just as placeholders. There’s even a few I just don’t use.

This domain was registered alongside the .com variant – where I run my main business. I’ve used it for all kinds of things over the space of several years but mostly it’s been a playspace.

I recently re-evaluated it’s use and decided it was a good place for a blog to live.I still use it for a few things but at the moment it’s the place where I keep this personal blog. I’m going to be doing that with a few of my domains and it’s going to result in a shake-up of the services I offer.

Firstly I’ll be taking a look at my hosting site and seeing what I can turn that into that’s more useful. Currently it’s the front-end for my managed hosting service but there has been a slow uptake in the offer and managing a growing cluster of servers, tracking what runs where and rejigging things as necessary has become a pain.

It often takes me more time to keep it running smoothly than I get paid for by the users.

In short – it was an idea I tested and it isn’t viable for 2 reasons. The traffic I send to it isn’t interested in managed hosting – they are technical enough to do that themselves. The pricing point is hard to compete with larger companies that offer ‘shared hosting’ because my target market can’t quite see the difference between shared and managed.

I’ll be shutting up shop on the hosting and using the domain for something different.

Similarly I’ve had another domain that I planned to use as a split testing/conversion optimization service. It never got anywhere because it evolved to the point where 2 server-side services I created for it continued to grow to the point where it would have been an inefficient million lines of code. I vastly underestimated what would be needed to make it work like I pictured so the project – while it’s still been worked on in development – is stagnant till I finish. Eventually this service will exist but it’s a long time off.

Also I’ve tested the water with split testing content on my site and there’s been some interest but not as much as I’d like. That means that to get traffic to the service I’d need to invest a lot more time in research and content creation before I could get enough people who would be interested. That’s time that I don’t currently have considering that my family is about to grow and I’ll have a new baby to look after.

I’m still not sure what I’ll be doing with the repurposed domains but I suspect that I’ll narrow the audience I was targeting and focus purely on the audience I do have traffic from – other web developers like me.


IWC – Honeypot comment spam filter

So I see spam bots buzzing around my sites all the time. There’s one particular site that gets hit more than others and it’s causing problems.

Every now and then a spambot tries to post hundreds or thousands of comments one street the other and it ties up server resources. That shows the whole server down and eventually if it continues can cause crashes and other problems – like memory exhaustion.

You can clearly see the offending spam bots in your access logs because you’ll see several lines that contain:

POST /xmlrpc.php

Note: the IP in the line above is from a real spambot that hit my site. It got past most of the protection systems and in the end fail2ban had to step in and ban the offending IP.

I have other systems in place to restart on crash, to rate limit spam bots and to eventually block them. The problem is that they’re not working 100% effectively even when properly configured.

The new idea is to prevent then being able to submit the comment form in the first place.

A honeypot might not be the best solution but it will defiantly help to stop automated submissions so it’s a start.


Chatting About Open Source Software

I’m of the opinion that open source software is better software. I know that’s a broad statement and I suppose it’s not entirely factual – but that’s my opinion. It’s free to use, modify or sell and anyone can browse the code to see how it works for whatever purpose.

Open source software is found everywhere. WordPress (and all the themes and plugins in the repo) is open source under the GPLv2 or greater licence and my entire server stack uses open source software to power it.

In general the entire web relies heavily on open source software to make it work. The most common web server softwares (Apache and NGINX) are open source and another great example is how WordPress powers about 23% of all websites online. Google uses (and creates) open source software for many of it’s systems and even Facebook created – and then open sourced – the server software they use.

It’s crazy how much the web relies on open source to work. It’s part of the very heart of how we make and deliver what we build. I think that every web developer should take a few minutes every now and then to honestly consider if what they are doing could be contributed back to the community.

If it could be contributed back that doesn’t necessarily mean that it should be but it is worth considering.

With open source software it can be very easy for you to contribute to projects or make new ones. Many projects are hosted at GitHub – which is a free to use code and project hosting site that uses the Git software to manage repositories of code and provide distributed and centralized management capabilities.

GitHub is by far the largest open source code hosting site of all time so learning a bit about using Git is probably in your best interest if you use, or want to contribute to, open source projects.

With Git the learning curve feels very steep but it quickly levels off to a comfortable progression only needing to learn more if you want to have more power over your repository.

Since I’m a big user of open source software and I feel strongly about it from this moment onwards I’m committing myself to finding at least 1 hour in my week so I can work on open source projects.

I will be contributing to existing projects as well as releasing some of my own personal ones for anyone to use. I actually started to work on making a split testing plugin for WordPress a long time ago and never finished it so I’ve been working a bit on that. I recently pushed the MVTS plugin to GitHub if you’re interested.

WordPress Security

Recent WordPress Security Issues – Steps to Avoid Them & How to Fix Them

Recently there’s been a number of high profile WordPress security issues which has led to a massive increase in compromised sites. It’s worth noting that none of the security concerns were to anything to do with WordPress core – all of the issues found were inside of some commonly used plugins.

Some of the Affected Plugins

All of these plugins have several thousand active installs, one of them even reaches well beyond the million mark.

This post contains a list of some well used plugins that had issues in the last few months. Most of these are very recent but there’s one that’s been an issue for over half a year and many sites are still affected.

  • Slider Revolution
  • Gravity Forms
  • WordPress SEO by Yoast
  • FancyBox for WordPress
  • WPML
  • WooCommerse
  • MainWP Child
  • Pods Framework

Slider Revolution and Gravity Forms were 2 premium plugins that were discovered to have vulnerabilities. These 2 plugins are ones that are loved by both end-users and developers so they both have a massive user base.

Gravity Forms is acclaimed to be the best drag-and-drop form plugin because it’s so easy to use, accessible and hookable/customizable where needed. I use it on all of my sites. The Slider Revolution plugin was distributed thousands of times with themes through Envato – it’s also available standalone. 

Gravity Forms had an upload issue that allowed hackers to post directly to it and upload a file so long as the file didn’t end directly with an excluded file extension (so .php was excluded but .php.x would not be). Getting the files onto the server is more than half the battle in situations like this.

The issue was fixed with the release of version 1.9.3.

The Slider Revolution issue allowed hackers to download a full copy of the wp-config.php file (or any other file they wanted) from the server and look at it to obtain database credentials and compromise a site directly via the DB however they wanted. Anything that modifies the database is a nightmare to track down.


I still see requests to my sites using urls like the one above as people still scan the web looking for vulnerable sites.

This issue was patched in February however it was disclosed and exploited for a long time before it was patched. Versions 4.0.2 or above are no longer vulnerable.

Part of the issue with this particular plugin is that it was bundled with many themes and because it’s not hosted by there are no automatic update notifications. Many site owners are not aware that there’s even a problem.

Yoast’s WordPress SEO plugin is a hugely popular plugin – a freely available one through the repo. I install it on all of my sites, all my clients sites and recommend it as a must to anyone else with a self-hosted WordPress site.

A vulnerability was found that would potentially allow a hacker to execute a blind SQL injection attack on the site and compromise the site through executing commands on the database.

Since the plugin is entirely open source and hosted on GitHub this was patched and released quickly to everyone affected. There are literally millions of sites using this plugin so pushed an automatic update out for it.

If you’re on version 1.7.4 or higher your site is no longer vulnerable.

The FancyBox for WordPress plugin took a serious hit with a zero day vulnerability used to upload and execute code on the site’s hosting server.

Updating to version 3.0.4 or higher solves the issue.

Another plugin that had several serious vulnerabilities was the WPML plugin. Exploiting it allowed SQL injection, post deletions, reflected XSS and unauthenticated admin access to certain functions.

These issues were fixed with version 3.1.9 – if you’re on that version or higher your protected.

WooCommerse had a flaw that opened an SQL injection vulnerability. It was found by a researcher at WordFence and was fixed in a matter of hours by the development team at WooThemes. That’s exactly how it should be done.

The MainWP Child WordPress plugin has over 90 thousand installs and had an issue that would allow a hacker to login to a vulnerable site bypassing the WordPress password authentication mechanism entirely and get access to the dashboard.

Pods Framework proactively took the opportunity to do a security review of the plugin following the discovery of the blind SQL injection vulnerability in Yoast’s SEO plugin. They discovered a similar issue and quickly pushed an update.

Versions was released with a security fix however it’s extremely refreshing to see that even older versions of the plugin can be patched with download packs available on the resources page of the plugin site.

Ways to Find out if your site is Compromised

There are a few online tools that can run world facing scans of your site to detect malware. I routinely turn to Securi to run quick external site scans. There’s also plugins to check your site’s filesystem for problems. I suggest you do use both of them as one of them is likely to find an issue there are any.

Sometimes (particularly with world facing scans) there will be things missed. If initial scans fail to flag anything and your still not convinced the site is clean then the hacker has probably done a good job at hiding their presence. Hackers tend to be quite good at hiding things because the longer they stay hidden the longer they can make use of their victims.

A clever hacker will use several methods to prevent detection. The most common would be encrypted (or obfuscuted) code. With anything world facing there’s generally a referror and user agent check that happens somewhere too which helps prevent world facing scans detecting it.

With referror/user agent checking a hacker can hide from a site owner. Owners will almost always arrive on their site via directly typing the url – if a hacker checks referrer (or logged in status) and only outputs to those people who arrive with a referrer from off-site then the owner may never see it.

Similarly if it checks the user agent for something that is obviously a bot (say for example GoogleBot) then that bot may never know the site is infected. In the case hiding from GoogleBot they can prevent search engines from showing a safe browsing warning – keeping search engines sending traffic that can be exploited.

One way to try and make sure that any injected content will show for you when you suspect that a site might be compromised is to arrive on your site exactly how ordinary users would. That might be through a link on another site but probably through a search engine.

Make sure you’re logged out of your site and then find it through a search engine. Visit the site through several different links (or search terms) and check the page for any injected content (particularly links that shouldn’t be there and javascipt that is included). If the search engine has found a problem then you’ll probably get a warning before visiting the site if not you may be able to find something that has been injected.

What to do About the Issues & How to Avoid Them

All of the plugins I mentioned here are actively developed, maintained and used throughout the WordPress community. When vulnerabilities are discovered they are generally patched quite quickly.

Fixes can be available for users within hours – and in the case of plugins available in the plugin repo they can automatically be pushed out to everyone affected when the situation is dire enough – like was done with the recent WordPress SEO plugin issue.

You should regularly check for updates and run any on your site that are available. That’s the best protection against known vulnerabilities.

In the case of zero day vulnerabilities (which are vulnerabilities exploited before they are publicly disclosed and/or before the developer knows about them) there isn’t a sure fire defence. The best you can do is monitor for suspicious activities on your site, check for anything unusual in your server logs and definetly be vigilant with checking and backing up.

Note that even themes and plugins that aren’t active can still be used to find a vulnerability because in some situations hackers can request or POST to them directly. Either remove unused ones or keep them updated.

What To Do With A Compromised Site

Because of vulnerabilities like these lots of sites are being targeted and used for a number of things from spreading malware and redirects to pharma-hack style links to spamming emails from the server. Once a site is compromised anything is pretty much fair game for a hacker.

First off I hope that you have a backup. This is the prime example of why backup plugins aren’t for backing up – they’re for restoring. If you have a backup the process of removing a hack and getting rid of the infection becomes much easier.

Deploy a backup from before the site was infected, update plugins and themes to hopefully close any vulnerabilities and change the database and user account passwords. You should be good to go providing the issue isn’t a zero day vulnerability.

If You Don’t Have A Recent Backup

If you don’t have a backup then I’d suggest you consider redeploying an old backup and rebuilding any content or changes to the site since that point.

If you really don’t have any option to deploy a backup then I suggest the best thing to do right away is change passwords for user accounts and the database – that may help reduce the chances of reinfection but it’s very likely that other backdoors have been installed.

Update WordPress, your themes & plugins then run a scan on your files for potentially malicious changes (modification time can be a clue here as to when the site was compromised).

Compare the files in your install against the original files for differences. There are plugins available that can do this for you with a detection mechanism used to spot things that might be malicious. WordFence is what I use as the first step of filesystem scanning. Make sure to deal with any issues that it shows, particularly when it tells you that core files or opensource themes/plugins have been modified – that’s a sure sign of something untoward.

The rest of the clean-up is going to differ depending on what kind of hack has been done to your site (and it will even differ from hacker to hacker). With a little luck the only infections will be inside executable files that are on the filesystem. The alternative is having to clean up check even files that aren’t normally executable (in particular the image files) and the database in addition to the filesystem.

Finding infections or backdoors inside the database is much more complicated and can be a far more daunting task. There’s even situations where there might be content added that does not execute or do anything malicious (such as links are injected into the content of pages or posts) that can be extremely hard to pinpoint and can have an awful knock-on effect to the site’s search rankings.

Making sure you get everything can be a major annoyance so once you’ve done all of that that you really need to monitor server logs for requests to unusual files, keep track of user logins and use an analytics package to track outbound clicks for anything suspicious. Monitor and block anything that looks even remotely suspicious.

At this point in time again it’s a good idea to change user and database passwords again – even if you done it before.

If You Can’t Clean Up The Site Yourself

You can contact a specialized security company to get help. My personal recommendation is Securi. They will clean up your site and offer protection from future attacks as part of a single subscription. They will even put your site behind their firewall and make sure all known attacks are blocked.

You can always contact me on this site and ask me for help with the clean-up or visit my main WordPress Development site and contact me there. I keep up-to-date with WordPress security news and have seen many different methods of infection that used dozens of different vulnerabilities to accomplish the hackers plan. I can probably spot patterns of infection quickly and help to deal with them ASAP.

Disclosure: The link to Securi is NOT an affiliate link and I will receive no compensation if you purchase through the link. I am not otherwise affiliated with Securi nor have I ever worked with or for them – I just think they are the best company to go to if your WordPress site needs cleanup or protection.


Varnish CDN

A while ago I wrote about an idea I’d had to make use of the Varnish forward caching proxy as a CDN. As it happens I’m not the only one who’s had the idea. There are companies offering Varnish as a CDN in SaaS (or IaaS) form out there but the prices I seen for the minimum offerings were definitely above the average WordPress site’s CDN requirements and budget.

If other companies are using a similar system and charging for it then it seems like the idea is a good one. As it happens it’s not all that hard to implement. In fact this very site is using Varnish as a CDN right now (inspect the page and look at one of the static resources in the network tab and you should see some Varnish Headers).

A bit of testing testing and configuration and 2 hours later it was ready to be put in production. A single DNS change to point it towards the Varnish Server and it was live.

Hosting & Servers

Using Varnish as a CDN

Update – 22/02/15: This site now uses a Varnish Backed CDN. Turns out it was pretty strait forward to implement 🙂

Varnish is a front-end caching proxy that serves only static content. The way it works is not too far removed from how the top level server operations work with an origin-pull CDN.

A CDN server receives a request for a static file and it delivers it. If the file us on hand then it sends it, if it isn’t available then it pulls the file from the origin and serves that while storing the file it in it’s cache. That’s basically what Varnish does as well.

I’ve had this idea for a while but only recently added a spare Varnish caching proxy to my cluster that I can use for testing.

The primary server will be the one rewriting urls to point to the CDN domains.

I already have a basic statics server set-up and running on a separate box from the main domain. It’s got a push-style propagation method, is configured with long expirations for files and doesn’t accept cookies.

That already gets populated with files so I’ll use that as the origin to keep the busy worker count on the main server down. I want about half the requests to hit the statics server and half to hit the varnish server. The main domain will be the one that handles rewriting to make that happen. I may use the W3 Total Cache plugin to do it through PHP or I might use mod_pagespeed domain sharding through Apache.

Using Pagespeed for it has it’s benefits but it would likely be a much simpler set-up process if done with W3 Total Cache.

The statics server already gets filled with it’s files (initially filled with rsync and kept up to date by W3 Total Cache – rsync runs on cron to make sure the files are always the latest versions). The Varnish server is not primed when it starts like the statics server is. We need to tell Varnish where it can find the files it doesn’t have.

To do that a backend is set that points to the statics server and Varnish gets told that when a request arrives on a specific domain and it doesn’t have the file in it’s cache then it should request from a specific server then cache it and serve from the cache next time.

Once things are set-up and the Varnish cache has been running for a while it’ll serve the function of being a 2nd node in the Content Delivery Network. The benefit of doing it this way is the ability to add extra nodes with ease and they can be put to use like I’ve described, behind load balancers or with GeoIP targeting all with minimal configuration.

That’s the basic idea in a nutshell. In reality things are a little more complicated. There’s on-the-fly optimizations done by the upstream server that get performed by mod_pagespeed and likely a need to create some kind of tweaked LRU eviction function for Varnish so that it’s cache doesn’t fill with multiple versions of the same file at various different optimization stages.

I’ll deal with the problems as I come across them but there’s no harm in testing the idea and building the system. The potential performance increase for a small single site is probably negligible but across an entire network of sites it’s likely to amount to a substantial performance improvement all round.


Programmers Effieciency

The efficiency that a programmer demonstrates in their code could be misconstrued in the real world as laziness.

As a programmer one of the things that we try to do is solve problems or perform a task in the most efficient way possible. In computing terms efficiency generally bogs down to doing it in less code or doing it with less CPU cycles.

Knowing how programmer efficiency could be perceived by other people I tend not to point out the basic though process I go through whenever my wife asks me to do something. It’s best if that never gets declared globaly lol.

“What’s the quickest way possible to get this done?”, “Do I need to do all of these steps or are some unnecessary?” or

  • “Would looping small sections of tasks instead of doing it one big block be better?”
  • It’s not lazyness it’s efficiency… at least that’s what I tell myself in my head.

    WordPress Defaults

    Trying The Twenty Fifteen Theme

    Well I’ve just started a brand new personal blog and thought: What better time to try out the next default theme?

    Twenty Fifteen is shipping with the beta version of 4.1 that you can try out by installing the beta plugin and setting it to bleeding edge nightlies.

    It’s clean… really clean… like nothing to it kind of clean. And that’s the main problem, there’s basically nothing to it. It demonstrates a really nice use of the WP Customizer – allowing you to select a colour scheme from their predefined palette (or tweak each colour to a custom value if you want), upload and use a custom header or background and set menus in 2 theme location.

    It only has the option of a right sidebar and both menus go in there along with the widgets you pick. The primary menu is basically like a blogroll from the old days.

    The second menu is a social icon menu. It will automatically parse what social network you have linked and display it as an appropriate icon – instead of a plain old text link. That’s a pretty cool feature, probably the coolest thing about the theme if you ask me, but I only use Twitter so it’s wasted on me.

    It’s built mobile first so it gets a +1 from me for working that way but design-wise it’s really not to my taste.

    All of the default post formats are enabled though so maybe that’s the way to go when it comes to customizing your site if you use Twenty Fifteen.

    In theory taking the default theme back to it’s blogging roots and making it über clean and streamlined is a great idea. In practice it appears not to work all that well.

    I’m crossing my fingers that a lot changes are made between now and the official release of the theme but I won’t hold my breath. There’s not been a great deal of talk on Make WordPress Core about changes and it’s slated for release with WP 4.1 in December – which doesn’t leave a lot of time to do much about it.

    Since Twenty Fifteen is scheduled for the end of 2014 maybe the could start working on Twenty Sixteen early next year… heck maybe I should hop on over there and push to try to have some input into what Twenty Sixteen should be like.