タグアーカイブ 500エラー

WordPress 7.0 ブロックエディターで多言語プラグイン Bogo 有効時に REST API 500 エラーが出る原因と対処

WordPress の多言語プラグイン Bogo を有効化した状態でブロックエディターを開くと、カテゴリーなどのタクソノミーパネルが空になり、REST API が 500 Internal Server Error を返す症状は、Bogo が REST API に付与する lang パラメータと WordPress 7.0 のブロックエディター側のリクエスト処理が競合していることが主な原因だ。

なぜ Bogo とブロックエディターの組み合わせで REST API が 500 エラーを返すのか

この問題の核心は、ブロックエディターが内部で使用する REST API エンドポイントに対するリクエストにある。ブロックエディターは編集画面を表示する際、/wp-json/wp/v2/taxonomies や /wp-json/wp/v2/users/〜 といった複数のエンドポイントに同時にリクエストを送信し、カテゴリー一覧や投稿者情報を取得している。

Bogo は多言語対応のために、これらの REST API リクエストに対して自動的に lang クエリパラメータを付与する。たとえば ?lang=en や ?lang=ja といった具合だ。このパラメータ追加の処理が、ブロックエディターの特定の内部リクエストと組み合わさった際に、サーバー側で PHP の致命的エラーを引き起こしている。

データベースから要求された言語のデータを取得しようとするが、ブロックエディターのコンテキストでは想定外の引数が渡され、結果として WP_Query やタクソノミー取得関数が WP_Error オブジェクトを返す。これが REST API のレスポンス生成時に適切にハンドリングされず、500 エラーとして表面化する。

エラーの切り分けと原因特定の手順

まずは問題が本当に Bogo とブロックエディターの組み合わせに限定されているのかを確認する。以下のフローに沿ってテストを進めると、原因の特定がスムーズになる。

上記の最小構成でもエラーが再現する場合、Bogo とブロックエディターの直接的な競合と判断できる。なお、クラシックエディタープラグインをインストールして同じ操作を行った際に問題が発生しないことも、ブロックエディター固有の問題であることの強い証拠になる。

実用的な回避策と当面の対応

根本的な修正は Bogo プラグイン側のアップデートを待つ必要があるが、運用を止めずにしのぐ方法はいくつか存在する。状況に応じて以下を使い分ける。

クラシックエディターへの一時的な切り替え

最も確実で即効性のある回避策は、クラシックエディタープラグインをインストールして旧来の編集画面を使うことだ。クラシックエディターは REST API に依存したデータ取得を行わないため、Bogo の lang パラメータ付与が問題を引き起こす余地がない。

クラシックエディターは WordPress の公式プラグインディレクトリから無料でインストールできる。インストール後は「設定」→「投稿設定」からデフォルトのエディターを切り替えられる。

REST API への lang パラメータ付与をフィルターフックで制限する

Bogo は REST API リクエストに言語パラメータを付与する際、rest_dispatch_request や rest_pre_dispatch といったフィルターフックを経由している。子テーマの functions.php に以下のようなコードを追加することで、管理画面からのリクエストに対して言語パラメータの付与を抑制できる。

add_filter( 'rest_dispatch_request', function( $dispatch_result, $request, $route, $handler ) {
    // 管理画面からの REST API リクエストの場合、Bogo の言語処理をスキップ
    if ( is_admin() || ( defined( 'REST_REQUEST' ) && REST_REQUEST && strpos( $route, '/wp/v2/' ) === 0 ) ) {
        remove_filter( 'rest_dispatch_request', 'bogo_rest_dispatch_request', 10 );
    }
    return $dispatch_result;
}, 5, 4 );

このコードは、/wp/v2/ から始まる REST API ルート（ブロックエディターが使用する主要なエンドポイント）に対して、Bogo が持つ bogo_rest_dispatch_request フィルターを一時的に除去する。ただし、この方法は Bogo の内部実装に依存しているため、プラグインのバージョンアップによって動作が変わる可能性がある点に注意が必要だ。

プラグインのダウングレードまたはフォーク版の利用を検討する

Bogo 3.9.2 で問題が顕在化したのであれば、1つ前のバージョンである 3.9.1 にダウングレードすることで問題が回避できる可能性がある。ただし、ダウングレードはセキュリティ上のリスクを伴うため、あくまで開発者側の対応を待つ間の暫定策と位置づける。

