タグアーカイブ トラブル解決

WP All Importで物件画像が混ざる原因とファイル名の一意化による解決方法

WP All Importで物件画像が混ざる原因とファイル名の一意化による解決方法

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

WP All Import でインポートした画像が混ざる原因は何か

WP All Import でインポートした画像が混ざる原因は何か

WP All Import は XML フィードから画像をダウンロードし、メディアライブラリに追加する。ここで「すでに同じファイル名の画像がメディアライブラリに存在する」と、意図せず既存の画像を参照してしまうことがある。特に検索やマッチングをすべてオフにしていても、ファイル名の衝突が発生すると新規ダウンロードをスキップして既存画像にリンクを張る挙動が起こりうる。これが、異なる物件で同じ画像が表示される最大の原因だ。

もう一つの原因は、Houzez テーマやそのアドオンがインポート後に画像ギャラリーを再構築する際、メディアライブラリ内の添付ファイルの親子関係やメタデータを誤って上書きしてしまうケースだ。プレビュー段階では正しいのに、インポート完了後に別の物件の画像に差し替わるのは、インポート後のテーマ側の処理タイミングで画像の紐付けがずれるために起こる。

画像ファイル名を一意にして他物件との画像混入を防ぐ方法

画像ファイル名を一意にして他物件との画像混入を防ぐ方法

WP All Import では、インポートテンプレートの「画像」セクションで、保存時のファイル名をカスタマイズできる。ここで物件ごとに絶対に重複しない名前を付けるのが最も確実な対策だ。具体的には、物件 ID や MLS 番号、住所の一部など、XML 内のユニークな要素をファイル名に組み込む。

Before 重複しやすい設定
ファイル名指定 {filename}.jpg
↓ XML に「1.jpg」「1.jpg」… 重複発生
After 一意になる設定
ファイル名指定 {mls_id[1]}_{typename[1]}_{index}.jpg
↓ 物件ごとに絶対衝突しない
重複危険  一意保証

上のデモのように、{mls_id} や {property_id} といった絶対に重複しないフィールドをファイル名に含める。インポート時に「既存画像を保持」の設定をオフにしていても、ファイル名が重複すると WordPress 本体側で「ファイル名-1」「ファイル名-2」のように連番サフィックスが付与されることがあり、このサフィックス付きファイル名を Houzez アドオンが正しく追跡できない場合もある。ファイル名の段階で完全にユニークにしておけば、そのリスクも回避できる。

WP All Import の画像マッチング設定を適切に構成する

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 アドオンとテーマ側の画像処理を確認する

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 使用時の画像混入を防ぐ

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 使用時は同期処理への切り替えが安全
WP Extendedのスニペット一覧が真っ白になった時のファイル復旧方法

WP Extendedのスニペット一覧が真っ白になった時のファイル復旧方法

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

なぜ WP Extended のスニペット一覧が表示されなくなったのか

なぜ WP Extended のスニペット一覧が表示されなくなったのか

WP Extended のようなコードスニペット管理プラグインで一覧画面が機能しなくなる原因は、プラグイン自体の不具合というより、特定の環境下での PHP エラーやデータベースの不整合によるところが大きい。特に有効化したスニペットに文法エラーがあると、管理画面全体が「このサイトで重大なエラーが発生しました」といった真っ白な画面に陥るケースもある。実際の管理画面が表示されなくなった時の典型的な引き金は次のとおりだ。

  • 直前に有効化したスニペット内の PHP コードに誤りがある
  • プラグイン本体の更新と WordPress 本体または PHP バージョンとの相性問題
  • 他のプラグインとの競合で管理画面の読み込みが途中で止まる
  • サーバーのメモリ制限やファイル権限の問題でスニペットディレクトリを読み取れない

いずれにしても、スニペット一覧が見えなくなったからといって、作成したコードが消えたわけではない。WP Extended は各スニペットを wp-content ディレクトリ内に実ファイルとして保存しているため、管理画面が動作しなくてもサーバー側から直接回収できる。

スニペットの実体はどこに保存されているのか

スニペットの実体はどこに保存されているのか

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

↓ よくあるディレクトリ構成
/wp-content/
└─ wpextended-snippets/
    ├─ snippet-1.php
    ├─ snippet-2.php
    └─ snippet-3.php
※ 管理画面からアクセスできなくても、この場所をサーバー上で直接開けばスニペットのコードを取り出せる

サーバー上の PHP ファイルからスニペットのコードを回収する手順

サーバー上の PHP ファイルからスニペットのコードを回収する手順

管理画面が使えなくても、レンタルサーバーのファイルマネージャーか SFTP クライアントを使えばスニペットの実体にアクセスできる。全体の流れは以下のデモのとおりだ。

STEP 1 SFTP またはファイルマネージャーでサーバーにログインする
STEP 2 wp-content/wpextended-snippets ディレクトリを開く
STEP 3 スニペットの PHP ファイルをローカルにダウンロードする
STEP 4 エディタでファイルを開き、中身の PHP コードをコピーする

ファイルマネージャーを使う場合

多くの国内レンタルサーバーが提供しているブラウザ上のファイルマネージャーを開き、wp-content フォルダへ移動して wpextended-snippets を探す。目的のスニペットがどれかわからない場合は、すべての PHP ファイルを一旦ダウンロードし、ローカルで中身を確認すればよい。

SFTP クライアントでアクセスする場合

FileZilla などの SFTP クライアントを使い、ホスト名・ユーザー名・パスワード(または SSH 鍵)で接続する。接続後、リモートサイト側のディレクトリツリーから wp-content/wpextended-snippets へ進み、ファイルを一括ダウンロードする。権限不足で開けない場合は、サーバー管理画面からファイルのパーミッションを 755 に修正する。

取り出した PHP コードを別のスニペット管理プラグインへ移す

取り出した PHP コードを別のスニペット管理プラグインへ移す

ダウンロードしたファイルをテキストエディタで開くと、WP Extended が自動生成したヘッダコメントに続いて実際の PHP コードが記述されている。スニペットの中身だけをコピーし、別のコードスニペット管理プラグイン(例: 無料の Code Snippets プラグイン)に貼り付ければすぐに再利用できる。

