Every decision has a pro and a con

But first there is an oft overlooked reality that we need to establish. Almost every decision made in development has a pro and a con.

Usually, every decision is a trade off with a pro and a con in one of the following attributes:

• Time and cost of developing the website
• The skill required by the developer who builds it
• The user friendliness of the backend
• Loading speed of the site
• The minimum requirements needed of the server
• Control of the code, layout, style and functions
• Dependency on 3^rd parties
• Risk of having a security / stability flaw
• The cost to fix each security / stability flaw when they happen

E.g., an off the shelf slider plugin like Revolution Slider is fast to install and requires no coding knowledge to setup, but it’s fiddly and frustrating to use and slows the website page load speed down dramatically. Alternatively, a build it yourself slider such as Flexslider is much leaner and faster and is easier for a user to edit but needs a skilled developer to setup.

Likewise, an atomised portfolio input system (where you have a single data specific input field for each for bit of data: e.g. subtitle, description, gallery, testimonial) is easy and intuitive for even the office junior to use and produces consistently templated pages but removes the freedom for that editor to build their own layout if they feel a specific portfolio item warrants it.

An introduction to WordPress

WordPress is our CMS (Content Management System) of choice. It’s not the only one we use. We have worked in dozens of others. But it’s the one with the greatest market demand and so it’s the one we work in as standard.

WordPress was developed as a blogging platform and was later altered to be used as CMS for commercial websites, but its internal logic is still very much what you expect a news website to need.

The core role of WordPress is to be an interface between a set of files (that include: the sites stylesheet; the sites function files; the site’s image files; and the sites templates) and the site’s database (which includes: the content; revision history of the content; menu system; user list; and general site settings). WordPress is a very good technical solution at this core role.

However, there is complication, which is ironically both the biggest strength and the biggest weakness of WordPress as a platform. That is that it is very easy to install plugins that extend the functionality of WordPress.

This is great because it means that an awful lot can be done quickly and cheaply. Don’t know how to install Google Analytics in the header.php file? Search for Google Analytics in the plugin library and in two clicks you can install a plugin that will put an input field in the backend of WordPress so you don’t need to.

This is a problem because it incentivises shortcuts and these shortcuts have consequences.

Adding the Google Analytics tracking code to the header.php file is a job that an entry level developer can do and which poses zero risk. However, any plugin has the ability to do pretty much anything. From a simple issue like loading JS (JavaScript) a second time and thus breaking the JS scripts on the site, to major issues like allowing hackers access to company emails stored on the same server (see our article on the Mossack Fonesca scandal for more on this). If you don’t know who wrote the code then you don’t know how safe it is. In the WordPress plugin library there are free plugins created by dedicated development teams with multi-million pound budgets and stringent quality control processes right next to plugins made by school kids, right next to plugins made by malicious players. How do you know that it is safe? Even if you can vet the code on the current version, how do you know there won’t be a trojan, accidental or purposeful, in the next update?

This is especially risky if the purpose of the plugin is so simple that no developers use it. No one with the skill to inspect the code in the example Google Analytics plugin would need to use it, so would never have installed it on their projects, and never would have looked at it. Thus, you can be pretty sure that that plugin has little or no community oversight and is a fertile place for malicious players and the mistakes of underdeveloped developers to fester.

Alternatively, a plugin like ACF (Advanced Custom Fields), which is a partial website solution that handles creation of inputs and requires a developer to then code the outputs, and is used exclusively by developers, is under constant peer review and scrutiny and thus is a very safe and well-made plugin.

However, a more frequent problem than security is inefficiency. Most of the plugins designed to be used by non-developers work by creating an interface in which you set what functions you want and then it saves those settings in the database. However, that’s not how databases were designed to work. They are using MySQL (the database) to do a role that PHP was beautifully designed for. It’s the equivalent of using a power drill to hammer in a nail. It’ll do it, but it’s so much slower, messy and prone to unwanted complications.

Each coding language used in website development: PHP (server-side functions), JS (device side scripts), MySQL (database), HTML (templates) and CSS (styling) are intelligently designed to efficiently solve the kind of problems that you encounter in their area. If they are used in the manner that they were designed to be used the site will be fast and stable and any issues will be easily identified and resolved.