Moving from Custom Product Tabs for WooCommerce (YIKES)

The current release on WordPress.org is 1.8.6, dated 12 April 2025. Its plugin header declares Tested up to WordPress 6.7 and WC tested up to WooCommerce 9.8.

None of that makes the plugin stop working from one day to the next. WordPress does not disable plugins that go quiet, and a shop can run 1.8.6 for a long time without noticing anything. It does mean nobody is currently shipping fixes for it.

The authors built something a lot of shops depend on, and this page is not an argument about their work. It is a description of what a successor plugin has to do to take over that data safely.

Three properties of the code matter when you are deciding what to do. All three are visible in the released 1.8.6 source.

1. A product save rewrites the whole tab list from the submitted form. The save routine reads a hidden field holding the number of tabs, rebuilds the list from the posted fields and writes it with update_post_meta unconditionally. If those fields do not arrive — the usual cause is PHP's max_input_vars limit truncating a large product form — the meta is overwritten with an empty list, and the tabs are gone from the storefront. This is the failure that most "my product tabs disappeared" reports come down to.
2. Deleting the plugin deletes the tab data. Its uninstall.php removes every yikes_woo_products_tabs post meta row and the saved-tab options. Deactivating the plugin is harmless and leaves everything in the database. Choosing Delete in the plugins screen is not.
3. Content is unslashed twice on save. The save routine calls stripslashes() and then hands the value to update_post_meta(), which unslashes again. Backslashes inside tab content — JSON in a shortcode attribute, an escape sequence in inline script — are lost a little more on each save.

Beyond the code: an unmaintained plugin receives no compatibility updates as WordPress and WooCommerce change, and no security fixes.

It reads it, immediately, without changing it

Product Tabs Studio ships a permanent read-only adapter for that data format. For any product that has no tabs of its own in the new plugin, it reads yikes_woo_products_tabs and renders those tabs directly. There is no import step you must complete before the storefront looks right.

The adapter reproduces the original behaviour rather than approximating it:

• Order. Custom tabs are given priorities 25, 26, 27 and so on, and the Reviews tab is pushed after them — the same arithmetic the old plugin used, so the tab strip does not reshuffle.
• Keys. Each tab's stored id becomes the tab key verbatim, so existing #tab-… anchors and links keep working.
• Markup. When YIKES data is detected the plugin sets its legacy CSS mode, which prints exactly the old heading markup: <h2 class="yikes-custom-woo-tab-title yikes-custom-woo-tab-title-{key}">, with no extra wrapper. Theme CSS written against those classes keeps applying.
• Key collisions. The collision policy is set to replace, which reproduces the old rule that a tab named "Description" takes over WooCommerce's Description tab. A key owned by some other plugin's tab is still renamed rather than overwritten.
• Content pipeline. The old yikes_cpt_use_the_content option is read once and translated into the matching rendering mode.
• Old filters. Legacy hook mode re-fires yikes_woo_filter_all_product_tabs, yikes_woocommerce_custom_repeatable_product_tabs_heading and yikes_woocommerce_custom_repeatable_product_tabs_content, so theme snippets written against them still run.

It copies your saved tabs into a library

The old plugin's "saved tabs" live in a site option and are copied into each product that uses them. On first run, Product Tabs Studio creates one global tab in its own library for each saved tab, keeping the title, content, slug and admin label, and recording where it came from. Nothing is written to any product during this step, and the original option is left exactly as it was.

It converts a product only when you save that product

A product moves to the new native storage the first time you save it from the Product Tabs panel. Until then it keeps being read from the old meta. When a product does convert, the plugin can keep a copy in the old format in sync — that setting is switched on automatically when legacy data is found — so the old plugin would still find its data if you reactivated it.

If the old plugin is still active

When both plugins are active, Product Tabs Studio removes the old plugin's front-end and admin callbacks so that only one of them renders tabs and its product panel cannot overwrite tab data. An admin notice and a Site Health check both report this state. Deactivating the old plugin is still the cleaner arrangement.

For the other two plugins with adapters (Barn2 and WB), the opposite rule applies: while their plugin is active, Product Tabs Studio renders nothing from their data, to avoid duplicate tabs.

Reading through the adapter is a supported, permanent state. Converting is worth doing when you want the tabs to behave like native data everywhere: bulk work in the new plugin, WPML or Polylang translation of tab fields, and JSON export and import between environments.

The conversion is labelled Convert to native storage (optional) on the Migrate card and runs in batches of 50 products, resumable if the page is closed. For each product it writes the adapter's output into the native format and records where it came from. The old meta is not deleted, and the mirror keeps it current afterwards.

Before that, Dry run reports what would happen without writing anything: how many products and tabs, plus warnings for tab keys that collide with WooCommerce defaults, duplicate keys on one product, empty titles, and content that sanitising would alter. Verify then renders every migrated product both ways — through the adapter and from native storage — and compares the ordered keys, the titles and a checksum of each rendered panel, listing any product where they differ.

Reversibility is a property of how the plugin is built, not a feature you have to enable:

• The adapter only reads. It never writes to yikes_woo_products_tabs or to the saved-tab options.
• Migration only adds: new global tabs and new native product meta. The old keys are left untouched.
• The mirror setting keeps a copy of each converted product's tabs in the old format, so the old plugin finds its data if you reactivate it.
• Rollback on the Migrate card deletes exactly what the migration created: the global tabs it made, and the native tab data of products that have not been edited by hand since. Products you did edit afterwards are kept and listed by name, so nothing is removed behind your back. The adapter is switched back on.

One asymmetry to know about: edits you make to a converted saved tab in the new editor are not written back into the old plugin's saved-tab option. If you roll back after editing global tabs, those tabs revert to their content at the time of conversion.