Before
WP Extended の管理画面でスニペット一覧が空白のまま操作不能
After
サーバーから回収したコードを別のスニペット管理画面に登録し、正常に動作中
Before(問題発生時)  After(復旧後)

スニペットを 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_actionadd_filter)が正しく記述されているか見直す。

WP Extended を再インストールしたらスニペットは戻るのか

プラグインを一度アンインストールすると、wpextended-snippets ディレクトリやデータベースの情報が削除される可能性がある。そのため、再インストール前に必ずスニペットファイルのバックアップを取っておく。バックアップが無ければ、サーバーのバックアップサービスからの復元が必要になる。

スニペットが複数あり、どれが目的のコードかわからない

ファイル名だけでは判別が難しいため、全ての PHP ファイルを一度ローカルにダウンロードし、エディタで内容を確認する。WP Extended のヘッダ部分にスニペット名が書かれていることが多いので、それを手がかりに必要なファイルを特定する。

この記事のポイント

  • WP Extended のスニペット一覧が見えなくなっても、ファイルは wp-content/wpextended-snippets に残っている
  • サーバーのファイルマネージャーまたは SFTP で PHP ファイルを回収できる
  • 回収したコードは別のスニペット管理プラグインや子テーマに移せる
  • 事前のバックアップとテストで同じトラブルを防げる
メガメニューのスタイルが崩れた時の原因と直し方

メガメニューのスタイルが崩れた時の原因と直し方

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

なぜプラグイン更新後にメガメニューのスタイルが崩れるのか

なぜプラグイン更新後にメガメニューのスタイルが崩れるのか

メガメニュープラグインは、独自の CSS と JavaScript を読み込んでスタイルを適用している。アップデートによってこれらのファイル構成が変更されると、ブラウザやサーバーに残った旧バージョンのキャッシュが新バージョンのスタイルと衝突し、見た目が崩れることがある。

また、プラグイン内部で HTML 構造が変更された場合、テーマ側で追加したカスタム CSS のセレクタが合わなくなり、スタイルが外れてしまうケースも少なくない。これが「項目が完全に見えなくなる」原因になることもある。具体的には、項目を非表示にする CSS ルール(display:none など)が誤って適用されたり、z-index の競合で他の要素の裏に隠れたりする。

メガメニューの崩れを直す緊急対処の流れ

メガメニューの崩れを直す緊急対処の流れ

まずはサイトの表示に直接影響するキャッシュをすべて取り除き、それでも直らなければプラグインを以前のバージョンに戻す。この順序で作業すると、無駄な切り分けを減らせる。

STEP 1 ブラウザキャッシュとサーバーキャッシュを完全に削除する
STEP 2 キャッシュ系プラグインで CSS と JS を再生成する
STEP 3 改善しなければプラグインを旧バージョンに巻き戻す
STEP 4 自動更新を一時停止して修正版のリリースを待つ

キャッシュを完全に除去する手順

まず 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:nonevisibility:hidden が適用されていないか確認する。該当プロパティがあれば、打ち消し線が入っているか、どの CSS ファイルの何行目から来ているかが表示される。

もしテーマの style.css や追加 CSS に身に覚えのないルールがあれば、そのセレクタがアップデート後の HTML に誤ってマッチしている可能性が高い。一時的にそのルールをコメントアウトして表示が復活するかを試すと、原因の特定が早い。

テーマとプラグインの競合を調べる

メガメニュープラグインのアップデート後に問題が起きた場合、テーマ側のメニュー処理と競合していることも考えられる。一時的に標準テーマ(Twenty Twenty-Five など)に切り替えて、メニューが正常に表示されるか確認する。標準テーマで問題なければ、テーマ側のカスタマイズや専用のメニュー関数が干渉していると判断できる。

Before(エラー状態)
メニュー項目「会社概要」が表示されず、他の項目もスタイルが崩れている
After(標準テーマで検証後)
全項目が正しく表示され、スタイルも元に戻る。テーマ側の干渉と特定
エラー状態  標準テーマで正常化

再発を防ぐためのアップデート前チェックリスト

再発を防ぐためのアップデート前チェックリスト

メガメニューのようなサイト全体の導線を担うプラグインは、更新ひとつで売上や問い合わせに影響が出る。以下の手順を踏んでおけば、今回のようなスタイル崩れを未然に防げる。

  • ステージング環境で事前にアップデートを検証する
  • テーマのカスタム CSS はメガメニューのクラス名に依存しすぎない
  • 更新前に必ずサイト全体のバックアップを取る
  • キャッシュ系プラグインの設定を更新後に見直す習慣をつける

特に、ステージング環境での事前検証は手間に見えて最も確実な安全策だ。多くの国内レンタルサーバーはワンクリックでステージングを作れる機能を備えている。更新後、メニューの表示やモバイルでの開閉動作を一通りチェックしてから本番に反映すれば、今回のような急なスタイル崩れでサイトが長時間壊れる事態を回避できる。

よくある質問

旧バージョンの ZIP が見つからない場合はどうする?

プラグインの公式ディレクトリページ下部にある「以前のバージョン」からダウンロードできないケースでは、開発者の公式サイトや GitHub リポジトリを探す。WP Rollback のようなプラグインを使えば、管理画面から直接過去のバージョンに切り替えられる場合もある。

キャッシュを削除しても直らないのはなぜ?

サーバー側のキャッシュに加え、CDN を使用している場合は CDN のキャッシュもパージする必要がある。また、ブラウザの Service Worker が古いファイルを保持していることもあるので、シークレットウィンドウで確認するか、デベロッパーツールから Service Worker の登録を解除する。

アップデートを戻したのに一部のスタイルが直らない

旧バージョンに戻した後も、キャッシュ系プラグインが生成した最適化済み CSS ファイルが残っている可能性がある。「CSS の再生成」や「クリティカル CSS の削除」も実行する。さらに、テーマ側のカスタマイザーで追加した CSS が悪さをしていないか、追加 CSS 欄を一時的に空にして確認する。

修正版がリリースされるまでどう運用すればよい?

プラグインの自動更新を停止し、旧バージョンのままサイトを運用する。管理画面の「更新」通知は無視して問題ない。修正版が公開されたら、最初にステージング環境でテストし、スタイルや項目の表示に問題がないことを確認してから本番に適用する。

