PHP warnings and compatibility

A production site should not print PHP messages to the screen at all. If you can read a deprecation notice at the top of the admin, or worse on the storefront, the site is configured to display errors. That is a bigger problem than the deprecation itself, because messages contain absolute file paths and sometimes query fragments.

In wp-config.php, above the line that says it should stop editing:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

That records everything in wp-content/debug.log and shows nothing to anyone. Reproduce the problem, then read the end of that file. When you are finished, set WP_DEBUG back to false; a debug log left on grows without limit and is readable by anyone who guesses the URL unless the directory is protected.

On a live site with real customers, do the diagnosis on a staging copy. Everything below works the same there.

Every PHP message ends with a file path and a line number. That path is the answer, and it is not a guess:

Deprecated: Automatic conversion of false to array is deprecated in
/home/site/public_html/wp-content/plugins/some-plugin/admin/class-tabs.php on line 214

Read the segment after wp-content/. plugins/some-plugin/ means that plugin's code; themes/some-theme/ means the theme. That is the file that has to change, and its author is the person who can change it.

Two complications are worth knowing about.

• The path points at wp-includes/ or wp-admin/. WordPress core is rarely the culprit. Something passed core a value it no longer accepts. With WP_DEBUG_LOG on, the log often carries a backtrace; the first line below the core file that lives in a plugin or theme directory is the caller you want.
• The theme's file is named but a plugin's data caused it. This happens, and it does not change the conclusion. Code that cannot cope with the value it is given is the code that needs fixing, even when the value is unusual.

Confirming by elimination

When the path is unclear or you want to be certain, isolate it. WordPress's own Site Health tools include a troubleshooting mode that disables plugins and switches themes for your session only, leaving visitors on the working site. Failing that, on a staging copy:

1. Switch to a default theme such as Storefront or Twenty Twenty-Five. If the notice disappears, it is the theme.
2. Restore your theme and deactivate plugins in halves rather than one at a time, until the notice goes.
3. Reactivate everything and confirm the notice comes back with the one you identified.

If the culprit turns out to be a product tabs plugin that is no longer maintained, deactivating it is safe: this plugin reads its stored tabs directly and the storefront stays intact. Deleting it is a different matter, and there is a real trap in it — read the deletion trap before you press Delete.

Deprecated

Code uses something PHP intends to remove. It still works today. It will become a warning or an error in some future PHP version. Nothing is broken now.

Warning

Something went wrong and PHP carried on with a fallback. Output may be subtly incorrect. Worth investigating.

Fatal error

Execution stopped. This is what produces a white screen or a "critical error" email from WordPress. Not the same category as the above.

Most deprecation notices in older plugins come from a handful of changes: PHP 8.1 deprecated passing null to string functions that expect a string, and deprecated converting false to an array by writing to it; PHP 8.2 deprecated creating object properties that were never declared, and the ${…} form of variable interpolation in strings; PHP 8.0 removed create_function() and made several previously tolerated argument mistakes into errors. A plugin last updated before 2021 will meet several of these. The fixes are small and local, which is why an actively maintained plugin usually clears them within a release or two of each PHP version.

None of this is specific to tabs. A deprecation notice in a tabs plugin does not put your tab data at risk on its own; the data is post meta and PHP versions do not touch it.

Products → Tabs Tools & Health has a System report tab: a block of text with a Copy to clipboard button. It does not capture PHP notices — it is not an error log, and it will not tell you which plugin emitted a deprecation. What it does tell you is which versions and which code are involved, which is most of what anyone would otherwise have to ask you:

• Versions of WordPress, WooCommerce, PHP, this plugin and its database schema, the locale, and whether WP_DEBUG and SCRIPT_DEBUG are on.
• The active theme and its parent, and whether it is a block theme.
• Every plugin that is active, with its version. This is the list you narrow down when eliminating.
• Whether your theme overrides the WooCommerce tabs template, and the path of the file that does it.
• Every callback attached to WooCommerce's product tabs filter, with its priority and the file and line it lives in. Callbacks that run after this plugin are marked as such, because they are the ones able to reorder or remove tabs after we have added them. When tabs are wrong rather than merely noisy, this section usually names the responsible code outright.
• PHP limits: max_input_vars with a verdict comparing it against your largest product form, memory limit, execution time, post_max_size, upload_max_filesize, and whether the mbstring and json extensions are present.
• Which page builder was detected, whether WPML or Polylang is present, whether HPOS is enabled and whether an object cache is in use.
• Counts of products with tabs, global tabs, and the last fifty entries of this plugin's own activity log.

The Health tab next to it runs six checks about tabs specifically, and the same checks appear in WordPress Site Health. Only one of them concerns a PHP setting: Truncated product saves, which reports saves refused because the form exceeded max_input_vars, and shows the current value. See the truncated-save message for that one.

The Log tab lists what this plugin itself recorded — refused saves, rendering fallbacks, key renames, decoding problems. It is a local table and is never sent anywhere.

We say 8.3 because that is the range we run the plugin on. Newer PHP versions are not claimed here; when one has been exercised properly, this page and the readme will say so and not before. If your host has already moved past that range, the plugin may well be fine, but you would be ahead of our testing rather than covered by it.

What "no PHP 8-only syntax" is worth: it means the plugin will not fail to parse on an older host, which is the failure that takes a site down. It is not a promise that no future PHP version will ever deprecate something we use. When one does, the fix ships as an update.

Then it is ours to fix, and we would like the report. Send:

• The complete message, with the file path and line number, exactly as it appears in debug.log.
• The system report from Tools & Health.
• What you were doing when it appeared: which screen, which action, which product.

A deprecation notice with a file and line in it is usually a short fix. Without them it is guesswork, which is why the log matters more than a screenshot. See Support.