We want to be transparent about a bug we discovered in the Next-Gen cloning engine, which is currently in BETA in the free WP STAGING plugin and in WP Staging Pro. Under certain conditions it can corrupt data on the staging site it creates. We are truly sorry for the trouble this may have caused, and this article explains exactly what happens, which data is affected, and how to recover.
The short version: only staging sites created with the Next-Gen cloning engine (BETA) are affected. The default Classic cloning engine is not affected, and your live production website is never touched by this bug. To keep everyone safe, we are temporarily disabling the Next-Gen engine in the next releases while we finish and test the fix.
Contents
Who Is Affected
You are affected only if all of the following are true:
- You created a staging site using the Next-Gen cloning engine (BETA), and
- Your live site uses the standard
wp_database table prefix (the WordPress default that most sites use).
You are not affected if:
- You used the Classic cloning engine (the default in WP STAGING). Classic copies your rows verbatim and is not affected by this bug.
- You only create backups. This bug is specific to the Next-Gen clone process.
Affected versions: the Next-Gen cloning engine shipped as a beta in WP Staging Pro 6.9.0 and 6.9.1 and in the free WP STAGING plugin 4.9.0 and 4.9.1. If you cloned a site with the Next-Gen engine on one of these versions, this notice applies to you. The problem is fixed in the free WP STAGING plugin 4.9.2 and WP Staging Pro 6.9.2, where the Next-Gen engine is temporarily disabled until the repair is complete.
Most important of all: your live website is not affected. The bug only writes to the new staging copy while that copy is being created. Your production database is left exactly as it was. There is nothing to fix on your live site.
What Goes Wrong
When WP STAGING clones your site, it has to rename your database table prefix on the copy, for example from wp_ to wpstg0_, so the staging tables can live next to your live tables. That prefix rename is supposed to touch only the table names and a small, well defined set of fields.
In the Next-Gen engine, this rename was applied too broadly. Instead of renaming only the table prefix, it replaced the text wp_ everywhere it appeared, including inside WordPress metadata field names and inside stored values.
The most visible result is that metadata keys containing wp_ get renamed. For example, the field _wp_page_template, which tells WordPress which template a page should use, becomes _wpstg0_page_template. WordPress then cannot find the page’s assigned template, so the page falls back to the theme’s default template. On a static front page this looks broken: a sidebar reappears and the hero or background layout is gone, even though the correct theme is still active.
Which Data Is Affected
Because the replacement matched the plain text wp_ anywhere it appeared, several kinds of data on the staging copy can be affected. Here is the detailed breakdown.
| Data | Metadata field | Affected? | What you see on the staging site |
|---|---|---|---|
| Page templates | _wp_page_template |
Yes | Pages assigned a custom template render the theme’s default template instead. Front pages and landing pages can look broken: sidebars reappear, hero or background layouts disappear. |
| Image and media metadata | _wp_attachment_metadata |
Yes | Image sizes and srcset break where WordPress reads this field, so some images do not display at the intended size. |
| Attached file paths | _wp_attached_file |
Yes | The stored path for each media file is renamed. Images may still load through a fallback, but the reference is no longer correct. |
| Image alt text | _wp_attachment_image_alt |
Yes | Alt text can be lost where it is read from this field. |
| Featured images | _thumbnail_id |
No | This field has no wp_ in its name, so it is untouched. Featured images keep working. |
| Serialized settings | any stored value containing wp_ |
Yes | Plugin and theme settings that are stored as PHP serialized data can become unreadable if the value contained the text wp_. No error is shown; the value is simply wrong on the clone. |
| Core site options | page_on_front, active theme, and similar |
No | The core options we checked stayed intact, which is why the site still loads and the correct theme stays active. |
The serialized data case deserves a word of explanation, because it is the quiet one. PHP serialized data stores a character count right next to each piece of text. When wp_ (three characters) was replaced with wpstg0_ (seven characters), the text grew but the stored character count did not change. WordPress and plugins can then no longer read that value correctly. There is no warning; the setting just behaves as if it were empty or wrong on the staging site.
To be completely clear once more: every item above describes the staging copy only. None of this happens to your live database.
What We Are Doing About It
We take data integrity extremely seriously, and we are sorry this slipped through in the beta engine. Here is our plan:
- We are temporarily disabling the Next-Gen cloning engine. In the next releases, the free WP STAGING plugin version 4.9.2 and WP Staging Pro version 6.9.2, the Next-Gen engine will be switched off until the fix is complete and fully tested. The Classic cloning engine remains available and is the default.
- We are fixing the root cause. The prefix rename is being scoped back down so it only touches the fields it is meant to touch, exactly the way the Classic engine already does.
- We will re-enable Next-Gen only after verification. Once the fix passes our tests, we will bring the Next-Gen engine back in a later release.
What You Should Do
For most people, the simplest and safest path is to start the staging site over:
- Delete the affected staging site. Open WP STAGING, find the staging site you created with the Next-Gen engine, and delete it.
- Create a new staging site with the Classic cloning engine. Because Classic copies your data verbatim from the live site, the new staging site is a faithful, correct copy.
Please do not push a Next-Gen staging site to your live site. Pushing a corrupted clone back over your live data would carry the corruption to production. As long as you only delete the staging site and re-clone with Classic, your live site stays safe.
How to Recover Data You Want to Keep
If you have already done work on the affected staging site that you do not want to lose, you do not have to throw it away. Your live site still holds the correct, uncorrupted data, so the missing pieces can be restored. There are three paths, from simplest to most involved.
Option 1: Re-Clone With the Classic Engine (Recommended)
If you have not made changes on the staging site that you need to keep, delete it and create a new staging site with the Classic engine, as described above. This gives you a clean, correct copy of your live site and needs no scripting.
Option 2: Repair the Staging Database With a Script (Advanced)
The most visible breakage, lost page templates and image metadata, can be repaired directly on the staging site. In those cases the value itself is still intact; only the field name was renamed. Renaming the field back restores it, and this does not touch your live site at all.
This is a manual, advanced step. Run it only on the staging site, never on your live site, and back up the staging database first. The commands below use WP-CLI, run over SSH. If your host does not have WP-CLI installed (many shared hosts do not), skip this block and use the phpMyAdmin version further down instead.
# Run these on the STAGING site only. Never run them against your live site.
# 1) Back up the staging database first.
wp db export staging-before-repair.sql
# 2) Find your staging site's table prefix (for example wpstg0_).
wp config get table_prefix
# 3) Rename the corrupted metadata keys back to their original names.
# Replace wpstg0_ below with the prefix from step 2 if it is different.
for key in page_template attachment_metadata attached_file attachment_image_alt attachment_backup_sizes; do
wp db query "UPDATE wpstg0_postmeta SET meta_key='_wp_${key}' WHERE meta_key='_wpstg0_${key}'"
done
# 4) Clear caches so the restored templates take effect.
wp cache flushAfter running this, reload the staging front page. The custom template, hero, and layout should be back, and images should return to their correct sizes. This script fixes the metadata keys whose value was left intact. It does not repair serialized values that were themselves rewritten (see Option 3).
No WP-CLI? Use phpMyAdmin or Adminer instead. Most hosts include phpMyAdmin or Adminer in the control panel, so you do not need WP-CLI. First back up the database from the Export tab, then run the same repair as SQL. Replace wpstg0_ with your staging site’s real table prefix.
UPDATE wpstg0_postmeta SET meta_key = '_wp_page_template' WHERE meta_key = '_wpstg0_page_template';
UPDATE wpstg0_postmeta SET meta_key = '_wp_attachment_metadata' WHERE meta_key = '_wpstg0_attachment_metadata';
UPDATE wpstg0_postmeta SET meta_key = '_wp_attached_file' WHERE meta_key = '_wpstg0_attached_file';
UPDATE wpstg0_postmeta SET meta_key = '_wp_attachment_image_alt' WHERE meta_key = '_wpstg0_attachment_image_alt';
UPDATE wpstg0_postmeta SET meta_key = '_wp_attachment_backup_sizes' WHERE meta_key = '_wpstg0_attachment_backup_sizes';After running the SQL, clear any caching plugin from the staging dashboard so the restored templates take effect.
Option 3: Copy the Affected Data From Your Live Site (We Will Help)
For the deeper serialized-value corruption, the reliable source of truth is your live site. The affected rows can be copied from the live database into the staging database, and the prefix references can be re-normalized the correct, scoped way. This is scriptable, but exactly which rows to copy depends on the plugins and themes you run, and a blanket copy could overwrite the changes you made on the staging site.
For that reason we do not recommend running a blind, one-size-fits-all restore script. Instead, let us help. Our support team will work with you to migrate only the parts you need from your live site to a fresh, healthy staging site, so your staging-only work is preserved and nothing on your live site is put at risk.
We Are Here to Help
We know how disruptive a broken staging site can be, and we are genuinely sorry. This should not have happened, and we take full responsibility for it. For most sites the fix is in your hands: delete the affected staging site and re-clone with the Classic engine, or run the repair script above. If those steps do not cover your case, for example you have work on the staging site to keep and serialized settings were affected, contact us on the WP STAGING support page and we will help you migrate it.
We let you down by shipping a clone process that produced a broken staging site, and we are working hard to make it right. Thank you for your patience while we fix this.
Related Articles
