TL;DR: クイックフィックス
Warning: count()エラーを解決するポイントは1つです。カウントしようとしている変数が実際に「カウント可能（countable）」であることを確認することです。開発者の方は、nullやスカラ値を適切に処理するために、以下のようなチェック処理でコードを囲んでください。
// 以前の、リスクのある書き方:
$count = count($maybe_null_variable);
// 安全でモダンな書き方:
$count = (is_array($maybe_null_variable) || $maybe_null_variable instanceof Countable) ? count($maybe_null_variable) : 0;
サイト運営者の方であれば、修正はより簡単です。すぐにプラグインやテーマを更新してください。この警告のほとんどは、PHP 7.2で導入された厳格なルールに対応していない古いコードが原因で発生します。
なぜエラーが発生するのか？
2017年末にリリースされたPHP 7.2より前は、count()関数は渡されるデータ型をそれほど気にしていませんでした。単一の文字列やnullを渡しても、エラーを出さずに1や0を返していました。その結果、関数がデータ型の不一致を隠蔽してしまい、不適切なコーディング習慣につながっていました。
PHP 7.2ではコードの品質を向上させるためにルールが変更されました。現在、count()にはarray（配列）またはCountableインターフェースを実装したオブジェクトを渡すことが厳密に求められます。それ以外のものを渡すと、PHPは警告を発信します。WordPress環境では、プラグインがメタデータをデータベースに問い合わせた際、期待される結果リストの代わりにfalseが返ってきた場合などにこの現象がよく発生します。
原因箇所の特定
まず、警告を発生させている具体的なファイル名と行番号を特定する必要があります。エラーがフロントエンドに表示されていない場合は、WordPressのログを確認する必要があります。
- FTPやファイルマネージャーを使用して、
wp-config.phpファイルを開きます。 define('WP_DEBUG', false);という行を探し、trueに変更します。- 画面ではなくファイルにエラーを記録するために、その直下に以下の行を貼り付けます：
define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);
- サイトをリロードします。その後、`/wp-content/debug.log`を開きます。
`/wp-content/plugins/outdated-plugin/functions.php on line 145`のような行を探してください。これで問題の場所が正確に特定できました。
## コードを修正する3つの方法
### 方法1: is_countable チェック (PHP 7.3以降に最適)
サーバーがPHP 7.3以降を実行している場合は、専用の`is_countable()`関数を使用します。これが最もクリーンで読みやすい解決策です。
if (is_countable($variable)) { $total = count($variable); } else { $total = 0; }
### 方法2: 変数の適切な初期化
変数が配列として初期化されていないためにエラーが発生することがよくあります。`count()`を呼び出す前に、根本的な箇所で修正しましょう。例えば、投稿のメタデータを取得する場合：
$results = get_post_meta($post_id, 'user_preferences', true);
// メタデータが存在しない場合は、空の配列にする if (!$results) { $results = []; }
echo count($results);
### 方法3: 型キャストによる短縮法
単純な変数のためのクイックフィックスが必要ですか？型キャストを使用して、変数を強制的に配列形式にします。これは警告を防ぐための信頼できる「1行」の解決策です。
$count = count((array)$variable);
## 環境ごとの注意点
サイトのホスティング環境によって、エラーの表示方法が異なります。DockerやXAMPPなどのローカル環境は、軽微な警告もすべて表示するように設定されていることが多いです。共有ホスティングでは、これらのエラーは汎用的な`error_log`ファイルの中に隠れている場合があります。KinstaやWP Engineなどのマネージドホストは通常、画面上での警告を抑制しますが、ログが500MBや1GBにまで肥大化すると、継続的なディスク書き込みによってサイトのパフォーマンスが低下する可能性があります。
## 修正の確認
サイトの見た目が問題ないからといって、修正が完了したと思い込まないでください。以下の手順で確実に確認しましょう：
- RedisやMemcachedなどのオブジェクトキャッシュ、およびページキャッシュプラグインをクリアします。
- ログファイルをリアルタイムで監視します。SSHアクセスができる場合は、以下を実行します：
```
tail -f wp-content/debug.log
- 特定のエラーが発生したページにアクセスするか、エラーを発生させたアクションを実行します。ログに新しい行が表示されなければ、正常に修正されています。