
WP All Importで物件画像が混ざる原因とファイル名の一意化による解決方法
WP All Import で物件情報をインポートした際、他の物件の画像が表示される不具合は、画像ファイル名の重複と画像マッチング設定の不備が主な原因だ。この問題は、WP All Import のファイル名指定で一意の名前を生成し、画像マッチングルールを適切に設定することで解決できる。
WP All Import でインポートした画像が混ざる原因は何か

WP All Import は XML フィードから画像をダウンロードし、メディアライブラリに追加する。ここで「すでに同じファイル名の画像がメディアライブラリに存在する」と、意図せず既存の画像を参照してしまうことがある。特に検索やマッチングをすべてオフにしていても、ファイル名の衝突が発生すると新規ダウンロードをスキップして既存画像にリンクを張る挙動が起こりうる。これが、異なる物件で同じ画像が表示される最大の原因だ。
もう一つの原因は、Houzez テーマやそのアドオンがインポート後に画像ギャラリーを再構築する際、メディアライブラリ内の添付ファイルの親子関係やメタデータを誤って上書きしてしまうケースだ。プレビュー段階では正しいのに、インポート完了後に別の物件の画像に差し替わるのは、インポート後のテーマ側の処理タイミングで画像の紐付けがずれるために起こる。
画像ファイル名を一意にして他物件との画像混入を防ぐ方法

WP All Import では、インポートテンプレートの「画像」セクションで、保存時のファイル名をカスタマイズできる。ここで物件ごとに絶対に重複しない名前を付けるのが最も確実な対策だ。具体的には、物件 ID や MLS 番号、住所の一部など、XML 内のユニークな要素をファイル名に組み込む。
↓ XML に「1.jpg」「1.jpg」… 重複発生
↓ 物件ごとに絶対衝突しない
上のデモのように、{mls_id} や {property_id} といった絶対に重複しないフィールドをファイル名に含める。インポート時に「既存画像を保持」の設定をオフにしていても、ファイル名が重複すると WordPress 本体側で「ファイル名-1」「ファイル名-2」のように連番サフィックスが付与されることがあり、このサフィックス付きファイル名を Houzez アドオンが正しく追跡できない場合もある。ファイル名の段階で完全にユニークにしておけば、そのリスクも回避できる。
WP All Import の画像マッチング設定を適切に構成する

現在「すべてオフ」の状態は、一見すると毎回新規ダウンロードされそうに見えるが、実際にはファイル名の重複や WordPress の内部キャッシュによって想定外のマッチが起こりうる。以下の設定を見直す。
画像 URL またはファイル名でのマッチを有効にする
「Match image by URL」をオンにすると、WP All Import は XML 内の画像 URL とメディアライブラリ内の元 URL メタデータを照合し、すでに同じ URL からダウンロードされた画像があれば再利用し、なければ新規ダウンロードするという明確な挙動になる。「すべてオフ」よりも意図が明確で、混入が防ぎやすい。
Search Media Library for existing images の使い所
この設定は、ファイル名やタイトルで既存画像を検索する。ファイル名が重複しがちな構成ではオフのままが安全だが、ファイル名を一意にしたうえでオンにすれば、再インポート時の二重ダウンロードを防ぎつつ正確にマッチできる。画像ファイル名の一意化が完了しているなら、ここをオンにして「既存画像の検索」に任せるのも選択肢になる。
First image set as Featured Image の副作用に注意する
この設定がオンの場合、WP All Import と Houzez アドオンがそれぞれ「アイキャッチ画像」を設定しようとして、2つの処理が干渉することがある。画像の入れ替わりが激しいなら、いったんこの設定をオフにして、Houzez アドオン側にアイキャッチ設定を任せてみる。それで安定するなら、アドオン側の処理が優先される構成に統一する。
Houzez アドオンとテーマ側の画像処理を確認する

Houzez アドオンはインポート後に物件ギャラリーやアイキャッチ画像を再構成する独自の処理を行う。この処理が WP All Import のメディアライブラリ操作と競合し、別の物件の画像を拾ってしまうことがある。特に再インポート時に、アドオンが「物件に紐づく既存画像」を誤ったロジックで上書きするパターンが報告されている。
アドオンの画像処理フックを一時停止して検証する
子テーマの functions.php に以下のコードを一時的に追加し、Houzez アドオンの画像処理をスキップしてインポート結果が正しくなるかテストする(テスト後は必ず削除する)。
// テスト用 インポート後の Houzez 画像処理を無効化
add_action('init', function() {
if (class_exists('Houzez_Property_Feed')) {
remove_all_actions('pmxi_after_xml_import');
remove_all_actions('pmxi_saved_post');
}
}, 99);これで画像の混入が止まるなら、Houzez アドオン側の処理が原因だ。その場合、アドオンの最新バージョンへのアップデート、または Houzez 公式サポートに「WP All Import インポート後の画像上書き」の修正を依頼する。アドオンのバージョンが古いと、WP All Import の最新 API との互換性が崩れていることがある。
再インポート前にメディアライブラリの紐付けをリセットする
WP All Import で「既存の投稿を更新」する形で再インポートする場合、過去のインポートで作られたメディアの紐付け(post_parent やメタデータ)が残っていると、新しい画像が正しく割り当てられない。この場合は、一度該当の物件投稿と画像の紐付けを手動で外すか、WP All Import 実行前に該当物件の画像をメディアライブラリから削除してから再インポートすると、クリーンな状態で画像が再構築される。
Amazon S3 Offload 使用時の画像混入を防ぐ

Amazon S3 Offload(WP Offload Media 等)を使用している場合、メディアライブラリの画像実体は S3 に移動され、ローカルにはメタデータだけが残る。この状態で WP All Import が「同じファイル名」の画像を処理しようとすると、S3 上の URL とメディアライブラリのメタデータに不整合が生じ、参照がずれることがある。
S3 Offload の URL 書き換えタイミングを確認する
WP Offload Media はアップロード後に URL を書き換えるが、このタイミングが WP All Import のインポート後処理や Houzez アドオンのギャラリー構築タイミングと重なると、書き換え前のローカル URL が一時的に保存されてしまう。S3 Offload プラグインが「非同期処理」や「スケジュール処理」で URL を更新する設定になっているなら、同期処理に切り替えて、インポート完了までにすべての URL が書き換わるようにする。
インポート中は S3 Offload を一時停止する
大量インポート時は、WP Offload Media のアップロードフックを一時的に停止して、WP All Import のインポートが完全に終わったあとに手動で一括オフロードする方法も有効だ。インポートスクリプトの先頭でオフロードを無効化し、完了後に再有効化するワークフローにすると、混入リスクをほぼゼロにできる。
よくある質問
Preview では正しいのに本番インポートで画像が混ざるのはなぜか
Preview は実際のダウンロードとメディアライブラリ登録をスキップし、XML の URL だけを表示する仕組みだ。本番インポートではメディアライブラリへの保存が行われ、このときにファイル名衝突やテーマの後処理が発動して画像が入れ替わる。この違いが「Preview では正しいのに本番で壊れる」現象の正体だ。
画像が混ざった物件を一括で修正できるか
WP All Import の「既存の投稿を更新」機能を使い、画像フィールドだけを再インポートすることで一括修正できる。その際、ファイル名の一意化とマッチング設定の見直しを事前に済ませておく必要がある。メディアライブラリに重複画像が大量にある場合は、一度不要画像を一括削除してから再インポートすると確実だ。
Houzez テーマ以外でも同じ問題は起こるか
起こる。WP All Import とテーマ付属の独自インポートアドオンが競合する構図は、不動産テーマ(HomePress、RealHomes 等)や EC(WooCommerce の WP All Import アドオン)でも報告されている。基本的な対策であるファイル名の一意化とマッチング設定の見直しは、どのテーマでも有効だ。
画像 URL にクエリパラメータが付いている場合の注意点はあるか
URL の末尾に ?w=800&h=600 のようなパラメータが付いていると、WP All Import が「別の画像」として認識せず、パラメータ部分を無視してファイル名を生成するため重複が起きやすい。URL マッチングを使用する場合も、パラメータ除去後のベース URL で照合されるため、意図したマッチが働かないことがある。可能なら XML 側でクエリパラメータのないクリーンな URL を用意するのが望ましい。
メディアライブラリの画像が増えすぎないか心配だ
ファイル名の一意化と画像 URL マッチングを適切に設定すれば、同じ URL の画像はメディアライブラリに一度だけ保存されて再利用される。重複ダウンロードが起きていたのは、ファイル名衝突によって新規保存と既存参照が混在していたためで、設定を見直せばメディアライブラリの肥大化も抑えられる。
この記事のポイント
- 画像混入の主因はファイル名重複とマッチング設定の不備
- XML 内のユニーク ID をファイル名に組み込む
- 画像 URL マッチングをオンにして明確な挙動にする
- Houzez アドオンの画像処理競合はフック停止で検証
- S3 Offload 使用時は同期処理への切り替えが安全

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

