タグアーカイブ 致命的エラー

Klarna Paymentsで注文支払いページが500エラーになる原因と対処法

Klarna Payments を有効にした WooCommerce サイトで注文支払いページにアクセスした際に「このサイトで重大なエラーが発生しました」と表示される問題は、プラグイン内部のコードに null チェックが欠落していることが原因だ。存在しない注文 ID に対して get_order_key() メソッドを呼び出そうとして致命的エラーが発生している。この問題は Klarna Payments 4.12.0 以前のバージョンで発生し、プラグインのコードを1行修正するか、開発元のアップデートを適用することで解決できる。

存在しない注文の支払いページでなぜ500エラーが起きるのか

このエラーの直接の原因は、Klarna Payments プラグインの class-kp-assets.php ファイル内にある get_checkout_params() メソッドの実装にある。このメソッドは注文支払いページでチェックアウトスクリプトを読み込む際に呼び出されるが、URL パラメータから取得した注文 ID で wc_get_order() を実行したあと、戻り値が false（注文が見つからなかった場合）かどうかを確認せずに get_order_key() を呼び出している。

PHP は false に対してメソッドを呼び出せないため、「Call to a member function get_order_key() on bool」という致命的エラーが発生し、サイトが HTTP 500 を返す。通常 WooCommerce は存在しない注文に対して「この注文は無効です」という通知を表示する仕様だが、Klarna Payments のスクリプトが先にエラーを起こすことで画面全体が停止してしまう。

この問題は単に手動で不正な URL を入力した場合だけでなく、実際の運用でも発生する。WooCommerce は定期的に保留中や失敗した古い注文を自動的に削除する（woocommerce_trash_pending_orders などのスケジュールタスク）。顧客が「注文保留中」のメールを受け取り、その支払いリンクをクリックした時点で注文が既に削除されていると、本来表示されるべきエラーメッセージの代わりに HTTP 500 エラーに直面することになる。

エラーが発生しているかどうかを確認する方法

致命的エラーが発生すると、WordPress はデフォルトで「このサイトで重大なエラーが発生しました」というメッセージを表示し、サイト管理者に自動的にメールを送信する。このメールにはエラーの詳細と、問題が発生したプラグイン名が記載されている。まずはこのメールを確認するのが最も早い。

デバッグモードを有効にしてエラーの詳細を確認する

エラーメールが届いていない場合や、より詳細なスタックトレースを確認したい場合は、WordPress のデバッグログを有効にする。wp-config.php に以下の定数を追加または既存の行を変更する。

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

この設定により、エラーは画面に表示されず /wp-content/debug.log ファイルに記録される。問題の URL（存在しない注文 ID を含む注文支払いページ）にアクセスしたあと、このログファイルを開いて「Call to a member function get_order_key() on bool」というエラーが記録されているかを確認する。

サイトヘルス画面でエラー情報を取得する

WordPress 5.2 以降では、管理画面の「ツール」→「サイトヘルス」→「情報」タブで、最近発生した致命的エラーの一覧を確認できる。「WordPress の致命的エラー」セクションに、発生時刻とエラーメッセージが表示されるため、本番環境でデバッグモードを常時有効にできない場合の手がかりとして活用できる。

Klarna Payments プラグインのコードを修正する手順

この問題の根本的な解決には、プラグインのコードに適切なガード条件を追加する必要がある。修正対象は /wp-content/plugins/klarna-payments-for-woocommerce/classes/class-kp-assets.php ファイルの get_checkout_params() メソッド内にある約181行目付近のコードだ。

修正前のコードと問題箇所

if ( ! empty( $order_id ) ) {
    $order     = wc_get_order( $order_id );
    $order_key = $order->get_order_key(); // $order が false の場合にエラー
}

修正後の安全なコード

if ( ! empty( $order_id ) ) {
    $order = wc_get_order( $order_id );
    if ( $order ) {
        $order_key = $order->get_order_key();
    }
}

追加するのは「もし $order が存在するなら」という条件分岐の1行だけだ。この修正により、wc_get_order() が false を返した場合に get_order_key() の呼び出しがスキップされ、Klarna Payments のスクリプトが正常に読み込まれなくなる代わりに、WooCommerce の標準的な「この注文は無効です」という通知が表示されるようになる。

プラグインファイルを安全に編集する際の注意点

この修正はプラグインのコアファイルを直接変更するため、次の点に注意が必要だ。最も重要なのは、プラグインが自動アップデートされると修正が上書きされる点である。Klarna Payments の開発元である Krokedil が次回のバージョンでこのバグを修正する可能性が高いため、当面の暫定対応としてのみ行うべきだ。

修正前に必ずバックアップを取得する

FTP クライアントまたはサーバーのファイルマネージャーで class-kp-assets.php をローカルにダウンロードし、class-kp-assets.php.bak のような名前でコピーを保存してから編集する。誤った修正でサイトが停止した場合にすぐ元に戻せるようにするためだ。

プラグインの自動アップデートを一時的に停止する

カスタム修正を適用したプラグインが自動アップデートされると修正が消えるだけでなく、場合によっては修正とアップデートの競合でさらに問題が起きる可能性もある。WordPress 管理画面の「プラグイン」→「プラグインの自動更新を無効化」から Klarna Payments の自動更新をオフにするか、より安全な方法として wp-config.php に define( 'WP_AUTO_UPDATE_CORE', false ); を追加してプラグイン自動更新全体を制御する方法もある。ただしこの定数は WordPress コアの自動更新にも影響するため、既存の設定と相談して決める必要がある。

エラーログを監視して修正後の状態を確認する

修正を適用したあとは、デバッグログを数日間監視し、同じエラーが再発していないか確認する。また、実際に存在しない注文 ID を含む URL（/checkout/order-pay/99999999/?pay_for_order=true&key=whatever）にアクセスし、500 エラーではなく「この注文は無効です」という WooCommerce の通知が表示されることを検証する。検証が終わったら WP_DEBUG と WP_DEBUG_LOG を false に戻し、デバッグログファイルを削除する。

よくある質問

プラグインの修正を待つ間の一時的な回避策はあるか

コード修正以外の回避策として、Klarna Payments のチェックアウトフロー設定を「redirect（リダイレクト）」に変更する方法がある。管理画面の「WooCommerce」→「設定」→「支払い」→「Klarna Payments」で「Checkout flow」を「redirect」に設定すると、注文支払いページでのスクリプト読み込み動作が変わる可能性がある。ただしこの設定が確実にエラーを回避するかは環境によって異なるため、検証が必要だ。

このエラーは特定のテーマが原因で発生するのか

テーマは直接の原因ではない。エラーのスタックトレースにテーマ名（例: Shoptimizer）が含まれるのは、テーマが wp_head() を呼び出し、そのフック経由で Klarna Payments のスクリプトが実行されるためだ。テーマを変更してもこの問題は解決しない。原因はあくまで Klarna Payments プラグインのコードにある。

Klarna Payments の代わりに別の決済プラグインに切り替えるべきか

この種の null チェック不足は、特定のバージョンに限った問題であり、他にも多数の決済プラグインで過去に同様のバグが報告されている。Klarna Payments 自体は広く使われている安定したプラグインであり、1つのマイナーなバグのために乗り換えるほどの問題ではない。上記の1行修正で解決できる範囲だ。

同じ修正を子テーマの functions.php で適用できるか

このケースでは適用できない。問題のコードはプライベートメソッド get_checkout_params() 内にあり、WordPress のフィルターフックやアクションフックを提供していない。そのためフックで動作を上書きしたり無効化したりすることができず、プラグインファイルの直接編集が必要になる。フックで対応できるのは、プラグインが明示的に do_action() や apply_filters() を提供している箇所に限られる。

この記事のポイント

• Klarna Payments 4.12.0 以前で存在しない注文の支払いページにアクセスすると致命的エラーが発生する
• 原因は class-kp-assets.php 内で wc_get_order() の戻り値が false かどうかを確認せずにメソッドを呼び出していること
• if ( $order ) の1行を追加することでエラーを回避できる
• プラグインのコアファイルを編集する前に必ずバックアップを取得する
• プラグインの自動アップデートにより修正が上書きされるため、一時的な対応として扱う

佐々木 太陽

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