この記事のポイント

  • プラグイン更新後のメガメニュー崩れはキャッシュの完全削除から試す
  • 改善しなければ旧バージョンに巻き戻し、自動更新を一時停止する
  • 項目消失は CSS の意図しない適用が原因になりやすい
  • テーマとの競合を疑う場合は標準テーマで切り分ける
  • 再発防止にはステージング環境での事前検証が最も有効
Kadence BlocksのナビゲーションAdvブロックでフォント設定が効かない時の直し方

Kadence BlocksのナビゲーションAdvブロックでフォント設定が効かない時の直し方

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

なぜナビゲーションAdvブロックのフォント設定だけが消えるのか

なぜナビゲーションAdvブロックのフォント設定だけが消えるのか

ブロックエディター上や公開サイトで、ナビゲーションメニューの文字サイズが指定したとおりに表示されず、標準テーマのデフォルト値に戻ってしまう。検証ツールで要素に付与されているインラインスタイルを見ると、次のような壊れた CSS が埋め込まれていることが確認できる。

Before(エラー状態)
.kb-nav-link-319_9f80b8-fd > /*…*/ .kb-nav-link-content{{font-size:var(–global-kb-font-size-md, 1.25rem);}}
二重に重なった中括弧があるため、ブラウザがこの行全体を正しいCSSとして認識できない
After(修正後)
.kb-nav-link-319_9f80b8-fd > /*…*/ .kb-nav-link-content{font-size:var(–global-kb-font-size-md, 1.25rem);}
正規の中括弧だけになるので、フォントの装飾が有効に戻る
エラー状態  正しいCSS

このデモで示したとおり、本来は {…} であるべきブロックのスタイル指定が、バグにより {{…}} と出力されてしまう。この形式はブラウザの構文解析でエラー扱いされ、font-size や font-weight がまったく適用されなくなる。Kadence ナビゲーション(Adv)ブロックを使っているメニューすべてで発生し、管理画面のブロックエディター上でもプレビューが崩れてしまうのが典型的な兆候だ。

ナビゲーション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 をライブラリから削除する
STEP 2 旧バージョンのZIPを入手し、アップロードしてインストール
STEP 3 有効化してサイトキャッシュを削除すれば完了

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 以前へのダウングレードとキャッシュクリア
  • プラグインの削除・再インストールでデータは消えず、設定も維持される
  • 自動更新を止めて、本番適用前に検証する運用が望ましい
  • 公式の修正パッチがリリースされ次第、最新版に戻して問題ない
WooCommerce MyParcelで重大エラーが出た時のデフォルト配送業者設定方法

WooCommerce MyParcelで重大エラーが出た時のデフォルト配送業者設定方法

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

なぜデフォルト配送業者が未設定だとエラーになるのか

なぜデフォルト配送業者が未設定だとエラーになるのか

このエラーは PHP の致命的エラー(Fatal Error)であり、MyParcel プラグインが「No default carrier available(利用可能なデフォルトの配送業者がない)」という例外を発生させて停止している。スタックトレースを追うと、発端は受注確認ページ(サンキューページ)などで追跡情報を表示しようとする際、プラグインが内部的に呼び出す getDefaultCarrierOrThrow() メソッドで落ちている。

MyParcel は配送ラベル作成や追跡情報の連携を行うプラグインであり、動作には「どの配送業者をデフォルトで使うか」という情報が必須だ。この設定を一度も行っていなかったり、アップデート時に何らかの理由で消えたりすると、サイトの該当ページでエラーが表示される。

≪ エラー発生時 ≫
MyParcel プラグインがデフォルトの配送業者を取得できず、例外をスロー
≪ 設定後 ≫
デフォルト配送業者が設定され、プラグインが正常に動作
設定未完了状態  設定完了後

デフォルト配送業者を設定する具体的な手順

デフォルト配送業者を設定する具体的な手順
STEP 1 WordPress 管理画面にログインし、左メニューから「WooCommerce」→「MyParcel」を開く
STEP 2 「設定」タブを選択し、「デフォルトの配送業者」項目を探す
STEP 3 プルダウンから利用する配送業者(例: ヤマト運輸や佐川急便など契約中のもの)を選択する
STEP 4 画面下部の「変更を保存」をクリックし、エラーが消えたか確認する

管理画面にアクセスできる状態であれば、この手順だけでエラーは即座に解消する。設定項目の名称はプラグインバージョンによって「デフォルトの配送業者」「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 設定からデフォルト配送業者を選択して保存すれば解決
  • 管理画面に入れない場合はプラグインフォルダのリネームで一時無効化する
  • アップデート後は配送系プラグインの設定リセットに注意が必要
JavaScriptがログアウト時に動かない原因と直し方

JavaScriptがログアウト時に動かない原因と直し方

管理画面にログインしているときだけ JavaScript が動き、ログアウトすると止まる。この現象の原因は、ほぼ「スクリプトの読み込み順序」と「キャッシュ・最適化プラグインの挙動」のどちらか、あるいは両方の組み合わせだ。ログイン時は管理バー用のスクリプト等が読み込まれるため依存関係が偶然成立し、ログアウト時にそれが外れてエラーになるケースが多い。

ログアウト時だけ JavaScript が動かなくなる仕組み

ログアウト時だけ JavaScript が動かなくなる仕組み
ログイン時(動作する)
jQuery 管理バー用JS スライダーJS
管理バー用のスクリプトが jQuery を読み込むため、後続のスライダーが依存できている
ログアウト時(動作しない)
jQuery 未読込 スライダーJS エラー
管理バーが無いため jQuery が読み込まれず、スライダーの処理が失敗する
ログイン時  ログアウト時

このデモは典型的な依存関係の崩れを示している。ログイン中は WordPress が管理バーやフッターに jQuery を読み込むため、その後に記述されたスクリプトが偶然動く。ログアウトすると jQuery が存在せず、$ is not definedjQuery is not defined といったエラーで止まる。

HTML ブロックに直接書いた JavaScript が招く問題

HTML ブロックに直接書いた JavaScript が招く問題

