WP Offload Mediaでサイトに重大なエラーが発生した時の原因と対処法
WP Offload Media（S3/CloudFrontにメディアを転送するプラグイン）でサイトに「このサイトで重大なエラーが発生しました」と表示され、画面が表示されなくなる場合、PHP 8.xではプラグイン内部のsprintf()呼び出しに引数が1つ足りないのが原因だ。最新版へのアップデートで解消する。
なぜWP Offload MediaでArgumentCountErrorが起きるのか
このエラーの直接の原因は、WP Offload Mediaの remove-local-handler.php 内にある sprintf() 呼び出しだ。メディアをS3へ転送（オフロード）した後、ローカルファイルを削除しようとして失敗すると、エラーメッセージを整形する処理が走る。その際、翻訳文字列にファイルパス用の %s が含まれているのに、実際のファイルパスが渡されていない。
PHP 7.xまでは引数不足の sprintf() は警告で済んでいた。ところが PHP 8.0 以降では ArgumentCountError という致命的エラーになり、未処理の例外としてサイト全体が停止する。本来なら所有権やパーミッションの警告で済むはずの内部メッセージ生成が、フロントエンド全体を落とす事態になる。
発火のきっかけは特定の操作に限らない。Yoast SEO のスキーマ生成が wp_head 内で wp_get_attachment_image_url() を呼ぶケースもある。カスタム投稿やギャラリー、商品ページのサムネイル取得など、アップロード済みメディアの URL を取得する場所ならどこでも起こり得る。
修正版では sprintf() の第2引数として $file（実際のファイルパス）が追加される。未処理の例外がなくなるため、フロントエンドの停止を防げる。
エラーログから原因の関数名を確認する手順
画面上では「このサイトで重大なエラーが発生しました」とだけ表示され、詳細はわからない。管理者宛のメールやサーバーのPHPエラーログにスタックトレースが残っている場合もあるが、WordPress の debug.log を有効にするのが最も確実だ。
- wp-config.php をテキストエディタかFTPで開く
- WP_DEBUG と WP_DEBUG_LOG を true にして保存する
- エラーが起きたページを再読み込みする
- wp-content/debug.log を開き、ArgumentCountError と Remove_Local_Handler を探す
スタックトレースに「2 arguments are required, 1 given」という記述があれば、この症状と一致する。Yoast SEO が呼び出し元に含まれる場合もあるが、他のプラグインやテーマ由来でも発火するため、関数名の確認を優先する。
WP Offload Mediaをアップデートして修正する手順
修正が取り込まれたバージョンがリリースされていれば、管理画面からプラグインを更新するのが最短の対応だ。WP Offload Media はサブスクリプション型のライセンスで更新が配布されるため、ライセンスが有効かどうかも確認しておく。
更新後はサーバーキャッシュとブラウザキャッシュを削除してから、エラーが出ていたページを開き直す。WP CLI を使える環境では wp plugin update コマンドでも更新できる。
すぐに更新できない場合の一時的な対処
サブスクリプションの期限切れなどで更新が受けられない場合は、remove-local-handler.php に直接修正を加える方法がある。管理画面の「プラグイン」メニューにある「プラグインファイルエディター」からWP Offload Media を選び、remove-local-handler.php を開く。
sprintf() に $file を追加して回避する
修正箇所は2つある。remove-local-handler.php の180行付近と185行付近だ。どちらも sprintf() の閉じ括弧の前に、カンマと $file を追加する。このファイルはプラグイン本体のため、次回のアップデートで上書きされるが、修正版が配布されるまでの時間稼ぎにはなる。
// 修正前（180行付近）
$file_to_remove['remove_result']['message'] = sprintf(
__( "Error removing local file. Couldn't find the file at %s", 'amazon-s3-and-cloudfront' )
);
// 修正後
$file_to_remove['remove_result']['message'] = sprintf(
__( "Error removing local file. Couldn't find the file at %s", 'amazon-s3-and-cloudfront' ),
$file
);
// 185行付近も同様に $file を追加するプラグインを一時的に無効化する
管理画面に入れる場合は、WP Offload Media を一時的に無効化すればサイトは復旧する。ただし、メディアがすでにS3にオフロードされていると、無効化中はローカルに存在しない画像が表示されないことがある。緊急時の対応と割り切って使う。
PHPバージョンを7.4に戻す
サーバーの設定で PHP を 7.4系に戻せばエラーは出なくなる。ただし、PHP 7.4はセキュリティサポートが終了しているため、恒久対策にはならない。あくまで更新までの一時的な回避策だ。
所有権とパーミッションを見直して再発を防ぐ
このエラーが起きたということは、オフロード後に削除するはずのローカルファイルに削除権限がなかった可能性が高い。プラグインの修正後は、アップロードディレクトリの所有権とパーミッションを確認し、Webサーバーユーザーが書き込める状態にしておく。
アップロードディレクトリ（wp-content/uploads）は、ディレクトリが755、ファイルが644であることが一般的だ。所有権がFTPユーザーになっていると、Webサーバープロセスが削除できず同じ状態になる。サーバー管理画面やシェルから、アップロードディレクトリの所有者をWebサーバーの実行ユーザーに合わせる。
# 所有者とグループをWebサーバー実行ユーザーに合わせる（www-data は環境により異なる）
sudo chown -R www-data:www-data wp-content/uploads
# ディレクトリとファイルの権限を整える
find wp-content/uploads -type d -exec chmod 755 {} \;
find wp-content/uploads -type f -exec chmod 644 {} \;実行ユーザーの名前はサーバー環境によって www-data、apache、nginx など異なる。レンタルサーバーでは管理画面のファイルマネージャーから所有者を変更できないこともあるため、その場合はカスタマーサポートに依頼するか、PHP を実行ユーザーと同じ権限で動かす設定を検討する。
よくある質問
管理画面にも入れないほど真っ白になった場合はどうする？
FTPやサーバーのファイルマネージャーから wp-content/plugins/ に入り、WP Offload Media のフォルダ名を「WP Offload Media_backup」のように変更して無効化する。WordPress はプラグインが存在しないと認識し、サイトを復旧できる。その後、原因を修正してからフォルダ名を元に戻す。
プラグインを更新したのにまだエラーが出るのはなぜ？
キャッシュが残っている可能性が高い。サーバーキャッシュとブラウザキャッシュを削除してから再確認する。それでも出る場合は、別のプラグインが同様の sprintf() 引数不足を起こしている。デバッグログのスタックトレースを再確認する。
ArgumentCountError は WP Offload Media 以外でも起きる？
起きる。PHP 8.0以降では、翻訳文字列に %s を含む sprintf() で引数を渡し忘れると同様の致命的エラーになる。古いテーマやプラグインで潜伏していることが多い。PHP 8.x へ移行する際は事前にステージング環境でテストするのが基本だ。
所有権の問題を放置するとどうなる？
ローカルファイルの削除が失敗し続け、アップロードディレクトリに同じファイルが重複して残る。ディスク容量やバックアップサイズにも影響する。プラグイン自体は修正されても、警告ログが出続けるため、所有権は合わせて直しておくべきだ。
この記事のポイント
- WP Offload Media の sprintf() 引数不足が PHP 8.x で致命的エラーになる
- 「このサイトで重大なエラーが発生しました」の裏で ArgumentCountError が起きている
- 修正版への更新が最短の解決策
- 更新できない間は sprintf() の第2引数に $file を追加する
- 所有権とパーミッションを整えて同じ失敗が起きないようにする
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている