Mixd have over 15 years of experience developing enterprise level solutions for public sector clients. We have used WordPress as our preferred Content Management System (CMS) as it provides a very user friendly content editing experience and as WordPress’ popularity has grown, so has familiarity with it, and as such clients are very enthusiastic to use it.
Despite enthusiasm from content editors, if you were to ask web developers what they think of WordPress you will likely hear some less positive opinions of what it is like. This is largely because WordPress has not jumped on the ‘latest-and-greatest’ bandwagon of things that are considered best practice in the industry.
WordPress has made some substantial changes to the platform over the last few years; They introduced the WordPress Rest API and more recently they have overhauled the whole editing experience with the introduction of the Gutenberg editor.
These changes presents a progressive leap into the ‘modern web’ for WordPress who appear to be doing everything they can to shake off any notion that they are behind the times. As developers this is extremely exciting and allows us to radically change the way we approach developing projects in the future. As developers we now have complete freedom over how we define and build our frontend architecture.
I have personally been building WordPress websites for over a decade. The first WordPress website I ever built for a client is still live and has been running without fault since 2008. I think it’s fair to say that in 2019 we are largely using the same development stack that we have been using since 2008. Linux, Apache, MySQL and PHP (LAMP) are used to serve the website. Users visit the website and the WordPress PHP framework processes the user requests, fetches all the necessary content from the database and media library to serve the page. It’s straightforward, simple, efficient and extremely reliable but that doesn’t leave us with much room for innovation.
We know what works and what doesn’t and we have implemented solutions to these issues in our projects over the years with products like WP-Deploy which we developed to overcome the limitations of deployment via FTP which traditionally was the recommended way of maintaining a WordPress site. We were also the first agency to deliver a responsive website for an NHS trust.
WordPress is written in PHP. This means that web pages are generated server-side, this allows us to worry less about the functional capabilities of the older browsers we must support for public sector clients. It also means that the codebase is all conveniently kept together within a WordPress theme.
WordPress has a rich plugin ecosystem for extending the core functionality of WordPress. The official plugin repository has a rating system and a discussion forum so you can quickly establish how trustworthy each plugin is. We typically audit the plugins that we recommend to our clients and while we try to use as few as possible there are some incredible plugins that take WordPress from a basic blogging tool to a full featured CMS such as the incredible Advanced Custom Fields.
User management in WordPress is great, it supports custom role delegation which we use for granting access to website administrators but also allows us to restrict access to certain areas of the site quite easily.
For a long time we (in the WordPress community) have found ways to really optimise our theme development to make pages as quick as possible. We reduce the number of requests and compress images and frontend assets. We even take advantage of server-side technologies to squeeze every drop of performance out of the stock WordPress configuration.
One of the down-sides of server rendering is that for each page load a user must make a request to the server. The server hands the request off to PHP. PHP glues together a bunch of templates for various elements on the page and also has to make a series of requests to the MySQL database for the actual content. This process takes time and the user has to wait for all this before the page begins to load.
Being a good WordPress developer is difficult. It’s very much a full-stack job role and developers (even juniors) are expected to be proficient in both frontend and backend disciplines and often it can even include elements of devops and hosting management. This leads to a tendency for WordPress developers to know the bits of full-stack development they have picked up using WordPress but not enough understanding to transfer those skills into other full stack roles. Similarly it means developers don’t get the opportunity to specialise and really hone their skills into either full stack, backend or frontend roles which isn’t inline with the industry as a whole.
Being the most widely adopted CMS on the planet unfortunately means it’s one of the largest attack targets on the web. WordPress websites are commonly targeted for two reasons; Firstly, WordPress is predictable. files are always in the same place server to server so writing an exploit that can traverse the entire WordPress installation can be used on millions of potentially vulnerable sites. The second reason is Plugins. WordPress take security very seriously for the core product but they can’t and seemingly don’t take responsibility for the thousands of plugins out there and, without thorough vetting, there is no way of knowing with certainty that these plugins are safe. As a matter of due diligence, all the plugins Mixd use in production are vetted against our own internal stringent performance and security checks.
We have spent the last few months researching and debating how to evolve our ‘standard project’. Taking all of the great things we like about WordPress combining it with the new frontend innovations going on in the industry, we wanted to create a new workflow to take us to 2020 and beyond.
All of our industry research has led us to an exciting new development stack that will carry us beyond 2020 and we expect it to pave the way for the next 5 years. We spent the last weekend as a team together in Milan and during our company meeting over a few drinks we pitched the idea of change to the development team who, after hearing the following ideas, became extremely excited and inspired.
Headless WordPress is the concept of running WordPress only as a backend. Posts and Pages are created in WordPress and the data from them can be accessed by the WordPress REST API. This allows us to host the backend and frontend of the website on completely separate servers which means that we can do much more to harden the security of the CMS.
By decoupling the frontend from the backend it makes it fairly simple for us to incorporate enterprise level functionality such as Single Sign On, allowing us to add a further layer of security for clients using Active Directory, Microsoft Office 365 or Google Apps who all offer SSO solutions.
GraphQL as they say on their website is a ‘query language for your API’. It adds a lot of simplicity to working with an API driven data exchange and allows us to write simple queries to return only the data we need. There is an excellent GraphQL WordPress plugin to assist in serving and managing GraphQL data. There are also plenty of frontend solutions for interfacing with GraphQL. We can even map ACF custom fields to the API.
Something we couldn’t live without on our projects is the Gravity Forms plugin. Luckily they have a feature rich API that we can use to deliver forms to the frontend without a reliance on the CMS allowing us to move away from the pre-constructed markup that Gravity Forms provide out of the box in favour of our own controlled form markup making it much easier to make changes to improve accessibility and the overall UX.
We are really excited about solutions like Elasticsearch to go beyond what we can currently achieve. It’s something we are actively researching to ensure the best search experience all round. We are most excited about improving the quality of search results and the speed at which results can be displayed.
One of the benefits of separating the frontend and the backend of the website is that we don’t necessarily need to provision ultra high spec servers to accommodate for the backend and frontend traffic as the traffic to the CMS would be relatively low. Only content editors would be accessing the backend and data that is being served via the API will be using smart technologies for caching static assets on the frontend to massively reduce the overhead on the server.
We want to move our static assets such as imagery and media into regional Content Distribution Networks (CDNs) which will rapidly speed up load times on the frontend by serving content from the closest server to the end user.
A modern frontend for public sector
Having used an ad-hoc server side PHP component loader of our own for the last few years the team are very familiar with the concept and React gives as several features that simply aren’t possible with PHP, such as state and lifecycle.
We have been really enjoying working with Styled Components as our CSS-in-JS solution. It is architecturally a big change from Sass but we feel that the pros absolutely outweigh the cons.
The Mixd development team are very excited to transition into this vastly new methodology and together over the next 6 months we will be heavily investing in research and development to solidify this approach before bringing this into production for our clients. Our desire and commitment to excellence remains unwavered so it is of the utmost importance that the solution has been rigorously tested.
If you have read this far and you want to work for a company that is innovating in these areas we are always recruiting for talented professionals to join our backend PHP (Laravel, headless WordPress and API development) team and our frontend team (HTML, CSS, React, CSS-in-JS, GraphQL).