Blog

If you’ve landed here because your site is showing something like Warning: count(): Parameter must be an array... in the middle of a page — or a plugin’s support team asked you to “turn on debug mode and send the log” — this guide is for you.

WordPress hides most PHP errors and warnings by default so visitors never see them. That’s good for your site’s visitors, but it also means you usually can’t see what’s actually broken either. Debug mode turns that hiding off, on your terms, so you can find the exact line causing the problem — or copy the exact error text to send to support.

This takes about 5 minutes and doesn’t require touching any plugin code.

What “debug mode” actually does

WordPress ships with a set of constants you can set in one file, wp-config.php, that control how PHP errors, warnings, and deprecation notices are handled:

• WP_DEBUG — the master switch. Turns on PHP error reporting across WordPress core, themes, and plugins.
• WP_DEBUG_LOG — writes every error to a log file (wp-content/debug.log) instead of (or in addition to) showing it on screen.
• WP_DEBUG_DISPLAY — controls whether errors print directly on the page for anyone visiting. You want this off, even while debugging — see the warning below.

The recommended combination for diagnosing a live site is: log everything, display nothing.

Method 1: Edit wp-config.php (most reliable)

wp-config.php lives in your WordPress root folder — the same folder as wp-admin and wp-content. Access it via your host’s File Manager or an FTP client (FileZilla, Cyberduck, etc.).

1. Open wp-config.php and find this line near the bottom:

   /* That's all, stop editing! Happy publishing. */

2. Add this block directly above it:

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

3. Save the file and reload your site.

Nothing will look different on the page itself — that’s the point of WP_DEBUG_DISPLAY = false. Instead, every warning, notice, and error is now being written to a new file: wp-content/debug.log.

If wp-config.php already has a define( 'WP_DEBUG', ...) line further up, edit that one instead of adding a second one — WordPress only reads the first definition of a constant, and PHP will throw its own error if you accidentally define it twice.

Method 2: No file editing (managed hosting / no FTP access)

Some managed WordPress hosts lock wp-config.php from editing, or you’d rather not touch it directly. Two free plugins cover this:

• WP Debugging — adds the same WP_DEBUG / WP_DEBUG_LOG / WP_DEBUG_DISPLAY behavior above through a plugin instead of a file edit. Activate it, it’s on.
• Query Monitor — goes further, showing PHP errors, slow database queries, and which plugin/theme triggered each one directly in an admin toolbar panel. Genuinely useful even after you’ve fixed the immediate problem.

Where to find and read the log

Connect via FTP/File Manager to wp-content/debug.log. If the file doesn’t exist yet, it’s created the first time an error actually occurs after you enable logging — reload a few pages on your site (especially the one that showed the warning) if it’s empty.

A typical line looks like this:

[09-Sep-2026 14:22:07 UTC] PHP Warning:  count(): Parameter must be an array or an object
that implements Countable in /wp-content/plugins/some-plugin/some-plugin.php on line 412

Three things to read out of that line:

1. The plugin/theme folder (/wp-content/plugins/some-plugin/) — tells you which plugin is responsible, even if the error message itself doesn’t name it.
2. The file and line number (some-plugin.php on line 412) — exactly where in that plugin’s code the problem is.
3. The error type (PHP Warning vs PHP Notice vs PHP Fatal error) — a Warning or Notice is usually cosmetic (the site still works, just noisily); a Fatal error means something actually stopped executing, which is far more urgent.

Common warnings and what they mean

Most of what you’ll see once you enable this falls into a handful of repeat offenders — almost all caused by plugins written for an older version of PHP, running on a newer one:

If any of these are coming from a plugin, updating that plugin to its latest version is the first thing to try — most of this class of warning gets cleaned up in routine PHP 8.x compatibility updates, YotuWP included.

Turn debug mode back off when you’re done

Debug logging on its own is low-risk (nothing is shown to visitors, it just writes a file), but there’s no reason to leave it running indefinitely — the log file grows forever, and it sometimes contains file paths you don’t need publicly guessable. Once you’ve got what you need:

define( 'WP_DEBUG', false );

Or deactivate/delete the WP Debugging plugin if you used Method 2. You can also just delete wp-content/debug.log at any time — WordPress recreates it automatically the next time WP_DEBUG_LOG is on and something logs.

Never enable WP_DEBUG_DISPLAY on a live site. It prints file paths and code details on the page for anyone to see, which is a genuine information-disclosure risk, not just an ugly page. Log-only (WP_DEBUG_DISPLAY = false) is the safe way to debug production.

Reporting the error to us

If the warning is coming from wp-content/plugins/yotuwp-easy-youtube-embed/ (or yotuwp-pro/), copy the exact log line and send it our way through the contact page along with:

• Your YotuWP version (YotuWP → General Settings, or the Plugins screen)
• Your WordPress version and PHP version (Tools → Site Health → Info)

That’s usually enough for us to reproduce and fix it directly, instead of guessing from “it shows a warning sometimes.”

FAQ

Will turning on debug mode break my site?
No. WP_DEBUG on its own doesn’t change how anything runs — it only changes whether PHP tells you about problems that were already happening silently.

I enabled it and nothing showed up in debug.log — why?
The file is only created once an actual error occurs after logging is turned on. Visit the specific page where you saw the warning, then check again.

Is a Warning or Notice something I need to fix immediately?
Usually not — they mean the site is still working but something older/less strict is happening under the hood. A Fatal error is the one that actually needs urgent attention, since it stops the page from finishing.

Can I just ignore the warnings if the site looks fine?
For a short-term band-aid, yes — with WP_DEBUG_DISPLAY off, visitors never see them either way. But they’re worth fixing (usually just by updating the plugin/theme in question) since some of today’s Deprecated notices become tomorrow’s Fatal errors once PHP removes the old behavior entirely.

Running an older version of YotuWP? Update to the latest release for the current PHP 8.x / WordPress compatibility fixes, or see what’s in YotuWP Pro.