WP Extendedのスニペット一覧が真っ白になった時のファイル復旧方法
WP Extended の管理画面でコードスニペットの一覧が突然真っ白になり、まったくアクセスできなくなっても、作成したスニペット本体はサーバー上に PHP ファイルとして残っている。慌てずに /wp-content/wpextended-snippets ディレクトリを開き、必要なコードを取り出せばよい。本記事ではファイルの所在確認からコードの復旧、別環境への移し替えまでを具体的に示す。
なぜ WP Extended のスニペット一覧が表示されなくなったのか

WP Extended のようなコードスニペット管理プラグインで一覧画面が機能しなくなる原因は、プラグイン自体の不具合というより、特定の環境下での PHP エラーやデータベースの不整合によるところが大きい。特に有効化したスニペットに文法エラーがあると、管理画面全体が「このサイトで重大なエラーが発生しました」といった真っ白な画面に陥るケースもある。実際の管理画面が表示されなくなった時の典型的な引き金は次のとおりだ。
- 直前に有効化したスニペット内の PHP コードに誤りがある
- プラグイン本体の更新と WordPress 本体または PHP バージョンとの相性問題
- 他のプラグインとの競合で管理画面の読み込みが途中で止まる
- サーバーのメモリ制限やファイル権限の問題でスニペットディレクトリを読み取れない
いずれにしても、スニペット一覧が見えなくなったからといって、作成したコードが消えたわけではない。WP Extended は各スニペットを wp-content ディレクトリ内に実ファイルとして保存しているため、管理画面が動作しなくてもサーバー側から直接回収できる。
スニペットの実体はどこに保存されているのか

WP Extended が保存するスニペットの実ファイルは、WordPress インストール先の wp-content/wpextended-snippets ディレクトリに置かれている。個々のスニペットは snippet-XX.php といった名前の独立した PHP ファイルになっており、コード本体のほかスニペット名や優先度などのメタ情報がコメントとして残っていることも多い。
└─ wpextended-snippets/
├─ snippet-1.php
├─ snippet-2.php
└─ snippet-3.php
サーバー上の PHP ファイルからスニペットのコードを回収する手順

管理画面が使えなくても、レンタルサーバーのファイルマネージャーか SFTP クライアントを使えばスニペットの実体にアクセスできる。全体の流れは以下のデモのとおりだ。
wp-content/wpextended-snippets ディレクトリを開くファイルマネージャーを使う場合
多くの国内レンタルサーバーが提供しているブラウザ上のファイルマネージャーを開き、wp-content フォルダへ移動して wpextended-snippets を探す。目的のスニペットがどれかわからない場合は、すべての PHP ファイルを一旦ダウンロードし、ローカルで中身を確認すればよい。
SFTP クライアントでアクセスする場合
FileZilla などの SFTP クライアントを使い、ホスト名・ユーザー名・パスワード(または SSH 鍵)で接続する。接続後、リモートサイト側のディレクトリツリーから wp-content/wpextended-snippets へ進み、ファイルを一括ダウンロードする。権限不足で開けない場合は、サーバー管理画面からファイルのパーミッションを 755 に修正する。
取り出した PHP コードを別のスニペット管理プラグインへ移す

ダウンロードしたファイルをテキストエディタで開くと、WP Extended が自動生成したヘッダコメントに続いて実際の PHP コードが記述されている。スニペットの中身だけをコピーし、別のコードスニペット管理プラグイン(例: 無料の Code Snippets プラグイン)に貼り付ければすぐに再利用できる。
スニペットを Code Snippets に移す場合の注意点
Code Snippets のような別のプラグインに移すときは、コピーした PHP コードをそのまま新規スニペットとして貼り付ける。ただし、WP Extended では「フロントエンドのみ実行」「管理画面のみ実行」といった実行条件を設定している場合、それらを移行先プラグイン側で改めて指定し直す必要がある。条件が無く単純な functions.php 的コードであれば、貼り付けて保存するだけですぐに動く。
子テーマの functions.php に直接書く方法
スニペットの数が少なく、なおかつテーマの関数として常時読み込ませて構わない場合は、子テーマの functions.php に直接コードを転記するという手もある。ただし、テーマを切り替えると動作しなくなるため、サイト全体で使うコードは専用プラグインとしてまとめるほうが管理しやすい。
同じ問題が再発しないようにするための対策

WP Extended の管理画面が再び使えなくなる事態を防ぐには、以下の点を普段から意識しておくことが重要だ。
- スニペットを新規追加・有効化する直前は、必ずローカルやステージング環境で動作確認する
- プラグイン本体や WordPress 本体を更新する前に、スニペットのバックアップ(ディレクトリごとダウンロード)を取る
- PHP エラーログを定期的に確認し、構文エラーが残っていないか点検する
- 別のコード管理プラグインへの移行を検討する場合、スニペットのエクスポート機能が無いか事前に調べる
よくある質問
管理画面が真っ白で wpextended-snippets ディレクトリも見つからない
WordPress のインストール先がサブディレクトリになっている可能性がある。サーバールートではなく、WordPress を設置したフォルダ(例: public_html/wp/)の中を確認する。また、何らかの理由でプラグインが削除されているとディレクトリごと消えている場合があるため、事前にバックアップが無いかレンタルサーバーの管理画面を調べる。
PHP ファイルの中身をコピーしても新しいプラグインで動作しない
多くの場合、スニペットが <?php 開始タグなしで保存されているか、WP Extended 独自の定数やフィルターフックに依存していることが原因だ。コードの先頭に <?php を付け、必要なフック(add_action や add_filter)が正しく記述されているか見直す。
WP Extended を再インストールしたらスニペットは戻るのか
プラグインを一度アンインストールすると、wpextended-snippets ディレクトリやデータベースの情報が削除される可能性がある。そのため、再インストール前に必ずスニペットファイルのバックアップを取っておく。バックアップが無ければ、サーバーのバックアップサービスからの復元が必要になる。
スニペットが複数あり、どれが目的のコードかわからない
ファイル名だけでは判別が難しいため、全ての PHP ファイルを一度ローカルにダウンロードし、エディタで内容を確認する。WP Extended のヘッダ部分にスニペット名が書かれていることが多いので、それを手がかりに必要なファイルを特定する。
この記事のポイント
- WP Extended のスニペット一覧が見えなくなっても、ファイルは
wp-content/wpextended-snippetsに残っている - サーバーのファイルマネージャーまたは SFTP で PHP ファイルを回収できる
- 回収したコードは別のスニペット管理プラグインや子テーマに移せる
- 事前のバックアップとテストで同じトラブルを防げる

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

メガメニューのスタイルが崩れた時の原因と直し方
プラグイン更新後にメガメニューのスタイルが崩れ、一部のナビゲーション項目が表示されなくなった場合、まずは以前のバージョンへの巻き戻しと全キャッシュの削除を試みる。この2つで多くのケースは即座に復旧する。
なぜプラグイン更新後にメガメニューのスタイルが崩れるのか

メガメニュープラグインは、独自の CSS と JavaScript を読み込んでスタイルを適用している。アップデートによってこれらのファイル構成が変更されると、ブラウザやサーバーに残った旧バージョンのキャッシュが新バージョンのスタイルと衝突し、見た目が崩れることがある。
また、プラグイン内部で HTML 構造が変更された場合、テーマ側で追加したカスタム CSS のセレクタが合わなくなり、スタイルが外れてしまうケースも少なくない。これが「項目が完全に見えなくなる」原因になることもある。具体的には、項目を非表示にする CSS ルール(display:none など)が誤って適用されたり、z-index の競合で他の要素の裏に隠れたりする。
メガメニューの崩れを直す緊急対処の流れ

