Static WordPress. How WP Code Box helped me go “serverless”.

In my last blog post I was floating the idea of moving from WordPress to a Static Site Generator (SSG) called Astro.

Instead, I made a local install of WordPress into my Static Site Generator. WP Code Box, although not essential to this, made things much easier to move toward a Jamstack approach.

This is in two parts:

1. I’ll give my reasons for this change as a follow up to my last post.
2. I will give an overview of how this new set-up works using a simple live site.

I’m not sure if there will be much demand for more detailed “how to” content on this, but if you think there is, please let me know in the comments.

My reasons for using WordPress for static sites

Familiarity:

After nearly two decades with WordPress, the idea working entirely within a code editor seemed quite a leap. This is diminishing, but I certainly needed a stepping stone.

I’ve never had much capacity for learning code as it’s always been a means to an end for me. Even the CSS I considered I knew had changed so much that I needed to start again.

Fortunately, if organised, CSS is more logical and designer friendly than it’s ever been and I found it easier to learn than Gutenberg.

I’m pleased I went this route as recently almost every element of a website has been subject to a better alternative. I’m talking about things like:

• Site wide CSS grid layout.
• Variable Fonts.
• AVIF image optimisation.
• Responsive art direction with images.
• HD colours and new many units and ways to organise styles.

I can’t see much of this coming to builders soon because their aim is to save users from being overwhelmed or from needing to understand the wider CSS concepts.

Stability:

This became my main problem with WordPress as a live platform. I began to feel my clients were paying an unnecessary amount for hosting, maintenance and software only to be treated like guinea pigs for the developer’s commercial experiments.

Existing client sites became the battle ground in which plugins authors slugged it out to be the number one “game changer” to bloat sites with features. The constant cycle of updates brought dread. But with a significant rise in security issues there was no getting off it.

I don’t blame the developers. They need to appeal to new customers as the existing ones get more impatient and less loyal. I don’t blame the customer. They were hooked in by the thrill of a constant supply of game changers.

The upshot is I was losing control over my business. Worse I discovered that most of my present clients didn’t actually want to learn or use a CMS.

Now I am only using the permanent and basic features of the WordPress CMS:- shortcodes, custom posts and fields. There’s no plugin or Gutenberg dependencies. It’s just my local tool and honestly I’m loving it again like I did back in 2007.

The client gets an unbreakable site with no indication WordPress was involved. They are not paying for my lack of up-dated skills and this money is now going into ongoing improvements.

This use of WordPress presently feels more stable than using an SSG. Astro made only a few minor breaking changes in its last update to V. 2.0, but even that could be an issue to someone like me who relies on tutorials from a year ago.

Speed:

Many new clients’ jobs have been about rebuilding an old or broken WordPress site and this route allows me to quickly import some content and metadata.

Support:

A.I. tools have been well trained on the basic PHP WordPress code I’m using. Help is easier to find compared to the newer Static Site Generators at the moment.

Importantly: I’ve tried to use WordPress in a similar way to how I would have worked with Astro, so if needed, I could swap over without affecting the client.

When I later show how I use WordPress HTML snippets saved as shortcodes (via WP Code Box in this case) it is the rough equivalent of what Astro is doing with its tag.

WP Code Box V.2

I should say that as I’m working locally, I’m using a beta of WP Code Box V.2. This will be out soon, but for proper updates on this and new features it’s best to follow Ovidiu’s excellent YouTube channel and join his Facebook group.

In terms of this content, the difference between v.1 and 2 is the implementation of shortcodes and the change of editor to Microsoft’s Monaco editor. This is the same as the popular VS Code editor which I also would be using if working with Astro.

---

Special 25% off coupon: “beaverjunction” for the best discount available.

---

Going serverless

If you are unfamiliar with “serverless” or edge hosting. It’s about sending site files to global Content Delivery Networks (CDN’s) and serving them closest to where the user is.

There’s no single server to manage, update and make powerful enough to cope with unexpected changes. It’s much cheaper (free for me at the moment), secure, greener and faster.

You may have heard of “Headless WordPress” which is a way to go static via WordPress’s React API. I am not doing that. My thoughts on this are best summed up by this image sent to me from Nathan at WP Builds

