Not all WordPress sites are created equal
WordPress 7.0 was released yesterday.
With significant changes around media handling, block behavior, rendering, and modern developer workflows, it’s worth talking about the operational side of upgrading modern WordPress sites.
There’s a lot to cover, so let’s start with one important reality:
Not all WordPress sites are created equal.
Broadly speaking, there are at least two very different operational models.
The first is publisher-style sites: newsrooms, media organizations, active editorial teams, high-volume content operations.
On those sites, once the upgrade happens, the content and data state of the site may begin changing almost immediately through:
- newly published posts
- media uploads
- automatically generated revisions
- editorial workflow activity
- taxonomy and metadata changes
- feed ingestions and other plugin-driven content creation
At that point, rollback becomes much more complicated — if not practically impossible — because new content, metadata, revisions, and workflow activity immediately become intertwined with the upgraded application and database state.
In other words, once a busy production site begins operating on the new version, it can become very difficult to cleanly separate “newly created content” from “changes introduced by the upgrade itself.”
Contrast that with a relatively static marketing site or low-change business website: if a problem is discovered a day later, there’s often a much cleaner path to restoring from a previous snapshot because comparatively little content changed after the upgrade.
That’s why “Should we upgrade immediately?” is often less about WordPress itself and more about operational workflow, rollback strategy, and how actively the site changes day to day.
Modern WordPress operations increasingly look like application lifecycle management, not simple website maintenance.
Posted originally to LInkedin here.
Compatible up to: 7.0
WordPress 7.0 was released less than a week ago, and one interesting operational reality is how long it can take compatibility information to catch up across the plugin ecosystem.
A plugin displaying “Compatible up to: 7.0” usually reflects a manual process:
- testing against the new version
- updating plugin metadata
- committing changes to WordPress.org
- allowing those updates to move through publishing, review, and propagation processes
Many major commercial and actively maintained plugins already showed WordPress 7.0 compatibility on release day.
But across a massive plugin ecosystem, compatibility metadata naturally takes time to catch up with operational reality.
I spot-checked a few production sites and already found several high-quality, widely used plugins still displaying “Compatible up to: 6.9.4” in the WordPress plugin details dialog.
Are those plugins broken on WordPress 7.0?
Probably not.
But should upgrades still be validated carefully before deployment onto production systems?
Absolutely.
That is the important operational distinction:
A plugin showing an older compatibility version does not automatically mean the plugin is incompatible with WordPress 7.0.
The real question is:
“How does this application behave inside our environment, with our plugins, workflows, integrations, caching layers, and infrastructure stack?”
That is why staging environments matter.
A staging environment is not merely a preview site. It is a private, operationally identical clone of production where upgrades, plugins, caching behavior, media handling, workflows, and deployment assumptions can be validated safely before release to live traffic.
That word — identical — matters.
Because as WordPress deployments become larger and more operationally sophisticated, upgrade strategy increasingly becomes a question of workflow, validation, rollback planning, and application lifecycle management — not simply whether a button labeled “Update” exists.
Posted originally to LinkedIn here…
Dusting off the cobwebs
Haven’t touched this site in a while, but bringing it back as a working space.
I’ll be using it as a test bed for PressHarbor updates and to explore what’s new in WordPress — including Studio, MCP, cloud connections, and whatever else shows up along the way.
Expect a mix of notes, experiments, and half-finished ideas.
Just wrapped up migrating nearly 20 WordPress sites from a customer’s fleet onto our new PressHarbor platform, built on Automattic’s WP Cloud infrastructure.
One thing stood out:
Long-running WordPress sites carry a lot of history. The good and the bad.
One of the things I enjoy seeing during a well-executed migration is that history being preserved.
When a migration is performed using tools like rsync, file modification timestamps can be preserved along with the files themselves. It’s surprisingly satisfying to see an image uploaded in 2014 still showing a 2014 modification date after arriving on the new platform.
But history isn’t just found in file timestamps.
It’s also found in the plugin list.
Many of these sites carried image optimization plugins, CDN plugins, caching plugins, and various performance tools that solved very real problems when they were installed.
Those choices weren’t mistakes. In many cases they were exactly the right solution at the time.
But platforms evolve. WordPress evolves.
Today we’re running on a platform with a built-in CDN, integrated edge caching, image optimization, and dynamic image resizing capabilities that simply weren’t available when many of these sites were first optimized.
It raises an interesting question:
How many of the optimizations on a site are still solving today’s problems, and how many are solving yesterday’s?
Sometimes the best optimization isn’t adding another plugin.
It’s removing the ones you no longer need.