メガメニューのスタイルが崩れた時の原因と直し方
プラグイン更新後にメガメニューのスタイルが崩れ、一部のナビゲーション項目が表示されなくなった場合、まずは以前のバージョンへの巻き戻しと全キャッシュの削除を試みる。この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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
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 11.0が商品オブジェクトキャッシュを標準化！新規ストアは自動有効
WooCommerce 11.0がリリースされ、商品オブジェクトキャッシュが新規ストア向けにデフォルトで有効化された。この機能は、商品ページやチェックアウト処理で同じ商品データを何度もデータベースから取得する無駄を省き、ECサイトの表示速度を底上げする。
可変商品がある製品ページでは約9〜12%、バンドル商品を含むチェックアウト処理では6〜12%の処理速度改善が報告されている。今回の変更は、WooCommerce 10.5で実験的導入が始まったキャッシュ機構が安定動作の段階に達したことを示している。
新規にWooCommerce 11.0以上をインストールしたストアには自動で適用されるが、アップグレードした既存ストアの設定は一切変更されない。必要に応じて管理画面から手動でオンにできる仕組みだ。
商品オブジェクトキャッシュの仕組みとパフォーマンス改善の数字
リクエスト内で商品データを使い回すメモリ内キャッシュ
このキャッシュは、一度のHTTPリクエストの間だけ生きている、揮発性のメモリ内キャッシュだ。wc_get_product(123)が呼ばれると、キャッシュに保存されていればデータベースに問い合わせず、すぐに商品オブジェクトの複製を返す。リクエストが終わればキャッシュは完全に消去されるため、次のリクエストで古い情報が残る心配はない。
特に、wc_get_product()を同じIDで何度もコールするパターンが多いテーマやプラグインで効果が大きい。各呼び出しが独立したオブジェクトのクローンを返すため、意図せず商品データの状態を共有してしまうバグも防げるようになった。
このデモは、同じ商品IDに対する繰り返し呼び出しがキャッシュによってどれだけ無駄を省けるかを示している。実際のECサイトでは、商品ループやセール情報の取得、決済フローの中で wc_get_product() が頻繁に呼ばれるため、体感速度の改善が期待できる。
実測値として9〜12%の高速化
WooCommerce 10.5の実験的導入時に公表されたパフォーマンス測定値は、今回の正式適用後も同じだ。可変商品（サイズや色のバリエーションがある商品）の製品ページでは、読み込み時間が9〜12%短縮された。バンドル商品を含むチェックアウト処理では6〜12%高速化されている。
この改善幅は、商品データを繰り返し取得する重いクエリがページ表示のボトルネックになっている状況で顕著だ。小規模なサイトでは効果が体感しにくいケースもあるが、商品数が多いストアや複雑な製品構成のサイトでは、目に見える速度向上が得られる。
WooCommerce 10.5から11.0への段階的な導入プロセス
10.5で実験的機能として登場、10.6で互換性の宣言が「互換」に
商品オブジェクトキャッシュは、WooCommerce 10.5で「実験的機能」として初めて公開された。当時はデフォルトで無効であり、ストア運営者が手動でオンにする必要があった。機能自体は、wc_get_product()の呼び出しをインターセプトし、リクエスト単位のメモリ内キャッシュからデータを返す仕組みだ。
WooCommerce 10.6では、この機能のプラグイン互換性宣言が「非互換」から「互換」に変更された。実験期間中に拡張機能エコシステム全体で互換性の問題が一切報告されなかったため、明示的に互換性を宣言していない拡張機能も、デフォルトで互換とみなされるようになった。
もし拡張機能が明示的に「この機能とは非互換」と宣言している場合は、WooCommerceの機能画面に従来通り非互換の通知が表示される。しかし、そのような宣言が必要になった拡張機能は見つかっていない。
11.0で新規ストアへの自動有効化を実装
WooCommerce 11.0のクリーンインストール時には、インストールプロセスの一環として商品オブジェクトキャッシュが自動で有効になる。機能登録自体は enabled_by_default => false のまま変更されていないが、新規インストール時に明示的に有効化が書き込まれる仕組みをとっている。
これは、HPOS（High-Performance Order Storage）など、他の機能がオプトインから新規インストール時デフォルトへ移行した際と同じパターンだ。バージョンアップだけでは既存ストアの設定を変更しない、慎重な設計が貫かれている。
既存ストアの挙動と手動有効化の手順
アップグレードしても設定は一切変わらない
WooCommerce 11.0より前に構築されたストアは、11.0へアップグレードしても既存のキャッシュ設定がそのまま維持される。もし以前に無効だった（それが11.0以前のストアのデフォルト設定だ）なら、アップグレード後も無効のままだ。すでに手動で有効にしていたストアは、そのまま有効が継続される。
つまり、次の3パターンに整理できる。
- WooCommerce 11.0以降を新規インストール → 自動的に有効（操作不要）
- 既存ストアで機能が無効だった → アップグレード後も無効のまま（手動で有効にできる）
- 既存ストアで機能が有効だった → アップグレード後も有効のまま（操作不要）
手動で有効化する方法
既存ストアでこの機能を試したい場合、管理画面の WooCommerce → 設定 → 詳細設定 → 機能 にアクセスし、「商品オブジェクトをキャッシュする（Cache Product Objects）」のトグルをオンにすればよい。ただし、設定変更後にサイト全体の動作を一通りチェックしておくことが推奨される。
トグルをオンにすると、その瞬間からリクエスト単位の商品キャッシュが働き始める。とくに、複数の拡張機能が同じ商品データにアクセスする大規模ストアでは、即効性のある改善が期待できるだろう。
拡張機能開発者への影響と注意点
標準APIを使っていればコード変更は不要
wc_get_product() やその他 WooCommerce 標準 API を通じて商品を取得している拡張機能は、このキャッシュの影響をまったく受けない。キャッシュは内部で透過的に動作し、呼び出し元には変わらず正しい商品オブジェクトが返る。
キャッシュから返されるのは、あくまで独立したクローンなので、取得した商品オブジェクトを編集しても他の処理に副作用が及ぶことはない。したがって、従来のコーディング規約に従っている拡張機能は、そのまま動作し続ける。
直接SQLを実行する拡張機能が注意すべきポイント
注意が必要なのは、WooCommerceのメタフックを経由せずに、商品データに対して直接SQLクエリを発行している拡張機能だ。これらのクエリはキャッシュの無効化フックを迂回するため、更新後のデータがキャッシュに反映されず、古い情報が返ってしまう可能性がある。
この問題は、商品オブジェクトキャッシュに限った話ではなく、WooCommerceのデータ整合性全般に関わる設計課題だ。該当する拡張機能を開発している場合は、標準の wc_get_product() やメタデータ更新用のAPIを使うことで、キャッシュの恩恵を受けつつ、データ不整合も回避できる。
今後のロードマップと全ストアへの有効化計画
データ蓄積後に全ストアで有効化へ
今回のリリースは通過点であり、最終的にはすべてのストア（既存ストアも含む）で商品オブジェクトキャッシュを有効化する計画が示されている。現時点で具体的な実施時期は明言されていないが、十分なストアでの稼働データが蓄積された段階で判断される。
すでに実験期間で問題が報告されていないこと、新規インストールのデフォルト有効化でさらなる実績が積み上がることを踏まえると、早ければ数バージョン後には全ユーザー対象の強制有効化に踏み切る可能性が高い。
問題が発生した場合の報告先
もし商品オブジェクトキャッシュに関連して予期せぬ挙動が見つかった場合、WooCommerceのGitHubリポジトリでIssueを報告してほしいと開発チームは呼びかけている。拡張機能開発者やストア運営者からのフィードバックが、今後の安定化に直結する。
この記事のポイント
- WooCommerce 11.0 で商品オブジェクトキャッシュが新規ストア向けに自動有効化された
- 可変商品の製品ページ読み込みは 9〜12％ 高速化、バンドル商品のチェックアウトは 6〜12％ 改善
- 既存ストアはアップグレードしても設定変更なし、管理画面から手動でオンにできる
- 標準の WooCommerce API を使う拡張機能はコード変更不要で動作する
- 最終的には全ストアで有効化される予定で、Issue 報告を募っている
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
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でスパムメールが大量に届く時の根本対策
Contact Form 7から件名や本文が空、または広告だけのスパムメールが大量に届くようになった状態は、ハニーポット（honeypot）と呼ばれる手法やシンプルな送信条件の制限を組み合わせることで、高い精度でブロックできる。
なぜContact Form 7にスパムが届くのか
お問い合わせフォームを設置したばかりのサイトは、公開直後から自動巡回するスパムボットの標的になる。ボットはPHPで生成されたフォームの構造を解析し、name属性やclass名を把握したうえで、迷惑メールの配信やSEO用の被リンク売り込みなどを自動送信する。Contact Form 7は世界中で使われているため、ボット側も「どのフィールドに何を入れれば送信が通るか」を熟知している。そのため、標準の状態ではほとんどのボットが素通りしてしまう。
ボットが大量のスパムを送り込むことによって、メールサーバーの評判低下や共用サーバーのリソース浪費、管理用メールアドレスのブラックリスト入りといった二次被害が発生する可能性がある。件名や本文が空に近いメールが届くときは、すでにボットによる自動送信が常態化しているとみてよい。
このデモは、対策の有無でスパムの到達状況がどう変わるかを示したイメージだ。対策を入れない限り、ボットはフォームの構造を正確に読んで送信を成功させてしまう。
ハニーポットでボットを静かにブロックする方法
ハニーポット（honeypot）とは、人間には見えずボットだけが反応する「罠」のフィールドをフォームに仕込む対策を指す。reCAPTCHAのようにユーザーに手間をかけず、Ajaxの競合リスクも低いため、Contact Form 7との相性が非常によい。
CSSで見えないチェックボックスを設置する
ボットは画面に表示されるかどうかを判断せず、HTMLソース内のすべてのフィールドを機械的に入力しようとする性質を持つ。この行動を利用し、人間には表示されないチェックボックスをフォームに追加する。チェックボックスにチェックが入った状態で送信された場合は、ボットとみなして送信を破棄する、という仕組みだ。
参考までに、公式のContact Form 7は、独自の同意チェックボックスであるacceptance（承諾）タグに対して invert default:on という属性をサポートしている。これは「デフォルトでチェックが入っており、人間だけが外せる」という逆転ロジックを作れる機能だ。ボットはチェックを外す操作を行わないため、罠として機能する。
ただし、acceptanceタグを使う方法は、実際にはCSSでフォーム項目をサイト上で見えなくする処理と組み合わせて使う必要がある。そうしないと、サイトを訪れた人間が混乱する原因になるためだ。
この手順ではCSSで視覚的に完全に隠すため、サイト訪問者はこのチェックボックスを一切意識せずに送信できる。一方、ソースコードを解析して全フィールドを埋めようとするボットは、デフォルトでオンになっているチェックを外さないまま送信するため、Contact Form 7のバリデーションでエラー扱いとなりメールが飛ばない。
acceptanceタグのロジックに過度に依存しない
acceptanceの逆転ロジックは簡易なボットに対しては有効だが、高度なボットはチェックボックスの状態を操作できるケースも報告されている。また、CSSを解析してスタイルを操作するスクリプトには、非表示の項目を見抜かれてしまう可能性もある。そのため、ハニーポットはあくまで一次フィルターと捉え、次の追加対策と組み合わせることが現実的な防御線だ。
reCAPTCHA v3でユーザー負荷をかけずに判別する
Contact Form 7はGoogle reCAPTCHA v3のインテグレーションを公式にサポートしている。reCAPTCHA v3は「私はロボットではありません」のチェックボックスや画像選択のような操作をユーザーに一切求めず、ページ滞在中のマウスの動きやスクロールといった行動データをもとにスコアリングし、スパムの可能性が高い送信をブロックする仕組みだ。
設定はGoogle reCAPTCHAの管理画面でサイトキーとシークレットキーを取得し、WordPress管理画面の「Contact」→「Integration」からreCAPTCHAの項目にキーを入力するだけで完了する。v2の「チェックボックス方式」は一部の環境でAjax送信との競合を起こすことがあるが、v3はその心配が少ない。フォームに直接ウィジェットが表示されないため、デザインを損なわない利点もある。
このフローは、reCAPTCHA v3導入の全体像を示したものだ。v2と異なり、Widgetの操作ステップが存在しないため、サイトの表示速度やユーザー体験への影響を最小限に抑えつつ、高精度なボット検知を実現できる。
メール本文に日本語必須ルールを追加する
海外から大量に届くスパムの多くは、英語や中国語、あるいは記号だけで構成されている。日本語圏のサイトであれば、送信内容に日本語が含まれていることを必須条件にすると、ボットによる自動送信の大半を止められる。Contact Form 7には、特定の文字種を含んでいるかどうかを検証する正規表現（Regex）の機能は標準で備わっていないが、無料の専用プラグインで補うか、functions.phpにフィルターフックを追加して実装できる。
具体的には、wpcf7_validate_text* や wpcf7_validate_textarea* といったバリデーションフックを使い、本文フィールドにひらがな・カタカナ・漢字のいずれかが1文字でも含まれているかをPHPの正規表現でチェックする。条件を満たさない場合はエラーメッセージを返し、メール送信を中止させるという流れだ。この対応は海外発の機械的スパムには極めて有効で、実装の手間に対する防御効果が高い。
よくある質問
ハニーポットを仕込んでもスパムが続く場合は？
ハニーポットだけで防げない場合は、ボットがCSSを解析して非表示フィールドを識別している可能性がある。その場合は、フィールドを完全に非表示にするのではなく、画面上の見えない位置にずらす方法（positionで画面外に飛ばす）や、JavaScriptを使って動的にフィールドを生成する方式に切り替えると効果が上がる。また、reCAPTCHA v3や日本語必須ルールの併用を必ず検討する。
reCAPTCHA v2よりv3のほうが本当に優秀なのか
ボット検知精度はどちらも高いが、v3は操作性と表示速度の面で大きく優れている。v2の画像選択がユーザーの離脱を招いたり、Ajaxフォームとの競合で送信エラーを起こす場面が減るため、問い合わせフォームとの相性という観点ではv3の導入が望ましい。ただし、v3はサイト全体のスコアリングを行うため、プライバシーポリシーへの記載が必要になる。
Contact Form 7以外のフォームに切り替えたほうがよいか
スパム対策だけを理由にフォームプラグインを移行する必要はない。Contact Form 7は世界的に使われている分、ボットの標的になりやすい面はあるが、今回紹介した対策を適切に組み合わせれば実用上十分な防御力を確保できる。移行によって別の競合やカスタマイズの手間が発生するリスクを考えると、まずは手元のContact Form 7を強化する方針が合理的だ。
この記事のポイント
- Contact Form 7へのスパムは、ボットがフォーム構造を熟知しているために発生する
- ハニーポット（CSS非表示のチェックボックス）で、人間には影響なくボットをブロックできる
- reCAPTCHA v3を導入すると、ユーザー操作なしで高精度なスパム判定が可能になる
- メール本文に日本語の文字種を必須にするルールを追加すると、海外発スパムの大半を遮断できる
- 単一の対策に頼らず、複数の層を重ねることでボットの突破を防ぐ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Trustindexプラグインの脆弱性、認証なしでトークンが漏洩する問題と対策
Trustindexプラグインのトラブルシューティング用RESTエンドポイントが認証なしでアクセス可能になっていると、Instagram Graph APIのアクセストークンを含む全オプションが外部に漏洩する。HMAC署名のキーに公開情報を使っている設計上の欠陥が原因であり、修正パッチが配布されるまでの間はエンドポイント自体を遮断する応急処置が必要になる。
何が起きているのか 〜 脆弱性の全体像
この問題は、Trustindexの「Instagram Feed」ウィジェットを設置したWordPressサイトで発生する。プラグインは管理画面のトラブルシューティング用に /wp-json/trustindex_feed_hook_instagram/troubleshooting というRESTエンドポイントを用意している。このエンドポイントに正しい署名付きリクエストを送ると、プラグインが保存している全オプション、つまりInstagramのアクセストークンや各種設定をJSON形式で返してしまう。
認証にはHMAC-SHA256による署名検証が使われているが、その署名用の秘密鍵（キー）がサイトごとに公開されている「パブリックID」になっている。このIDは、プラグインが生成するCDNのURL（https://cdn.trustindex.io/wp-feeds/XX/パブリックID/data.json）に含まれ、ページのソースコードやネットワークリクエストを覗けば誰でも取得できる。つまり署名の計算に必要な材料がすべて攻撃者の手に渡ってしまうため、認証がまったく機能していない状態だ。
影響は深刻だ。漏洩したInstagramアクセストークンを使えば、サイト運営者になりすましてInstagram Graph APIを呼び出し、プロフィール情報の取得やメディア投稿の操作が可能になる。トークンの有効期限が切れるか運営者が手動で失効させるまで、不正利用のリスクが続く。
自分のサイトが影響を受けるかどうかの確認方法
まず、TrustindexプラグインをインストールしてInstagramフィードを表示しているサイトが対象だ。それ以外のフィード（FacebookやGoogleレビューなど）を使っているだけの場合は、今回のエンドポイントとは関係がない。確認手順は次の3ステップで行える。
STEP 3の詳細は、UNIXのターミナルで以下のようなリクエストを投げる。HMACの計算にはパブリックIDと現在のUNIXタイムスタンプを使うため、スクリプトを組むか手動で計算する必要がある。
# PUBLIC_ID と TIMESTAMP は各自の値に置き換える
PUBLIC_ID="取得したパブリックID"
TIMESTAMP=$(date +%s)
SIGNATURE=$(echo -n "$TIMESTAMP" | openssl dgst -sha256 -hmac "$PUBLIC_ID" | awk '{print $2}')
curl -H "X-Signature: $SIGNATURE" -H "X-Timestamp: $TIMESTAMP" \
"https://あなたのサイトドメイン/wp-json/trustindex_feed_hook_instagram/troubleshooting"レスポンスに source.access_token や access_token といった文字列が含まれていれば、情報が丸見えの状態だと判断できる。この確認はあくまで自己診断用であり、他者のサイトに対して行ってはならない。
修正パッチが配布されるまでに取るべき応急措置
プラグイン開発者から公式のアップデートが提供されるまでは、以下のいずれかの方法で該当エンドポイントへの外部アクセスを完全に遮断する。
.htaccessでエンドポイントをブロックする
サーバーがApacheを使っている場合、WordPressのインストールディレクトリにある.htaccessファイルに以下の記述を追加する。これにより、該当URLへのリクエストは403 Forbiddenで弾かれる。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-json/trustindex_feed_hook_instagram/troubleshooting - [F]
</IfModule>functions.phpでREST APIアクセスを制限する
テーマのfunctions.php（子テーマ推奨）に下記のコードを追加すると、未ログインユーザーからの該当エンドポイントへのアクセスを拒否できる。管理画面にログインしているユーザーは引き続き利用できるため、サポートが必要になった際にも支障がない。
add_filter( 'rest_authentication_errors', function( $result ) {
if ( ! empty( $result ) ) {
return $result;
}
$current_route = $GLOBALS['wp']->query_vars['rest_route'] ?? '';
if ( strpos( $current_route, '/trustindex_feed_hook_instagram/troubleshooting' ) !== false && ! is_user_logged_in() ) {
return new WP_Error(
'rest_forbidden',
'このエンドポイントへのアクセスにはログインが必要です。',
array( 'status' => 403 )
);
}
return $result;
} );プラグインを一時停止する判断
Instagramフィードの表示が必須でないなら、脆弱性が修正されるまでプラグイン自体を無効化するのが最も確実だ。フィードが表示されなくなる影響が許容できるビジネスであれば、この選択肢も検討しよう。
すでにトークンが漏洩した可能性がある場合の対処
アクセスログを精査して不審なリクエストがなかったか確認するのが先決だが、ログが十分に残っていないケースも多い。疑わしい場合は、以下の手順でトークンを強制的に無効化し、新しいトークンを再発行する。
特にInstagram Graph APIのアクセストークンは長期トークン（Long-Lived Token）で運用していることが多く、一度漏洩すると数カ月単位で悪用されるリスクがある。トークン失効後は、フィードが一時的に表示されなくなるが、再設定すればすぐに復旧する。
根本的な原因と再発防止の考え方
今回の脆弱性の本質は、認証用の秘密情報が公開前提の値になっている設計ミスにある。HMAC署名を使うこと自体は正しいが、秘密鍵が「誰でも見られるURLの一部」にある時点でセキュリティは成り立たない。
プラグイン開発者側が取るべき修正は、プラグイン有効化時にランダムなシークレットを wp_options テーブルに保存し、その値を署名キーに使う方式へ変更することだ。さらに、トラブルシューティングという目的を考えれば、current_user_can('manage_options') で管理者権限を要求するだけでも十分な防御になる。このエンドポイントはあくまでサポートスタッフ向けであり、未認証ユーザーに開放する理由は一切ない。
サイト運営者としても、すべてのプラグインを無条件に信頼するのではなく、導入後に「どんなRESTエンドポイントが増えたか」「公開される情報はないか」をセキュリティプラグインや手動チェックで確認する習慣が身を守る。WordPressのサイトヘルス機能やQuery Monitorのようなツールを普段から使い、異常なAPIリクエストがないか注視しておくことが再発防止につながる。
よくある質問
プラグインのどのバージョンから修正されますか
2026年6月17日時点では、開発者は調査中と回答しており修正バージョンは未発表だ。Trustindexの公式チェンジログとWordPress管理画面の更新通知を定期的に確認し、セキュリティアップデートが配信され次第ただちに適用する必要がある。
応急処置としてプラグインを無効化すると、フィードはどうなりますか
プラグインを無効化すると、Instagramフィードは表示されなくなる。ただ、表示崩れが起こるだけでサイト全体がダウンするわけではない。トークン漏洩のリスクと天秤にかけて、ビジネス上の重要性が高い場合は上記の.htaccessやfunctions.phpによる遮断を選ぶほうが現実的だ。
Instagramのトークンを変えたあと、再度漏洩することはありますか
アプリやサーバー側の脆弱性が修正されていない限り、新しいトークンも同じエンドポイントから再び漏洩する可能性がある。必ず、アクセス制限の応急措置を先に施したうえでトークンを再発行する順序を守ってほしい。
FacebookやGoogleのフィードにも同じ問題はありますか
今回確認されたのは trustindex_feed_hook_instagram のエンドポイントのみだが、同じ認証設計を他のフィード用エンドポイントにも流用している可能性は否定できない。不安があれば、trustindex_feed_hook_facebook や trustindex_feed_hook_google といった類似のエンドポイントが存在しないか、REST APIのルート一覧で確認しておくと安心できる。
自分のサイトがすでに攻撃されたかどうか確かめる方法はありますか
サーバーのアクセスログに /wp-json/trustindex_feed_hook_instagram/troubleshooting へのリクエストが記録されていれば、それが正規のサポート用途か攻撃かを判別する必要がある。あわせて、Instagram Graph APIの使用状況をFacebook開発者コンソールの「アプリのインサイト」で確認し、見覚えのないAPIコールや異常なリクエスト数がないかを調査するのが確実だ。
この記事のポイント
- Trustindexプラグインのトラブルシューティング用RESTエンドポイントが認証不備によりInstagramアクセストークンを露出させている
- 原因はHMAC署名の秘密鍵として、誰でも取得できるパブリックIDを使用している設計ミス
- 修正パッチが配布されるまでは、.htaccessかfunctions.phpでエンドポイントへの外部アクセスを遮断する
- トークン漏洩が疑われる場合はInstagram側でトークンを即時失効させ再発行する
- 常にプラグインのREST APIエンドポイントを定期的に監視し、不要な露出がないか確認する習慣が再発防止の鍵
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress 7.0リリース後の開発者情報まとめ（2026年6月版）
2026年5月20日にWordPress 7.0が正式リリースされた。その後1ヵ月の間に、メディア編集の刷新やクライアントサイドでの画像処理、テーマ向けスタイル機能の強化など、開発者にとって見逃せないアップデートが続いている。
本記事では、Developer WordPress News の「What’s new for developers? (June 2026)」を読み解きながら、6月に登場した主要トピックを整理する。プラグイン開発者、テーマ制作者、そしてサイト運営者が押さえておきたいポイントを中心に、実務への影響をわかりやすく解説する。
メディア編集モーダルがデフォルトに、画像処理の進化
画像の切り抜きがより直感的に
Gutenberg 23.3では、画像の切り抜き操作が専用のモーダルウィンドウで行われるようになった。これまでは編集画面内で直接操作していたが、今回の変更により、縦横比の指定や回転、反転、ズーム、メタデータの編集までひとつのモーダルに集約されている。
操作の入り口はこれまで通り「切り抜き」ボタンだが、編集体験は格段に整理された。プラグインで画像編集機能を独自に拡張している場合や、画像メタデータに依存する処理を組んでいる場合は、実際の画像を使ったキーボード操作やタッチ操作のテストが必要だ。
ブラウザ上で画像リサイズを行うクライアントサイド処理
もうひとつ注目したいのが、クライアントサイドメディア処理のテスト呼びかけだ。これは、可能な場合にはブラウザ上で VIPS/WASM パイプラインを使って画像のサブサイズを生成し、必要に応じてサーバーサイド処理にフォールバックする仕組みである。
対応形式はAVIFやWebP、HEIC、Ultra HDR、JPEG XL、GIFから動画への変換など多岐にわたる。ただし、現時点ではChromiumブラウザと最新のGutenbergプラグインの組み合わせに限られ、FirefoxやSafariでは無効、メモリが2GB以下のデバイスではスキップされる。通信速度が遅い場合やContent Security Policyの worker-src が制限的な場合も利用できない。
このデモでは、従来のようにサーバーがすべてのリサイズを担当する方法から、可能なときはブラウザが先に処理を引き受ける流れへの変化を示している。サーバーの負荷軽減とユーザー体験の向上が期待されるが、環境による制限があるため、フォールバックを含めたテストが欠かせない。
プラグインとツールを取り巻く重要な更新
React 19への移行は一時的に巻き戻されたが準備は続く
WordPress 7.0ではReact 19へのアップグレードが計画されていたが、Gutenbergでは一時的にこの変更が巻き戻された。理由は、複数のプラグインがReact 18のJSXランタイムヘルパーをバンドルしており、React 19と同時に読み込むとクラッシュする問題が発生したためだ。
コアチームはWordPress 7.1でのReact 19導入を目指し、より段階的な戦略で進める方針を示している。コンパイル済みのJSXを同梱しているプラグインや、@wordpress/element を使っている場合、またはエディターのプライベートAPIに触れている場合は、引き続きテスト環境で最新のGutenbergを試すことをおすすめする。
Abilities APIの拡充が進行中
Abilities APIはこれまでのラウンドアップでも取り上げられてきたが、6月も継続的に改良が進んだ。ライフサイクルフィルターや入出力のバリデーションフィルター、wp_get_abilities() へのフィルタリングサポート、サイトやユーザー、環境情報のレスポンス拡張、RESTスキーマの堅牢化などが行われている。
能力（アビリティ）を使った実験を始めている開発者は、以前の想定に頼りすぎず、トランクの最新の挙動を確認しておくとよい。
PHPサポートの明確化とUnicodeメールアドレス対応の提案
WordPress 6.9および7.0では、PHP 8.5を完全にサポートすることが正式に明文化された。これにより、古い「ベータサポート」ラベルは廃止され、WordPress 7.0時点での最低動作バージョンはPHP 7.4、推奨はPHP 8.3に整理されている。
一方で、メールアドレスやユーザー名、スラッグにおけるUnicode対応を拡張する提案も公開され、フィードバックが募られている。この提案は is_email() や sanitize_email() などの関数、フィルター、データベース格納、文字の正規化などに影響を及ぼす可能性があり、メールアドレスを扱うプラグインは早めに内容を確認しておく価値がある。
AI Clientを使った画像生成プラグインのチュートリアル
4月・5月のラウンドアップで紹介されたAI ClientとConnectors APIに関する実践的なチュートリアルが登場した。ここでは、画像生成プラグインを構築する方法が解説されており、特に機能検出パターンが参考になる。プラグインは、プロバイダーが設定済みかどうか、そして必要な機能をサポートしているかを確認したうえでUIを表示すべきであり、チュートリアルではメディアライブラリから画像を生成し、添付ファイルとして保存する一連の流れが実装されている。
テーマ開発者向けのスタイルとブロックの改善
単一ブロックインスタンスへの擬似状態スタイルの適用
Gutenberg 23.3では、個別のブロックインスタンスに対して :hover や :focus、:visited といった擬似状態のスタイルを設定できるようになった。これまではサイト全体のブロックすべてに影響するスタイルしか設定できなかったが、この変更により、特定のボタンだけホバー時の色を変えるといった細やかな制御が可能になる。
この機能は、Add supports for pseudo states on single block instances というPRで実装されており、長年課題となっていたインタラクティブな状態の標準化に向けた動きとして注目されている。ボタンやリンク、ナビゲーションのデザインにこだわるテーマ制作者は、Gutenbergでテストしてみるとよい。
レスポンシブ対応のスタイル状態がさらに拡張
レスポンシブかつ状態を考慮したスタイル設定は、Gutenberg 23.2と23.3で大きく前進した。23.2ではグローバルなブロックスタイルに状態付きのレスポンシブ設定が導入され、23.3ではレイアウトのレスポンシブスタイルや、状態選択時に一部のコントロールを隠すUI調整が加えられている。
まだGutenbergプラグインでのテスト段階だが、theme.jsonのプリセットや設定、レイアウトプリセット、ブロックサポート、カスタムレスポンシブコントロールに依存しているテーマにとっては影響が大きいため、Responsive style states for blocks 、 iteration for WP 7.1 のIssueを追いかけておくとよい。
その他テーマ向けのブロックアップデート
細かいが実務に効く変更もいくつか入った。グローバルスタイルのカラーパネルでスラッグベースの色選択が統合され、ホームリンクブロックに不足していたコントロールが追加された。パンくずブロックでは視覚的な区切り文字がスクリーンリーダー向けに非表示となり、ナビゲーションでは非推奨化された block_core_navigation_submenu_render_submenu_icon() 関数のシムが復活している。画像ブロックでは幅か高さの片方だけが設定された場合に出力が崩れる問題も修正された。
また、WordPress 7.0では著者アーカイブリンクのデフォルトの title 属性（「Posts by Author」）が削除されている。マークアップのわずかな変更だが、テーマの表示テストやスナップショットテストに影響する可能性があるため注意しておきたい。
WordPress Playgroundの最新動向
wp-nowが非推奨に、Playground CLIへの移行を
ローカル環境を手早く立ち上げるために wp-now を使っていた開発者は、Playground CLIへの移行が必要になる。Developer WordPress Newsの記事によると、2026年6月8日付でwp-nowが非推奨となり、今後の推奨パスはPlayground CLIに一本化された。
移行は比較的スムーズに行えるよう設計されており、テスト用サイトを素早く立ち上げたいプラグイン開発者やテーマ制作者は、早めに切り替えておくとよいだろう。
PRプレビューとPHPスニペットの公式ガイド
Playground関連では、2つの役立つガイドも公開された。ひとつは「PR Preview with WordPress Playground: What changes in version 3 of the GitHub Action」で、プルリクエストのプレビューを自動化するGitHub Actionの最新バージョンについて解説している。プロジェクトでPlaygroundプレビューを利用しているなら、一度目を通しておきたい内容だ。
もうひとつは「Run PHP examples anywhere with WordPress Playground」で、WordPressの開発者向けドキュメントやチュートリアルに、ブラウザ上で実行可能なPHPサンプルを埋め込む方法を紹介している。技術記事を書く立場の開発者にとって、この手法は読者の理解を大きく助ける強力な武器になる。
保存型Playgroundと古いWordPressバージョンの復元
Playground v3.1.35およびv3.1.36では、サイトの保存とSites APIの機能が大きく進んだ。保存したブラウザ上のWordPressサイトに何度も戻れる永続化の仕組み、自動保存からの復元UX、埋め込みPlaygroundでの不要な保存プロンプト回避などが実装されている。
さらに、WordPress 0.7 のような過去のバージョンを丸ごとロードできるようになり、Virtual WordPress Museum のようなデモも登場した。デモやテスト、教育目的の用途が一層広がる変更といえる。
PHP.wasmによる高度なデモやフレームワーク対応
PHP.wasm周辺の開発も活発だ。新しい「Running PHP Frameworks in Playground」ガイドでは、WordPress以外のPHPフレームワークをPlayground上で動かす方法が示されており、ブラウザベースのツール構築の可能性を大きく広げている。また、@php-wasm/compile-extension ワークフローにより、PHP拡張のコンパイルも以前より容易になった。高度なデモやドキュメント用のサンプルを作る開発者には、これらの進歩も見逃せない。
ユーザーインターフェースとアクセシビリティの改良
実験的なダッシュボードのカスタマイズ機能がウィジェットを追加
カスタマイズ可能なダッシュボードはまだ実験段階だが、Gutenberg 23.3では新たに5つのウィジェット（サイトヘルス、ニュース、イベント、クイックドラフト、サイトプレビュー/URLバー）が追加され、レイアウトの調整も進んだ。ゴーストウィジェットやサイズプリセット、コンテナブレークポイントによるグリッドカラムなど、徐々に実用性が高まっている。
管理者画面の拡張やプラグイン独自の管理パネルを開発しているなら、この実験がどこに向かっているのかを customizable dashboard overview issue で追いかけておくことをおすすめする。
エディターと管理画面でのアクセシビリティの磨き込み
GutenbergとCoreの両方でアクセシビリティ関連の改善が続いている。Gutenberg 23.3ではリビジョン機能が改善され、フォントライブラリのフォーカスナビゲーションも修正された。Core側では、管理画面のカラースキームのコントラスト強化、フロントエンドツールバーのフォーカスアウトライン修正、ハイコントラストモード時のボタンアクティブ状態の不具合対応などが行われている。
カスタム管理画面やエディターパネル、メディア操作UIを提供している場合は、キーボード操作、ハイコントラストモード、文字サイズの拡大設定、標準以外の管理画面カラースキームを組み合わせたテストを定期的に実施することが重要だ。
この記事のポイント
- メディア編集はモーダルに集約され、クライアントサイド画像処理の実験的テストも始まった。サーバー負荷の低減とUX向上が見込まれる
- React 19移行は一時停止中だが、WordPress 7.1に向けた準備は継続。プラグイン開発者は互換性を確認しておく
- テーマ開発では、単一ブロックへの擬似状態スタイル適用やレスポンシブスタイルの拡張など、表現力が高まる変更が多い
- PlaygroundはCLIへの一本化、保存型サイトの強化、過去バージョン対応などで開発者の実験環境が飛躍的に便利になった
- アクセシビリティの改良も着実に進行。カスタムUIを作るならテストにキーボード操作やハイコントラストモードを含める
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験