WordPress の「カスタム HTML」ブロックに <script> タグを直書きする方法は、一見手軽だが制御が難しい。出力される位置がテーマやブロック配置に依存し、jQuery などのライブラリより前に実行されれば必ず失敗する。さらにインラインスクリプトは多くのキャッシュプラグインで最適化対象から外されたり、結合・遅延読み込みの対象にならず、ログアウト時だけ二重に不利な状況を生む。

HTML ブロック直書きスクリプトの3つの弱点

  • 読み込み順序を制御できない(テーマの render 順に依存する)
  • jQuery の依存関係を WordPress に伝えられない
  • キャッシュ・圧縮プラグインがスクリプトとして認識しない場合がある

ログアウト時でも動くようにする正しい組み込み手順

ログアウト時でも動くようにする正しい組み込み手順

原則は「JavaScript は HTML ブロックに直書きせず、WordPress の仕組み(wp_enqueue_script)で読み込む」ことだ。すでに直書きで動いているものを移行するには、以下の手順で進める。

STEP 1 既存の script タグの中身を別ファイルに切り出す
STEP 2 functions.php で wp_enqueue_script を使い、jQuery 依存を明示する
STEP 3 $ の衝突回避のため即時関数または noConflict でラップする
STEP 4 キャッシュプラグインの設定を見直し、スクリプトを除外する

STEP 1 既存の script タグを外部ファイルに移す

HTML ブロック内の <script>〜</script> 部分だけを抜き出し、子テーマのフォルダ内に testimonial-slider.js のような名前で保存する。<script> タグそのものは不要で、中身のコードだけを移す。HTML ブロックにはスライダーの構造(ul や div のマークアップ)だけを残す。

STEP 2 functions.php で安全に読み込む

子テーマの functions.php に以下のコードを追加する。管理画面ではなくフロントエンドだけに読み込ませるために wp_enqueue_scripts フックを使う。依存関係として jquery を指定すれば、WordPress 本体の jQuery が先に読み込まれてから実行される。

function my_testimonial_slider_script() {
    wp_enqueue_script(
        'testimonial-slider',
        get_stylesheet_directory_uri() . '/testimonial-slider.js',
        array('jquery'),
        '1.0.0',
        true
    );
}
add_action('wp_enqueue_scripts', 'my_testimonial_slider_script');

最後の引数 true はフッターで読み込む指定だ。スライダーの DOM 要素が本文中に存在する場合はフッター読み込みで問題ない。もしスライダーを本文より前に実行する必要があるなら false にしてヘッダーで読ませるが、多くのケースではフッターで十分だ。

STEP 3 $ の衝突を防ぐ

WordPress の jQuery は noConflict モードで動作しているため、$ がそのまま使えない環境がある。古いコードを流用している場合は $ is not a function エラーが起きやすい。回避策として、外部ファイル全体を即時実行関数で囲み、引数で $ を受け取る記法が安全だ。

(function($) {
    $(document).ready(function() {
        // ここにスライダーのコード
    });
})(jQuery);

STEP 4 キャッシュプラグインでスクリプトを除外する

ここまで対応しても直らない場合、キャッシュや最適化プラグインが原因の可能性が高い。ログアウト時はページキャッシュが有効になり、スクリプトの遅延読み込みや結合が適用される。自前の testimonial-slider.js をこれらの処理から除外する必要がある。

プラグインの設定画面で「スクリプトの除外」「遅延読み込みの除外」といった項目を探し、testimonial-slider(ハンドル名)または testimonial-slider.js(ファイル名の一部)を指定する。除外後は必ずキャッシュを全削除してからログアウト状態で確認する。

Elementor のフックやテーマのアクションフックを使った場合の注意点

Elementor のフックやテーマのアクションフックを使った場合の注意点

テーマ付属のフック(GeneratePress の Element など)に HTML ブロックごと差し込む方法も考えられるが、根本的にはスクリプトの読み込み順序問題は同じだ。フックで出力する位置を変えても、jQuery より前に呼ばれるリスクは残る。フックを使う場合でも、スクリプト部分は wp_enqueue_script に任せ、フックにはマークアップだけを出力する形が堅実だ。

Elementor Pro の「カスタムコード」機能を使っているなら、その中に script タグを書くのではなく、同様に子テーマのファイルとして切り出してハンドル登録するほうが制御できる。どうしても直書きが必要なら、カスタムコードの「場所」設定を「本文の終了タグ直前」にし、さらにコード内で jQuery を明示的に使う($ を使わない)ことでエラーを減らせる。

よくある質問

コンソールに「$ is not defined」と出るがどう直せばいいか

jQuery が読み込まれる前に $ を使っているか、noConflict モードで $ が無効になっている。即時関数で (function($) { ... })(jQuery); とラップし、すべての $ をこのスコープ内に収めれば解決する。

functions.php を編集せずに直す方法はあるか

「WPCode」などのコードスニペット管理プラグインを使えば、管理画面から wp_enqueue_script のコードを登録できる。functions.php を直接触りたくない場合の現実的な代替手段だ。スニペットの実行場所を「フロントエンドのみ」に設定するのを忘れないようにする。

キャッシュを削除しても直らないのはなぜか

ブラウザキャッシュだけを消していて、サーバー側のページキャッシュや CDN キャッシュが残っているケースが多い。WordPress のキャッシュプラグインの「すべてのキャッシュを削除」を実行し、さらに CDN を使っている場合はその管理画面からもパージする。シークレットウィンドウで確認するとブラウザキャッシュの影響を除外できる。

スライダーのマークアップだけ残して script を外したら表示が消えた

新しく作った JS ファイルが正しく読み込まれていない。ブラウザの開発者ツールの「ネットワーク」タブで testimonial-slider.js が 200 番で返っているか確認する。404 ならパスが間違っている。読み込まれているのに動かない場合は、コンソールに別のエラーが出ていないか調べる。

この記事のポイント

  • ログアウト時だけ JavaScript が動かない原因は、jQuery の依存切れとキャッシュ最適化の複合
  • HTML ブロックへの script 直書きは読み込み順序を制御できず、根本対策にならない
  • wp_enqueue_script で jQuery 依存を明示し、外部ファイルとして切り出すのが正攻法
  • 即時関数で $ の衝突を防ぎ、キャッシュプラグインでは独自スクリプトを除外対象に追加する
  • Elementor やテーマフックを使う場合も、スクリプトだけは enqueue に任せる設計が堅実

