Thursday, June 25, 2026

Front-ends and SPA-functionality on WordPress

I have for the last couple of weeks been exploring some techniques for creating a SPA type front-end using WordPress as the backend.

Althought WordPress is a stable and trustworthy CMS system, one thing that may be a bit old school is the way the CMS works with regards to page reloads. Since everything is rendered on the server, using PHP, every time a page needs to be updated, a page reload is required.

However, using JavaScript and AJAX, it is possible to achieve a Single Page Application (SPA) type front-end.

My first idea was simply to just use WordPress as a backend, using the REST-API that is built in and not worry about trying to use the front-end part of WordPress: working with the theme in wp-content.

The setup is basically that you use WordPress as a backend server and configure the web server so that WordPress is not on port 80.

Instead you create a standalone front-end in your preferred front-end framework – my choice was React and then you use the REST-API endpoints from your WordPress “bare metal” back-end server.

This worked quite well, but one thing that became obvious was that you would also need to handle the authorization and authentication as well. At least if you wanted user system functionality.

You could keep the front-end and “admin system”, using the login /wp-login.php or /wp-admin for administrative use and only use material from WordPress that is considered “public”.

This can be good enough for certain purposes but if you want users to be able to login and so on (and not login using the above mentioned wp-admin area), this might not be ideal.

However, I quite early on this attempt and it could be interesting to explore it a bit further at a later point.

My second attempt was to work with the theme and not a stand alone front-end. Instead, I opted for using some JavaScript/AJAX technology. Some possible options would include vanilla JavaScript for fetching JSON, jQuery AJAX/fetch or HTMX.

I decided to try HTMX as I had not used it before… And it turns out it was quite simple to implement and I got some nice results, being able to swap out parts of the DOM.

This worked well for certain type of material but I soon ran into some difficulties with state management. For example, to keep track of “back link URL:s”, turned out the be more troublesome than I first expected. However, a similar problem had occurred without HTMX so maybe it is JavaScript that introduces such issues.

I got my custom post type “works” to function quite well with HTMX, which made it possible to filter type of work, that was categorized using a custom taxonomy. Left to to do is the mentioned back links, so that you get back to filtered results. Another thing that needs to be solved is pagination, and pagination for filtered results.

But for now, it works quite well and is not over-engineered nor underdeveloped, in my humble opinion… But of course, every time one develops features like this, one runs into the risk of reinventing the wheel. Which I guess adds to the *fun* of web development.

To conclude, this is not my final say in this matter, but some reflections on my progress. Hopefully I will be able to come back to this topic at some point, perhaps when I have gotten some more experience with this type of development.

No comments:

Post a Comment

WordPress Null Handling Confusion in Custom Fields

I recently built a WordPress plugin that was going to handle custom fields. The functionality was similar to the plugin ACF (Advanced Custom...