1. Beware WordPress developers that rely on third-party plugins

Beware WordPress developers that rely on third-party plugins

Beware WordPress developers that rely on third-party plugin

When engaging a WordPress developer there’s one very simple but important question you must ask – do they develop or implement.

With hundreds of thousands of free plugins and many more premium plugins there’s an alarming trend of people claiming to be ‘WordPress developers’ but when it comes to the development they rely on these third-party plugins, earning themselves the title of ‘WordPress implementer’ and putting your project in a very dangerous territory.

What’s the difference?

A decent developer or implementer will listen to your requirements and work through them with you – but when it comes to the actual development,

  • the developer will build a solution to your exact requirements and
  • the implementer will start looking for solutions to each of your requirements, usually patching together several third-party solutions.

Why does it matter?

A developer or implement may be able to get the same results for your project, but what matters is how they achieve the results – as it affects the quality of the product, securitylicencing and the ongoing maintenance.


Plugin bloat is a well known fact in the WordPress community – the more plugins installed, the slower the site runs.

This is exactly what the implementer is doing to your site. They’re more than likely going to install multiple plugins with little regard to how the plugin affects your sites performance. Furthermore since the plugin is developed by a third-party developer for a the WordPress community it’s likely to be feature rich – features you most likely don’t need but contribute to the bloat.

On the other side the developer will use their expertise to code to your requirements – they will know 100% what code is running and when with no bloat.


It’s highly unlikely the implementer is going to read through the plugins code, if they even could understand the code they would be much more likely to develop.

The third-party plugin is a point of weakness in your websites security – without knowing exactly what the code does your website could be open to any number of vulnerabilities.

Engaging a developer involves trust – if you’ve ended up with an implementer you need ask yourself – do I trust all these third-party plugin developers with my website?


Licencing is something that’s easy to overlook, especially when you’re employing someone else to build the website.

With the developer you can simply stipulate no licence on the development, however when an implementer installs all those third-party plugins what they’re doing is making your agree to the terms of the third-party plugins. They may even be locking you into ongoing licence fees to the third-party plugin developer.


When you patch together several solutions you create a delicate balance that keeps things working.

When one plugin updates, that balance may break leaving your website broken.

When it comes to support instead of having the one developer that knows your code, you have several developers that may or may not be interested in supporting you.


I’m not advocating bespoke solutions for every project, I’m saying that people need to be aware of how their project will be achieved and what the implications are.

You need to ask – do I want a developed solution or an implemented Frankenstein patch work solution?

If you’re comfortable with an implemented solution, for each plugin you need to ask:

  1. Who developed it? Are they well established and trustworthy.
  2. When was it last updated? Is the plugin being maintained, does it work on the latest version of WordPress.
  3. Is it well supported? Is the third-party developer providing ongoing support.

And finally, remember that your site is only as secure and efficient as the code runs it.

The curiously grey market of GPL licensing

What is the GPL?

When WordPress plugins and themes are released they’re typically licensed under the GPL (General Public License) – this spells out the rights and limitations to using the software.

Whilst licensing under the GPL isn’t a requirement, it is the preferred license as it used for software in the WordPress plugin and theme directories.

The GPL is all about making sure software is free to run, study, share and modify. This makes the software is free to distribute (and modify) as long as you acknowledge the author.

GPL and premium software

Whilst the GPL is about free access to open source software it doesn’t out rule charging a fee for the distribution (access to and download) of the software (and updates).

When you purchase a “premium” plugin or theme that is licensed under the GPL you’re really paying for distribution and access to support.

Enter the grey market

Nothing in the GPL forbids you from taking someone’s software and redistributing it (as long as you acknowledge the author) – in fact it encourages it because it’s what makes open source software grow so quickly.

Some people take advantage of this by simply taking the software and adding their own price to access it, normally without support or updates.

What I find interesting is there are markets dedicated to this activity – where you pay a few dollars instead of the full price to download the software – most don’t even hide that they’re a third-party.

Whilst this is perfectly legal, it undermines the value of the GPL and the business model that supports the development of the software. Without the income developers will be forced to focus on other activities or release under a more restrictive license.

Ultimately purchasing the software from the developer provides you with updates and support and funds future development that is in everyone’s interest.



For more information on GPL licensing and fees see:


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 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.