Recovering lost tabs

Open one affected product in the editor and look at the Product Tabs panel in the Product data box.

• The rows are there, with their content. The data is fine and this is a rendering problem, not a loss. Nothing on this page applies. Go to tabs not appearing on the product page, which covers themes that removed the tabs output, page builders, and a second tabs plugin being active.
• The panel is empty, or has fewer rows than it should. Continue below.

Check a second product before concluding anything. One product missing its tabs and the whole catalogue missing its tabs have different causes, and the second usually points at a plugin state rather than at a save.

Every time this plugin writes a product's tabs, it first pushes the previous value into a history kept on that same product. This is the first thing to try, because it is instant and it commits nothing until you say so.

1. Open the product and look at the status bar at the top of the Product Tabs panel. It shows when the tabs were last saved and by whom.
2. Open Restore previous version. Each entry shows the date, the user, why it was written and how many tabs it held.
3. Pick one. You are asked to confirm, and then the rows in the panel are replaced by that version. Nothing is written yet. Read it, and if it is right, update the product or press Save tabs now.

The reason shown against each entry tells you what replaced it:

saved with the product

An ordinary product update.

Save tabs now

The panel's own save button.

restored

A previous restore. Restoring is itself recorded, so undoing a restore is one more click.

migration

A conversion from another tab plugin's data.

import

A JSON or CSV import.

before conversion

The state another plugin's data was showing, captured automatically the first time this plugin wrote tabs for that product. This one is worth knowing about: it means a conversion cannot lose what was there before it.

Five versions are kept per product by default. You can raise that to twenty under Tab Settings → General. There is also a size ceiling of 256 KB of history per product; when tabs are very large, the oldest entries are dropped early to stay under it, so a product with enormous tabs may hold fewer versions than the setting says.

The history lives on the product, in its own post meta. It is not a WordPress revision, so revision pruning and the usual "keep only N revisions" tricks do not touch it.

Two situations where the history will not help, so that you do not spend time on it: a product whose tabs were only ever supplied by another plugin and never saved here has nothing in its history yet, and a product whose native tab data was deleted along with the plugin has had its history deleted with it.

The most common way tabs vanish, across every plugin in this category, is mundane and worth understanding, because it tells you whether to keep looking.

PHP refuses to parse more than max_input_vars fields in one request — 1000 by default. Everything past the limit is discarded with no error and no warning. A product page with many attributes, many variations and several tabs passes 1000 fields more easily than it sounds. A plugin that writes whatever arrived then writes a short list over a long one, and the tabs are gone.

This plugin counts the rows it rendered into the form and compares them with the rows that come back. If fewer arrive, it writes nothing and says so:

Your product tabs were NOT saved because the form was truncated by PHP (max_input_vars = 1000). Increase max_input_vars in php.ini or use "Save tabs now". Previous tabs are intact.

A form that arrives with no tabs at all, when the product had some and you did not empty the panel, is refused the same way rather than treated as "delete everything". So is a payload that cannot be read. In each case the existing data is left exactly as it was. The full message and the ways to fix the limit are under the truncated-save guard.

The other half of the guard is that tabs are written on one code path only: a product save from the editor with the Product Tabs panel present, or that panel's Save tabs now button. Autosaves, revisions, quick edit, bulk edit, the WooCommerce CSV importer, the REST API, the block-based product editor and product duplication do not reach it. A save whose security token is missing or stale is skipped and logged rather than acted on. If your tabs disappeared while you were bulk-editing prices or running a CSV import, this plugin did not write that change.

If two people edit the same product at once, the second save still goes through — work is never thrown away — and a notice says it happened. The version that was overwritten is in the history.

The Health tab at Products → Tabs Tools & Health reports how many saves were refused in the last thirty days and the current max_input_vars, so you can tell whether this has been happening quietly.

This is the one that costs people their content, and it is worth reading even if your tabs are currently fine.

Deactivating a plugin and deleting a plugin are not the same act. Deactivating stops the code running and changes nothing in the database; you can undo it in a second. Deleting removes the files, and on the way out WordPress runs that plugin's uninstall routine. Many plugins use that routine to erase their own data — which is polite behaviour, and exactly what you do not want when their data is the tabs your shop is still showing.

What that means for the three tab plugins this one can read:

Three details that make this trap sharper than it looks.

• WordPress asks "are you sure" before deleting a plugin, but it says nothing about what the plugin will delete, because it cannot know. The confirmation reads like a question about files.
• There is no undo. The rows are removed from the database; the trash does not apply to post meta.
• Updating a plugin does not run its uninstall routine. Only Delete does. So a plugin that has sat inactive for two years is harmless until the day somebody tidies up the Plugins screen.

Product Tabs Studio cannot intervene in WordPress's delete action, so what it does instead is tell you, repeatedly and in plain words. The Health check about another tabs plugin says it, and so does an admin notice while legacy data is detected: deactivating is safe, deleting is not, convert first.

The safe order

1. Deactivate the old plugin. Its tabs keep appearing, read directly from where they already are, with their existing order and keys. Nothing has been converted and nothing has been changed.
2. Look at the storefront. Check a handful of products in different categories. This is the moment to notice a difference, while everything is still reversible.
3. Export from Tools & Health → Import / Export. A JSON file on your own disk costs nothing and is the only step here that survives a mistake at every later stage.
4. Convert from Tools & Health → Migrate: dry run, then migrate, then verify, which compares the two renderings tab by tab. The old plugin's data is not modified by any of these steps.
5. Then, and only then, delete the old plugin. By that point your tabs no longer depend on its data, and whatever its uninstaller removes is a copy you are no longer reading.

The per-plugin guides cover each of these in detail: Custom Product Tabs (YIKES), Barn2, WB.

Then work through these in order. They are ordered by how likely they are to work, not by effort.

1. Check the product panel and its history anyway. If tabs had ever been saved or converted here, the native data and its history are untouched by the other plugin's uninstaller. This is the case for anyone who ran the conversion, even partially.
2. Check what legacy data is left. The Migrate tab of Tools & Health counts, per plugin, how many products and global tabs still have data and whether an adapter is reading it. If you deleted one plugin but another one's data is still present, that is visible here. Note that a copy kept in the Custom Product Tabs (YIKES) format is stored under that plugin's own meta key, so its uninstaller removes the copy along with the original; it is a way back to that plugin, not a safety net against deleting it.
3. Restore from a backup. This is the real answer and usually the only complete one. Most hosts keep nightly backups for one to four weeks; ask, rather than assuming. Restore the backup to a staging site rather than over the live shop, then copy back only the tab data. Rolling the whole site back to yesterday also rolls back yesterday's orders, stock levels and customers, which is a worse problem than missing tabs.
4. Import a JSON export, if one exists from before the deletion. Products are matched by SKU first and then by id, so an export taken on staging still lands correctly.

If none of those apply — no native data, no mirror, no backup, no export — the content is gone and no plugin can bring it back. That is worth saying plainly at the point where you would otherwise spend an evening looking. Product titles, prices, images and orders are untouched; what is lost is the tab text. Rewriting it once and putting it in global tabs, so the same text lives in one place for many products, is usually less work the second time.

• Export before anything structural. Tools & Health → Import / Export writes one JSON file with the settings, every global tab and its rules, and every product's tabs with the product id and SKU. It runs in batches, so catalogue size is not a reason to skip it.
• Raise the history depth if you edit tabs often. Twenty versions per product is the maximum and costs a little post meta.
• Know what your host keeps. The retention window of your backups is the real boundary of what is recoverable, for tabs and for everything else.
• Leave the uninstall options alone. This plugin deletes nothing when it is removed unless you opt in under Tab Settings → Data. The first checkbox, off by default, removes the settings, the global tabs and the per-product tab data and history. A second one, which only takes effect together with the first, additionally removes the Custom Product Tabs (YIKES) copies of the tabs; switching that on means you can no longer switch back to that plugin. Barn2 and WB data is never touched by this plugin's uninstaller.

Copy the system report from Tools & Health and send it with your question. It says which tab plugins are installed, how much data each one still has, whether the adapters are reading it, and what the last fifty log entries were — which is most of what anyone would need to ask you at this point. See Support.

Say what happened immediately before the tabs went, as precisely as you can remember. "I deleted a plugin", "I saved a product with 40 variations" and "I ran a CSV import" lead to three different answers, and the first one is time-sensitive because backup windows expire.