1. WordPress 4.9 is out! And it’s awesome!

WordPress 4.9 is out! And it’s awesome!

WordPress 4.9 is out and features some seriously awesome new features.

Improved theme customiser

Draft and schedule design customisations

The theme customiser now allows you to create draft customisations and schedule their publish date.

This can be done using by clicking on the ‘cog’ icon in the theme customiser.

After creating a draft customisation you can share it with others using a special preview link.

This allows you to collect feedback and collaborate without having to publish to manage a staging site for theme customisations.

This can be found by clicking on the ‘cog’ icon in the theme customiser.

Design locks

The customizer now places locks to ensure two administrators don’t edit a theme at the same time.

WordPress 4.9’s design lock feature works similar to post locking secures your draft design so that no one can make changes to it or erase all your hard work.

Save changes prompt

WordPress will now protect you from loosing unsaved changes. It does this by prompting when you navigate away from the customiser and allowing you to continue unsaved changes.

Better safer code editing

Syntax highlighting

WordPress now provides syntax highlighting when editing CSS, HTML and PHP files.

This will help you visually scan your code and spot errors.

The HTML widget is also supported, but the post editor ‘text’ mode isn’t yet.

Error checking

A massive amount of work has gone into protecting you from bad code editing in theme and plugin files. Whilst it’s never recommended to edit code from the wp-admin – this should protect you from creating the white screen of death.

There are four layers to this protections:

  1. syntax highlighting – allowing you to visually identify errors
  2. inline error highlighting – prompting you of errors before they’re committed
  3. on screen prompts before committing changes with errors
  4. improved handling of white screen of death events – the previous method was unreliable and has been massively reworked to reliably disable the theme or plugin if it an edit creates a white screen of death.

Code edit warning

The first time you go to edit code you’ll get a warning letting you know the risks.

New and improved widgets

The new gallery widget lets you easily display images with a few clicks of the mouse – no code required.

Add media

The text widget now allows you to add media.

Shortcode support

The text widget now supports shortcodes – a very longstanding request that we finally have.

You no longer need to manually add shortcode support to your plugins and themes.

Better theme installation

Reliable theme switching

Often when you change themes widgets and menus can go haywire – moving position or disabling.

WordPress 4.9 includes improvements which will make this more reliable – allowing you to switch between themes without having to reconfigure your widgets and menus each time.

Theme browser improvements

The customiser now allows you to browse, filter and preview themes from the WordPress theme directory.

Improved menu creation

Making menus has never been that straight forward – with many people muddling their way through their first menu using lots of trial and error.

The process now includes tips to help guide you through create a menu.



Last but not least there were improvements to notify and protect administrators of changes to account email addresses.

There were also a handful of security enhancements.

Are WordPress developers “real” developers?

When it comes to software development, WordPress developers get a bad rap.

Many won’t consider WordPress developers “real” developers – and there’s no wonder with “developer” being so overused in the WordPress ecosystem – resulting in no separation between those that can install plugins and themes and those that produce them.

But what does it mean to be a “real” developer and when does it apply to WordPress developers?

What is a developer?

In the software world, a developer is someone that can design, write, test and debug software.

A real developer will add value to a solution beyond installing and configuring – they can design and create solutions using code.

For websites, this can be in two parts –

  1. front-end developer – using code such as CSS, JavaScript, HTML that is ran on the client (browser) side
  2. back-end developer – using code such as PHP and MySQL that is ran on the server side

Some developers may focus on one part or both – but ultimately they use code.

A developer will understand (and hopefully use) coding standards, best practice and secure code.

What about those that don’t use code?

The WordPress ecosystem is broad – and just because someone doesn’t use code to work with WordPress doesn’t mean their work has any less value, but someone that does not code is not a “developer”.

Instead there are other terms that can more accurately describe their role such as:

Web designer

A web designer focuses on the look and feel of a website.

They will use their expertise in design principles, colour theory, usability to create the design of the website.

They may provide a PSD and/or specification of a design – and may work with a developer who will use code to create an installable WordPress theme.

WordPress implementer

A WordPress implementer will take the requirements for a website and use existing “off the shelf” software to create a website.

They assemble the website like pieces of a puzzle, may use some basic coding but ultimately rely on software created by developers.

Why does this matter?

When everyone calls themselves a developer it leaves a confusing sea of people with vastly different skills and little hope for clients to find the right person for the job.

It agitates the ecosystem – if clients end up with someone that isn’t capable of doing the work it makes the WordPress community and product look bad.

So how do you identify an actual WordPress developer?

Without any official  WordPress certification you need to rely on a portfolio of past and present work – for example websites, themes and plugins.

If they have work in the WordPress plugin and theme directories? Check the review and support threads – how do they respond?

If you can, make contact with previous clients and ask them about their experience with the developer – both in the implementation and ongoing support.

WordPress Gutenberg – what happens when developers go wild

Since early 2017 WordPress developers have been working on a new content editor for WordPress – code name  “Gutenberg”.

