skip to content

Search

Summary: And a note about infrastructure

2 min read

We'll talk about infra (meh, breifly), congratulate ourselves for doing very little, and talk about other stuff we could add!

# series
# wordpress
# tutorial
# sage
Enterprise WP with Sage

A quick note about infrastructure…

You need a good caching strategy to perform well.

Wordpress plugins are not a good strategy, at least not on their own. Here’s how they will work at scale: for low traffics, it’ll instantly supercharge speed. But it’s throughput-limited, and when it fails, your site will randomly idle, which is what it’s designed to do.

I could ramble about concurrency for a while, so let’s just agree that you need Varnish (for apache) or nginx’s reverse proxy on…nginx. Or you can use an “upstream” cache on a CDN set to server static files. Every major off-the-shelf WP host has this by default, and plenty of enterprises prefer this to hosting it on their own AWS etc.

Understand you’ll need a strategy for geolocation and logged in views, which shatter this form of caching.

Improvemets

We’ve done plenty (congrats?), but there’s more features we could implement as part of our standard foundations:

  • Schema Migration: Not hard to implement, and maybe someday Roots will port some of the Laravel style DB migrations into Sage (idk, maybe that exists), but it’s a good idea to roll custom schemas at scale, because WordPress’s post_meta table is a grave crime against database optimization.

  • Block Wrapping:: Blocks will ignore the margin and padding set in the admin. This is easy to fix by making a base class that wraps your block and implementing a renderBlock method that adds these wrappers.

  • Next-gen Images: WordPress has a terrible thumbnail system. First, it fails to care if a thumbnail is missing and will serve a blank file instead of regenerating it. If sizes change, you need a third party plugin. Also, it doesn’t make next-gen formats like AVIFs with retina support and PNG or JPG fallbacks.

Summary

Celebrate, if you want.

We now have:

  • A component-based style of dev with decoupled server-side code and views that can power react, blocks, or simple HTML.

  • A way to hydrate components so we can leverage rich UI featuresets while still utilizing ACF’s immense toolset.

  • A strategy that will allow us to migrate large amounts of complex data into Wordpress while still creating a new, clean schema.

Actually, I have no idea if you have any of this, but I do! Hire me, maybe? 😉