Moving from a PHP to a JavaScript framework dependency would not make sense for me.

Additionally React’s popularity is waning and some developers now see it as a mistake in the development of the web.

Nevertheless, JavaScript more generally is replacing PHP and it looks like serverless is the future. The fall in the live use of PHP is seeing those types of CMS’s declining across the board.

WordPress is presently holding ground, but probably due to the surge of new DIY users created by the effective marketing of 3rd party page builders. Many using them for business have yet to learn that what you see is only a small part of UX design and there is the long term to consider.

Also the growth of Headless WordPress will mostly be indistinguishable from those running live PHP. Even so, you can see a drop in the 10K sites.

The Local WordPress Set-up

It’s best to watch this part of the video

Presently, I am refining it over a number of new client projects. Surprisingly I’ve taken on work that I would have considered as too complex when running WordPress as a live platform.

With the exception of forms, dynamic content for the site visitors is almost never needed for my projects and I prefer the client to know this responsibility lies with 3rd party API.

Local WP

I’ve been using Local WP to spin up my WordPress installs. I like the UI and that you can clone and organise the sites easily and save them to Google Drive or Dropbox.

My simple WordPress theme

Obviously, WordPress needs a theme to run and I have no PHP skills, but it only took a couple of days to follow along with this excellent free course by Mr Digital.

Since then, I have simplified things by handing over much of the work to WP Code Box.

In the header, footer and single post php pages I’m echoing shortcodes to HTML snippets I have added to WP Code Box.

I have found with Chat GPT or WP Codey (by the same author of WP Code Box) that it’s easy to find what you need.

For example on another site I wanted to add via native custom fields a “person schema” for each entry on a custom post type. Chat GPT just gave me what I needed to add to the theme.

I can’t be sure the code is the best, but it does not matter – the theme is not live and it is only the output that matters.

WP Code Box (Folders)

I’ve set up various WP Code Box Folders to organise my snippets. The content varies depending on the site and gets imported via my personal WP Code Box cloud space. What I have now is:

Functions:

This section uses snippets to replace plugins (again with AI help).

I could use a repository plugin for something like “duplicate post”, but as this should not need to change, I wanted to skip the chore of having to update only to get an advert or find that it does something completely different now.

WordPress Performance:

This is removing the extraneous stuff WordPress has added over the years: emoji support, feeds, the WP Generator Meta Tag and Gutenberg that I don’t need

I moved the images to their own folder called “images” and bypassed the WP Media library as well as the WP menus system. I use the squoosh.app for image optimization and resizing and have a shortcut to the image folder on my desktop.

This allows me to treat images according to the situation. I can:

• Use the HTML “picture” tag to serve differently cropped images to different device sizes
• Choose newer image formats and have a fallback for older browsers.
• Stop lazy loading on “above the fold” areas for performance.
• Remove the WP image title for better accessibility.

I had not previously paid much attention to how the media library can harm performance.
But without services like Shortpixel (that can’t work locally) WordPress seems to increase the file size of the images it crops. Until 15 times and it takes 30% off the quality. It might only be my Local WP server, but either way WordPress’s automatic approach to responsive images can never be optimal. It treats them all as l full width.

Global areas

Is where I keep most HTML snippets saved as shortcodes that go in the theme (as  mention earlier), in pages or in other shortcode snippets.

In the header we have a shortcode for the nav or menu. In this case it is as simple as it can be, but if I wanted a complex mega menu there are a lot of people and sites sharing their code and of course AI.

I like that with a “mobile first” full site CSS grid set up I could have easily had the nav at the bottom of the page on the default mobile layout (where those users thumbs are) and have it go to top right for larger devices without having to duplicate the code output.

One of the nice things about the new Monaco editor used in WP CodeBox 2.0 is that it includes Emmet to speed things up.

This, combined with WP Code Box’s auto-competes, has removed the chore of writing code that led me to favour page builders.

The off-putting thing about the code was the overwhelm of a large page of it and having to move from file to file to change something like a menu item.

This is gone with global areas like headers, footers and in this case the CTA section can be kept away from the main pages.

