WP Engine DE{CODE}

by Daryll Doyle
Get in contact – hello@builtbycactus.co.uk

Here at Build by Cactus 🌵 we’re big on continually developing ourselves, if we weren’t, then it wouldn’t be possible for us to consistently produce great solutions for our clients. On the 29th of Jan 2020, WP Engine ran a virtual developer conference. It’s safe to say that we were interested and took the time to follow along with the talks. Below are some of the talks I managed to catch, along with my initial thoughts.

Optimising WordPress for Speed

The first talk I managed to catch was by Patrick Garman, the CTO of Mindsize who offer eCommerce consultancy.

Patrick started off by explaining how they try (Mindsize) and get their WordPress sites performing within certain parameters. Speed is easily one of the main issues with WordPress and there are a lot of reasons for this, not least to mention the fact that running a lot of plugins will slow your site down.

He mentioned that they aim for a TTFB (Time to first byte) of 500ms or less. The time to first byte is the amount of time that it takes a server to receive a request, process it (interpret your PHP) and return something (hopefully HTML). 500ms is pretty quick, but then there has been a lot of research around how every second of waiting loses potential custom via your website, so you can see why speed is such an important factor.

Patrick spoke about how there were three distinct sections of optimisation that can happen on a website. Firstly you have the backend optimisation, which includes optimising your PHP and SQL. You then have the frontend optimisation, such as deferring scripts, lazyloading images etc. Finally you have caching which includes anything from OPCache to CDNs. The backend optimisation is generally where you’ll get the most gains and as such he focused this talk on this.

The core of Patrick’s talk was around two tools you can use to help you identify bottlenecks in your backend code and fix them.

The first tool was Query Monitor, a free WordPress plugin that runs on your local/development server and helps you to identify PHP errors, hooks, API calls, SQL queries and more, that may be slowing down your site. This is great when developing a new site as it can help you optimise as you build.

The second tool spoken about was New Relic, a SAAS tool that allows you to run constant application performance monitoring (APM) on your live server. Not only does this allow you to track errors on the live site, but it also shows you slow running queries and functions. As it runs as a PHP module it’s great for giving you insights into the littlest issue that can be optimised.

I’d really recommend anyone looking at increasing their site speed or developers wanting to know more about optimising WordPress for speed to give this talk a watch. You can register to watch the recording using the link below.

Advanced Plugin Development

The second talk I watched, was Advanced Plugin Development, this was more of a panel talk, given by Carl Alexander, Naomi C. Bush and Robert Windisch. Whilst the name of this talk may seem daunting to a new developer, it really wasn’t that much of a technical talk around plugin development. A lot more focus was put on how developers can push their plugins forward and what makes the difference between an amateur’s plugin and a seasoned developer’s plugin.

Some very good points were made in this talk, one being around how important code quality is. It was discussed how the quality of your code isn’t just for you to show off how great you are at implementing the latest and greatest design patterns. A higher level of code quality also helps with long term maintenence of a plugin, which is important if the plugin is to grow and succeed. I’m sure we’ve all been at the point where we look at code we’ve written in the past and been disgusted by it, at that point you’d prefer not to refactor and therefore the project dies. If you keep the quality of your code high, this is less likely to happen.

There was also a lot of talk around testing plugins, mainly Unit Testing using something like PHPUnit. When unit testing WordPress, a common issue is that the plugins usually rely on WordPress core code and therefore testing a small section of code in isolation becomes very difficult. A tool to help mock these WordPress functions was discussed; Brain Monkey is a mocking library but it’s real power comes in the ability to mock WordPress actions and filters, something that is a common point of frustration.

I’m a massive fan of writing unit tests but I’m more than happy to hold my hands up and say I commonly get frustrated when unit testing WordPress code for this exact reason. Brain Monkey looks like an absolute lifesaver and I can’t wait to use it on the next plugin we develop!

This talk had so many tips and tricks in that I can’t mention them all here. As before, use the link below to watch the replays.

Headless WordPress in Action

The final talk I’ve watched for now is Headless WordPress in Action, by WP Engine Technical Architect Matt Landers.

Matt’s talk is less of a talk and more of a demo on how to set up a WordPress CMS with a server side rendered (SSR) react front end. During this demo Matt used a number of technologies, some of which I’m very familiar with and some less so, so it was great to follow along.

The frontend was a React site, built using the Next.js framework, React Apollo and GraphQL. This was all hosted on Google App Engine. The backend was a WordPress install running off of WP Engine (surprisingly) and running the increasingly popular WPGraphQL plugin.

I’ve done a lot of work with React and WPGraphQL recently, so I was really excited to see how he approached this site. I’ve not used Next.js before or Google App Engine, so I was also curious to see how they worked.

My first impressions? Wow! Next.js made setting up the frontend as easy as pie, including SSR for SEO purposes. Deploying that frontend to Google App Engine also looked amazingly easy and he hinted that something similar may be on it’s way to WP Engine 🤞

All I can say is to watch this demo and you’ll be amazed.

I’d love to write more about this demo, but I’m off to play with Next.js now. All I can suggest is that you go and watch it yourself using the link below.