まずはサイトの表示に直接影響するキャッシュをすべて取り除き、それでも直らなければプラグインを以前のバージョンに戻す。この順序で作業すると、無駄な切り分けを減らせる。
キャッシュを完全に除去する手順
まず Chrome や Firefox のデベロッパーツールを開き、ネットワークタブで「キャッシュを無効化」にチェックを入れた状態で再読み込みする。これでブラウザキャッシュ由来の崩れかどうかをすぐに確認できる。改善したらブラウザキャッシュが原因だ。
次に WordPress の管理画面から、使用しているキャッシュ系プラグイン(WP Rocket や W3 Total Cache など)の設定画面を開き、「キャッシュをすべて削除」を実行する。さらに「CSS の最適化」や「JavaScript の結合」機能が有効なら、一度無効化してからキャッシュを再生成する。結合・最適化の過程で生まれた旧ファイルが新バージョンと衝突している可能性があるためだ。
サーバーレベルで Nginx や Varnish を使っている場合は、ホスティングのコントロールパネルからサーバーキャッシュもフラッシュする。
プラグインを以前のバージョンに巻き戻す
キャッシュの完全削除でも直らないときは、アップデートそのものに互換性の問題があると判断してよい。メガメニュープラグインを無効化し、旧バージョンの ZIP ファイルを入手して手動で上書きする。
旧バージョンはプラグインの公式ページにある「以前のバージョン」セクションや、開発者向けの SVN リポジトリからダウンロードできる。管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」から ZIP を選び、「既存のものを置き換える」形でインストールする。上書き後、管理画面でバージョン表記が古くなっていれば成功だ。
この作業でメガメニューが復旧したら、一時的に自動更新を停止しておく。プラグイン一覧画面や wp-config.php に define('WP_AUTO_UPDATE_CORE', false); を追加する方法もあるが、該当プラグインだけを止めるにはプラグイン単位の自動更新を無効化するコードを functions.php に書くか、管理プラグインを使う。
項目がまるごと消える問題の原因を切り分ける

スタイル崩れだけでなく、メニュー項目のひとつが完全に非表示になるケースでは、CSS の display プロパティや visibility プロパティが悪さをしていることが多い。HTML 構造が変わった結果、テーマ側で追加したカスタム CSS が意図しない要素を非表示にしている可能性がある。
デベロッパーツールで非表示の原因を特定する
Chrome の検証機能で消えたメニュー項目の HTML 要素を探す。要素が見つかるのに画面に出ていない場合は、右側の「スタイル」パネルで display:none や visibility:hidden が適用されていないか確認する。該当プロパティがあれば、打ち消し線が入っているか、どの CSS ファイルの何行目から来ているかが表示される。
もしテーマの style.css や追加 CSS に身に覚えのないルールがあれば、そのセレクタがアップデート後の HTML に誤ってマッチしている可能性が高い。一時的にそのルールをコメントアウトして表示が復活するかを試すと、原因の特定が早い。
テーマとプラグインの競合を調べる
メガメニュープラグインのアップデート後に問題が起きた場合、テーマ側のメニュー処理と競合していることも考えられる。一時的に標準テーマ(Twenty Twenty-Five など)に切り替えて、メニューが正常に表示されるか確認する。標準テーマで問題なければ、テーマ側のカスタマイズや専用のメニュー関数が干渉していると判断できる。
再発を防ぐためのアップデート前チェックリスト

メガメニューのようなサイト全体の導線を担うプラグインは、更新ひとつで売上や問い合わせに影響が出る。以下の手順を踏んでおけば、今回のようなスタイル崩れを未然に防げる。
- ステージング環境で事前にアップデートを検証する
- テーマのカスタム CSS はメガメニューのクラス名に依存しすぎない
- 更新前に必ずサイト全体のバックアップを取る
- キャッシュ系プラグインの設定を更新後に見直す習慣をつける
特に、ステージング環境での事前検証は手間に見えて最も確実な安全策だ。多くの国内レンタルサーバーはワンクリックでステージングを作れる機能を備えている。更新後、メニューの表示やモバイルでの開閉動作を一通りチェックしてから本番に反映すれば、今回のような急なスタイル崩れでサイトが長時間壊れる事態を回避できる。
よくある質問
旧バージョンの ZIP が見つからない場合はどうする?
プラグインの公式ディレクトリページ下部にある「以前のバージョン」からダウンロードできないケースでは、開発者の公式サイトや GitHub リポジトリを探す。WP Rollback のようなプラグインを使えば、管理画面から直接過去のバージョンに切り替えられる場合もある。
キャッシュを削除しても直らないのはなぜ?
サーバー側のキャッシュに加え、CDN を使用している場合は CDN のキャッシュもパージする必要がある。また、ブラウザの Service Worker が古いファイルを保持していることもあるので、シークレットウィンドウで確認するか、デベロッパーツールから Service Worker の登録を解除する。
アップデートを戻したのに一部のスタイルが直らない
旧バージョンに戻した後も、キャッシュ系プラグインが生成した最適化済み CSS ファイルが残っている可能性がある。「CSS の再生成」や「クリティカル CSS の削除」も実行する。さらに、テーマ側のカスタマイザーで追加した CSS が悪さをしていないか、追加 CSS 欄を一時的に空にして確認する。
修正版がリリースされるまでどう運用すればよい?
プラグインの自動更新を停止し、旧バージョンのままサイトを運用する。管理画面の「更新」通知は無視して問題ない。修正版が公開されたら、最初にステージング環境でテストし、スタイルや項目の表示に問題がないことを確認してから本番に適用する。
この記事のポイント
- プラグイン更新後のメガメニュー崩れはキャッシュの完全削除から試す
- 改善しなければ旧バージョンに巻き戻し、自動更新を一時停止する
- 項目消失は CSS の意図しない適用が原因になりやすい
- テーマとの競合を疑う場合は標準テーマで切り分ける
- 再発防止にはステージング環境での事前検証が最も有効

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

