Troubleshooting

The full message names the current limit:

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.

What happened. PHP refuses to parse more than max_input_vars fields in a single request — 1000 by default. Everything past that limit is discarded silently: no error, no warning, just a shorter form than the browser sent. A product page with many attributes, many variations and several tabs reaches 1000 fields more easily than it sounds.

What the plugin did. It counted the tab rows it rendered, saw fewer arrive, and refused to write. Your previous tabs are still in the database, unchanged. This is the guard working, not a bug.

How to fix it, in order of preference:

1. Raise the limit. In php.ini, set max_input_vars = 5000 and restart PHP. Many managed hosts expose this in their control panel; some also require raising suhosin.post.max_vars if that extension is installed. This fixes the problem for every plugin on the site, not just this one.
2. Use "Save tabs now". The button at the bottom of the Product Tabs panel saves the tabs on their own, in a request that carries nothing else. It works regardless of how large the rest of the product form is.
3. Reduce the form. Fewer attributes or variations on that product, or fewer tabs, brings the field count back under the limit.

With JavaScript enabled the panel packs all the tab rows into a single field before submitting, so the tabs themselves add almost nothing to the field count. The guard exists for the case where that field is dropped too, and for browsers with JavaScript off.

The Health tab reports how many saves were refused in the last thirty days and the current limit, so you can confirm a fix worked.

Open the Health tab first. Three checks cover this:

• WooCommerce product tabs output. If a classic theme has removed the hook that prints the tabs, no plugin can put them back by adding to the list. The fix is the [ptstudio_tabs] shortcode in the template, or restoring the hook.
• Theme overrides the product tabs template. Your theme is supplying its own tabs.php. It may filter or ignore parts of the tab list. The system report names the file.
• Another product tabs plugin is active. While one of the plugins with an adapter is active, this plugin does not render that plugin's data, to avoid duplicates.

If the theme is fine, check the tab itself: an empty title is never rendered, an unticked Enabled box hides it, and a global tab in "Only where attached manually" mode appears only where you attached it. On a global tab, the sidebar's match count tells you immediately whether the rules match anything.

When Elementor, Divi, Bricks or WPBakery takes over the single product template, two things happen: the builder may not print the WooCommerce tabs at all, and it usually rewrites the_content filter in a way that changes what tab content renders to.

The plugin detects those builders and recommends the isolated rendering pipeline, which applies the standard content filters by hand instead of going through the_content. Set it under Tab Settings → Rendering, and use the Test render button there: pick a product and it renders that product's tabs in all three pipelines and reports the output length, whether it was empty, and any error, so you can choose on evidence.

If the builder's layout does not print tabs at all, place [ptstudio_tabs] where they belong, or [ptstudio_tab key="…"] to place a single panel.

All three pipelines run shortcodes, so a shortcode that does nothing is usually one whose plugin only registers it on certain pages. Two specific cases:

• The shortcode is registered late, after the tabs have already rendered. Nothing in the tab plugin can help there.
• You wrote [[example]] expecting it to be executed. It stays escaped, which is the documented WordPress behaviour. Custom Product Tabs for WooCommerce ran shortcodes twice and did execute it; this plugin runs one pass.

Check, in this order: whether the tab has an explicit priority (a number in its Advanced section or its settings box overrides automatic placement); where the automatic slot sits on the Tab order screen; and whether something else is reordering the tabs after this plugin runs. WooCommerce sorts the tabs at the end of the chain, and themes commonly hook in just before that. The system report lists every callback on the product tabs filter with its priority and file.

If Reviews is no longer last, its priority has been changed — either on the Tab order screen or by another plugin. Reviews is pushed after the automatic tabs only while it still carries the priority WooCommerce gave it.

Two tabs on the same product asked for the same key, so the second was renamed rather than allowed to overwrite the first. A notice reports it when it happens. Give one of them a different key, or, if you meant a tab to replace a WooCommerce default tab, read about key collision policies.

Open the product, look at the status bar at the top of the Product Tabs panel and use Restore previous version. It lists the stored versions with their date, the user and what caused them. Choosing one fills the rows; nothing is written until you save.

If the tabs came from another plugin and stopped appearing, the likely cause is that plugin being active again — check the Health tab — or a completed migration having switched the adapter off, in which case the tabs are now native and should be in the panel.

Recovering lost tabs goes through this in order, including what to do when an old tabs plugin was deleted rather than deactivated.

The global tab that row pointed at was trashed or deleted. The product still holds a copy of the content, so nothing is lost. Either restore the global tab from the trash, or press the button on the row to convert it into a tab belonging to that product.

Your save was applied — the plugin does not throw away work — and the version you overwrote is in the history, one click away. The notice exists so that two people editing the same product notice it.

Tab content is kept verbatim when the person running the job may post unfiltered HTML. Otherwise WordPress's post-content sanitising applies, which strips script and a few other tags. The dry run counts exactly what would change before you run anything, and the report after the run lists it. Running the migration as an administrator on a single-site install avoids the sanitising step.

Copy the system report from Tools & Health and include it with your question. It answers most of what anyone would otherwise have to ask you. See Support.