In the CTA section I have another shortcode to form. With this I am using FormSpark to send to the client (but there are lots of similar form services appearing to capture those going static). It gave me the HTML and told me how to redirect to the Thank- you page and offered a range of anti-spam options.

Pages

Again, HTML snippets turn into shortcodes. I create WP pages in the usual way and can add a shortcode to them.

Where possible with basic semantic HTML tags like “main” and “section” With my CSS Grid set up I rarely need to add class selectors or divs

Sections are easily collapsed in the editor for better focus.

In pages I can also add via a shortcode what I’ve called components to reduce the code overwhelm.

Components

These are really my equivalent to Page builder modules or widget. It is used for things like galleries and accordions.

I use HTML snippets that will mostly include the component specific JS and CSS there.

Inline additions like these are mostly seen as a performance booster and Google recommends it.

One that is different on this site is the YouTube lazy loading which is used in the blog. It is assigned via the theme to a video category, but this is too much to get into. Finally there is..

Stylesheets

I have avoided frameworks like Bootstrap and Tailwind because I want to be able to tell the client that they fully own the site (at least the static output) and any frontend developer should be able to take over.

But I do use a slimmed version of OpenProps by Adam Argyle from the Google chrome CSS development team.

It gives me a battle tested system of CSS variables (Custom Properties) that makes use of modern CSS like fluid typography, calc and character length setting.

This helps me get design consistency and global control over my styles. It does not take long to create an entirely new look as there are no plugins adding their own HTML and CSS.

With the main layout and grid sheet I am taking the “section” tags and positioning them with :nth-child (1) 23 etc.

It means I don’t have to commit to adding project specific class names to everything. I use grid-template-columns to map the main areas.

I am still refining this, but once the home page layout is sorted it only takes a few lines to adjust it to the needs of other pages.

That’s the basics of my Code Box folder.

Blog Posts are done with the classic editor (or rather the TinyMCE editor). There is too much to say on this how I am using CPTs and custom fields on other projects to cover here.

Even though support for the Classic Editor plugin is supposed to be limited I can’t see Tiny MCE being removed from WordPress as it’s in Gutenberg via the classic block. If they do Chat GPT has already shown me how easy it is to re-install it myself.

In the worst case scenario I don’t have to update WordPress and could move to ClassicPress. Or make this the time move Astro. Until I’m fully set up I can still manually update via VS code.

One mistake I think I made on this site is on the blog. I have started to reassess the concept of the blog archive. The WP standard was set before the issue of weak or duplicate content started to annoy search engines and we put our reliance on fragile SEO plugins to tell the search engines the priorities.

I noticed on most of my sites that the archive page is rarely visited and further pagination and author pages hardly ever. I am thinking why not just have sectioned links on one page?

Presently I am using Slim SEO, but I’ll probably drop it on new sites for custom fields.

Flattening the site

I started by using the Simply Static plugin, but issues increased with updates and have switched to using the free Cyotek Webcopy program.

This is just for PC. Mac users might want to check out Site Sucker from Ricks Apps. There are other options out there.

I only need to add My site’s local URL and send it to a folder on my desktop, but there are a lot of fine tuning available should I need it.

This desktop folder is watched by my install of Desktop Github for changes and it shows me exactly where those changes are and which files were changed.

If I’m happy, I push these updates to a private repository on the Github site which, in my case, is automatically picked up by Netlify which in turn deploys them to the CDN. That is with Amazon Web Services (AWS).

It seemed complex at first, but no more so than the first time I installed WordPress on a server or used my first theme or page builder.

At least when working locally you can’t accidentally publish a draft and it is easy to roll back the changes sitewide.

What I like is that I have another website backup on Github with version control and I can share with any developer from any code background and allow them to branch it.

Netlify is great and user friendly (but there are a growing number of similar services). What they bring to the table is the ease with their Github integration and also a way to do things we usually expect a server to do like 301 redirects, 404 pages and a pretty URL.

It seems hard to exceed their free allowance (100GB of bandwidth per month and 300 build minutes) so I think I will be running quite a lot of client sites on it before I need to pay anything.