Kadence BlocksのナビゲーションAdvブロックでフォント設定が効かない時の直し方
Kadence Blocks のナビゲーション(Adv)ブロックでフォントサイズや太字の設定が反映されず、文字が意図したスタイルにならない現象の原因は、プラグイン側のバグだ。Kadence Blocks 7.3.3 以降のバージョンでは、ブロックが出力するインライン CSS に {{ のような余分な二重括弧が混入し、ブラウザが CSS のパースに失敗して該当の装飾が丸ごと無効になる。この問題はカスタマイズを台無しにするが、Kadence Blocks を 7.3.2 以前の安定版に戻せば即座に直る。
なぜナビゲーションAdvブロックのフォント設定だけが消えるのか

ブロックエディター上や公開サイトで、ナビゲーションメニューの文字サイズが指定したとおりに表示されず、標準テーマのデフォルト値に戻ってしまう。検証ツールで要素に付与されているインラインスタイルを見ると、次のような壊れた CSS が埋め込まれていることが確認できる。
このデモで示したとおり、本来は {…} であるべきブロックのスタイル指定が、バグにより {{…}} と出力されてしまう。この形式はブラウザの構文解析でエラー扱いされ、font-size や font-weight がまったく適用されなくなる。Kadence ナビゲーション(Adv)ブロックを使っているメニューすべてで発生し、管理画面のブロックエディター上でもプレビューが崩れてしまうのが典型的な兆候だ。
ナビゲーションAdvブロックの表示崩れを直す手順

根本原因は Kadence Blocks 7.3.3 以降のコードにある。修正アップデートがリリースされるまで、自力で解決するには古い安定バージョンにプラグインを差し戻すのが確実かつ短時間で終わる方法だ。サーバーをいじる必要はなく、WordPress 管理画面の操作だけで完了する。
現在の Kadence Blocks のバージョンを確認する
「プラグイン」→「インストール済みプラグイン」で Kadence Blocks 、 Gutenberg Blocks for Page Builder Features を探す。バージョン番号が 7.3.3 以上であれば、この不具合の影響を受けている可能性が高い。日本語環境では「Kadence Blocks(旧 Kadence Gutenberg Blocks)」と表記される場合もある。
一度 Kadence Blocks を削除せずにダウングレードするための準備
WordPress の仕様上、管理画面から直接古いバージョンを上書きインストールすることはできない。必ず一度無効化と削除を行い、その後 7.3.2 以前の ZIP ファイルを手動でアップロードする流れになる。ただし、削除してもデータベースに保存されているブロックの設定は消えないため、再度同じプラグインを導入すれば以前のデザインは保持される。
STEP 1:Kadence Blocks を無効化して削除する
「プラグイン」画面で Kadence Blocks を無効化し、続けて削除を実行する。「本当に削除してもよいか」という確認画面では、そのまま操作を進めて問題ない。削除によってブロックのレイアウトデータが消えることはなく、再度インストールすれば以前の状態に復元される。
STEP 2:7.3.2 以前のバージョンを手動でインストールする
WordPress.org の Kadence Blocks プラグインページにアクセスし、「アドバンスビュー」から「バージョンを選択」のドロップダウンで 7.3.2 を選び、ZIP ファイルをダウンロードする。バージョン一覧のURLは https://wordpress.org/plugins/kadence-blocks/advanced/ の末尾からアクセスできる。ダウンロードしたら「プラグイン」→「新規追加」→「プラグインのアップロード」から ZIP を選択し、「今すぐインストール」を実行する。
STEP 3:有効化してキャッシュをクリアする
インストール完了後、忘れずに Kadence Blocks を有効化する。続いて、サイトのキャッシュ系プラグイン(W3 Total Cache や WP Super Cache など)で全キャッシュを削除し、ブラウザのキャッシュもリロードして最新の状態を確認する。これでナビゲーションAdvブロックのフォント設定が元どおり反映されるはずだ。
ダウングレードが難しい場合の応急策と今後の注意点
WordPress の自動更新を一時的に停止しておく
Kadence Blocks に限らず、プラグインの自動更新が有効になっていると知らないうちにバグのあるバージョンに上がってしまい、同じ現象が再発する。とくに本番サイトでは「プラグイン」→「インストール済みプラグイン」の各プラグインに表示される「自動更新を有効化」のチェックが外れている状態を推奨し、アップデートはステージング環境で検証してから手動で行う習慣が安心だ。
プラグイン側の修正パッチを追う
この二重括弧の不具合は Kadence Blocks の無料版でも再現する純粋なバグのため、開発者のもとですでに修正が進められている可能性が高い。公式の変更履歴(Changelog)を定期的に確認し、次の安定版リリースがあれば速やかに導入することが基本となる。
よくある質問
ダウングレードしたがまだフォントが反映されない
ブラウザキャッシュや CDN のキャッシュに古いスタイルシートが残っているケースだ。シークレットウィンドウで表示確認するか、管理画面の「外観」→「カスタマイズ」で該当のナビゲーションブロックの設定を一度開いて「公開」を押し直すと、強制的に新しい CSS が生成されて直ることが多い。
ほかの Kadence ブロックも同じ現象が起こるのか
今のところ報告が集中しているのはナビゲーション(Adv)ブロックのみだ。ただし Kadence の高度なブロック群で似たような CSS 生成の仕組みを使っている可能性はゼロではないため、別のブロックで表示の異常を見つけた場合は同じ手順でバージョンを戻してみると切り分けになる。
Pro 版の Kadence Blocks でも同じバグは起こるのか
今回の不具合は無料版のコア機能に起因しており、Pro 版を併用している環境でも 7.3.3 以降に更新すればまったく同じように発生する。ダウングレードの手順も無料版と変わらない。
プラグインを削除せずに直す方法はないのか
functions.php などでフィルターフックを使い、動的に二重括弧を除去するコードを書くことは理論上可能だが、すべてのブロックに干渉するためリスクが高い。安全をとって旧バージョンに戻す方が現実的だ。
この記事のポイント
- Kadence Blocks 7.3.3 以上でナビゲーションAdvブロックのフォント設定が消えるのは、インラインCSSの二重括弧が原因
- 解決の最短手段は 7.3.2 以前へのダウングレードとキャッシュクリア
- プラグインの削除・再インストールでデータは消えず、設定も維持される
- 自動更新を止めて、本番適用前に検証する運用が望ましい
- 公式の修正パッチがリリースされ次第、最新版に戻して問題ない

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

WooCommerceで国別価格設定後にカートで価格が18%下がる原因
国別価格プラグインとWooCommerceの標準税設定を併用していると、商品をカートに入れた瞬間に約18%引きの価格が表示される現象が起きる。これはインド向けの税率が米ドル建ての表示価格にまで漏れ出し、税抜き再計算が走ってしまうためだ。
なぜカートで価格が18%下がるのか

カートに追加した直後に129ドルが約109ドルに減る理由は、WooCommerceの「税設定」と「価格表示」に潜む優先順位の構造にある。販売地域がインドで基本通貨を米ドルに設定し、かつ国別価格プラグインで国ごとに異なる価格を手動入力している店舗では、インド向けの18%税率が米ドル表示側に干渉しやすい。
WooCommerceの税設定には「税込で価格を入力する」か「税抜きで入力する」かの二択がある。税込(ベース価格に税が含まれている前提)を選ぶと、システムは表示価格を税込み総額とみなし、該当する税率に基づいて税抜き部分と税額に内部で分離する。ここに、本来その国には適用されるはずのないインドの18%スラブが食い込むと、129ドルを「税抜き価格+18%税相当」と計算し直し、税抜き価格約109ドルをカートに表示してしまう。
特にPrice Based on Country系のプラグインは、通貨ごとに手動価格を入力できても、WooCommerceの標準税テーブルと密接に連動しているわけではない。このため国検出ロジックと税ルールが別々に動き、非インド顧客の米ドル表示にもインド税率がかぶさる不整合が起こる。
税テーブルと国別価格の干渉を解消する手順

不整合の根源である税テーブルを整理し、適用範囲を正しく限定すれば価格の引き下げは止まる。管理画面から次の流れで修正する。
税率テーブルを開くと、インド向けの18%行の「国コード」欄が空白または複数国に誤設定されているケースがある。これをIN単独に直し、米国など他国に波及しないようにする。Price Based on Countryプラグイン側でも、米ドル表示の国リストに見落としがないか再確認する必要がある。
価格表示オプションの「税込」「税抜」を整理する

税込み入力モードは税テーブルと不可分に動くため、通貨ごとに手動価格を割り当てる運用との相性が悪い。税抜き入力に切り替えて価格を純粋な本体金額とし、税は決済時に国ごとのテーブルにしたがって自動加算する形が安定する。
ただし切替時に既存商品の価格は変わらないため、129ドルと入力していた商品は税抜き129ドルとみなされ、かえって値上がりする。そこで切り替え後は全商品の価格を意図した税抜き金額(たとえば税込み表示にしたいなら本体109ドル前後)に書き換える作業が必要になる。国別価格プラグインに一括更新機能があれば活用すると手間を減らせる。
商品価格 129ドル → 自動で18%税抜き計算 → カートに109ドル表示
商品価格 109ドル(本体) → 税は決済時のみ加算 → カート表示は109ドルで安定
税込み入力モードのまま運用を続ける場合は、インドの税率をいったん無効化し、Price Based on Countryプラグイン側の価格に税込み金額を直接登録する方法もある。ただこの方法は今後の税率変更に弱く、国ごとの税計算をWooCommerceの標準機能に任せられなくなるため推奨しない。
よくある質問
米ドル建てに18%の税率が見当たらないのに価格が下がるのはなぜか
米ドル用の税率が存在しなくても、WooCommerceは税込み入力モード時に「顧客の所在地に連動した税率」を内部で適用しようとする。国検出がインドと判定された瞬間に18%スラブが動き、価格が再計算されるのが根本原因だ。
国別価格プラグインを一時停止すればすぐ直るか
プラグインを無効化すると国別の価格表示そのものが消え、全ユーザーに基本通貨の価格が表示されるため、18%引きは起こらなくなる。ただし根本解決ではなく、多通貨販売をあきらめることになる。
税率テーブルでIN以外の国をすべて削除しても問題ないか
税率を適用したい国が増えるたびに行を追加する運用になるが、現在問題が起きている状態よりは安全だ。税率テーブルには最低限必要な国コードだけを残し、ワイルドカード指定は避けることを勧める。
価格を税抜き入力に切り替えた後、カートで税が表示されずに困る場合の対処は
税抜き入力にしたら「表示価格」の設定を「税込み」に戻すと、フロントエンドでは本体価格に税が乗った金額が表示される。この設定は「WooCommerce → 設定 → 税」の「店舗での価格表示」で変更できる。
キャッシュが原因で設定変更がすぐ反映されないときはどうするか
WooCommerceの「ステータス → ツール」から顧客セッションと製品の価格キャッシュをクリアし、さらにサイトキャッシュやCDNキャッシュもあわせて削除する。プライベートウィンドウで確認すると切り分けが早い。
この記事のポイント
- カートでの価格引き下げは税込み入力モードと国別税率の干渉で起こる
- 税率テーブルの国コードを見直し、不要な適用範囲を削除する
- 「税抜きで価格を入力する」モードに統一すれば価格は安定する
- 設定変更後はキャッシュクリアと価格再設定を忘れずに行う

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

Contact Form 7 PayPal Stripe Add-onの脆弱性と最新版への更新手順
Contact Form 7 PayPal & Stripe Add-on のバージョン 2.4.9 以前には、PayPal 決済を本来の支払い金額や通貨と無関係に「支払い完了」として通過させてしまう脆弱性がある。最新版へ更新すれば対処でき、放置すると注文だけが成立して金銭が回収できない重大なリスクを抱えるため、至急確認する必要がある。
Contact Form 7 用 PayPal & Stripe Add-on にどんな脆弱性があるのか

この脆弱性は CVE-2026-9189 として採番されており、攻撃者が PayPal の正当な通知(IPN)に見せかけたリクエストを送信することで、実際の支払い金額や通貨、受取人の一致をまったく検証せずに「支払い済み」とマークできてしまう。プラグインは PayPal からの通知の署名検証は行っていたものの、肝心の取引金額・通貨コード・受取人メールアドレスの突き合わせを実装していなかったため、ゼロまたは極端に低い金額の注文が成立してしまう。
具体的には、フォーム送信時に生成される注文レコードに対して、PayPal のトランザクション ID と支払いステータスのみが照合され、注文時に設定された金額と実際に PayPal 上で決済された金額の比較が行われない。このため、正規のトランザクション ID を悪用、あるいは偽装した通知に対してプラグインが「正当な支払い」と誤認する状況が生まれていた。
PayPal 通知の受信 → 署名検証のみ実施 → 金額・通貨・受取人の検証なし → 0円でも「支払い完了」
PayPal 通知の受信 → 署名検証 → 金額・通貨・受取人を注文情報と突合 → 一致時のみ「支払い完了」
上の図が示す通り、修正後は金額・通貨・受取人の3点を必ず比較するロジックが追加されている。この検証が欠けていたことが、支払いバイパスを成立させる根本原因だった。
どのバージョンが影響を受けるのか

Contact Form 7 PayPal & Stripe Add-on のバージョン 2.4.9 以下が影響を受ける。2026年6月中旬時点で修正済みのバージョンがリリースされており、2.5.0 以降に更新すればこの脆弱性は解消される。
自分のサイトでどのバージョンを使用しているかは、WordPress 管理画面の「プラグイン」→「インストール済みプラグイン」一覧で確認できる。該当プラグインが有効化されている場合は、バージョン番号を直ちにチェックしておきたい。
最新版へ更新する具体的な手順

更新前にサイト全体のバックアップを取得しておくとなお安心だ。更新が完了したら、プラグイン一覧でバージョンが 2.5.0 以降に切り替わっていることを必ず確認する。
更新がすぐに実行できない場合の対処

何らかの理由で即時更新が難しい場合は、一時的に PayPal 決済機能を停止し、フォームそのものを別の決済手段に切り替えるなどの対策が有効だ。とはいえ、あくまで暫定的な措置であり、根本対策は最新版への更新以外にない。
プラグインを無効化すれば脆弱性は発動しなくなるが、フォーム経由の PayPal 決済も一切使えなくなる。その間に代替として WooCommerce の標準決済や別のフォームプラグインへ移行する判断も必要になるだろう。
よくある質問
Stripe 決済にも同じ問題はあるのか
この脆弱性は PayPal の通知処理に起因する問題であり、Stripe 側の処理ロジックには同様の不備は確認されていない。ただし、セキュリティ修正の一環で Stripe 関連のコードにも改善が加えられているため、プラグイン全体を最新に保つのが賢明だ。
すでに不正な取引が行われていないか調べる方法はあるか
PayPal の取引履歴と Contact Form 7 の送信ログを突き合わせ、注文金額と実際の決済金額が一致しているかを手動で検証する必要がある。プラグイン自体に取引監査の機能はないため、自社の売上レポートと PayPal の管理画面を定期的に照合する習慣をつけることを推奨する。
自動更新を有効にしていれば問題は起きなかったのか
自動更新が有効でも、WordPress.org のプラグインディレクトリに修正版が配信されるタイミング次第では数時間から数日のラグが生じる。さらに、サイトの更新設定によってはメジャーアップデートが自動適用されないケースもあるため、手動での確認を怠らないほうが安全だ。
このプラグインを使い続けるリスクは他にもあるか
Contact Form 7 のアドオンは多数の開発者によって提供されており、サポートや更新の頻度はプラグインごとにまちまちだ。決済を扱う以上、常に開発が継続され、すみやかにセキュリティパッチが提供されるプラグインを選ぶことが大前提となる。
この記事のポイント
- Contact Form 7 PayPal & Stripe Add-on 2.4.9 以前に支払いバイパスの脆弱性がある
- PayPal 通知の金額・通貨・受取人を検証しないため 0 円でも「支払い完了」になる
- 修正済みの最新版(2.5.0 以降)に更新すれば問題は解消される
- 更新前にバックアップを取り、バージョン番号を必ず確認する
- 決済系プラグインは常に最新を保ち、定期的なログ照合を習慣化する

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

Relevanssiで日本語検索クエリが原因のテーブルフルスキャンを防ぐ
—
Relevanssiで日本語だけの検索クエリがデータベースの全テーブルスキャンを引き起こす問題は、トークナイズ結果が空文字になるケースをカスタムコードで事前に検知し、SQLを発行せずに空の結果を返すことで根本的に回避できる。設定のチューニングと併用すれば、サイト全体の検索パフォーマンスを維持できる。
なぜ日本語の検索クエリでRelevanssiがテーブル全体を読み込むのか

Relevanssiは登録された投稿のタイトルや本文を分解し、単語単位でインデックスを作る全文検索プラグインだ。英語などスペースで区切られた言語では問題なく機能するが、日本語や中国語、韓国語といったCJK(中国語・日本語・韓国語)テキストでは事情が異なる。
CJKの文字列は単語境界の空白が存在しないため、Relevanssiが検索クエリを受け取ると、内部のトークナイザ(単語への分割処理)で適切な単位に区切れないことがある。特に、形態素解析エンジンがインストールされていない標準環境では、クエリが解析不能と見なされ、トークンがゼロ個、つまり空の状態になりやすい。
この「空のクエリ」が問題の本質だ。Relevanssiの検索SQLでは、本来なら検索語に基づいてWHERE term = '検索語'のように絞り込む。しかしトークンが空になると、検索語を表す変数に何も入らず、SQLがWHERE term = termという常に真になる条件へと崩れる。結果としてwp_relevanssiテーブルの何百万行という全レコードを走査するフルスキャンに陥り、応答に数十秒かかる事態を引き起こす。
これはバグではなく、空のクエリに対するフォールバック(予備動作)が設計上考慮されていないために発生する。本来なら検索語が存在しないと判断された時点で、データベースに問い合わせず「該当なし」を返すのが望ましい。
検索クエリが空になるのをコードで検出し早期リターンする

最も確実な解決策は、RelevanssiがSQLを構築する前に検索クエリの内容をチェックし、有効なトークンがなければ検索処理を打ち切る仕組みをテーマのfunctions.phpに組み込むことだ。Relevanssiは複数のフィルターフックを提供しており、そのうちrelevanssi_search_okまたはrelevanssi_modify_wp_queryを利用する。
具体的な実装コードと設置手順
このデモが示す流れで、コードを追加する。以下は実際に利用できる実装例だ。
add_filter( 'relevanssi_search_ok', function( $ok, $query ) {
// 検索クエリが文字列であり、内容が空でないか確認する
if ( ! is_string( $query->query_vars['s'] ) || '' === trim( $query->query_vars['s'] ) ) {
return false; // 検索を実行せず早期リターン
}
// スペースを除いたテキストがCJK文字だけで構成されているか簡易チェック
$search_term = trim( $query->query_vars['s'] );
// CJK統合漢字・ひらがな・カタカナ・ハングルの正規表現
$cjk_pattern = '/[\x{4e00}-\x{9faf}\x{3040}-\x{309f}\x{30a0}-\x{30ff}\x{ac00}-\x{d7af}]+/u';
preg_match_all( $cjk_pattern, $search_term, $matches );
// マッチしたCJK文字列が存在するかを確認
if ( empty( $matches[0] ) ) {
// CJK文字がなければ通常の検索を続行
return $ok;
}
// 簡易的なトークン判定: Relevanssiが実際に使うトークナイザを再現
// ここではCJKクエリが本当にインデックス可能か簡易判定する
$tokens = relevanssi_tokenize( $search_term, true );
if ( empty( $tokens[0] ) ) {
return false; // 有効なトークンがないため検索中止
}
return $ok;
}, 10, 2 );このコードでは、Relevanssiの内部関数relevanssi_tokenize()を呼び出し、実際に検索に使われるトークンが生成されるかどうかを見ている。もし空の配列が返ってきたら、それは全テーブルスキャンを引き起こす危険な状態だと判断し、falseを返すことで検索SQLの実行そのものをブロックする。
もうひとつ重要なのは、relevanssi_search_okフィルターがSQL構築の直前で動作するため、無駄なクエリがデータベースに発行される前に検索を止められる点だ。サイトの規模が大きく、wp_relevanssiテーブルが数百万行を超える場合でも、安全に空の結果を返せるようになる。
テーマの functions.php に追加する際の注意点
コードは必ず子テーマのfunctions.phpまたは専用のカスタムプラグインに記述する。親テーマのfunctions.phpを直接編集すると、テーマのアップデートで変更が失われる。また、PHPのバージョンが7.4以上であることをあらかじめ確認しておく。
コードを追加したら、日本語だけで構成された検索クエリを実際に投げてみる。検索結果がゼロ件で返ってくることを確認し、同時にMySQLのスロークエリログやQuery Monitorプラグインで、フルスキャンが発生していないかチェックすると確実だ。
データベースの負荷を根本的に下げるRelevanssiの設定

コードによる早期リターンと並行して、インデックスと検索設定そのものを見直すことで、CJKクエリ以外の場面でもパフォーマンスを向上させられる。
最小文字数制限をCJKに合わせて調整する
Relevanssiの管理画面には「インデックスを作成する最小文字数」という設定がある。デフォルトでは2文字程度に設定されていることが多いが、CJK環境では1文字でも意味を持つ(例: 「本」「水」など)ため、1に下げるのが基本だ。ただし、1文字にするとインデックスサイズが膨張しやすいため、サイトの投稿規模に応じて2以上にするか、あるいは後述の文字種フィルタリングと組み合わせる。
検索から除外する投稿タイプやステータスを絞る
wp_relevanssiテーブルが肥大化する大きな要因は、リビジョンや自動下書き、非公開のカスタム投稿タイプまでインデックスに含めているケースだ。設定画面の「インデックスを作成する投稿タイプ」で、実際にサイトのフロントエンド検索で必要になる投稿タイプと公開済みのものだけに限定する。リビジョンが無駄に行を占有しているだけで、テーブルサイズが数割変わることもある。
MySQL / MariaDB のバッファ設定を最適化する
13万投稿、1300万行のインデックスを持つ規模では、サーバーのデータベース設定そのものがボトルネックになる。特にinnodb_buffer_pool_sizeをサーバーの物理メモリの70%程度に設定し、Relevanssiのテーブル全体がメモリに収まるようにすると、たとえスキャンが発生してもディスクI/Oを避けられる。設定変更は必ず本番環境でテストした後に適用する。
よくある質問
コードを追加した後、通常の英語検索に影響はないか
上記のコードは、トークンが空になる場合にのみ検索を中止する。英語のスペース区切りクエリや、英数字が混在する日本語クエリでは通常どおりRelevanssiのインデックスが使われるため、影響はない。万が一、正常な検索がブロックされていると感じたら、relevanssi_tokenize()の結果をエラーログに出力して確認する。
Relevanssi以外の全文検索プラグインでもこの問題は起こるのか
起こりうる。特にPHPベースのトークナイザに依存するプラグインでは、CJK文字の分割に失敗すると同様の空クエリ問題が発生する可能性がある。検索プラグインを選定する際は、形態素解析(MeCabなど)に対応しているか、もしくは外部の検索エンジン(Elasticsearch、Algoliaなど)と統合できるかを基準にするとよい。
大量のクローラーからCJKクエリを繰り返し受けている場合の対策は
検索クエリが空になるパターンは、ボットがランダムな文字列や日本語の記事タイトルを検索ボックスに投げ込むことで頻発する。コードによる早期リターンでサーバー負荷は防げるが、さらにCloudflareやWAFのレート制限で同一IPからの過剰な検索リクエストを制限すると、クローラー起因のリソース浪費全体を抑えられる。
functions.php を触れない環境で他にできることはあるか
管理画面のRelevanssi設定で「検索を許可する最低文字数」を意図的に上げる(例: 3文字)方法がある。ただし、これは短い日本語の単語が検索できなくなる副作用を伴う。根本解決にはならないが、緊急のパフォーマンス低下を抑える応急処置としては有効だ。
この記事のポイント
- 日本語のみの検索クエリでRelevanssiが全テーブルスキャンに陥る根本原因は、トークナイズ結果が空になりSQLが常に真になるため
- カスタムコードでSQL実行前に空トークンを検出し、早期リターンさせることでデータベース負荷を回避できる
- インデックスの最小文字数制限や対象投稿タイプの絞り込みをCJK向けに最適化すると、さらなるパフォーマンス改善につながる
- コード追加後も通常の英数字検索には影響を与えず、安全に運用できる
- クローラーからの大量アクセスに対してはWAFやレート制限との併用が効果的

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

WooCommerceにEU契約撤回ボタンを無料で追加する方法
2026年6月19日からEU消費者へ販売するオンラインショップには、契約を撤回する「離脱ボタン」をストアフロントに設置する義務が発生する。WooCommerceには標準でこの機能がないため、無料の専用プラグインを見極めて導入すれば、技術的な難しい変更なしに対応できる。
なぜ2026年6月からEU向けWooCommerceに契約撤回ボタンが必要なのか

EU指令2023/2673(従来の消費者権利指令に第11a条を追加)が、2026年6月19日以降にEU在住の消費者を対象に販売するすべての事業者に対して、契約を撤回するための「明確に表示されたワンクリック機能」の提供を義務付けている。これは商品の返品とは別に、契約そのものから離脱する手段を消費者に与えるものだ。
日本からEUへ越境ECを行う事業者も、現地の消費者をターゲットにしている限り例外ではない。WooCommerce単体ではこの離脱機能に対応しておらず、公式要望トラッカー上で議論は続いているものの、すぐに実装される見込みはない。そのためプラグインによる早期の対応が欠かせない状況になっている。
WooCommerce向け離脱ボタンプラグインで絶対に押さえるべき機能

多数の無料プラグインが出回っているが、法令を満たすために最低限チェックするポイントは変わらない。見落としを防ぐために、以下の基準を事前にリストアップしておくことが大切だ。
ワンクリックで契約撤回が完了する仕組み
消費者がボタンを押すだけで、追加のフォーム入力や本人確認なしに撤回の意思表示が完了しなければならない。撤回の受付通知が自動的にメールで送られる仕組みも必須になる。
わかりやすく目立つボタン表示
「契約を撤回する」といったボタン文言が、注文確認画面やマイアカウントページなど、消費者が容易に見つけられる位置に常に表示される必要がある。テーマのスタイルに埋もれず、かつ法的に十分な表示であることが求められる。
GDPRおよび個人データ取り扱いへの配慮
離脱ボタンの動作に伴って取得される個人データ(注文ID、メールアドレスなど)の取り扱いがGDPRに準拠しているかも確認する。プラグインが不要なデータを保存していないか、またデータ保持期間の設定ができるかが重要な判断材料になる。
多言語対応と日本向けの翻訳品質
EU圏内で複数言語のサイトを運営する場合、ボタン文言や通知メールを各国語に切り替えられる多言語対応が必須になる。日本語で運用しているサイトでも、管理画面表示が適切に翻訳されているか、表示されるフロント文言が自然かを確かめておきたい。
更新の継続性とエコシステムとの相性
WordPress本体やWooCommerceのアップデートに追従しているか、アクティブインストール数や最終更新日を確認する。法典の変更に応じて仕様が変わる可能性もあるため、活発にメンテナンスされているプラグインを選ぶことで将来のリスクを抑えられる。
無料のEU契約撤回プラグインを安全に選んで導入する流れ

実際にプラグインを選ぶ際には、機能のチェックリストをクリアするだけでなく、自分のサイト環境で競合なく動作するかのテストがとても重要だ。以下の手順で進めれば、手戻りなく導入できる。
上図は一般的な導入手順を示したイメージで、実際のプラグインによって設定画面の構成は異なる。
プラグイン導入後に必ずチェックする項目と表示カスタマイズのコツ

プラグインを有効化しただけでは、テーマの都合でボタンが正しく表示されなかったり、通知メールが迷惑メールに振り分けられたりするケースがある。以下のポイントを必ず実機で確認しておく。
マイアカウントページと注文詳細画面の両方にボタンが現れるか
購入後の消費者がアクセスするマイアカウント内の注文一覧や個別注文画面、そしてゲスト購入者向けの注文確認ページの両方でボタンが機能するかを必ず検証する。プラグインによってはゲスト購入に対応していないこともあるため注意が必要だ。
撤回後のフローがEC事業者側にも通知されるか
消費者が撤回ボタンを押したあと、店舗運営者にメールや管理画面内の通知が届く仕組みになっているかも重要だ。対応が遅れるとトラブルに発展するため、通知が確実に飛ぶ設定になっているかを最初のテストでつかんでおく。
表示をCSSで微調整したい場合の注意
ボタンの色やサイズをテーマに合わせたいときは、追加CSSに直接スタイルを書いて調整するのが現実的な方法だ。ただし、プラグインが出力するHTMLのクラス名やIDはアップデートで変わることがあるため、子テーマのstyle.cssに依存しすぎないようにし、変更後は必ず再テストを行う。
よくある質問
WooCommerce用のEU離脱ボタンプラグインは本当に無料で使えますか
現在、WordPress公式リポジトリで複数の無料プラグインが公開されている。いずれも基本機能は無料で提供されており、有料版で追加機能が解放される場合もあるが、法令要件を満たすだけなら無料で十分対応できる。
ボタンの設置だけでEUの法律要件はすべて満たせますか
離脱ボタンは指令が求める機能の一部だ。合わせて返品ポリシーの明示や、撤回後の返金手続きを整備する必要がある。プラグインはあくまで技術的な「ボタンの提供」部分を解決するものだと理解しておくことが大事だ。
多言語サイトでボタン文言を日本語にしたい場合の対処法は
多くのプラグインは翻訳ファイルを内包しているか、管理画面でボタン文言を自由にカスタマイズできる。日本語の翻訳が不完全な場合はLoco Translateなどの別の翻訳プラグインを併用して、表示テキストだけを書き換えることも可能だ。
プラグインがWooCommerceの今後のアップデートで動かなくなる心配は
定期的に更新されているプラグインを選ぶことでリスクは下げられる。導入前に最終更新日とアクティブインストール数、サポートフォーラムの反応を確認し、万が一に備えてステージング環境を用意しておくのが堅実な運用だ。
この記事のポイント
- 2026年6月19日からEU向け販売店に契約撤回ボタンの設置が義務化された
- WooCommerce標準には機能がなく、無料プラグインでの対応が現実的な解決策
- プラグイン選びではワンクリック完了、明確な表示、GDPR配慮、多言語対応をチェック
- 導入後は表示場所とゲスト購入時の動作を必ずテストし、通知設定も確認する
- 定期更新が続いているプラグインを選び、ステージング環境で動作検証を行う

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験

WooCommerce MyParcelで重大エラーが出た時のデフォルト配送業者設定方法
WooCommerce の MyParcel プラグイン使用時に表示される「このサイトで重大なエラーが発生しました」というエラーは、プラグイン内にデフォルトの配送業者が設定されていないことが原因だ。プラグイン設定画面からデフォルトの配送業者を選択すれば、エラーはすぐに解消する。
なぜデフォルト配送業者が未設定だとエラーになるのか

このエラーは PHP の致命的エラー(Fatal Error)であり、MyParcel プラグインが「No default carrier available(利用可能なデフォルトの配送業者がない)」という例外を発生させて停止している。スタックトレースを追うと、発端は受注確認ページ(サンキューページ)などで追跡情報を表示しようとする際、プラグインが内部的に呼び出す getDefaultCarrierOrThrow() メソッドで落ちている。
MyParcel は配送ラベル作成や追跡情報の連携を行うプラグインであり、動作には「どの配送業者をデフォルトで使うか」という情報が必須だ。この設定を一度も行っていなかったり、アップデート時に何らかの理由で消えたりすると、サイトの該当ページでエラーが表示される。
デフォルト配送業者を設定する具体的な手順

管理画面にアクセスできる状態であれば、この手順だけでエラーは即座に解消する。設定項目の名称はプラグインバージョンによって「デフォルトの配送業者」「Default Carrier」などと表記が異なるが、いずれも一つのプルダウン形式で表示される。
管理画面にすらアクセスできない場合の対処
エラーがサイト全体に影響し、管理画面も真っ白になってしまうケースがある。その場合は FTP またはサーバーのファイルマネージャーを使い、一時的に MyParcel プラグインのフォルダをリネームして無効化する。
- サーバーに接続し、
/wp-content/plugins/ディレクトリへ移動する woocommerce-myparcelフォルダをwoocommerce-myparcel_deactivatedなどに変更する- これでプラグインが停止し、管理画面へアクセスできるようになる
- 管理画面に入れたら、上の STEP 手順で設定を行い、フォルダ名を元に戻して有効化する
設定を保存してもエラーが再発する場合
設定保存後に再び同じエラーが発生するなら、プラグインまたは関連データベース設定に不整合が起きている可能性が高い。以下の順で追加対応を試す。
- 一度プラグインを完全に削除し、最新バージョンを再インストールする
- WooCommerce のシステムステータス画面で、不要なトランジェント(期限付きキャッシュ)をクリアする
- MyParcel アカウントとの API 接続情報(API キーなど)を再入力する
エラーを未然に防ぐための注意点

プラグインのメジャーアップデート後や WordPress 本体の自動更新後に、こうした設定がリセットされる事例は珍しくない。MyParcel に限らず、配送系・決済系プラグインは「接続先のデフォルト設定」が必須となるものが多い。アップデート後はテスト環境や低トラフィック時間帯に決済フローとサンキューページの動作を一通り確認する習慣をつけると安心だ。
よくある質問
エラーメッセージが英語で「No default carrier available」と表示されているが日本語環境でも同じ?
日本語環境の WordPress でも管理画面やログに表示されるエラーメッセージは英語のままになる。ただしサイト訪問者には「このサイトで重大なエラーが発生しました」という日本語の汎用エラー画面が表示されるため、管理者はサーバーのエラーログやデバッグモードで英語エラーを確認することになる。
MyParcel 以外の配送プラグインでも同様のエラーは起こる?
配送ラベル生成や追跡機能を持つプラグインは、内部で配送業者を特定する仕組みに依存していることが多く、設定不足で同種のエラーが起きる可能性がある。具体的には「デフォルトの配送業者」「デフォルトの配送方法」が未選択であると、ページ表示時に致命的エラーになる構造は共通している。
Divi テーマを使っていることがエラーと関係ある?
スタックトレースに Divi のパスが含まれているのは、サンキューページを Divi の WooCommerce モジュールで構築しているためだ。エラーの根本原因はあくまで MyParcel プラグイン側の設定不足であり、Divi そのものに問題があるわけではない。
デフォルトの配送業者を設定しても配送ラベルが発行できない
デフォルト配送業者の設定はエラー解消の第一歩だが、実際にラベルを発行するには MyParcel アカウントとの正しい API 接続と、WooCommerce の配送クラスや商品重量の設定が必要になる。エラーが消えた後は、MyParcel の管理画面で接続ステータスが「アクティブ」になっているか確認する。
この記事のポイント
- PHP の致命的エラーは MyParcel のデフォルト配送業者未設定が原因
- 管理画面の MyParcel 設定からデフォルト配送業者を選択して保存すれば解決
- 管理画面に入れない場合はプラグインフォルダのリネームで一時無効化する
- アップデート後は配送系プラグインの設定リセットに注意が必要

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

Contact Form 7のPDF出力で条件分岐ショートコードが効かない時の直し方
Contact Form 7 から出力する PDF に条件分岐のショートコード([if] や [hide-*] など)が反映されないとき、最も多い原因は Send PDF for Contact Form 7 プラグインが、Conditional Fields のような他プラグインのショートコードを PDF 生成時に評価しないことだ。この問題は、PDF テンプレート内で直接条件分岐を記述する代わりに [_mail_body] タグを使ってメール本文を丸ごと流し込むか、出力直前にショートコードを再評価するフィルターフックで解決できる
なぜ PDF 出力で条件分岐ショートコードが効かなくなるのか

Send PDF for Contact Form 7 は、フォーム送信時に生成されたデータを PDF テンプレートに差し込んで出力する。このとき、[text-123] のような Contact Form 7 の標準タグは正しく展開されるが、Conditional Fields が提供する [group] や [if] といった条件分岐用のショートコードは、PDF 生成のコンテキストでは実行されないことが多い
理由は主に2つある。ひとつは、これらのショートコードが WordPress の do_shortcode フックに登録されていても、PDF プラグインがテンプレートを処理する段階では、フォームの送信データや条件判定に必要なコンテキストが不足しているケースだ。もうひとつは、Conditional Fields のショートコードが「メール送信時」にのみ動作するように設計されており、PDF 作成時にはそもそも処理の対象外になっているパターンだ
[if kosten-an-arbeitgeber]この見積は雇用主向けです[/if]
※条件にかかわらずショートコードがそのまま表示される
この見積は雇用主向けです
※条件に合致したテキストだけが PDF に出力される
このデモのように、PDF テンプレート内に [if] や [hide-*] を直書きしても、Send PDF 側で解釈されずに終わってしまう。以前は偶然動いていたとしても、プラグインのバージョンアップで処理順序が変わると即座に壊れる原因になる
プラグイン更新後に突然動かなくなったのはなぜか

「以前は PDF で条件分岐が効いていたのに、更新したら動かなくなった」という声は非常に多い。これは、Send PDF for Contact Form 7 または Conditional Fields for Contact Form 7 の内部実装が変更され、テンプレートの評価タイミングやショートコードの登録順が変わったためだ
具体的には、Send PDF プラグインの旧バージョンでは、PDF テンプレート全体を do_shortcode で処理していたが、パフォーマンスやセキュリティの改善に伴ってその処理が省略されたり、独自の置換処理に切り替わったりすることがある。結果として、Conditional Fields のショートコードが一切処理されなくなる
また、Conditional Fields 側のアップデートで、[if] タグの内部実装が変わり、PDF 出力時に必要なデータが揃わなくなった可能性もある。どちらにせよ、PDF テンプレート内で直接条件分岐を記述する方式は、プラグインのバージョンに依存しやすく、根本的に不安定と言える
[_mail_body] タグでメール本文をそのまま PDF に流し込む
![[_mail_body] タグでメール本文をそのまま PDF に流し込む](https://www.aandgweb.co.jp/wp-content/uploads/2026/06/2026-06-19_pain_001_h2_003.webp)
最も簡単で安全な解決策は、PDF テンプレート内に [_mail_body] を記述することだ。このタグは、Contact Form 7 が送信する「メール本文」をそのまま PDF 内に差し込む。メール本文のほうでは、Conditional Fields の条件分岐が正常に評価されているため、結果的に PDF にも正しい内容が出力される
この方法を使えば、Conditional Fields に限らず、メール本文で動作するあらゆるショートコードが PDF に反映される。ただし、PDF 独自のレイアウトや追加情報(会社ロゴや利用者に合わせた細かな差し込み)が必要な場合は、[_mail_body] の前後に固定の HTML を加えることで対応できる
注意点として、[_mail_body] はメール本文をそのままコピーするため、メール用の改行やスタイルが PDF に持ち込まれる。どうしてもレイアウトを細かく制御したい場合は、次に紹介するフィルターフックを使った方法を選ぶ
functions.php で PDF 生成前に条件分岐を再評価させる

Send PDF for Contact Form 7 には、PDF の最終的な内容を上書きできるフィルターフックが用意されている。これを利用すれば、テンプレート内の [if] や [hide-*] を手動で再評価できる。テーマの functions.php に次のようなコードを追加すると、Conditional Fields のショートコードが PDF 出力時に正しく展開される
add_filter( 'cf7_send_pdf_template_html', function( $html, $form_id ) {
// フォームの送信データを取得し、ショートコードを再評価する
$submission = WPCF7_Submission::get_instance();
if ( $submission ) {
$posted_data = $submission->get_posted_data();
// 一時的に do_shortcode を再度適用
$html = do_shortcode( $html );
}
return $html;
}, 10, 2 );このコードは、PDF テンプレートが組み立てられた直後に do_shortcode を実行し、[if] や [group] といったショートコードをその場で評価する。投稿データが揃っているため、Conditional Fields の条件判定も正しく動く
ただし、[hide-*] のように独自のショートコードを使っている場合は、そのショートコードがどのプラグインで定義されているかを確認し、該当のプラグインが有効でなければ動作しない。もし自作のショートコードであれば、あらかじめ add_shortcode で登録しておく必要がある
さらに、Send PDF プラグインのバージョンによってはフック名が異なる可能性もあるため、公式ドキュメントを参照し、cf7_send_pdf_template_html の部分を適切なフックに置き換える。このフックが利用できない場合は、wpcf7_before_send_mail などのアクションを使って PDF 生成前にデータを補完する方法もある
よくある質問
[_mail_body] を使うとメールの HTML タグがそのまま PDF に出てしまうのでは?
はい、メールフォーマットが HTML の場合、その HTML が PDF に適用される。多くは問題にならないが、シンプルなテキスト PDF を望むなら、メール設定を「テキスト形式」に切り替えるか、フィルターフックで HTML タグを strip_tags で除去するといった工夫が必要になる
Conditional Fields の [group] ショートコードも [_mail_body] で有効になるのか?
なる。[_mail_body] は、メール送信時に CF7 が最終的に組み立てた本文をそのまま埋め込むため、[group] の条件判定もすでに解決された状態で出力される
functions.php にコードを追加しても PDF が変わらないのはなぜ?
フック名が正しいか、また対象のショートコードが本当に do_shortcode で評価可能な形式かを確認する。Conditional Fields の [if] が内部で別のロジックを使っているレアケースでは、CF7 のメールテンプレート用のフィルター(wpcf7_mail_components など)を利用してメール本文を直接 PDF に渡すほうが確実だ
独自の [hide-*] ショートコードを PDF で動かすにはどうすればいい?
該当のショートコードを定義しているコードがテーマの functions.php にあるなら、そのまま do_shortcode で評価される。もし別のプラグインに依存しているのであれば、そのプラグインが常に有効でなければならない。動作が不安定な場合は、[_mail_body] 方式に切り替えるのが無難だ
この記事のポイント
- PDF テンプレート内で [if] や [hide-*] が効かないのは、Send PDF がそれらのショートコードを処理しないため
- [_mail_body] タグを使えば、メール本文ですでに展開された条件分岐結果をそのまま PDF に流し込める
- functions.php のフックで do_shortcode を再実行すれば、PDF 出力直前に任意のショートコードを動かせる
- プラグイン更新後に動かなくなったのは、ショートコード処理のタイミングが変わったのが原因
- 安定運用には[_mail_body]方式を推奨。細かいレイアウトが必要ならフィルターフック方式を使う

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