The intent is to replace the current content editor, TinyMCE, but for the meanwhile Gutenberg is a plugin in it’s beta development phase.

Gutenberg is attempting to completely reinvent how editors interact with content – most significantly:

  1. separating the parts of content into “blocks” – for example, paragraphs, lists and images will all be separate blocks. A concept that has remained in desktop word processors, such as Microsoft Word, since their invention
  2. providing a minimalist interface which only provides buttons contextually when they can be used.

The good

I  can understand the desire to be innovative and provide improvements – in fact, I  applaud it.

The current editor, TinyMCE, was introduced to WordPress in version 2.0 in 26 December 2005.

Since then it’s seen several updates but has remained a traditional WYSIWYG content editor – one large block for all content, buttons at the top, ‘visual’ and ‘code’ mode etc.

During the same time other areas of WordPress have changed significantly – leaving the perception that the content editing experience also needs a revamp.

I’m not convinced that a revamp of this scale is necessary – specifically separating content into to blocks. 

But to be fair I do see one benefit – it will pave the way for developers to provide “block plugins”, much like WordPress widgets but for content. For example, you could create a button or an AdSense unit exactly where you want in the content with a few clicks of the mouse.

The bad

Change can be good – but it needs to be tested and refined based on feedback.

I’m concerned that Gutenberg went too far before user testing and now even after user testing is revealing its faults the ship has already sail.

Developers tend to have a “build to improve” mindset – an unwillingness, or inability to accept some features are not good and will focus on building on the feature when sometimes you just need to accept that some faults are not fixable, or at least not with code.

Just take a look at the Gutenberg reviews – at the time of writing there are 38 1 star reviews, compared to 15 5 star reviews.

Will the developers listen to this feedback?  Will they refocus on the usability and functionality shortfalls?  Or will they just focus on the technical implementation?

The ugly

The truth is – the Gutenberg plugin leaves a lot of room for improvement.

By removing all the traditional editor buttons and trying to make a minimalist design the usefulness and ease of use has been drastically reduced.

Extra clicks

Using Gutenberg I found myself to click, hover and look for the buttons – instead of them being visible and available immediately.

I accept that once you learn a new user interface you things get quicker – but even after learning how to change a heading to a list it still took 8 seconds in Gutenberg, compared to 2 seconds in TinyMCE.


Failing to recognise vastly different WordPress uses

I feel like it fails to recognise the vastly different ways WordPress is being used to manage the different types and formatting of content.

For example, I manage a how-to blog. Listed items (UL or UL) and pictures are fundamental to providing how-to-instructions. But with Gutenberg even this very basic requirement is not possible – to add an image you need to end the list, insert the image then start a new list – returning the list back to 1.

Clunky reformatting

In content creation I often reformat text, for example changing listed items to headings or switching an H2 to an H3 to create a better structure. Gutenberg did not handle this well at all. Turning a list to headings created some hideous heading block with <br>’s (not that I can check due to the lack of a “Source” option).

Learning curve

The platform may be web/browser – but the end users are used to desktop word processors and will be expecting a similar user experience when trying to use HTML WYSIWYG editors.

If the usability testing has said anything – it’s that there will be a lot of end user support and hand holding to train non-technical users in how to steer it. Not something I’m particularly keen to spend time on.

For example, select-all – this should select EVERYTHING in the document — not just the current content block.

No source view

For the more HTML literate users – the lack of a “Source” option to view and manually change the HTML will be significant. If you’ve ever needed to paste content in HTML format into a post, add custom formatting, edit/clean HTML – you’ll be at a complete loss with Gutenberg.

Third-party TinyMCE

Some people have argued that there will always be third-party plugins to re-introduce TinyMCE.

But I don’t think this is enough – the content editor needs to be a consistent user experience for ALL WordPress users and MUST have core support.


I acknowledge that Gutenberg is still in beta, and that the developers have put a lot of work into getting it to where it is now.

But I find it hard to see the Gutenberg editor providing an easier experience for any content management scenario I’ve dealt with.

I feel like they’re trying to solve a problem that just doesn’t exist, not at least for the majority of users. To me it seems like there are enough solutions like TinyMCE and CKEditor to not justify recreating an entirely new editor and new editor experience.

How to write a changelog and why it matters

If you thought changelogs were to document what has changed – you’re wrong.

That may be what you do in a changelog, but what’s often not seen is how they act as bridge between the software developer and users. 

It’s a shame because this is incredibly powerful – with this you can:

  • demonstrate good communication, attention to detail and professionalism to the users
  • show a continued development cycle – which builds confidence
  • refer users to related documentation

Instead they’re often underrated – and hence poorly done. I’ve seen some shocking examples – ranging from vague, over-detailed or even worse – just a link to a “diff” that shows what code has changed.

Here I’m going to share some tips on how to write a change log that matters to the user. More information on what makes a good change log can be found at Keep a Changelog.