特定商品ブロックを設置した固定ページでfatal errorが発生する問題の直し方

特定商品ブロックを固定ページに配置したときに「Uncaught Error Call to a member function get_id() on null」というfatal errorが表示されるのは、PreCart for WooCommerce のバグが原因だ。プラグインを最新バージョンへ更新するか、functions.php へ一時的な修正コードを追加すれば直る。

なぜ固定ページ上の商品ブロックで fatal error が起こるのか

なぜ固定ページ上の商品ブロックで fatal error が起こるのか

PreCart は WooCommerce の商品情報を扱うフィルターフック(woocommerce_product_add_to_cart_text など)にコールバック関数を登録し、その中で global $product から商品オブジェクトを取得して $product->get_id() を呼び出している。しかし、ブロックエディタで「特定商品」ブロックを通常の固定ページに配置すると、WooCommerce のブロック表示パイプラインではグローバル変数 $product が null のままフィルターが走るケースがある。PreCart のコードには null チェックがないため、null に対して get_id() を呼び出してしまい、致命的なエラーでページ全体が落ちる。

STEP 1 固定ページに「特定商品」ブロックを追加し任意の商品を選択
STEP 2 WooCommerce ブロック描画時に PreCart のフィルターが発火
STEP 3 グローバル変数 $product が null のままコールバックが実行される
STEP 4 $product->get_id() で致命的エラー発生(画面が真っ白になる)

影響を受けるメソッドは change_add_to_cart_text()display_pre_order_messgae()display_pre_order_badge() など、いずれも保護コードがない。WooCommerce の商品ブロックを店舗ページ以外で使っているサイトはすべてこの問題に遭遇し得る。

PreCart を更新してエラーを解消する手順

PreCart を更新してエラーを解消する手順

開発元はこの問題を認識しており、すでに修正アップデートがリリースされている。まずは管理画面からプラグインを最新版に上げるのが最も安全で確実な対処法だ。

STEP 1 WordPress 管理画面へログインし「プラグイン」→「インストール済みプラグイン」を開く
STEP 2 PreCart for WooCommerce に更新通知が出ていたら「今すぐ更新」をクリック
STEP 3 サイトのキャッシュ(プラグインキャッシュ、サーバーキャッシュ)をすべて削除
STEP 4 問題のあった固定ページをフロントエンドで再度開き、エラーが出ないことを確認

更新通知が表示されない場合

「ダッシュボード」→「更新」から更新の再確認を行うか、PreCart のプラグインページで一度「プラグインを削除」→ 公式リポジトリから再インストールする方法もある。ただしこの場合、設定がリセットされる可能性があるため、事前に PreCart の設定をメモしておくかエクスポート機能があれば使っておくと安心だ。

functions.php で null チェックを追加して一時的に対処する方法

functions.php で null チェックを追加して一時的に対処する方法

どうしてもすぐにプラグインを更新できない場合や、何らかの理由で更新後に問題が残る場合は、テーマの functions.php にフックを追加して一時的にエラーを回避できる。

/**
 * PreCart の null チェック不足による fatal error を回避(一時的対応)
 */
add_filter( 'woocommerce_product_add_to_cart_text', function( $text, $product ) {
    if ( ! $product || ! is_a( $product, 'WC_Product' ) ) {
        return $text;
    }
    // 以下は原本の処理が走るが、早期リターンで保護
    return $text;
}, 1, 2 );

add_filter( 'woocommerce_single_product_summary', function() {
    global $product;
    if ( ! $product || ! is_a( $product, 'WC_Product' ) ) {
        return;
    }
    // 同様に早期リターン
}, 1 );

上記のコードは PreCart が使っているのと同じフックに、より優先度の高いコールバック(優先度 1)で null チェックを追加し、商品オブジェクトが存在しないときは処理を打ち切る仕組みだ。PreCart のフィルターよりも先に実行されるため、致命的エラーに至る前に関数を抜けられる。

Before(危険)
global $product;
$product->get_id();
null チェックがないためエラー
After(安全)
if ( ! $product || ! is_a( $product, ‘WC_Product’ ) ) { return; }
$product->get_id();
null のときは早期リターン
修正前  修正後

functions.php 編集時の注意点

子テーマを使っていない場合、テーマ更新で修正が上書きされるリスクがある。必ず子テーマの functions.php にコードを追加するか、Code Snippets プラグインでコードを管理するのが望ましい。また、この一時対応はあくまで応急処置であり、PreCart の他の機能が正常に動作しない可能性もゼロではない。早めに公式アップデートを適用して、追加コードは削除する。

手動修正後に確認しておきたいポイント

手動修正後に確認しておきたいポイント
  • 一時的なコードを追加した後、サイトの表示速度やエラーログに変化がないか定期的にチェックする
  • PreCart の機能(カート追加テキストの変更や予約注文バッジなど)が期待どおり動作しているかテストする
  • PHP のエラーログを確認し、別の箇所で同様の null 参照エラーが隠れていないか調べる
  • サイト全体のキャッシュをクリアし、CDN を利用している場合は CDN キャッシュも破棄する
  • PreCart の更新が確認できたら必ずプラグインを最新版に上げ、追加コードを削除する

よくある質問

PreCart 以外のプラグインでも同じように商品ブロックでエラーが出ることはありますか

ある。WooCommerce のブロックを通常ページで使うと、$product グローバルを正しく取り扱っていない他の拡張プラグインでも同様の null 参照エラーが起きるケースが報告されている。エラーの文面に別のプラグイン名が含まれている場合は、そちらの開発元へ報告しつつ、同じように functions.php で早期リターンを追加すれば応急回避できることが多い。

WooCommerce の商品ブロックを固定ページで使うこと自体は問題ないのでしょうか

WooCommerce のブロックは基本的に店舗ページや商品ページで使うことを想定しているが、WordPress の標準ブロックとして技術的にはどの投稿タイプでも利用できる。プラグインがグローバル変数の有無を適切にハンドリングしていれば固定ページで使っても問題は起きない。ただ、テーマやプラグインが認めるまで、動作確認は入念に行ったほうがよい。

エラーメッセージが表示されずに画面が真っ白になる場合はどうすればよいですか

WordPress が致命的エラーを表示しない設定(WP_DEBUG が false)のときは、管理画面のメールに送られる復旧モード用のリンクを探すか、サーバーの PHP エラーログを確認する。wp-config.php で define('WP_DEBUG', true); を一時的に有効にすれば、画面上にエラー詳細が表示され、原因を特定しやすくなる。なお、本番環境ではデバッグモードをすぐに無効に戻すこと。

管理画面にも入れなくなってしまった場合はどうすれば直りますか

FTP またはレンタルサーバーのファイルマネージャーで /wp-content/plugins/precart/ ディレクトリの名前を一時的に変更(例:precart_deactivated)すれば、プラグインが無効化されて管理画面に再ログインできる。その後、前述の更新や一時コードで対処し、ディレクトリ名を元に戻す。

この記事のポイント

  • 固定ページに WooCommerce 商品ブロックを配置したときの fatal error は PreCart の null チェック不足が原因
  • 解決策は PreCart プラグインの最新版への更新が最も安全で確実
  • すぐに更新できない場合は、functions.php にフックで早期リターンを追加すれば応急回避できる
  • functions.php 編集は子テーマで行い、アップデート後は必ず追加コードを削除する
  • 管理画面に入れなくなったら FTP でプラグインフォルダ名を変更し無効化する
Elementorエディタが開かない時のREST API 403エラー解決法

Elementorエディタが開かない時のREST API 403エラー解決法

Elementorエディタが読み込まれずにフリーズし、REST APIが403禁止エラーを返す場合、根本原因は「プラグインコアファイルの破損」「WordPressのサブディレクトリ構成による認証不整合」「サーバーレベルのアクセス制限」のいずれか、または複合にある。FTPやファイルマネージャーから手動でElementorを再設置し、サイト設定の見直しとパーマリンク構造のリセットを実施すれば、大半のエラーは解消する。

なぜ Elementor エディタが開かず REST API が403エラーになるのか

なぜ Elementor エディタが開かず REST API が403エラーになるのか

プラグインコアファイルの破損が引き起こす連鎖不具合

Elementorが途中でアップデートに失敗したり、サーバー上でファイルが欠損したりすると、致命的なクラス読み込みエラーが発生する。代表的なものが「Uncaught Error: Class “Elementor\Controls_Stack” not found」だ。これはElementor本体の動作に必須のファイルが物理的に存在しないか、PHPの要求に対して不完全な状態で読み込まれていることを示す。管理画面からの再インストールではサーバーキャッシュや権限の影響で上書きに失敗するケースがあるため、手動での完全初期化が必要になる。

WordPressのサブディレクトリ構成が生む認証クッキーのズレ

WordPress本体を/wordpressに配置し、サイトアドレスだけをルートドメインに設置する構成は、REST APIの認証において深刻な不具合を引き起こす。ブラウザはWordPressのログインクッキーを物理的なインストールパスに対して発行するため、サイトURLと実際のパスが異なると、APIリクエストに必要なnonceや認証クッキーが正しく送信されず「rest_not_logged_in」が返る。Elementorエディタは内部的に多数のREST API通信を行っているため、この認証エラーが編集画面そのものを動作不能にする。

サーバー設定やセキュリティプラグインがAPIをブロックしている

ModSecurityやWAF(ウェブアプリケーションファイアウォール)、あるいは.htaccessに記述された独自ルールが、/wp-json/パスへのアクセスを機械的にブロックしている場合も403エラーが発生する。また、一部のセキュリティプラグインはREST APIのエンドポイントを厳格に制限する機能を備えており、無効化したと思っていてもキャッシュ層に設定が残って影響していることがある。

Before(エラー状態)
Fatal Error Class “Elementor\Controls_Stack” not found
403 Forbidden /wp-json/elementor/v1/site-navigation/recent-posts
要素: エディタ画面が白またはローディング停止。REST APIがログイン状態を認識せず全遮断。
After(解決状態)
200 OK 全プラグインファイルが完全に復元される
Auth OK REST APIがユーザー認証を正しく通過
要素: Elementorエディタが即座に起動し、ウィジェットの読み込みや保存が可能に。

エラーが発生している環境では、管理画面からの通常操作がほぼ通じない状態になっている。上のBefore/AfterのようにエディタとAPI認証を同時に復旧させるには、外部からのファイル操作とURL設定の修正が不可欠となる。

実際に環境を修復する4ステップの手順

実際に環境を修復する4ステップの手順
STEP 1 FTPからElementorを手動で再設置する
STEP 2 パーマリンクをリセットしキャッシュを削除する
STEP 3 wp-config.phpでサイト構成の不整合を補正する
STEP 4 .htaccessとサーバー側の認証ブロックを解除する

STEP 1 FTPからElementorを手動で再設置する

管理画面の「プラグイン」から削除するだけでは、不完全なファイルが残る危険がある。FTPソフト、またはサーバーのファイルマネージャーを開き、/wp-content/plugins/elementor/ディレクトリを直接削除する。Pro版を使用している場合は/wp-content/plugins/elementor-pro/も同様に削除する。削除後、Elementorの公式サイトから最新のzipファイルをダウンロードし、同じディレクトリにアップロードして展開することで、完全に健康なコアファイルが書き戻される。これで「Controls_Stack」を含むクラスファイルの欠損は物理的に解消される。

STEP 2 パーマリンクをリセットしキャッシュを削除する

管理画面の「設定」→「パーマリンク」にアクセスし、「変更を保存」を2回クリックするだけでもREST APIのルーティング情報が再生成される。これにより、サイトの内部URL構造が強制的にリセットされる。あわせて、導入しているキャッシュプラグインの全キャッシュ削除、およびサーバー側のVarnishやNginxキャッシュが有効な場合はそれらのパージも実行する。

STEP 3 wp-config.phpでサイト構成の不整合を補正する

WordPress本体がサブディレクトリにある環境では、認証クッキーのパス指定を明示的に定義することで403エラーが劇的に改善する。ルートのwp-config.phpに以下の定数を追記する。これは「COOKIE_DOMAIN」の指定だけでなく、管理画面と公開側で異なるパスにクッキーを適応させるための指示だ。

define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');
define('ADMIN_COOKIE_PATH', '/');
define('COOKIE_DOMAIN', '.〇〇.com'); // 自ドメインに合わせる

自サイトがSSL化されている場合は、管理画面の「設定」→「一般」内の「WordPressアドレス」と「サイトアドレス」の両方がhttpsで始まっているかも再確認する。片方がhttpで残っているとREST APIのリクエストがクロスオリジン扱いされ、認証が外れる。

STEP 4 .htaccessとサーバー側の認証ブロックを解除する

WAFやModSecurityが/wp-json/へのアクセスを攻撃と誤認してブロックしている場合、サーバー管理パネルから当該ルールを一時無効化するか、ホワイトリストに追加する。レンタルサーバーの場合、管理画面の「セキュリティ」関連項目にWAFの遮断ログが記録されていることが多い。.htaccessに手動でREST APIを遮断する記述を追加した覚えがなくても、セキュリティプラグインが自動追記しているケースがあるため、以下の記述群が存在しないか確認する。

# もし以下のような記述があれば一時的に削除かコメントアウト
# RewriteRule ^wp-json - [F]

致命的エラー「Class “Elementor\Controls_Stack” not found」の根本対応

致命的エラー「Class

このエラーは単にファイルが見つからないと言っているのではなく、「Elementorの起動シーケンスの中で呼び出されるべき抽象クラスがメモリ上に展開できない」という致命的な状態を指す。管理画面から一度プラグインを「無効化」して「再有効化」してもPHPのオートローダーが不完全なファイル索引を参照し続けるため、FTPから一度完全に削除して、再設置するSTEP 1だけが確実な解決策となる。Pro版を導入している場合、Free版のコアクラスが正しくロードされていないとPro版の処理がすべて失敗するため、必ず両方を手動で入れ直す。

サブディレクトリ環境で403を連発させない設定の定石

サブディレクトリ環境で403を連発させない設定の定石

WordPressを/wordpressに置き、公開URLはルートにする構成は、管理画面へのアクセスパスと公開APIパスの二重構造を生む。システム内部ではadmin-ajax.phpやREST APIの呼び出し元が物理パスを参照する傾向にあるため、ここでクッキーの不一致が起きる。最も安定させる方法は、ルートにあるindex.phpが正しくサブディレクトリを指しているかを確認し、かつwp-config.phpで前述のクッキー定数を定義することだ。可能ならば、この際にWordPressをサブディレクトリからルートディレクトリへ正式に移動させることも検討する価値がある。

よくある質問

セーフモードを有効にしてもElementorエディタが開かないのはなぜか

セーフモードはテーマとElementor以外のプラグインを外して動作するが、今回の主原因は「Elementor本体ファイルの破損」と「REST APIの認証エラー」である。そのため、セーフモードでも参照するコアファイルが破損していれば画面は起動せず、API認証の障害もそのまま残り続ける。セーフモードはあくまで「他のプラグインとの競合」を疑う場合の手段であり、今回のような根本的なファイル破損には効果がない。

変更を保存したはずのパーマリンク設定が元に戻ることはあるか

サーバーの.htaccessファイルやNginxの設定ファイルが書き込み禁止になっていると、パーマリンクの更新が表層的に成功したように見えても内部的に反映されない。FTPで.htaccessのパーミッションが606や666など適切な値になっているか確認し、WordPressが自動生成するRewriteEngine On以下のブロックが存在するかも検証する必要がある。

PHPのバージョンアップが原因でElementorが動かなくなることはあるか

PHP 8.2や8.3、8.4へのアップデートで、従来は警告で済んでいたコードが致命的エラーに格上げされるケースは確かにある。しかし「Controls_Stack not found」はバージョン互換性よりもファイルの単純な欠落または不完全なアップロードが原因だ。事前にサーバーのPHPエラーログを開き、不足している具体的なファイルパスが出力されていないかを確認すると、欠落しているファイルが明確になる。

REST APIを意図的に無効化するセキュリティプラグインの代表例はあるか

WordfenceやiThemes Securityなどの包括的なセキュリティプラグインは、設定次第で未認証または全ユーザーのREST APIアクセスを制限できる。今回のケースではログイン済みの管理者でも「rest_not_logged_in」になるため、むしろクッキーやURLの不一致が強く疑われるが、検証のためにはそれらのプラグインを本当に全停止し、サーバー側のキャッシュを完全にパージする必要がある。

この記事のポイント

  • 403エラーとエディタ停止はコアファイル破損と認証不整合の複合症状である
  • 管理画面ではなくFTPから手動でフォルダを削除し再設置する
  • サブディレクトリ環境では必ずCookie定数を明示的に定義する
  • パーマリンクの再保存と全キャッシュの削除をセットで実行する
  • WAFや.htaccessがREST APIをブロックしていないか確認する
WordPressのキーが長すぎるエラーをMariaDB 11.4で修正する方法

WordPressのキーが長すぎるエラーをMariaDB 11.4で修正する方法

「指定されたキーが長すぎます。最大キー長は 1000 バイトです」というエラーが WordPress サイトのデータベースで発生した場合、対象となるテーブルの複合インデックス定義で長すぎるカラムのプレフィックス長を制限すれば解決する。これはデータベースの照合順序と文字コードの関係で、インデックスが許容バイト数を超過することが直接の原因だ。

「キーが長すぎる」エラーが発生する根本原因

「キーが長すぎる」エラーが発生する根本原因

このエラーは特定のデータベーステーブルに複合インデックスを作成しようとした際に、インデックスに含まれるカラムの合計バイト数がデータベースの上限を超えたために発生する。MariaDB や MySQL では、InnoDB ストレージエンジンの行フォーマットとサーバー設定によってキー長の上限が決まる。具体的には ROW_FORMAT が COMPACT または REDUNDANT のテーブルでは最大 767 バイトまでしか許容されず、DYNAMIC や COMPRESSED の場合でも実質的に 3072 バイトが上限となる。

今回のようなエラーが顕在化しやすいのは、データベースを MariaDB の最新バージョン(11.4 系など)に移行したタイミングだ。デフォルトの文字コードが utf8mb4 に設定されている環境で、VARCHAR 型のカラムをインデックスに含めると、1 文字が最大 4 バイトとして計算されるため、たとえば VARCHAR(255) のカラムが含まれているだけで、そのカラムだけで 1020 バイトを消費する計算になる。

