A staging site makes testing updates easier—but copying your live site can also bring along customer emails, payment credentials, and background automations. Without safeguards, your tests can reach real customers.

Start by identifying the environment. Add this line to your staging site’s wp-config.php, above the “That’s all, stop editing!” comment:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

If WP_ENVIRONMENT_TYPE is already defined, change its value to 'staging' instead of adding another definition.

This tells WordPress and compatible plugins that the site is staging. Because it’s stored in a file rather than the database, it survives database refreshes from your live site. Alok Jain’s article explains the approach.

That line alone won’t stop outgoing emails or payments. Pair it with a few safeguards:

• Block customer emails or redirect them to a test inbox.
• Use test payment credentials and review connected services.
• Pause background automations unless you’re testing them.
• Restrict access and keep staging out of search results.

For email specifically, Jain shares a small must-use plugin that blocks messages sent through WordPress outside production. Plugins that send directly through an email service’s API need separate controls.

Prefer a ready-made option? Staging Superpowers recognizes the staging setting and bundles protections for email, connected services, scheduled tasks, indexing, and more.

After each refresh, verify your safeguards with a test form submission or order. A staging site should give you room to experiment without surprising your customers.

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.

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.