Know your audience

As with any writing – the first step is to know your audience.

Are your users all technically minded, for example if you had a developer tool, or are they the type of user that is only capable of installing a WordPress plugin?

I usually consider my audience as:

  • my mother
  • a developer
  • myself

The key here is you need to write to the lowest level – so I always think “does this pass the mother test” — “will she understand what this means”.

Keep It Simple Stupid

Avoid using technical terms in the changelog and only talking in general terms.

For example

BAD: added async processing of ZIP file 
BETTER: improve time taken to create ZIP file

The level of detail to include will likely be contextual, for example – do you need to refer to where ZIP files are created? If so,

BETTER: improve time to send notification email with ZIP file

Write in terms of features

Most users are interested in the what – not the how. It can be hard to remember this when you spend so long thinking about how things work and making it happen.

For example

BAD: minify JS and CSS
BETTER: make page load quicker by reducing size of JavaSript and CSS

Avoid technical documentation

Don’t fall into the trap of including technical documentation in a changelog – for example providing examples on how actions or filters can be used.

Unlike a changelog, technical documentation is not set in stone – it’s a living breathing beast. What happens when that filter gets a new parameter – will you be retrospectively changing the past changelog entries? (I hope not!)

Instead simply provide a high level reference to the technical element, for example the name of a new or updated filter – and provide a link to the official documentation.

If this isn’t an option at least provide inline documentation in the code.

Break it down

If your changelog is for a complicated multi-part project, for example software that has a front-end and an API – use headings to break updates into their relevant part.

For example


+ make page load quicker by reducing size of JavaSript and CSS


+ improve time to send notification email with ZIP file


Before each item in the changelog, prefix with a category that describes the type of change in a single word.

For example

  • Feature – for new features
  • Improved – for general improvements
  • Maintenance – for tidying code
  • Changed – for changes in existing functionality
  • Deprecated – for soon-to-be removed features
  • Removed – for removed features
  • Fixed – for any bug fixes
  • Security – in case of vulnerabilities

Decide on how you want to do this early on and continue to use it as a “controlled vocabulary” – your users will rely on this being consistently used so they can scan through the list.

Don’t forget WHEN

For each update, include at the top the version number and the date the update was released.

This can help when jumping multiple versions or if a bug is discovered several months after the update is installed.

Include the full history

Don’t assume that the changelog is only being used for the latest updates.

By including the full history you allow the changelog to be used as a historical reference – for your users and the developer.

Anything else?

What else do you think makes a changelog matter for the user – comment below.

How I run a 10k hits a day WordPress website for $5 a month

For years I ran itsupportguides.com on a “business plan” cPanel host – it cost $25 dollars a month and while it ran OK most the the time, it was a shared service – which suffered performance issues or even outages when someone else on the server did something out of the ordinary.

That was before I found DigitalOcean – a cheap Virtual Private Server (VPS) host with prices from $5 a month – backed by solid infrastructure, awesome documentation and various one-click installs to get your website going as quick as possible.

At the time itsupportguides.com received around 10k visits a day – which left me thinking – could I run this one the cheapest $5 a month VPS?

The answer – YES! And even better – with DigitalOcean I can easily upgrade the plan if I ever need more, even temporarily – giving a quick easy scalability.


At the moment the $5 a month plan gets you a VPS with:

  • 512 MB RAM
  • 1  core processor
  • 20 GB  SDD  HDD
  • 1  TB  of traffic

At first glance this is actually a significant step down from my cPanel hosting – but the key is your website is the only thing using these resources AND you can optimise the server for YOUR website.

Software and configuration

The biggest concern that stopped me from moving to a VPS was security and maintenance – I didn’t want to get bogged down by worrying about the server software or configuration and I definitely didn’t want to introduce any security issues.

Fortunately there was an answer for this as well – ServerPilot – who take away all the hard work of configuring the server and installing WordPress – leaving you with a highly optimised web host. If you don’t believe me, check out the amazing features they install.

The best part – once setup it’s completely hands off – they deal with the servers security updates.

The stack

  • A choice of PHP versions – 5.4, 5.5, 5.6, 7.0 or 7.1
  • Nginx in front of Apache
  • PHP-FPM – PHP’s official FastCGI process manager
  • MySQL
  • HTTP/2
  • Google PageSpeed Module

Server performance

itsupportguides.com gets about 10k visits a day with a peek of 800 visits an hour. 

Using the performance tools provided by DigitalOcean I can see the server is sitting quite comfortably handing the traffic – with only once in a month that memory usage was above my 70% alert threshold.

Page speed

My cPanel hosting would give somewhere between a 3 – 5 second page speed. Which isn’t bad, but I knew I could do better.

On the DigitalOcean $5 a month plan I a much better page speed – normally below 1.5 seconds.

A massive improvement at a fraction of the cost.

How do I do this?

I’ve written a detail set of instructions at The idiots guide to installing WordPress on DigitalOceans $5 a month plan.