プラグインが独自に追加した CHANGE_LOG テーブルでは、object_type、object_id、created_at という 3 つのカラムで複合インデックスを作ろうとしている。object_id は外部キーや参照用に VARCHAR で定義されていることが多く、これが長いままだとバイト数制限に引っかかる。解決の本質は、インデックスで実際に使用する範囲を object_id カラムの先頭部分だけに限定することにある。

エラーを特定するための確認手順

エラーを特定するための確認手順

実際のエラーメッセージをログから確認する

データベースエラーの内容を正確に把握するために、まずは WordPress のデバッグログを有効化する。wp-config.php に以下の定数を追加する。

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

エラーを再現させたあと、/wp-content/debug.log を確認すると「Specified key was too long; max key length is 1000 bytes」というエラーが記録されているはずだ。このエラーには対象のテーブル名や、キーを作成しようとした SQL 文も含まれている。

テーブルのインデックス定義を直接調べる

データベース管理ツール(phpMyAdmin など)で CHANGE_LOG テーブルの構造を開き、「インデックス」タブを確認する。object_lookup という名前の複合インデックスが存在し、そこに object_id カラムがフルサイズで含まれていれば、これがエラーの原因だと特定できる。

SQL コマンドに慣れているなら、以下のクエリでインデックス情報を取得してもよい。

SHOW INDEX FROM wp_change_log;

文字コードとバイト数の関係を理解する

utf8mb4 は 1 文字を最大 4 バイトで表現するため、VARCHAR(255) として定義されたカラムは、インデックス上で最大 1020 バイトを占める。複合インデックスでは、含まれる全カラムの最大バイト数の合計が制限値となる。VARCHAR(100) なら最大 400 バイト、VARCHAR(50) なら 200 バイトと計算していき、上限(1000 バイトや 767 バイト)を超えていないかを確認する。この計算を怠ると、一見問題ない定義に見えても実行時にエラーとなる。

複合インデックスを修正する具体的な手順

複合インデックスを修正する具体的な手順

修正の基本方針は object_lookup インデックスから既存の定義を削除し、object_id カラムのプレフィックス長を制限した新しいインデックスを作り直すことにある。これによりバイト数制限を回避しながら、インデックスの機能自体は維持できる。

修正前(エラー)
KEY object_lookup (object_type, object_id, created_at)
↑ object_id がフルサイズのためバイト数制限を超過
修正後(正常)
KEY object_lookup (object_type, object_id(100), created_at)
↑ object_id の先頭100文字分だけをインデックス化

このデモは object_id にプレフィックス長を設定する前後のインデックス定義の違いを表している。修正後はバイト数制限に収まるため、エラーが解消される。

phpMyAdmin で安全にインデックスを変更する

データベースの直接操作に不慣れな場合、phpMyAdmin を使うとミスが少ない。該当テーブルを開き、「構造」タブから「インデックス」セクションに移動する。object_lookup インデックスを選択して削除し、新たに「インデックスを作成」から複合インデックスを追加する。

カラムを選択する際、object_type と created_at はそのまま指定し、object_id だけ「サイズ」欄に 100 と入力する。これで object_id(100) としてインデックスが作成される。

SQL コマンドで直接修正する場合

コマンドラインや SQL タブから実行するなら、以下の 2 文を順に実行する。DROP で既存のインデックスを削除し、ADD で新しいインデックスを作成する。

ALTER TABLE wp_change_log DROP INDEX object_lookup;
ALTER TABLE wp_change_log ADD INDEX object_lookup (object_type, object_id(100), created_at);

実行前に必ずデータベースのバックアップを取得すること。誤った ALTER TABLE はテーブル構造を壊す可能性がある。

プラグインのアップデートで上書きされないようにする

このインデックスはプラグインが管理するスキーマファイル(class-change-log-schema.php)で定義されているため、プラグインがアップデートされると修正が上書きされてしまう可能性が高い。恒久的な対策としては、プラグインのアクティベーションフックやスキーマ更新処理にフックし、独自のインデックス定義を適用するコードを子テーマの functions.php かカスタムプラグインに記述する方法が有効だ。

データベースのバージョンや設定に依存する問題のため、サーバー環境を変更しない限りこの修正は必須となる。プラグイン開発者が将来的に修正を加えるまでは、自前のフックで対応しておくと安全だ。

よくある質問

このエラーは MariaDB 11.4 だけで発生するのか

MariaDB 11.4 に限らず、キー長制限が厳格に適用される環境ならば発生する可能性がある。古い MySQL 5.6 以前の設定や、InnoDB の ROW_FORMAT が COMPACT のテーブルでも同様のエラーが起こる。

object_id(100) のようにプレフィックスを制限しても検索性能は落ちないのか

先頭 100 文字までをインデックス化するため、100 文字を超える部分での検索精度は低下する可能性がある。ただ、object_id のような識別子は冒頭部分で十分に一意性が確保されることが多く、実際のクエリ性能に大きな影響は出ない。

エラーが WordPress 本体のテーブルで出た場合はどうすればよいか

WordPress コアのテーブルでこのエラーが発生することは稀だ。通常はプラグインやテーマが独自に追加したカスタムテーブルで起こる。もしコアテーブルで起こった場合は、データベースの文字コードや ROW_FORMAT の設定自体を見直す必要がある。

SQL の直接実行が不安なときの代替手段はあるか

WP-CLI(WordPress のコマンドライン管理ツール)が利用できるなら、「wp db query」コマンドで安全にクエリを実行できる。また、データベースの移行や最適化を支援するプラグイン(WP Migrate など)にも SQL 実行機能が備わっているものがある。

この記事のポイント

  • インデックスに含まれるカラムの合計バイト数がデータベースの上限を超えるとキー長エラーが発生する
  • utf8mb4 環境では VARCHAR 型のカラムが 1 文字最大 4 バイトを消費する点に注意が必要
  • object_id(100) のようにカラムのプレフィックス長を指定してインデックスを再作成することでエラーを回避できる
  • プラグインのアップデートで修正が上書きされるため、恒久的な対処にはフックを用いたコード管理が推奨される