代替の多言語プラグインへの移行を検討する

Bogo はシンプルな多言語化プラグインとして長く使われているが、ブロックエディターとの相性問題が続くようであれば、Polylang や WPML、TranslatePress といった代替プラグインへの移行も選択肢に入る。これらのプラグインはブロックエディターとの互換性テストがより積極的に行われており、多言語サイトの構築で実績も豊富だ。

デバッグモードで詳細なエラー情報を取得する

REST API の 500 エラーは、通常の PHP エラーとは異なり debug.log に記録されない場合がある。そのため、wp-config.php に以下の定数を追加して、より詳細なエラー情報を取得する。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'SAVEQUERIES', true );

さらに、ブラウザの開発者ツールで「ネットワーク」タブを開き、500 エラーを返している REST API リクエストを特定する。該当するリクエストの「レスポンス」タブを確認すると、サーバーから返された HTML のエラーページや JSON エラーオブジェクトが表示される。WordPress 7.0 では「このサイトで重大なエラーが発生しました」というメッセージが返ってくることが多い。

どうしてもエラーの詳細が取得できない場合は、wp-config.php に以下のコードを追加し、REST API エラー専用のログファイルを作成する方法もある。

add_action( 'rest_api_init', function() {
    set_error_handler( function( $errno, $errstr, $errfile, $errline ) {
        $log = sprintf( '[%s] %s:%d %s', date( 'Y-m-d H:i:s' ), $errfile, $errline, $errstr );
        file_put_contents( WP_CONTENT_DIR . '/rest-api-errors.log', $log . PHP_EOL, FILE_APPEND );
    });
}, 1 );

このコードは REST API の初期化時にカスタムエラーハンドラを登録し、発生したエラーをすべて wp-content/rest-api-errors.log に記録する。問題が解決したら必ず削除すること。

よくある質問

Bogo の代わりに Polylang を使っても同様のエラーは出るか

Polylang は REST API との統合が設計段階から考慮されており、ブロックエディターとの組み合わせでも同様の 500 エラーが発生する可能性は極めて低い。実際に多くの多言語サイトで Polylang とブロックエディターの組み合わせが問題なく運用されている。移行を検討する価値は十分にある。

この問題は WordPress 7.0 以前のバージョンでも発生するのか

WordPress 6.x 系では報告が少なく、7.0 へのアップデート後に顕在化したケースが多い。ブロックエディターの内部実装が 7.0 で変更され、特定の REST API エンドポイントに対するリクエストのタイミングやパラメータの扱いが変わったことが影響していると考えられる。

クラシックエディターに切り替えた後、再びブロックエディターに戻せるのか

問題なく戻せる。クラシックエディターで作成した投稿は、ブロックエディターに戻した際に自動的にクラシックブロックとして読み込まれる。Bogo プラグイン側のアップデートで問題が修正されたら、クラシックエディタープラグインを無効化してブロックエディターに戻せばよい。

REST API のエラーはフロントエンドの表示にも影響するのか

今回の問題は管理画面のブロックエディター内に限定されており、公開済みサイトのフロントエンド表示には影響しない。カテゴリー一覧や投稿一覧の表示、多言語切り替え機能は通常どおり動作する。ただし、ブロックエディターでカテゴリーを選択・編集できないため、投稿の作成や編集作業に支障が出る。

functions.php にフィルターフックを追加する方法がわからない場合はどうすればよいか

最も安全な方法は、FTP クライアントまたはレンタルサーバーのファイルマネージャーを使い、子テーマの functions.php ファイルを編集することだ。操作に不安がある場合は、Code Snippets プラグインを利用して管理画面からコードを追加する方法もある。誤ったコードの追加はサイト全体に影響するため、必ず事前にバックアップを取得してから作業すること。

この記事のポイント

• Bogo 有効時にブロックエディターのカテゴリーパネルが空になるのは、REST API への lang パラメータ付与が競合を起こすため
• クラシックエディターに一時的に切り替えることで、即座に問題を回避できる
• functions.php にフィルターフックを追加し、管理画面からの REST API リクエストに対して Bogo の言語処理を抑制する方法もある
• 根本解決には Bogo プラグイン側のアップデートが必要で、状況によっては代替プラグインへの移行も検討する
• REST API の 500 エラーは debug.log に記録されないことがあるため、専用のエラーログ取得を設定すると原因特定が早まる

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている