AvadaとComplianzでGravity Formsが表示されない時の解決法
AvadaテーマとComplianzの組み合わせで、クッキー同意前にGravity Formsのフォームが表示されない問題は、ComplianzがAvadaの必須設定スクリプト（fusion-lightbox-js-extra）をマーケティングスクリプトと誤判定しブロックするのが原因だ。Complianzの設定を変更し、このスクリプトをブロック対象から除外すれば解決する。
なぜComplianzがAvadaのスクリプトをブロックするのか（原因）
ComplianzはGDPRなどのプライバシー規制に対応するため、事前の同意なしに個人データを収集する可能性のあるスクリプトを自動で検出し、ブロックする。Avadaのfusion-lightbox-js-extraは、ライトボックス機能で使用する設定値（fusionLightboxVars）をページに埋め込むための必須の設定スクリプトだ。
しかしこのスクリプトの中に、SNS共有用のURLの一部としてLinkedInのURLが含まれている場合、Complianzのスキャナーが「LinkedInのマーケティングスクリプトではないか」と誤って分類してしまう。結果としてスクリプトのtype属性がtext/plainに書き換えられ、ブラウザがJavaScriptとして実行しなくなる。Gravity Formsの表示に必要なfusionLightboxVarsが定義されず、後続のJavaScriptがエラーになるというのが根本的な原因だ。
var fusionLightboxVars = { … };
</script>
var fusionLightboxVars = { … };
</script>
このデモは、Complianzが誤検出した際のスクリプトタグの変化と、除外設定後の正常な状態を比較したものだ。
ComplianzでAvadaのスクリプトをブロック対象から除外する手順
上記の手順は、Complianzの設定画面から行える最も安全で公式な対処法だ。各STEPの詳細を順に説明する。
スクリプトセンターで「Avada Fusion Builder」統合を有効にする
Complianz Free 7.5.0以降では「スクリプトセンター」内に「サードパーティとの統合」というセクションがあり、主要なテーマやプラグイン向けのプリセット設定が用意されている。ここで「Avada Fusion Builder」を有効にすると、ComplianzはAvadaのコアスクリプトをマーケティングカテゴリから除外し、必須スクリプトとして扱うようになる。
この設定によってfusion-lightbox-js-extraのブロックが解除され、fusionLightboxVarsが正しく定義されるため、Gravity Formsの表示エラーは解消する。もしこの統合が既に有効なのに問題が続く場合は、次の手順を試す。
特定のスクリプトをURL指定で除外する
統合を有効にしても問題が解決しない場合、該当のスクリプトをComplianzのスクリプトブロックから直接除外する方法がある。Complianzの「スクリプトセンター」には「URLを指定してブロック除外」という項目があり、ここに除外したいスクリプトのパスを追加する。
具体的には/wp-content/themes/Avada/assets/min/js/library/jquery.flexslider.jsもしくは/wp-content/plugins/fusion-builder/配下のスクリプトを除外リストに追加する。これによって該当のJSファイルがComplianzのブロック対象から完全に外れ、クッキー同意前でも実行されるようになる。
除外設定を追加したら、必ずシークレットウィンドウ（プライベートブラウジング）で動作を確認する。通常のブラウザでは既にクッキー同意済みの状態がキャッシュされているため、問題の再現確認にはシークレットモードが必須だ。
Complianzのフィルターフックでスクリプトのカテゴリを変更する方法（上級者向け）
特定のインラインスクリプトをComplianzのスクリプトブロックから除外する、より精密な方法として、Complianzが提供するフィルターフックを使う手がある。この方法は、スクリプトを誤分類から守りつつ、他のスクリプトのブロック機能は維持したい場合に有効だ。
テーマのfunctions.phpに除外フィルターを追加する
子テーマのfunctions.phpに以下のコードを追加することで、fusion-lightbox-js-extraのスクリプトハンドルをマーケティングカテゴリから外し、必須スクリプト（functionalカテゴリ）として扱える。
add_filter('cmplz_script_class', function($class, $total_match, $found) {
if ($found === 'fusion-lightbox-js-extra') {
return 'cmplz-native'; // 必須（functional）カテゴリとして扱う
}
return $class;
}, 10, 4);このフィルターはComplianzがスクリプトをスキャンする段階で動作し、指定したハンドル名（ここではfusion-lightbox-js-extra）を持つスクリプトの分類をcmplz-nativeに上書きする。cmplz-nativeは必須カテゴリ扱いとなり、クッキー同意前でもブロックされずに実行される。
コードを追加した後は、必ずサイトのキャッシュをクリアし、シークレットウィンドウで動作を確認する。また、Complianzの管理画面で「スクリプトセンター」→「スクリプトを再スキャン」を実行すると、変更が即座に反映される。
他のAvadaスクリプトが同様にブロックされる場合の追加対処
fusion-lightbox-js-extra以外にも、Avadaの他のスクリプトが同じ理由でブロックされるケースがある。特にfusion-video-js-extraやfusion-flexslider-js-extraといった-js-extraで終わるインラインスクリプトは、SNS共有URLを含むことが多く、同様に誤判定される可能性が高い。
ブラウザの開発者ツール（F12）でコンソールを開き、「is not defined」で終わるエラーが他に出ていないか確認する。もし複数のAvada変数が未定義になっている場合は、該当するスクリプトハンドルをすべてComplianzの除外対象に追加するか、前述のフィルターフックで一括して必須カテゴリに振り分ける。
恒久的な対策としては、Complianzの「スクリプトセンター」→「Avada Fusion Builder」統合が正式にこれらのスクリプトをカバーするよう、Complianz側のアップデートを待つのも一手だ。とはいえ、テーマとプラグインの両方を常に最新版に保つことで、多くの互換性問題は徐々に解消される。
よくある質問
Avada統合を有効にしても直らないのはなぜか
ComplianzのバージョンやAvadaのビルドによっては、統合機能がfusion-lightbox-js-extraまでカバーしていない場合がある。その場合はURL指定の除外かフィルターフックを併用する。また、キャッシュプラグインやCDNが変更前のスクリプトを配信し続けている可能性もあるため、すべてのキャッシュをクリアしてから再度確認する。
クッキー同意後はフォームが表示されるのに、同意前だけ出ないのはなぜか
まさに今回の問題の典型例だ。Complianzは同意前にマーケティングカテゴリのスクリプトをブロックする。Avadaのスクリプトが誤ってマーケティングカテゴリに分類されているため、同意前はブロックされ、同意後に初めて実行される。除外設定でこの誤分類を修正すれば、同意前でもフォームが表示されるようになる。
Gravity Forms以外のプラグインにも影響は出るのか
fusionLightboxVarsが未定義になると、Avadaのライトボックス機能全体が破綻する。そのためライトボックスに依存するあらゆる要素（ポップアップ、モーダルウィンドウ、Ajax読み込みのフォームなど）が影響を受ける可能性がある。Gravity Forms以外にも、ポップアップメーカーやモーダル系のプラグインを使っている場合は同様の症状が出ることがある。
Complianzの代わりに他のクッキープラグインを使うべきか
必須ではない。Complianzは無料版でも柔軟な除外設定が可能であり、問題のスクリプトを適切に除外すればAvadaとの共存に支障はない。GDPR対応のためのスクリプト管理機能は他のプラグインでも同様の誤検出リスクがあるため、移行するよりも現在の環境で正しく設定する方が効率的だ。
フィルターフックのコードを追加しても反映されない場合は
まずComplianzの「スクリプトセンター」で「スクリプトを再スキャン」を実行する。それでもダメなら、キャッシュプラグインの全クリアとCDNのパージを行う。また、cmplz_script_classフィルターの優先度（第三引数の10）を9999に上げると、他の処理より後に実行されて確実に上書きされる。
この記事のポイント
- ComplianzがAvadaの必須スクリプトをLinkedInマーケティングスクリプトと誤判定しブロックするのが原因
- Complianzの「スクリプトセンター」でAvada Fusion Builder統合を有効にするのが最も簡単な解決策
- 統合で直らない場合はURL指定除外かフィルターフックで該当スクリプトを必須カテゴリに振り分ける
- 修正後は必ずシークレットウィンドウで動作を確認し、キャッシュのクリアを忘れずに行う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Gravity Forms PDFで合計金額が倍になる原因と修正方法
Gravity Forms で作成したフォームから PDF を出力するプラグイン「PDF Invoices for Gravity Forms」を使っていて、テンプレート内で get_total() メソッドを複数回呼び出すと合計金額が呼び出し回数に応じて倍々に膨らんでしまう現象は、静的変数 self::$total が各呼び出しのたびに加算され続ける設計になっているのが原因だ。直すにはヘルパークラスを子テーマから拡張し、get_total() の内部で毎回リセットして再計算させる変更を加える。
合計金額が倍になる現象はどのようなときに起こるのか
たとえば請求書のテンプレートに「小計」と「総合計」を別々の位置に表示したい場合、PDF_Invoices_For_GravityForms_Helpers::get_total() を2回呼ぶことになる。ところがイベント参加登録や商品注文フォームなどで実際にこの処理を通すと、2回目の呼び出し時には1回目に加算された値にさらに同じ計算が上乗せされ、本来 10,000 円のところが 20,000 円になるといった不具合が起きる。
なぜ get_total() を複数回呼ぶと値が積み上がるのか
問題の根本は class-pcafe-gfpi-helpers.php ファイル内の get_total() メソッドにある。このメソッドは静的変数 self::$total を使い、内部で次のように加算している。
public static function get_total(){
self::$total += self::get_subtotal();
self::$total += self::$shipping;
return self::$total;
}静的変数はリクエストの間ずっと値を保持するため、同じ処理中に get_total() が呼ばれるたびに前回の合計に小計と送料が足されていく。2回呼べば「小計 + 送料」が2倍になり、3回なら3倍になる。通常、こうした合計取得メソッドは毎回ゼロから計算し直すべきであり、内部で継ぎ足す構造は意図したものでない可能性が高い。
変数 self::$total が 10,500 を保持したまま
2回目呼び出し: 変数をリセット後 再計算 → total=10,500
上の図のように、2回目で合計が倍になる。特に「小計」「消費税」「総合計」など複数の金額を PDF テンプレートに配置する場合にこの問題が顕在化しやすい。
get_total() 修正の基本的な考え方
プラグイン本体のファイルを直接編集してしまうと、アップデートのたびに修正が上書きされて消える。そのため子テーマの functions.php を使い、プラグインのヘルパークラスを拡張した独自クラスを用意する方法をとる。拡張クラスでは get_total() メソッドをオーバーライドし、計算前に self::$total を強制的に 0 にリセットしてから小計と送料を加算する。
子テーマでヘルパークラスを拡張して修正する手順
独自ヘルパークラスを作成する
まず子テーマの functions.php に、プラグインのヘルパークラスを継承したクラスを定義する。子テーマがない場合は、Code Snippets プラグインを使うか、wp-content/themes/（現在のテーマ）/functions.php に追記する形でもよい。コードは以下のようになる。
class Custom_GFPI_Helpers extends PDF_Invoices_For_GravityForms_Helpers {
public static function get_total() {
self::$total = 0; // 計算前に必ずリセットする
self::$total += self::get_subtotal();
self::$total += self::$shipping;
return self::$total;
}
}テンプレート内でカスタムクラスを呼び出す
拡張クラスを作っただけでは既存のテンプレートには反映されない。PDF テンプレート内で PDF_Invoices_For_GravityForms_Helpers::get_total() を呼んでいる箇所を、先ほど定義した Custom_GFPI_Helpers::get_total() に置き換える。
テンプレートファイルは多くの場合 wp-content/uploads/pdf-invoices-for-gravity-forms/templates/ 以下にカスタムテンプレートとして配置されている。該当の .php ファイルを開き、以下のように書き換える。
<?php
// 修正前
// echo PDF_Invoices_For_GravityForms_Helpers::get_total();
// 修正後
echo Custom_GFPI_Helpers::get_total();
?>これでテンプレート内のどの場所から呼び出しても、毎回リセット後に計算が走るため合計が積み上がることはなくなる。
変更後にキャッシュと動作を確認する
変更を加えたあとは、必ず PDF を生成し直して合計金額が正しいか確認する。Gravity Forms のエントリーから「PDFを表示」ボタンで実際の請求書を開き、同じ合計が要求された位置すべてに正しく表示されているかをチェックする。サイトでキャッシュプラグインを使っている場合は、キャッシュを全削除してから確認すると確実だ。
よくある質問
プラグイン本体のファイルを直接修正してもよいか
推奨しない。プラグインがアップデートされるたびに修正が上書きされ、その都度同じ変更を加えなければならなくなる。子テーマや Code Snippets を使う方法なら、アップデートに影響されず継続的に動作する。
他の金額表示（税額や値引き額）も倍増している場合の対処は
同じヘルパークラス内で定義されている get_tax() や get_discount() にも同様の静的変数の加算構造がある可能性が高い。それらのメソッドも同じ要領でカスタムクラス内にオーバーライドし、内部で該当の静的変数をリセットする処理を加えるとよい。
子テーマを使っていない場合でも対応できるか
子テーマがない場合は Code Snippets プラグインが便利だ。スニペットとしてクラス定義を追加すれば、テーマに依存せず同じ修正を適用できる。テンプレートの書き換えは手動で行う必要があるが、クラスの読み込み自体はスニペット経由で問題なく動作する。
修正後に PDF が真っ白になる場合の確認点は
クラス名やメソッド名のスペルミス、オートローダーがカスタムクラスを見つけられていないケースが考えられる。まず PHP のエラーログを確認し、クラスが見つからないという趣旨の致命的エラーが出ていないか調べる。出ている場合はクラス定義の記述ミスか、定義のタイミングが早すぎる可能性があるため、init フックなどで定義を遅らせると改善することがある。
この記事のポイント
get_total()の多重呼び出しで合計が倍増するのは、静的変数self::$totalが加算され続ける設計のため- プラグイン本体を直接修正せず、子テーマの functions.php でカスタムクラスを定義する
- カスタムクラス内で
get_total()をオーバーライドし、計算前にself::$total = 0;でリセットする - PDF テンプレート側の呼び出しをカスタムクラスに差し替え、キャッシュ削除後に動作確認する
- 同様の構造を持つ
get_tax()やget_discount()も併せて修正を検討する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている