タグアーカイブ ブロックエディタ

WordPressのアコーディオンブロックが開かない原因と直し方

WordPressのアコーディオンブロックが開かない原因と直し方

WordPress 6.9のアコーディオンブロックをクリックしても展開しない場合は、ページ読み込み時にブロックのJavaScriptが正しく初期化されていないことが原因だ。キャッシュを完全に削除し、プラグインの競合を確認することで大半のケースは解決する。改善しない場合はテーマの読み込み順を調整する。

なぜアコーディオンブロックが展開しないのか

なぜアコーディオンブロックが展開しないのか

この現象は、アコーディオンブロックの内部で使われる view.min.js が、ページの読み込み完了前にクリックイベントを受け取ってしまうことで起きる。具体的には、ブロックの状態(開閉のデータ)がまだ存在しないタイミングで「開く」処理が実行され、「未定義のプロパティを読めない」というTypeErrorが発生するという仕組みだ。

読み込み速度が極端に速い場合も、逆に特定のスクリプトが遅延して遅くなった場合も、内部のタイミングがずれて初期化が完了しないまま操作できてしまう。Twenty Twenty-Fiveテーマに限らず、他のテーマやプラグインがページの読み込み順を変えていると同様の症状が出ることがある。

■ エラー発生時の状態
ページ読み込み → アコーディオンブロックのJS読み込みが完了する前 → ユーザーがクリック → cundefined → エラー
■ 正常な状態(修正後)
ページ読み込み → JSの初期化が完全に終わる → クリック可能 → 開く/閉じるが動作
エラー状態  修正後

JavaScriptエラーの原因を開発者ツールで確認する方法

まずエラーが出ているか正確に把握する。ChromeやEdgeのデベロッパーツール(F12キー)を開き、Consoleタブを確認する。該当ページでアコーディオンをクリックした瞬間に赤いエラーメッセージが出ていれば、今回の症状に合致する。

エラー文は日本語環境でも英語で「Uncaught TypeError: Cannot read properties of undefined (reading ‘isOpen’)」と表示される。ファイル名に view.min.js が含まれていれば、WordPress 6.9の標準アコーディオンブロックの初期化問題だと特定できる。

アコーディオンが開かない場合の5つの対処法

アコーディオンが開かない場合の5つの対処法

以下の手順は、簡単で効果が高いものから順に並べている。1つずつ試し、改善した時点で後続の手順は不要だ。

STEP 1 サイト全体のキャッシュを削除する
STEP 2 プラグインをすべて無効化する
STEP 3 テーマをTwenty Twenty-Fiveのままでリセットする
STEP 4 子テーマのfunctions.phpでスクリプト読み込み順を調整する

サイト全体のキャッシュを完全に削除する

キャッシュ系プラグイン(W3 Total CacheやWP Super Cacheなど)を導入している場合は、管理画面から全キャッシュを削除する。加えてサーバー側のキャッシュ(NGINX FastCGI CacheやLiteSpeed Cache)もクリアする。ブラウザキャッシュを個別に消すよりも、プラグインやサーバー管理パネルからの一括削除のほうが確実だ。

全プラグインを無効化して原因を特定する

プラグインのいずれかがJavaScriptの読み込み順やタイミングに干渉している可能性がある。「プラグイン」→「インストール済みプラグイン」からすべてのプラグインを一時的に無効化し、アコーディオンブロックの動作を確認する。問題が解消したら、1つずつ有効に戻していき、再発するプラグインを特定する。

この方法で原因プラグインが判明した場合、そのプラグインの代替を探すか、開発元に修正を依頼するのが現実的だ。特にJavaScriptを多用するページビルダーや最適化系プラグインは干渉しやすいので注意する。

テーマの状態をリセットする

子テーマやカスタマイズを行っている場合は、一時的に親テーマのTwenty Twenty-Fiveに直接切り替える。必要に応じて「外観」→「テーマ」から親テーマを有効化し、カスタマイザーで追加した独自のCSSやJavaScriptが干渉していないか切り分ける。

functions.phpでスクリプト読み込み順を調整する

上記の手順で解決しない場合、テーマやプラグインの読み込み順が影響している可能性が高い。子テーマの functions.php に以下のコードを追加し、WordPress標準のスクリプトをより早い段階で読み込ませる方法が有効だ。

<?php
function force_accordion_script_priority() {
    if ( has_block( 'core/accordion' ) ) {
        wp_enqueue_script( 'wp-block-library' );
        // モジュールスクリプトの読み込みを優先
        add_filter( 'script_loader_tag', function( $tag, $handle ) {
            if ( false !== strpos( $handle, 'accordion' ) ) {
                $tag = str_replace( 'defer', '', $tag );
            }
            return $tag;
        }, 10, 2 );
    }
}
add_action( 'wp_enqueue_scripts', 'force_accordion_script_priority', 5 );

このコードは、アコーディオンブロックがページ内に存在する場合にだけ動作し、defer 属性を除去して読み込みの優先度を上げる。極端な遅延読み込みが原因でエラーが起きている場合に効果を発揮する。

そもそもこのエラーが起きる条件とは

そもそもこのエラーが起きる条件とは

このエラーはWordPress 6.9の標準ブロックに含まれる view.min.js のタイミング依存が直接の原因だ。以下のような条件が重なると発生しやすい。

  • 高速なサーバー環境やCDNによってHTMLの描画が極端に速い
  • 最適化プラグインがスクリプトに deferasync を追加している
  • ページビルダーが独自の方法でスクリプトを結合・遅延読み込みしている
  • カスタムテーマが wp_head()wp_footer() を正しく呼び出していない

いずれも、WordPressが想定するスクリプトの読み込み順序が変更されることで、ブロックの状態管理オブジェクトが生成される前にクリックイベントのリスナーが機能し始めてしまう点で共通している。

再発を防ぐための設定ポイント

再発を防ぐための設定ポイント

この問題を恒久的に避けるには、スクリプト最適化の設定を見直すのが最も効果的だ。キャッシュプラグインや高速化プラグインの「JavaScriptの遅延読み込み」「結合」「minify」などの機能を無効化するか、該当ブロックだけ除外設定を追加する。

具体的には、プラグインの設定画面で「遅延読み込みの除外」に view.min.js または accordion を含むパスを指定する。多くの高速化プラグインでは、特定のスクリプトハンドルやファイル名を除外リストに登録できる。

また、WordPressのアップデートによってコア側の修正が入る可能性も高い。そのため、WordPress本体とテーマは常に最新の状態を維持し、修正が公式にリリースされ次第適用することも大切だ。

よくある質問

特定のブラウザだけで起きるのか

いいや、ブラウザの種類よりもページの読み込み速度やスクリプトの実行順序に左右される。Chrome、Edge、Firefox、Safariのいずれでも発生しうる。特定のブラウザだけで再現する場合は、ブラウザ拡張機能の影響も疑うとよい。

プラグインをすべて無効にしても直らない場合は

テーマに原因がある可能性が高い。一度Twenty Twenty-Fiveの親テーマを直接有効化し、それでも改善しなければサーバー側のキャッシュ機構やCDNの設定を見直す。functions.phpに追加したカスタムコードが干渉しているケースもある。

キャッシュをクリアしても改善しないときの次の手順は

ブラウザのシークレットウィンドウでテストし、ブラウザキャッシュを完全に排除した状態で確認する。それでも同じエラーが出るなら、上記のSTEP 4のコード追加を試すか、WordPress本体の再インストールを検討する。

このエラーはWordPressのバグなのか

厳密にはタイミング依存のバグであり、WordPress 6.9に標準で含まれる view.min.js に起因する。今後のアップデートで修正される見込みだが、現時点ではサーバー環境やプラグイン構成によって発生が左右されるため、回避策を講じるのが現実的だ。

テーマ側で何かできることはあるか

ある。先述のfunctions.phpによる defer 属性の除去のほか、テーマが wp_footer() の直前に不要なスクリプトを挿入していないか確認することも有効だ。シンプルなテーマほどこの問題は起こりにくい。

この記事のポイント

  • アコーディオンが開かない原因はJavaScript初期化のタイミングずれ
  • キャッシュの全削除とプラグイン全無効化でほぼ修正できる
  • 改善しなければfunctions.phpでスクリプト優先度を上げる
  • 最適化プラグインの設定で view.min.js を除外登録する
  • WordPress本体とテーマは常に最新版を保つ
ブロックエディタが点滅してクラッシュする時の原因と直し方

ブロックエディタが点滅してクラッシュする時の原因と直し方

ブロックエディタの画面が激しく点滅し、操作不能になったりエラーでクラッシュする場合、原因の大半はブラウザ拡張機能やキャッシュ、プラグイン競合による JavaScript の競合だ。セーフモードでの編集とブラウザのトラブルシューティングを順に行えば、大半のケースはすぐに編集を再開できる。

なぜブロックエディタが点滅してクラッシュするのか

なぜブロックエディタが点滅してクラッシュするのか

今回の事象の中心にあるのは getComputedStyle@[native code] から始まる JavaScript エラーだ。ブロックエディタは React ベースの画面であり、DOM 要素のスタイルを動的に計算する処理を多用している。この getComputedStyle 呼び出しが失敗すると、React の内部状態が破綻し、画面全体の再描画が無限ループに陥って「点滅」が発生する。

エラーが起きるトリガーは主に以下の3つだ。

  • AdBlock や Grammarly、翻訳ツールなど、ページの DOM 構造を書き換えるブラウザ拡張機能がエディタの動作と衝突している
  • プラグインやテーマが独自に読み込む古い JavaScript ライブラリが、WordPress 本体のバンドル済み React と二重読み込みになっている
  • ブラウザやサーバーに残ったキャッシュが、更新後のスクリプトと旧バージョンのスクリプトを混在させている

点滅はエディタが「レンダリング → クラッシュ → 再マウント → レンダリング」を一瞬で繰り返すために起こる。ユーザーからは、画面全体がチカチカしてボタンやブロックをクリックできない、またはクリックした瞬間に「このブロックでエラーが発生しました」と表示されて操作不能になる状態として見える。

Before(点滅発生中)

エディタ画面全体が高速で明滅し、ブロックを選択できない。クリックすると「このサイトで重大なエラーが発生しました」と表示される。

After(正常動作)

エディタが安定し、ブロックの選択・編集・移動が問題なく行える。画面のちらつきは完全に消えている。

エラー状態  修正後

ビジュアルエディタの点滅を止めて編集を再開する手順

ビジュアルエディタの点滅を止めて編集を再開する手順

原因を一つずつ潰していくのが確実だ。以下の手順は、影響範囲が小さくすぐ試せるものから並べている。手順1〜3で解決しなければ、手順4以降の WordPress 内部の切り分けに進む。

STEP 1 ブラウザ拡張機能をすべて無効にする
STEP 2 シークレットウィンドウで動作確認する
STEP 3 ブラウザキャッシュとサーバーキャッシュを削除する
STEP 4 プラグインの競合を切り分ける(セーフモード)
STEP 5 テーマを標準テーマに切り替える

ブラウザ拡張機能をすべて無効にして試す

最も短時間で試せて、かつ最も解決率が高い対処だ。ブロックエディタは高度な JavaScript で動作しており、広告ブロッカーや文法チェッカーなどの拡張機能が DOM に手を加えると、React の仮想 DOM と実際の DOM の整合性が崩れて getComputedStyle エラーが発生する。特に AdBlock 系、Grammarly、翻訳アドオン、ユーザースクリプト(Tampermonkey 等)が競合しやすい。

Chrome の場合、アドレスバー右の拡張機能アイコンから「拡張機能を管理」を開き、すべての拡張機能を一度オフにする。その状態でエディタを開き直し、点滅が収まるかを確認する。収まった場合は、拡張機能をひとつずつオンにして犯人を特定する。

シークレットウィンドウかゲストモードで動作を確認する

拡張機能を一括で無効化できるもっと手軽な方法が、シークレットウィンドウ(Chrome は Ctrl+Shift+N、Firefox は Ctrl+Shift+P)だ。シークレットモードでは拡張機能がデフォルトで無効になるため、ここで問題が再現しなければ、原因はほぼ確実に拡張機能かブラウザのキャッシュにある。

別のブラウザ(普段 Chrome を使っているなら Firefox や Edge)をインストールし、拡張機能を何も入れていない状態でエディタにアクセスするのも有効な切り分けになる。複数ブラウザで同じエラーが出る場合は、拡張機能ではなく WordPress 側の問題の可能性が高い。

ブラウザキャッシュとサーバーキャッシュを削除する

WordPress のバージョンアップやプラグイン更新の直後に点滅が始まった場合、ブラウザに古い JavaScript ファイルがキャッシュされている可能性が高い。キャッシュされた古いスクリプトと、サーバー上の新しいスクリプトが混ざると、関数の呼び出し不一致で React がクラッシュする。

  • ブラウザのキャッシュと Cookie を全期間で削除する(Chrome 設定→プライバシーとセキュリティ→閲覧履歴データの削除→「キャッシュされた画像とファイル」にチェック→全期間)
  • サーバー側で W3 Total Cache や WP Super Cache などのキャッシュプラグインを使っている場合は、管理画面から「全キャッシュを削除」する
  • Cloudflare などの CDN を利用している場合は、ダッシュボードでキャッシュをパージする
  • 一部のレンタルサーバーで提供される独自キャッシュ機能もオフにする

セーフモードでプラグインの競合を切り分ける

ここまでの手順で解決しない場合、WordPress 内部で JavaScript の競合が起きている。特定のプラグインやテーマが、WordPress 本体がバンドルしている React とは別バージョンの React を読み込んでいたり、jQuery の古いバージョンや別の JavaScript ライブラリを強制的に読み込んでいるケースが多い。

全プラグインを一度に無効化すると管理画面まで影響が出る操作もあるため、WordPress のトラブルシューティングモード(Health Check & Troubleshooting プラグイン)を使うのが安全だ。このプラグインをインストールして有効化すると、管理画面のツールバーに「トラブルシューティングモード」ボタンが現れる。これを押すと、自分だけに影響するセッションで、すべてのプラグインが無効化され標準テーマに切り替わった状態でエディタをテストできる。他の訪問者には通常通りのサイトが表示される。

トラブルシューティングモードでエディタが正常に動けば、原因はプラグインかテーマにある。次にプラグインをひとつずつ有効化していき、どのプラグインを有効にした瞬間に点滅が再発するかを特定する。Health Check プラグインが使えない環境では、本番に近いテスト環境(ステージング)を作って同じ手順を行う。

テーマを標準テーマに切り替える

有料テーマやカスタマイズの多いテーマは、独自のページビルダーやアニメーションライブラリを読み込んでいることがある。プラグインをすべて無効化しても直らない場合、テーマが原因の可能性が高い。一時的に Twenty Twenty-Five などの標準テーマに切り替え、エディタの点滅が止まるか確認する。

テーマを切り替えるとウィジェットやメニュー構成が変わる可能性があるため、先にサイトのバックアップを取ることを推奨する。点滅がテーマに起因していた場合は、テーマの開発元に getComputedStyle エラーの情報を添えて問い合わせるか、子テーマで競合するスクリプトの読み込みを停止させる。

点滅エラーの詳細を開発者ツールで特定する方法

点滅エラーの詳細を開発者ツールで特定する方法

どうしても原因がわからない場合や、特定のプラグインをどうしても無効化できない事情がある場合は、ブラウザの開発者ツールで詳細なエラー情報を収集する。

  • Chrome で F12 キー(開発者ツール)を開き、「Console」タブを確認する
  • 赤いエラーメッセージの右に表示される「ソース」のリンクをクリックすると、エラーが発生している JavaScript ファイルと行番号が表示される
  • ファイルパスに /wp-content/plugins/プラグイン名//wp-content/themes/テーマ名/ が含まれていれば、そのプラグインまたはテーマがエラーの発生源だ
  • 「Network」タブで、404 エラー(Not Found)になっている .js ファイルがないかも確認する。ファイルの読み込みに失敗していると、依存する React の処理が途中で止まりクラッシュする

これらの情報を、原因と思われるプラグインやテーマのサポートフォーラムに提出すれば、開発者側での修正も期待できる。エラーメッセージを丸ごとコピーして伝えるとスムーズだ。

それでも直らない時の一時的な回避策

それでも直らない時の一時的な回避策

納期が迫っていてどうしても編集を進めなければならない場合、以下の回避策で作業を継続できる。

コードエディタで直接編集する

ビジュアルエディタが使えなくても、ブロックエディタの右上の三点メニューから「コードエディタ」に切り替えれば、HTML ベースでブロックの内容を編集できる。ビジュアルのプレビューは見られないが、少なくとも点滅に悩まされずにテキストの修正やブロック構造の調整は可能だ。

クラシックエディタプラグインを一時的に有効化する

Classic Editor プラグインをインストールして有効化すると、旧来のクラシックエディタで記事を編集できる。点滅の原因がブロックエディタ固有の React 処理にある場合、クラシックエディタでは問題が発生しないことが多い。作業が完了したらプラグインを無効化して元のブロックエディタに戻し、根本原因の調査を続ける。

よくある質問

同じブラウザで他の WordPress サイトは正常に動く。自サイトだけ点滅するのはなぜか

自サイトのプラグインまたはテーマが読み込んでいる JavaScript が原因だ。他の WordPress サイトが正常なのは、そのサイトでは問題のスクリプトが読み込まれていないからだ。「セーフモードでプラグインの競合を切り分ける」手順で原因のプラグインやテーマを特定する。

getComputedStyle エラーは WordPress のバージョンを戻せば直るか

バージョンを戻すことで一時的に直るケースはあるが、セキュリティ更新が適用されなくなるため推奨しない。WordPress 本体には問題がなく、特定のプラグインやテーマが新しい WordPress のバンドル済み React に対応していないことがほとんどだ。プラグインやテーマの更新を待つか、開発元に報告して対応を依頼する方が安全だ。

ブラウザのハードウェアアクセラレーションは関係あるか

ごくまれに、GPU レンダリングの不具合が画面の点滅を引き起こすことがある。Chrome の設定→システム→「ハードウェア アクセラレーションが使用可能な場合は使用する」をオフにして再起動すると直るケースも報告されている。ただし、getComputedStyle エラーを伴う場合は JavaScript の競合が原因の可能性が高い。

全プラグイン無効化と標準テーマでも直らない場合はどうするか

ここまで試しても直らない場合は、WordPress 本体のファイル破損やサーバー側の特異な設定(mod_security など)が影響している可能性がある。WordPress の再インストール(「ダッシュボード→更新」から「再インストール」を実行)を試す。それでもダメならサーバーのエラーログを確認し、PHP のメモリ制限や実行時間制限が不足していないかも調べる。

エラーのスタックトレースにプラグイン名が出ていない時はどう調べるか

エラーが react-dom.min.jscomponents.min.js で発生している場合、直接の原因箇所がミニファイされた WordPress 本体のファイルになっている。この場合は「Network」タブで、読み込まれているすべての .js ファイルを確認する。プラグインが読み込むスクリプトの数が多い順に疑い、ひとつずつ無効化して切り分ける。

この記事のポイント

  • ブロックエディタの点滅と getComputedStyle エラーの主因はブラウザ拡張機能と JavaScript 競合
  • シークレットウィンドウと拡張機能無効化で素早く原因を絞り込める
  • Health Check プラグインのトラブルシューティングモードで安全にプラグインを切り分ける
  • どうしても急ぐ場合はコードエディタや Classic Editor プラグインで一時的に編集を続行できる
Kadence Blocksでエディタのフォントがセリフ体になる原因と直し方

Kadence Blocksでエディタのフォントがセリフ体になる原因と直し方

Kadence Blocks の Advanced Typography で Google Fonts を選択したにもかかわらず、ブロックエディタ上でセリフ体のフォールバックフォントが表示される問題は、Kadence Blocks 3.7.3 以降のエディタ内フォント読み込み処理の変更に起因する。フロントエンドで正しく表示されているのであれば、エディタ側の設定やバージョン調整で解決できる。

なぜエディタ内だけ Google Fonts が正しく表示されないのか

なぜエディタ内だけ Google Fonts が正しく表示されないのか

Kadence Blocks の Advanced Typography は、サイトのフロントエンドとブロックエディタの両方に選択したフォントを読み込む仕組みになっている。しかしバージョン 3.7.3 以降、エディタ画面でのフォント読み込みパスや enqueue のタイミングに変更が入り、特定の環境下で Google Fonts のスタイルシートが正しく適用されなくなった。

実際の症状として、例えば Roboto を指定したのにエディタ上では明朝体や Times New Roman 系のセリフ体で表示される。これはブラウザが指定されたフォントを見つけられず、システムのデフォルトフォントにフォールバックしている状態だ。フロントエンドでは Kadence Theme 側のフォント読み込み処理が正常に機能するため問題が表面化しない。

この問題はプラグインの競合ではなく、Kadence Blocks 単体のエディタ向けフォント読み込み処理に起因する。そのため全プラグインを無効化しても再現し、標準テーマに切り替えても改善しない場合がある。

Kadence のフォント設定を確認して対処する

Kadence のフォント設定を確認して対処する

「外観」→「カスタマイズ」でフォントキャッシュを削除する

Kadence Theme には、Google Fonts のローカルキャッシュを管理する機能が組み込まれている。このキャッシュが破損していたり古い情報を保持していると、エディタで正しいフォントが読み込まれないことがある。

  1. WordPress 管理画面の「外観」→「カスタマイズ」を開く
  2. 「General」→「Performance」へ進む
  3. 「Google Fonts」セクションにある「Clear Font Cache」ボタンをクリックする
  4. カスタマイザーを保存して閉じ、ブロックエディタをリロードする

この操作で Kadence が保持していたフォント情報がクリアされ、次回エディタを開いた際に最新のフォントファイルが再取得される。キャッシュクリア後も改善しない場合は、次の手順に進む。

「Google Fonts の読み込み方法」を切り替える

Kadence は Google Fonts の読み込み方式を複数用意している。設定によってエディタ側のフォント描画に影響が出るため、別の方式に変更して検証する。

  • 「外観」→「カスタマイズ」→「General」→「Performance」→「Google Fonts」を開く
  • 「Load Method」を現在とは別のオプションに切り替える(例: 「Local」から「CDN」へ、またはその逆)
  • 保存後にブロックエディタを再読み込みしフォント表示を確認する

ローカル読み込み(Local)に設定すると、Google のサーバーからフォントをダウンロードして自サイト内に保存する。CDN 読み込みでは Google の配信網から直接フォントを取得する。サーバー環境やセキュリティ設定によっては、ローカル読み込み時のファイル生成に失敗してエディタ側のフォントが欠落することがある。

Advanced Typography のエディタ向け設定を確認する

Kadence Blocks のブロック設定パネルにある Advanced Typography には、エディタ内プレビュー用のフォント読み込みを制御する内部フラグが存在する。設定画面から直接変更できる項目ではないが、次の操作でリセットできる。

  1. 問題が発生しているブロックを選択し、右サイドバーの「Advanced」→「Typography」を開く
  2. フォント選択を一度「Default / Inherit」に戻し、保存する
  3. ページをリロードしたあと、再度目的の Google Fonts を選択し直す

これにより Kadence Blocks がエディタ向けにフォントを再登録し、正しいスタイルシートが読み込まれるようになる場合がある。

Before: セリフ体で表示される
見出しテキスト
エディタ上で Roboto を選択しているのに明朝体で表示されている
After: 選択した Google Fonts で表示される
見出しテキスト
Roboto が正しく適用され、フロントエンドと同じ見た目になった
セリフ体にフォールバック  Google Fonts が正常表示

上記のデモはエディタ画面内でのフォント描画の違いを表したものだ。修正後はフロントエンドと同じフォントがエディタでも適用される。

Kadence Blocks のバージョンを変更して問題を回避する

Kadence Blocks のバージョンを変更して問題を回避する

バージョン 3.7.2 にダウングレードする手順

この問題は Kadence Blocks 3.7.3 以降で発生し、3.7.2 では起こらないことが確認されている。どうしてもエディタ内のフォント表示を正しく保ちたい場合、一時的に 3.7.2 へ戻すのが確実な回避策になる。ただしダウングレードはセキュリティ面で推奨されないため、次のアップデートで修正されるまでの応急処置と割り切る。

  1. 管理画面の「プラグイン」→「プラグインの追加」→「プラグインのアップロード」ボタンをクリックする
  2. Kadence Blocks の旧バージョン(3.7.2)の ZIP ファイルをアップロードする
  3. 「現在のプラグインをアップロードしたものに置き換えますか?」という確認で「はい」を選択する
  4. プラグインが上書きされたら、必ず「自動更新を無効化」して意図しないアップデートを防ぐ

旧バージョンの ZIP ファイルは、WordPress.org のプラグインページにある「Advanced View」→「Previous Versions」からダウンロードできる。上書きインストール後はブロックエディタを再読み込みし、フォント表示が正常に戻ったか確認する。

アップデートで修正されたかを定期的に確認する

Kadence Blocks は更新頻度が高いプラグインのため、数週間以内にこの問題が修正された新バージョンがリリースされる可能性がある。ダウングレードした状態でも、WordPress 管理画面の「プラグイン」ページや Kadence の公式チェンジログを定期的にチェックし、修正版が公開されたら速やかに最新版へ更新する。

手動でエディタ用スタイルを補完する方法

手動でエディタ用スタイルを補完する方法

子テーマの editor-style.css でフォントを明示する

Kadence のエディタ内フォント読み込みが不安定な場合、子テーマにエディタ専用のスタイルシートを用意し、使用する Google Fonts を直接指定する方法が有効だ。これは Kadence の処理に依存せず、WordPress 標準の仕組みでエディタにフォントを読み込ませる。

/* 子テーマの functions.php に追加 */
function my_editor_styles() {
    add_theme_support( 'editor-styles' );
    add_editor_style( 'editor-style.css' );
}
add_action( 'after_setup_theme', 'my_editor_styles' );

/* 子テーマ直下の editor-style.css */
@import url('https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap');

.editor-styles-wrapper {
    font-family: 'Roboto', sans-serif;
}

このコードにより、ブロックエディタの読み込み時に指定した Google Fonts が強制的に適用される。Kadence 側のフォント読み込み処理が失敗しても、エディタ上では正しいフォントが表示されるようになる。ただし、この方法はサイト全体に適用されるため、ページやブロックごとに異なるフォントを使い分けている場合は注意が必要だ。

Kadence のフィルターフックでエディタ用フォントを追加する

よりピンポイントに Kadence Blocks のエディタ向けフォント読み込みを補強したい場合、Kadence が提供するフィルターフックを利用する。次のコードを子テーマの functions.php に追加することで、エディタ用のフォントスタイルをプログラム的に挿入できる。

add_action( 'enqueue_block_editor_assets', function() {
    wp_enqueue_style(
        'custom-editor-fonts',
        'https://fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap',
        [],
        null
    );
}, 99 );

このフックはブロックエディタが読み込まれるタイミングで実行され、優先度 99 で登録することで Kadence の内部処理より後にスタイルを追加する。結果として、Kadence が読み込みに失敗した場合でも確実にエディタ上で Google Fonts が利用可能になる。

よくある質問

フロントエンドでは正しく表示されるのにエディタだけおかしいのはなぜか

Kadence Blocks はフロントエンドとエディタで別々のフォント読み込み処理を行っている。フロントエンドは Kadence Theme の仕組みが、エディタは Kadence Blocks の仕組みが担当しており、後者の処理に不具合があるとエディタ内だけでフォントが崩れる。表示確認の際は必ず両方の環境を見比べることが大切だ。

キャッシュを削除しても直らない場合はどうすればよいか

Kadence のフォントキャッシュクリアで改善しない場合、ブラウザキャッシュやサーバー側のキャッシュ(CDN やキャッシュプラグイン)もすべて削除する。その後も直らなければ、Kadence Blocks のバージョンを 3.7.2 にダウングレードするか、前述の editor-style.css による手動補完を検討する。

特定の Google Fonts だけがエディタで表示されないのはなぜか

フォントのウェイト数が多いものや可変フォント(Variable Fonts)は、Kadence のエディタ向け読み込み処理が対応しきれずに欠落することがある。この場合、問題のフォントを Kadence の「Custom Fonts」機能で手動アップロードするか、前述のフィルターフックで直接 Google Fonts の URL を指定すると安定する。

Kadence Blocks のバージョンを下げると他の機能に影響はあるか

3.7.2 へのダウングレードでは、3.7.3 以降に追加された新機能やバグ修正が失われる。具体的にはブロックの追加オプションやパフォーマンス改善が適用されない。ただし、基本的なブロック編集機能やフロントエンド表示には大きな影響は出ない。ダウングレードはあくまで応急処置として考え、修正版のリリースを待つ姿勢が安全だ。

別のテーマに切り替えたらエディタでフォントが表示されるようになった

Kadence Theme を無効化して別のテーマにすると、エディタ内のフォント管理がそのテーマ側に移るため問題が解消されることがある。これは根本的な解決ではなく、Kadence Blocks と Kadence Theme の組み合わせ特有の不具合であることを示している。テーマを変更できない場合は、やはり前述のコードによる手動補完が現実的な対処になる。

この記事のポイント

  • Kadence Blocks 3.7.3 以降のエディタ向けフォント読み込み処理に不具合があり、セリフ体にフォールバックする
  • 「外観」→「カスタマイズ」のフォントキャッシュクリアと読み込み方式の切り替えで改善する可能性がある
  • 一時的な回避策として Kadence Blocks を 3.7.2 にダウングレードする方法がある
  • 子テーマの editor-style.css やフィルターフックでエディタ用フォントを手動補完すると確実に表示できる
  • 修正版がリリースされたら速やかに最新バージョンへ更新することが重要
WordPressでショートコードが表示されず文字列だけ出る時の直し方

WordPressでショートコードが表示されず文字列だけ出る時の直し方

WordPress 7.0 でショートコードが表示されず、角括弧付きの文字列がそのまま画面に出る場合、プラグインの停止・テーマの出力フィルタ不足・ブロックエディタとの相性が主な原因だ。直すにはプラグインの更新や有効化確認から始め、テーマ側で処理されていないときは強制実行のコードを functions.php に追加する。

なぜショートコードが表示されず文字列だけ出るのか

なぜショートコードが表示されず文字列だけ出るのか

ショートコードは [example] のような角括弧で囲まれた短い文字列で、WordPress が表示の瞬間に対応する PHP 処理や HTML に置き換える仕組みだ。この置き換えが行われず、角括弧付きのまま表示される場合、大きく分けて三つの原因が考えられる。

原因1 ショートコードを登録しているプラグインが停止している

プラグインが無効化されているか、WordPress 7.0 への更新後に互換性の問題で停止しているケースが最も多い。更新直後にサイトが「このサイトで重大なエラーが発生しました」という表示になった場合、WordPress は自動で問題のプラグインを停止する。この自動停止によってショートコードの登録処理が丸ごと抜け落ち、文字列だけが残る。

また、プラグインは有効に見えても、特定のページタイプ(固定ページ・投稿・カスタム投稿タイプ)で意図的にショートコードの置換を制限している設計もある。管理画面のプラグイン一覧で有効化状態を確認しても原因がわからないときは、プラグインの内部ロジックまで疑う必要がある。

原因2 テーマが本文中のショートコードを処理していない

ショートコードの置換は do_shortcode() という関数を通じて実行される。WordPress の標準ループやウィジェットエリアでは自動で処理されるが、テーマがカスタマイズされたテンプレートで直接 get_post_meta()the_content() を独自に加工している場合、この関数が呼ばれずショートコードが展開されない。とくに自作テーマや子テーマでカスタムフィールドの値を表示する箇所で起きやすい。

原因3 ブロックエディタの「ショートコードブロック」未使用

WordPress のブロックエディタ(Gutenberg)でショートコードを機能させるには、専用の「ショートコード」ブロックの中に記述する必要がある。段落ブロックや見出しブロックに直接 [example] と打ち込んだ場合、ブロックの保存・出力の仕様によってはテキストとしてそのまま表示されることがある。クラシックエディタに慣れていると見落としがちなポイントだ。

ショートコードが表示されないときの原因3分類
原因 A プラグインが無効化または停止している
原因 B テーマが do_shortcode() を呼んでいない
原因 C ブロックエディタでショートコードブロックを使っていない
プラグイン停止  テーマ側の処理不足  ブロック種別の選択ミス

上図の三方向から原因を絞り込めば、ほとんどのケースで該当箇所が見つかる。次項からは実際の対処手順を具体的に解説する。

ショートコードが機能しないときの具体的な対処手順

ショートコードが機能しないときの具体的な対処手順

手順1 プラグインの有効化と更新を確認する

管理画面の「プラグイン」→「インストール済みプラグイン」を開き、該当プラグインが有効化されているかを確認する。無効化されていれば「有効化」をクリックするだけで解決することが多い。有効化されているのに直らない場合は、プラグインの最新バージョンがリリースされていないか更新画面を確認する。WordPress 7.0 へのメジャーアップデート直後は、プラグイン開発者が緊急の互換性アップデートを出している可能性が高い。

管理画面にアクセスできないほどサイトが壊れている場合は、WordPress の「リカバリモード」を利用する。サイトで致命的エラーが発生すると、管理者メールアドレス宛に「このサイトで重大なエラーが発生しました」という件名のメールが届き、その中にリカバリモード用の特別なログインリンクが記載されている。このリンクからログインすると、問題のプラグインだけが停止した状態で管理画面に入れる。

手順2 テーマ側で do_shortcode() を明示的に実行する

プラグインが正常に動作しているのにショートコードが展開されない場合、テーマのテンプレートが原因だ。該当のショートコードを表示したい箇所がカスタムフィールドやウィジェットエリア内であれば、テンプレートファイル内の出力部分に do_shortcode() を追加する。

// カスタムフィールドの値をショートコード展開して出力
echo do_shortcode( get_post_meta( get_the_ID(), 'my_custom_field', true ) );

// 本文中のショートコードを意図的に再実行(通常は不要だが保険として)
echo do_shortcode( get_the_content() );

上記は functions.php ではなく、該当のテンプレート(single.phppage.php など)の出力箇所に追記するコードだ。子テーマを使っていない場合は必ず子テーマを用意してから編集し、テーマのアップデートで変更が失われないようにする。子テーマの作り方は後述の FAQ で扱う。

手順3 ブロックエディタで「ショートコード」ブロックを使う

ブロックエディタでページを編集している場合、ブロック挿入ツール(+ボタン)から「ショートコード」ブロックを検索して追加する。既存の段落ブロックに直接ショートコードを打ち込んでいる場合は、そのブロックを削除して新しくショートコードブロックを追加し、中にショートコード文字列だけを入力する。

STEP 1 ブロック挿入ツール(+)をクリック
STEP 2 「ショートコード」ブロックを検索して追加
STEP 3 ブロック内にショートコード(例: [example])を入力
STEP 4 プレビューまたは公開して表示を確認

この手順でブロックエディタ上の問題は解決するが、テーマ側の出力処理に起因する問題はこれだけでは直らない。手順2も併せて確認するのが確実だ。

WordPress 7.0 特有の注意点と想定外のエラーへの備え

WordPress 7.0 特有の注意点と想定外のエラーへの備え

WordPress 7.0 は内部のエラーハンドリングが強化され、従来は警告レベルで済んでいた処理が致命的エラーとして扱われるケースが増えている。プラグインが最新でも、内部の非推奨関数の呼び出しや PHP バージョンとの不一致があると、サイト全体がダウンし管理画面からも締め出される。

こうした状況では、FTP またはサーバーのファイルマネージャーで /wp-content/plugins/問題のプラグインフォルダ/ を一時的にリネームする方法が最も確実な緊急回避策になる。フォルダ名を「custom-profile-picture」から「custom-profile-picture_temp」などに変更すれば、WordPress はそのプラグインを検出できなくなり、サイトが正常に表示される状態まで復帰する。その後、プラグインの互換性情報を確認してから正式な対処を取る。

よくある質問

ショートコードを使うプラグインをアップデートしたらサイトが真っ白になった

WordPress 7.0 とプラグインの互換性が取れていない可能性が高い。リカバリモードのリンクがメールで届いていればそこからログインし、問題のプラグインを停止する。メールが届いていない場合は FTP で対象プラグインのフォルダをリネームし、管理画面にアクセスできる状態に戻してから代替プラグインを検討する。

子テーマの functions.php に追記する方法がわからない

子テーマとは、親テーマの機能を引き継ぎつつ安全にカスタマイズするための仕組みだ。まず親テーマと同じディレクトリに子テーマ用フォルダを作成し、style.cssfunctions.php の2ファイルを設置する。functions.php には親テーマのスタイルを読み込むコードと、do_shortcode() を含むカスタマイズコードを記述する。詳細な手順は WordPress 公式の子テーマ作成ガイドが役立つ。

ショートコードブロックを使っても特定のページだけ表示されない

キャッシュ系プラグインや CDN が原因のことが多い。キャッシュを全削除し、CDN を使用している場合は一時的に開発モードにしてから表示を確認する。また、該当ページがカスタム投稿タイプで、テンプレートが専用の出力処理をしている場合も同様に do_shortcode() の追加が必要になる。

プラグインを更新したが問題が再発した

更新で一度直っても、WordPress の自動エラーハンドリングが再度働いて同じプラグインを停止することがある。サーバーのエラーログを確認し、PHP のメモリ不足や実行時間制限が原因であれば、wp-config.phpWP_MEMORY_LIMIT を 256M 以上に設定する。根本的にはプラグイン開発者の対応を待つ必要があるケースもある。

この記事のポイント

  • ショートコードが文字列のまま表示される主因はプラグイン停止・テーマの処理不足・ブロック選択ミスの3つ
  • 管理画面に入れない場合はリカバリモードか FTP でプラグインフォルダをリネームして復旧させる
  • テーマ側で do_shortcode() が呼ばれていない箇所は子テーマのテンプレートに追記する
  • ブロックエディタでは必ず「ショートコード」専用ブロックの中に記述する
  • WordPress 7.0 はエラーハンドリングが強化され互換性問題が表面化しやすい
WooCommerce 10.6.2リリース——WordPress 7.0対応と変動商品ブロックの不具合修正

WooCommerce 10.6.2リリース——WordPress 7.0対応と変動商品ブロックの不具合修正

WooCommerce 10.6.2が3月30日にリリースされた。今回のアップデートは、WordPress 7.0の正式リリースに備えた管理画面の互換性向上と、Add to Cart with Optionsブロックにおける変動商品の選択不具合修正が主な内容だ。

WooCommerce 10.6.1で部分的に修正された問題を完全に解決し、WordPressの次期メジャーバージョンに向けた安定性を確保する。ECサイト運営者は、WordPress 7.0への移行を円滑に進めるための重要なアップデートとして位置づけられる。

変動商品の属性選択不具合を完全解決

変動商品の属性選択不具合を完全解決

WooCommerce 10.6.2では、Add to Cart with Optionsブロックにおける変動商品の選択問題が修正された。この問題は、商品属性の名前に特殊文字が含まれている場合や、カスタムスラッグが変換後の名前と異なる場合に発生していた。

属性名とスラッグの不一致が原因

変動商品とは、色やサイズなどの属性(バリエーション)を持つ商品だ。顧客は商品ページでこれらの属性を選択し、購入する特定の商品を決定する。

問題は、属性の「表示名」と内部的に使用される「スラッグ」が一致しない場合に生じていた。例えば、表示名が「Blue/Green」でも、スラッグが「blue-green」に変換されるケースがある。Add to Cart with Optionsブロックは、以前は変換後の名前とスラッグを比較していたため、この不一致により正しい属性を選択できない不具合が発生していた。

WooCommerce 10.6.2では、比較ロジックを「表示名と表示名」を直接比較する方式に変更した。これにより、内部的なスラッグ変換の影響を受けず、顧客が画面で見ている属性名通りに選択が可能になる。

10.6.1からの継続的な改善

この修正は、WooCommerce 10.6.1で行われた部分的対応の続きとなる。開発チームはGitHubのプルリクエスト#63771を通じて、問題の根本原因を特定し、より堅牢な解決策を実装した。

変動商品を多く扱うECサイト、特にファッションや食品など多様なバリエーションを持つ業種では、この修正により顧客の商品選択体験が確実に向上する。属性選択が正しく機能しないことは、直帰率の上昇やカート放棄率の増加につながるため、EC運営者にとっては重要な改善点だ。

WordPress 7.0への対応を強化

WordPress 7.0への対応を強化

WooCommerce 10.6.2のもう一つの主要なテーマは、WordPress 7.0との互換性確保だ。WordPressのコアが更新されると、管理画面のスタイルやコンポーネントの挙動が変化する。これに伴い、WooCommerceの管理画面でも様々な表示上の問題が発生していた。

管理画面の表示不具合を一括修正

修正された問題は多岐にわたる。分析テーブルやダッシュボードカードに余計なパディング(余白)が表示される問題、小さな画面でアクションボタンが不自然に折り返される問題、注文管理画面全体での配置やサイズの不整合などが含まれる。

特に注目すべきは、アクティビティパネルでの無限再レンダリングループの修正だ。この問題は、特定の条件下で管理画面の一部が応答しなくなる原因となっていた。WordPress 7.0の新しいReactレンダリングエンジンとの相互作用で発生していたと見られる。

メタボックスとコントロール要素の表示改善

メタボックスとは、WordPressの編集画面で投稿や商品の追加情報を入力するボックスのことだ。WooCommerceでは商品データや注文情報の入力に多用される。WordPress 7.0ではこれらのUIコンポーネントのスタイルが更新されたため、WooCommerce側でも調整が必要だった。

複数のプルリクエスト(#63873、#63881、#63836など)を通じて、管理画面全体のスタイル一貫性が確保された。これにより、商品登録や注文処理といった日常業務におけるユーザー体験が、WordPress 7.0環境下でも安定して維持される。

ECサイト運営者が取るべきアクション

ECサイト運営者が取るべきアクション

WooCommerce 10.6.2はメンテナンスリリースであり、新機能は含まれない。その性質上、ECサイト運営者は速やかな適用を検討すべきだ。

ステージング環境での事前テストが必須

まず、本番環境に直接アップデートする前に、ステージング環境(本番環境のコピー)でテストを実施する。WordPress 7.0がまだ正式リリース前であっても、WooCommerce 10.6.2の互換性修正が既存のWordPress 6.x環境に悪影響を及ぼさないかを確認する必要がある。

テストの重点項目は3つある。1つ目は、変動商品を持つ商品ページで、Add to Cart with Optionsブロックが正しく動作するか。2つ目は、管理画面の分析レポートや注文一覧などの表示が崩れていないか。3つ目は、カスタマイズしたテーマやプラグインとの互換性だ。

WordPress 7.0への移行計画と連動

WooCommerce 10.6.2の適用は、WordPress 7.0への移行計画と連動させるべきだ。WordPressのメジャーバージョンアップデートは、テーマやプラグインの互換性に大きな影響を与える可能性がある。

理想的な順序は、まずWooCommerceを10.6.2に更新し、問題がないことを確認した後でWordPressを7.0にアップデートすることだ。これにより、問題が発生した際の原因切り分けが容易になる。WooCommerce開発チームは、WordPress 7.0の正式リリースに先立ち、主要な互換性問題を解消した形だ。

開発者コミュニティからの貢献

開発者コミュニティからの貢献

今回のリリースには、GitHub上で報告された多数のイシューとプルリクエストが反映されている。オープンソースプロジェクトとしてのWooCommerceは、世界中の開発者やユーザーからのフィードバックによって改善が続けられている。

GitHubを中心とした協働開発

修正内容はすべてGitHubのプルリクエストで公開され、コードレビューを経て本体にマージされた。例えば変動商品の問題は#63771で、WordPress 7.0対応の様々な修正は#63873や#63881など複数のPRで追跡できる。

この透明性の高い開発プロセスは、ユーザーが問題を理解し、必要に応じて一時的な修正を自身で適用することを可能にする。また、特定の不具合が自分のサイトにどのような影響を与えるかを事前に評価する材料にもなる。

今後のリリースに向けた準備

WooCommerce 10.6.2は、WordPress 7.0という大きな環境変化の前に行われた重要な調整リリースと位置づけられる。開発チームは、コアとなるEC機能の安定性を最優先し、新機能の追加は次の機会に委ねた形だ。

ECサイト運営者は、このリリースを通じて基盤の堅牢性が強化されたと捉えることができる。特に変動商品の取引が多いサイトや、管理画面を頻繁に利用する運営者にとっては、業務効率と顧客体験の両面でメリットが大きい。

この記事のポイント

  • WooCommerce 10.6.2は、WordPress 7.0正式リリースに先立つ互換性向上リリースである。
  • Add to Cart with Optionsブロックで、特殊文字を含む属性名の変動商品が正しく選択できるよう修正された。
  • 管理画面の分析レポート、注文一覧、アクティビティパネルなど、多数のUI表示不具合が解消されている。
  • 本番環境適用前には、必ずステージング環境で表示や機能のテストを行うことが推奨される。
  • 修正内容はGitHubのプルリクエストで公開されており、開発者や上級ユーザーは詳細を確認できる。
WordPress画像SEOの決定版ガイド:Googleが評価する10の最適化ポイント

WordPress画像SEOの決定版ガイド:Googleが評価する10の最適化ポイント

WordPressサイトにおける画像の最適化は、単にファイルサイズを小さくするだけでは不十分だ。多くのガイドは表示速度の向上で解説を終えているが、本来の目的は「Googleに見つけてもらい、正しく理解してもらうこと」にある。

画像SEOには、パフォーマンス(表示速度)とディスカバラビリティ(見つけやすさ)という2つの層が存在する。いくら圧縮された画像でもGoogleにインデックスされなければ意味がなく、逆に素晴らしい代替テキストを設定しても、読み込み時にレイアウトが崩れればユーザー体験を損なう。

この記事では、WordPressサイトを運営する担当者が明日から実践できる、画像SEOの10のチェックポイントを解説する。これを実践することで、検索流入の増加とサイトの健全性向上を同時に実現できるはずだ。

サイト全体で取り組むべき画像SEOの基盤設定

サイト全体で取り組むべき画像SEOの基盤設定

まずは、サイト内のすべての画像に自動的に適用される基盤部分を整える。一度設定してしまえば、その後の運用負荷を大幅に軽減できる項目だ。

画像サイトマップの構築と確認

検索エンジンは、見つけることができない画像をランク付けすることはない。画像サイトマップは、Googleに対してサイト上のすべての画像への直接的な経路を示す役割を果たす。これは、画像検索からのトラフィックが重要なサイトにとって極めて重要だ。

一般的なSEOプラグインは標準でXMLサイトマップに画像を含めている。ただし、画像がCDN(コンテンツ・デリバリー・ネットワーク)のサブドメインや別ドメインにホストされている場合は注意が必要だ。標準の設定では、メインドメイン以外のファイルが除外されているケースがある。著者のマーク・ザーラ氏は、プラグインが有効かどうかだけでなく、実際のサイトマップ出力を確認することを推奨している。

画像最適化プラグインの一本化

複数の画像最適化プラグインを同時に実行すると、競合が発生してトラブルの原因になる。圧縮された画像が歪んだり、サムネイルが正しく生成されなかったり、サーバーのエラーログが肥大化したりするリスクがある。プラグイン同士が同じ処理プロセスを奪い合うため、結果が予測不能になるからだ。

信頼できるプラグインを1つ選び、適切に設定するのが賢明だ。例えば、圧縮、WebPやAVIFへの変換、EXIF情報の削除、AIによる代替テキスト生成などを一括でこなせるツールを選べば、他のツールを併用する必要はなくなる。もし現在、複数の画像関連プラグインを入れているなら、まずはそれらを整理することから始めたい。

ブラウザキャッシュの適切な設定

ブラウザキャッシュとは、一度訪れたユーザーのブラウザに画像などの静的ファイルを保存させ、再訪問時の読み込み速度を上げる仕組みだ。これにより、2回目以降のアクセスではサーバーからデータをダウンロードする必要がなくなる。

キャッシュプラグインや、高速な国内レンタルサーバーを利用していれば、多くの場合サーバーレベルで設定済みだ。しかし、設定の有無で再訪問時の表示速度には劇的な差が出るため、正しく機能しているか確認する価値はある。

投稿ごとに行うべき画像最適化チェックリスト

投稿ごとに行うべき画像最適化チェックリスト

次に、記事を投稿するたびに意識すべき個別の最適化項目を見ていく。日々のルーチンに組み込むことで、サイトのSEO強度は着実に積み上がっていく。

アップロード前のファイル名リネーム

画像のファイル名は、小さいながらも確実なSEOシグナルになる。「IMG_20240314.jpg」のような名前はGoogleに何も伝えないが、「wordpress-seo-dashboard.jpg」という名前なら、画像の内容を正確に伝えることができる。

メディアライブラリにアップロードする前に、内容を表す英単語をハイフンでつなげた名前に変更する習慣をつけよう。キーワードを詰め込む必要はない。目が見えない人にその画像を説明するような、簡潔で正確な名前が理想的だ。この作業には数秒しかかからないが、サイト全体で積み重なれば大きな差となる。

画像のwidthとheight属性の明示

HTMLタグに画像の幅(width)と高さ(height)を記述することで、ブラウザは画像が読み込まれる前にそのスペースを確保できる。これが指定されていないと、画像が表示された瞬間に周囲のコンテンツが押し下げられる「レイアウトシフト」が発生する。

CLS(Cumulative Layout Shift)は、Googleがランキング要因として採用しているCore Web Vitalsの指標の一つだ。WordPressの標準エディタを使っていれば自動的に付与されるが、カスタムブロックや一部のページビルダーでは属性が抜け落ちることがある。出力されたソースコードを確認し、サイズ指定が含まれているかチェックしてほしい。

Altテキスト(代替テキスト)の質を高める

Altテキストは、検索エンジンが画像内容を理解する主要な手段だ。また、視覚障害者が使用するスクリーンリーダーで読み上げられるほか、画像が読み込めない際の代替表示としても機能する。

「プラグインのスクリーンショット」のような不親切な説明ではなく、画像の内容を自然に記述することが重要だ。装飾目的の画像であれば、Alt属性を空(alt=””)に設定することで、スクリーンリーダーにスキップすべき画像であることを伝えられる。大量の画像がある場合は、AIを活用した自動生成ツールの利用を検討してもよいが、最終的には人間の目で確認するのがベストだ。

Core Web Vitalsを改善する高度な画像制御

Core Web Vitalsを改善する高度な画像制御

ユーザー体験を数値化する指標「Core Web Vitals」において、画像は大きな影響力を持つ。特にLCP(Largest Contentful Paint / 最大視覚コンテンツの表示時間)の改善には、特別な配慮が必要だ。

LCP画像の遅延読み込み(Lazy Load)を解除する

遅延読み込みは、画面外の画像を必要になるまで読み込まないことで初期表示を速める技術だ。しかし、ページの最上部にある「ヒーロー画像」や「アイキャッチ画像」にこれを適用すると、逆に表示が遅れてLCPスコアを悪化させる。

WordPress 5.9以降では、最初の画像が自動的に遅延読み込みから除外されるようになっている。しかし、テーマやページビルダーの構造によっては、ソースコード上の最初の画像がヒーロー画像でない場合がある。重要な画像に「loading=”lazy”」が付与されていないか、ブラウザの検証ツールで確認することが推奨される。

fetchpriority属性で優先度を指定する

最新の最適化手法として「fetchpriority=”high”」属性の活用がある。これをLCP画像に付与することで、ブラウザに対して「この画像は最優先でダウンロードすべきものだ」と伝えることができる。

記事によれば、この属性を追加するだけでLCPが20〜30%改善したテスト結果もあるという。パフォーマンスプラグインの中にはこれを自動で設定するものもあるが、手動でコードを調整できる環境であれば、ヒーロー画像への適用は非常に効果的だ。

検索結果での露出を増やすリッチな情報付加

検索結果での露出を増やすリッチな情報付加

画像そのものの情報だけでなく、その周辺情報を充実させることで、Googleはより自信を持って画像を検索結果に表示できるようになる。

キャプションによるコンテキストの提供

Googleは、画像自体のメタデータだけでなく、その周囲にあるテキストやキャプションからも情報を抽出している。適切に記述されたキャプションは、画像検索における競争力を高める要因になる。

ただし、すべての画像にキャプションを付ける必要はない。読者が画像の内容を理解する助けになる場合にのみ記述すべきだ。無理なキーワードの詰め込みは避け、編集上の価値を優先させよう。

構造化データ(Schema.org)の活用

構造化データを使用すると、画像に関する詳細なコンテキストをGoogleに伝えられる。特に製品(Product)やレシピ(Recipe)の画像は、構造化データがあることでGoogleショッピングパネルやリッチリザルトに表示される資格を得る。

WooCommerceなどのECサイトや料理ブログを運営しているなら、この設定は必須だ。主要なSEOプラグインを使っていれば、投稿タイプに応じて自動的にスキーママークアップが行われることが多いが、正しく出力されているか「リッチリザルトテスト」などのツールで確認しておきたい。

独自の分析:画像SEOにおける「ユーザー体験」と「AI理解」の融合

独自の分析:画像SEOにおける「ユーザー体験」と「AI理解」の融合

近年の画像SEOにおいて最も大きな変化は、Googleの画像解析能力が飛躍的に向上したことだ。かつてはファイル名やAltテキストに頼らざるを得なかったGoogleだが、今やAIによって画像内の物体やテキスト、さらには文脈まで高精度に理解している。

この変化は、SEO対策のあり方を「ハック」から「本質的な改善」へとシフトさせている。例えば、fetchpriority属性の導入は、単なる検索順位対策ではなく、ユーザーに「いかに速く、ストレスなくコンテンツを届けるか」というブラウザ制御の最適化だ。また、Altテキストの重要性が増しているのは、アクセシビリティ(誰でも情報にアクセスできること)がSEOの評価軸として確立されたことを意味している。

WordPress運営者が目指すべきは、技術的なチェックリストを埋めることだけではない。画像が読み込まれるまでの数秒間、ユーザーを待たせないためのパフォーマンス管理と、画像検索から訪れるユーザーに対して正確な情報を提示するディスカバラビリティの管理。この両輪を回すことが、結果としてGoogleからの高い評価につながるのだ。

この記事のポイント

  • 画像サイトマップの確認:CDN利用時は特に注意し、Googleが画像を見つけられる状態にする。
  • プラグインの競合回避:画像最適化ツールは1つに絞り、予期せぬエラーを防ぐ。
  • ファイル名とAlt属性の徹底:アップロード前に名前を変え、具体的で自然な説明文を添える。
  • LCP対策の高度化:最上部の画像は遅延読み込みを解除し、fetchpriorityで読み込みを加速させる。
  • GSCでのフィールドデータ確認:PageSpeed Insightsの単発テストだけでなく、Search Consoleで実際のユーザー体験を監視する。

出典

  • WP Mayor「WordPress Image SEO Checklist: What Google Actually Looks For」(2026年3月19日)
WordPress開発の転換点:PHPのみでGutenbergブロックを構築する方法

WordPress開発の転換点:PHPのみでGutenbergブロックを構築する方法

WordPressのブロックエディタ(Gutenberg)が登場して以来、カスタムブロックの開発にはReactやNode.jsといったJavaScriptベースの技術習得が不可欠だった。しかし、最新のアップデートにより、PHPコードのみでブロックを構築・管理できる手法が確立された。この変更は、従来のPHP中心のWordPress開発者にとって、学習コストを劇的に下げる重要な転換点となる。

Gutenberg 21.8以降で導入されたこの機能により、サーバーサイドのJavaScript環境を構築することなく、PHPの関数だけでエディタとフロントエンドの両方にブロックを表示できる。ビルドプロセスの複雑さを排除し、保守性の高いサイト制作を可能にするのが「PHP-onlyブロック」だ。

本記事では、PHPのみでブロックを登録する具体的な手順から、管理画面UIの自動生成、さらには既存のショートコードをブロック化する実践的なテクニックまでを詳しく解説する。この記事を読むことで、最新のWordPress標準に準拠した効率的な開発手法を習得できるはずだ。

PHP-onlyブロックの概要と導入のメリット

PHP-onlyブロックの概要と導入のメリット

これまで、カスタムブロックを作成するには、Reactの知識に加え、WebpackやNPM(Node Package Manager)を用いたビルド環境の構築が必須であった。これは、主にサーバーサイドのPHPでサイトを構築してきた開発者にとって、非常に高い参入障壁となっていた。PHP-onlyブロックは、この障壁を取り払うために設計された仕組みだ。

なぜPHPだけでブロックが作れるようになったのか

WordPress開発チームは、ブロックエディタの普及をさらに加速させるため、従来のPHP開発者が慣れ親しんだ手法でブロックを作成できる環境を整えた。具体的には、サーバー側で登録されたメタデータをエディタ(JavaScript側)へ自動的に受け渡す「auto_register」機能が実装されたことが大きい。これにより、エディタ用のJSファイルを手動で記述する必要がなくなったのだ。

開発者にとっての3つの主要な利点

第一の利点は、学習コストの圧倒的な低減だ。ReactやNode.jsの複雑なエコシステムを学ぶ時間を、サイトの機能向上やデザインのブラッシュアップに充てることができる。第二に、フロントエンドのパフォーマンス向上が挙げられる。不要なJavaScriptの読み込みを削減できるため、ページの読み込み速度を最適化しやすい。第三に、保守性の向上だ。PHPコード一箇所でブロックの定義と出力(レンダリング)を管理できるため、コードの可読性が高まり、バグの混入を防ぎやすくなる。

基本的なPHP-onlyブロックの作り方

基本的なPHP-onlyブロックの作り方

PHP-onlyブロックの作成は、従来の「動的ブロック(Dynamic Blocks)」の登録方法と似ているが、最大の違いはエディタ用のスクリプトを指定せずに、特定のフラグを有効にする点にある。元記事の著者は、最小限のコードでブロックを動作させる手法を示している。

register_block_type と auto_register の役割

ブロックの登録には、WordPress標準の `register_block_type` 関数を使用する。この関数の `supports` 配列内に `’auto_register’ => true` を含めることが、PHP-onlyブロックとして動作させるための鍵となる。このフラグが有効な場合、WordPressは `ServerSideRender` というコンポーネントを自動的に使用し、管理画面上でもPHPで生成されたHTMLをプレビュー表示する。

最小構成のコード例

以下は、プラグインやテーマの `functions.php` に記述することで動作する、最もシンプルなPHP-onlyブロックのコードだ。

/**
 * レンダリング用コールバック関数
 */
function my_simple_php_block_render( $attributes ) {
    return '<div style="padding: 20px; background: #f0f0f0; border: 2px solid #0073aa;">
        <h3>🚀 PHP-only ブロック</h3>
        <p>このブロックはPHPのみで生成されています。</p>
    </div>';
}

/**
 * ブロックの登録
 */
add_action( 'init', function() {
    register_block_type( 'my-custom/php-block', array(
        'title'           => 'シンプルなPHPブロック',
        'icon'            => 'admin-plugins',
        'category'        => 'text',
        'render_callback' => 'my_simple_php_block_render',
        'supports'        => array(
            'auto_register' => true,
        ),
    ) );
});

🚀 PHP-only ブロック

このブロックはPHPのみで生成されています。

このコードを有効にすると、ブロックエディタの追加メニューに「シンプルなPHPブロック」が表示され、設置すると即座にグレーの枠線で囲まれたプレビューが表示される。これがPHP-only開発の第一歩だ。

属性(Attributes)を活用した管理画面UIの自動生成

属性(Attributes)を活用した管理画面UIの自動生成

単にHTMLを出力するだけでなく、ユーザーがエディタ上でテキストを変更したり、オプションを選択したりできるようにするには「属性(Attributes)」を定義する必要がある。最新のGutenbergでは、PHPで定義した属性に基づいて、サイドパネル(インスペクター)の入力フィールドを自動生成する機能が追加されている。

属性の定義と入力フィールドの対応関係

属性のデータ型(type)を指定することで、WordPressは適切なUIコンポーネントを割り当てる。著者によれば、現在のところ以下のマッピングがサポートされている。

  • string: テキスト入力フィールド
  • number / integer: 数値入力フィールド
  • boolean: チェックボックス(またはトグル)
  • enum(string内): セレクトボックス(ドロップダウン)

実践的な属性付きブロックのコード

以下の例では、タイトル、表示数、有効/無効の切り替え、サイズ選択の4つの属性を持つブロックを定義している。これらはすべて、JavaScriptを一行も書かずに管理画面のサイドバーに表示される。

register_block_type( 'my-plugin/advanced-php-block', array(
    'title'      => '設定付きPHPブロック',
    'attributes' => array(
        'blockTitle'  => array( 'type' => 'string', 'default' => 'デフォルトタイトル' ),
        'itemCount'   => array( 'type' => 'integer', 'default' => 5 ),
        'isEnabled'   => array( 'type' => 'boolean', 'default' => true ),
        'displaySize' => array(
            'type' => 'string',
            'enum' => array( 'small', 'medium', 'large' ),
            'default' => 'medium',
        ),
    ),
    'render_callback' => 'my_advanced_render_func',
    'supports' => array( 'auto_register' => true ),
) );

この仕組みの導入により、複雑なReactコンポーネント(TextControlやSelectControlなど)を組み合わせて `edit.js` を作成する手間が省ける。ただし、現時点ではリッチテキストエディタ(RichText)や高度なカラーピッカーなど、一部の複雑なコントロールはJS側での定義が必要な場合がある点には注意が必要だ。

実践例:カスタマイズ可能な価格表ブロックの構築

実践例:カスタマイズ可能な価格表ブロックの構築

より実用的な例として、Web制作の現場で頻繁に求められる「価格表(料金テーブル)」ブロックをPHPのみで作成する手法を解説する。ここでは、WordPress標準のスタイル機能(色、間隔、タイポグラフィ)を統合する方法が重要となる。

get_block_wrapper_attributes によるネイティブ機能の統合

PHP-onlyブロックで最も強力な武器となるのが `get_block_wrapper_attributes()` 関数だ。この関数は、ユーザーがエディタのサイドバーで設定した背景色、文字色、パディング、マージンなどのスタイル情報をクラス名やインラインスタイルとして一括生成してくれる。これをメインの `div` タグに出力するだけで、自作ブロックがWordPressの標準デザインツールに完全対応する。

価格表ブロックのレンダリング設計

著者が提案する「Smart Pricing Widget」の例では、プラン名、価格、ボタンテキストなどの属性に加え、`supports` 配列で `color`, `spacing`, `typography`, `shadow`, `border` を有効にしている。これにより、エンジニアがCSSを細かく調整しなくても、運用者がエディタ上で自由に見た目をカスタマイズできるようになる。

function render_smart_pricing_block( $attributes ) {
    // 属性の取得
    $plan_name = esc_html( $attributes['planName'] );
    $price     = intval( $attributes['price'] );
    
    // スタイル属性の生成
    $wrapper_attributes = get_block_wrapper_attributes( array(
        'class' => 'my-pricing-card',
    ) );

    return sprintf(
        '<div %s>
            <h3>%s</h3>
            <div class="price">¥%d</div>
            <a href="#" class="btn">申し込む</a>
        </div>',
        $wrapper_attributes,
        $plan_name,
        $price
    );
}

プロフェッショナル

¥4,900
申し込む

PHPのみで作成され、エディタの色設定が反映される価格表ブロックのイメージ

既存のショートコードをブロックへ変換する方法

既存のショートコードをブロックへ変換する方法

PHP-onlyブロックの最も現実的かつ即効性のある活用シーンは、古いサイトで多用されている「ショートコード」のブロック化だ。ショートコードは入力が煩雑でプレビューも困難だが、PHP-onlyブロックでラップすることで、直感的な操作感へとアップグレードできる。

ショートコードをラップするメリット

ショートコードをそのまま使い続けるのではなく、ブロックとして再定義することで、ユーザーは「`[my_shortcode type=”info”]`」のような文字列を打ち込む必要がなくなる。代わりに、サイドバーのドロップダウンから「情報」「警告」「エラー」を選択するだけで済むようになる。内部的には既存のショートコード関数を呼び出すため、ロジックを書き直す必要もない。

do_shortcode を使ったレンダリング手法

実装方法は非常にシンプルだ。ブロックの `render_callback` 内で、受け取った属性を基にショートコード文字列を組み立て、WordPress標準の `do_shortcode()` 関数に渡すだけである。記事によれば、これにより管理画面上でもショートコードの実行結果がリアルタイムにプレビューされ、編集体験が劇的に向上するという。

function render_shortcode_wrapper_block( $attributes ) {
    $type = esc_attr( $attributes['alertType'] );
    $msg  = esc_attr( $attributes['message'] );
    
    // 既存のショートコードを動的に生成
    $shortcode = sprintf( '[my_alert type="%s"]%s[/my_alert]', $type, $msg );
    
    return sprintf(
        '<div %s>%s</div>',
        get_block_wrapper_attributes(),
        do_shortcode( $shortcode )
    );
}

WordPress開発の未来とPHP-onlyブロックの立ち位置

WordPress開発の未来とPHP-onlyブロックの立ち位置

PHP-onlyブロックは現在、非常に強力なツールとして進化を続けているが、すべてのJavaScript開発を置き換えるものではない。高度なインタラクションや、複雑な状態管理が必要なUI(例:ドラッグ&ドロップを伴う高度なレイアウトエディタなど)には、依然としてReactによる開発が適している。

しかし、中小規模のWebサイト制作や、社内向けのカスタム機能の実装においては、PHP-onlyブロックで十分なケースが大半だ。著者も指摘するように、この機能は「ブロックエコシステムを、高度なJavaScriptを操る層以外にも広げる」ための重要な架け橋となるだろう。今後は、より多くの管理画面コントロールがPHPから定義可能になり、JSを書く必要性はさらに低下していくと予想される。

我々Web制作に携わる者にとって、技術の選択肢が増えることは歓迎すべきことだ。プロジェクトの予算、納期、そして保守を担当するチームのスキルセットに合わせて、ReactベースのブロックとPHP-onlyブロックを適切に使い分ける「ハイブリッドな開発スタイル」が、これからのスタンダードになると考えられる。

この記事のポイント

  • React/Node.js不要: 複雑なビルド環境なしでカスタムブロックが作成可能。
  • auto_registerフラグ: PHPで定義した属性から管理画面のUIを自動生成できる。
  • 保守性の向上: PHPコード一箇所で定義と出力を管理でき、コードの可読性が高い。
  • ショートコードの進化: 既存のショートコードを簡単に、プレビュー可能なブロックへ変換できる。
  • ネイティブ機能の統合: `get_block_wrapper_attributes` でWordPress標準のスタイル設定に即座に対応可能。

出典

  • Kinsta Blog「How to build PHP-only Gutenberg blocks」(2026年3月19日)
WordPress 7.0開発最新状況——リアルタイム共同編集とAI連携の標準化が加速

WordPress 7.0開発最新状況——リアルタイム共同編集とAI連携の標準化が加速

WordPress 7.0のリリースサイクルが佳境を迎えている。2026年3月現在、Gutenberg 22.6のリリースによって主要な機能セットが確定し、3月19日にはリリース候補版(RC1)の公開が予定されている。

今回のメジャーアップデートでは、長年待望されていたリアルタイム共同編集(RTC)の基盤実装や、AIサービスとの連携を標準化する「AIコネクター」など、プラットフォームとしての在り方を大きく変える機能が導入される。現在はBeta 3が公開されており、広範囲なテストが呼びかけられている状況だ。

本記事では、WordPress 7.0で導入される主要機能の技術的背景と、開発者が準備すべきポイントについて、最新の動向を基に解説する。

WordPress 7.0の新機軸:リアルタイム共同編集(RTC)の実装

WordPress 7.0の新機軸:リアルタイム共同編集(RTC)の実装

WordPress 7.0における最大の技術的トピックは、リアルタイム共同編集(RTC: Real-time Collaboration)の導入だ。複数のユーザーが同時に同じ投稿を編集できるこの機能は、これまで外部プラグインや特定のホスティング環境に依存していたが、ついにコア機能として組み込まれる。

HTTPポーリングによる高い互換性の確保

RTCの実装において、技術チームは当初検討されていたWebRTCではなく、HTTPポーリングによる同期プロバイダーを選択した。WebRTCはリアルタイム性に優れる一方で、サーバー構成やファイアウォールの設定によっては通信が不安定になる欠点がある。あらゆるホスティング環境での動作を保証するため、あえて汎用性の高いHTTPポーリングが採用された形だ。

データの整合性を保つ仕組みには、CRDT(Conflict-free Replicated Data Type / 衝突のない複製データ型)が採用されている。これは、複数の場所で同時に行われた変更を、矛盾なく統合するための数学的なアルゴリズムだ。更新データは「wp_sync_storage」という内部ポストタイプに保存され、定期的に圧縮・バッチ処理されることで、データベースへの負荷を最小限に抑える工夫がなされている。

拡張性を考慮した同期アーキテクチャ

この同期システムは、トランスポート層(通信手段)とストレージ層(保存先)を差し替え可能な設計になっている。デフォルトでは2名までの同時編集に制限されているが、ホスティング事業者は独自の同期プロバイダーを導入したり、wp-config.phpの設定値を変更したりすることで、より多人数での編集や高度なパフォーマンス最適化を図ることができる。

RTCをデフォルトで有効化するかどうかの最終判断は、RC2(リリース候補版2)前後で行われる予定だ。プラグイン開発者は、既存のメタボックスやカスタムフィールドがこの共同編集モードと競合しないか、事前の検証が求められる。

AI連携の標準化:AIコネクターとプロバイダーパッケージ

AI連携の標準化:AIコネクターとプロバイダーパッケージ

WordPress 7.0では、AIサービスとの通信を標準化するための「コネクター」機能が導入される。これは、特定のAIベンダーに依存せず、共通のインターフェースを通じてAI機能を利用できるようにするインフラストラクチャだ。

php-ai-clientによる共通インターフェースの提供

この機能の核となるのは「php-ai-client」パッケージだ。これは、主要なAIサービスとの通信を抽象化するPHPライブラリである。開発者はこの共通インターフェースに対してコードを書くことで、背後のAIプロバイダー(OpenAI、Google、Anthropicなど)が何であっても、同じように機能を実装できるようになる。

すでにプラグインディレクトリには、OpenAI、Google、Anthropicの各プロバイダーパッケージが公開されている。これにより、ユーザーは管理画面の「コネクター」設定から好みのAIサービスを選択し、APIキーを入力するだけで、サイト全体でAI機能を活用できる環境が整う。

プラットフォームとしてのAI対応

これまでAI機能は各プラグインが個別にAPI連携を実装していたが、コアが認証情報の管理やプロバイダーの選択を担うことで、開発効率とセキュリティが向上する。例えば、コンテンツ生成プラグインとSEO最適化プラグインが、同じAIコネクターの設定を共有するといった運用が可能になる。これは、WordPressが単なるCMSから「AI対応のオペレーティングシステム」へと進化する重要な一歩と言えるだろう。

編集体験の進化:視覚的な変更履歴とコンテンツ専用編集モード

編集体験の進化:視覚的な変更履歴とコンテンツ専用編集モード

ユーザーインターフェース(UI)の面でも、WordPress 7.0は大きな進化を遂げている。特にリビジョン管理とパターン編集の操作性が大幅に改善された。

カラーコードによる直感的なリビジョン管理

新しいリビジョンパネルでは、ドキュメント内の変更箇所が視覚的に強調表示されるようになった。追加されたブロックは緑、削除されたブロックは赤、設定が変更されたブロックは黄色で縁取りされる。テキスト内容についても、下線(追加)や打ち消し線(削除)を用いて、どこがどう変わったのかが一目で判別できる。

この機能はパフォーマンスにも配慮されており、まず変更されたブロックを素早く特定し、その後に詳細なテキスト比較を行う2段階のプロセスを採用している。テーマの色設定に合わせてカラーが自動調整されるため、どのようなデザインの編集画面でも視認性が損なわれない点も特徴だ。

構造を保護するコンテンツ専用編集(Content-Only Mode)

WordPress 7.0から、パターン編集のデフォルトが「コンテンツ専用編集モード」となる。このモードでは、レイアウトやスタイルの設定が隠され、ユーザーはテキストや画像などのコンテンツ入力に集中できる。これにより、誤ってデザインを崩してしまうリスクを低減できる。

構造的な編集が必要な場合は、パターンを「切り離す(Detach)」ことでフルアクセスが可能になる。管理者は、PHPフィルターやJavaScriptを使用して、非同期パターンのコンテンツ専用モードを無効化することも可能だ。制作会社がクライアントにサイトを引き渡す際、運用の安全性を高めるための強力なツールとなるだろう。

開発者向けツールとテーマ機能のアップデート

開発者向けツールとテーマ機能のアップデート

開発ワークフローを支えるツール群や、テーマ開発に役立つ新機能も多数追加されている。特にWP-CLIの強化と、ブロックの表現力向上に注目したい。

WP-CLIの新コマンドとPlaygroundの拡充

WP-CLIチームは、ブロックエンティティへの読み取り専用アクセスを提供する「wp block」コマンドや、権限管理を行う「ability」コマンドの開発を進めている。これらはWP-CLI v3.0の一部として、3月末の安定版リリースに向けて調整中だ。

また、ブラウザ上でWordPressを動作させる「WordPress Playground」のランタイムにおいて、phpMyAdminのサポートが追加された。wp-env.jsonの設定に1行加えるだけで、Docker環境と同等のデータベース管理ツールが利用可能になる。ローカル開発環境の構築がこれまで以上に迅速化される見込みだ。

アイコンブロックとナビゲーションオーバーレイ

テーマ制作において要望の多かった「アイコンブロック」がついに導入される。SVGアイコンをライブラリから選択して配置できる機能で、サーバーサイドの「SVG Icon Registration API」によって制御される。現在は標準のアイコンセットのみだが、将来的にはサードパーティ製のアイコンコレクションを登録できる拡張性も計画されている。

さらに、ナビゲーションブロックのモバイルメニュー(オーバーレイ)が完全にカスタマイズ可能になった。「ナビゲーションオーバーレイ」というテンプレートパーツとして独立したため、モバイル専用のメニューデザインを自由なレイアウトで作成できる。これは、モバイルファーストのデザインが求められる現代のWeb制作において、非常に価値の高いアップデートだ。

セキュリティアップデートと今後のロードマップ

セキュリティアップデートと今後のロードマップ

新機能の開発が進む一方で、既存バージョンのメンテナンスも継続されている。2026年3月10日には、WordPress 6.9.2(および6.9.4までのマイナーアップデート)がリリースされた。これには10件の脆弱性修正が含まれており、中にはSSRF(サーバーサイドリクエストフォージェリ)やXSS(クロスサイトスクリプティング)といった重要度の高いものも含まれる。

開発チームは、すべてのユーザーに対して直ちにこれらのマイナーアップデートを適用するよう強く推奨している。セキュリティはサイト運営の根幹であり、新機能のテストを行う際も、まずは基盤となる環境の安全性を確保することが先決だ。

WordPress 7.0の正式リリースは4月に予定されている。RTCやAIコネクターといった野心的な機能が安定して動作するか、RC版での検証結果が待たれるところだ。開発者は、自身のプラグインやテーマがこれらの新機能とどのように相互作用するかを確認し、必要に応じてコードの修正を進めるべきだろう。

この記事のポイント

  • リアルタイム共同編集(RTC): HTTPポーリングとCRDTを採用し、あらゆるホスティング環境で安全な同時編集を可能にする。
  • AIコネクターの標準化: 共通インターフェースを通じて主要AIサービスと連携。ベンダーに依存しないAI機能の実装が可能になる。
  • 視覚的なリビジョン管理: 変更箇所をカラーコードで強調表示。直感的な変更履歴の追跡が可能になり、編集ミスを防ぐ。
  • テーマ・開発ツールの強化: アイコンブロックの導入やナビゲーションオーバーレイの刷新、WP-CLIの新コマンドにより開発効率が向上する。
  • セキュリティの重要性: 6.9.x系の脆弱性修正が公開されており、7.0への移行準備と並行して既存サイトの即時アップデートが必要だ。

出典

  • Developer WordPress News「What’s new for developers? (March 2026)」(2026年3月10日)
  • WordPress.org「WordPress 7.0 Beta 3」(2026年3月5日)
  • Make WordPress Core「Real-Time Collaboration in the Block Editor」(2026年3月10日)
WP Rigで始めるWordPressテーマ開発——現代的なワークフローと学習環境

WP Rigで始めるWordPressテーマ開発——現代的なワークフローと学習環境

WP Rigは無料のWordPressテーマ開発ツールキットだ。スターターテーマとしての機能に加え、ComposerやNode.jsを統合した現代的な開発環境を提供する。2026年3月時点でバージョン3が公開されており、従来のクラシックテーマからブロックベースのテーマ、ハイブリッドなアプローチまで幅広く対応している。

プロジェクトの現在の管理者はRob Ruiz氏である。氏は2026年3月4日に公開されたWP Tavernのポッドキャストで、WP Rigの現状と将来像について語った。このツールキットは、テーマ開発の学習からプロダクション環境での利用まで、多様なユーザー層をサポートすることを目指している。

WordPressのエコシステムがブロックエディタとフルサイト編集(FSE)へと移行する中で、テーマ開発の在り方も変化している。WP Rigはこうした変化に対応し、開発者が最新のベストプラクティスを学びながら実践できる環境を整備した。

WP Rigとは何か——スターターテーマと開発ツールキット

WP Rigとは何か——スターターテーマと開発ツールキット

WP Rigは「スターターテーマ」と「開発ツールキット」の両方の性格を持つ。Underscoresのような最小限のテーマ基盤を提供する一方で、現代的なフロントエンド開発に必要なツール群をあらかじめ統合している点が特徴だ。

コアとなる機能と統合ツール

WP Rigのプロジェクトをクローンすると、Node.jsとComposerの依存関係が自動的に解決される。これにより、開発者はすぐにコーディング作業に取りかかれる。統合されている主なツールは以下の通りだ。

  • CSS処理: Lightning CSS(旧PostCSS)による最新CSS機能の先行利用とブラウザ互換コードへの変換
  • JavaScript処理: esbuildによるTypeScriptのトランスパイルとバンドル
  • コード品質: PHPCS(PHP Coding Standards)とWordPressコーディング標準(WPCS)に基づく自動チェック
  • 開発サーバー: ファイル変更の監視と自動ビルド

これらのツールは、開発者が個別に設定する必要がなく、WP Rigの設定ファイルを介して一元的に管理される。これにより、開発環境の構築にかかる時間を大幅に短縮できる。

従来のスターターテーマとの違い

従来のスターターテーマは、主にテンプレートファイルのひな形を提供することに焦点が当てられていた。一方、WP Rigは開発「プロセス」そのものを標準化することを目指している。コードの書き方からビルド、品質チェックまで、一連のワークフローをツールが支援する。

Rob Ruiz氏はポッドキャストで、このアプローチについて次のように説明している。「WP Rigは単なるファイルの集合ではない。ベストプラクティスを学び、適用するためのガードレールを提供するものだ」。特にチーム開発では、この標準化されたワークフローがコードの一貫性を保ち、レビュー工数を削減する効果がある。

誰のためのツールか——学習者からプロフェッショナルまで

誰のためのツールか——学習者からプロフェッショナルまで

WP Rigの対象ユーザーは幅広い。WordPress管理画面でのサイト構築に慣れたユーザーが、次のステップとしてコードベースのカスタマイズに挑戦する場合にも適している。一方、経験豊富な開発者が新規プロジェクトを効率的に立ち上げるためにも利用できる。

ページビルダーユーザーからの移行

ページビルダーやブロックエディタによるビジュアル編集には限界がある。デザインの細かい調整や、最新のCSS機能をすぐに利用したい場合、コードを直接編集する方が柔軟性が高い。WP Rigは、こうしたユーザーがローカル開発環境を整え、段階的にテーマ開発を学ぶための足がかりとなる。

Ruiz氏はポッドキャストで、コードによる制御の利点を強調した。「データベースに保存された設定値を一つずつ変更するのではなく、CSSファイルを一行修正するだけでサイト全体の見た目を変えられる。これがコードの持つ『超能力』だ」。WP Rigは、この「超能力」を安全に習得するための学習環境を提供する。

エージェンシーとチーム開発での活用

カスタムテーマをクライアントに提供するWeb制作会社では、開発プロセスの標準化が重要だ。WP Rigをプロジェクトの基盤とすることで、複数の開発者が同じコーディング規約とビルドプロセスを共有できる。新規メンバーのオンボーディングも容易になる。

また、WP Rigにはテーマの「バンドル」機能が備わっている。開発が完了したテーマを配布用にパッケージ化する際、すべてのソースコード内の「WP Rig」という文字列がテーマ名に置換される。これにより、エンドユーザーが基盤技術を意識することなく、完成したテーマを利用できる。

開発環境の構築とワークフロー

開発環境の構築とワークフロー

WP Rigを利用するには、ローカルマシンに特定のソフトウェアをインストールする必要がある。リモートサーバーではなく、ローカル環境でテーマ開発を行うのが基本だ。

必要な事前準備

WP Rigを動作させるための最小限の環境は以下の通りだ。

  • Node.js: JavaScriptの実行環境。バージョン管理ツール(nvmやfnm)でのインストールが推奨される。
  • Composer: PHPの依存関係管理ツール。グローバルにインストールする。
  • ローカル開発環境: Local WP、WordPress Studio、Dockerベースのwp-envなど、任意の環境を選択可能。

これらのツールをインストールした後、WP RigのGitHubリポジトリをクローンし、依存関係をインストールする。プロジェクトルートでnpm installcomposer installを実行すれば、開発環境の準備は完了だ。

開発からバンドルまでの流れ

WP Rigを使った典型的な開発ワークフローは以下のステップで構成される。

  • 1. 開発サーバーの起動: npm startでファイル監視と自動ビルドが開始される。
  • 2. コーディング: CSS、JavaScript、PHPファイルを編集する。変更は自動的に反映される。
  • 3. コードチェック: npm run lintでPHPとJavaScriptのコード品質を検証できる。
  • 4. ビルド: npm run buildで本番用の最適化されたアセットを生成する。
  • 5. バンドル: npm run bundleで配布用のテーマパッケージを作成する。

このワークフローの中で、開発者は複雑なビルド設定を意識する必要がない。ツールの更新が必要な場合も、WP Rigのバージョンアップに追随するだけで済む。

ブロックエディタ時代のテーマ開発

ブロックエディタ時代のテーマ開発

WordPressのフルサイト編集(FSE)とブロックベースのテーマが普及する中で、クラシックなテーマ開発の価値が問われている。WP Rigはこの変化を先取りし、複数の開発パラダイムをサポートするように進化した。

3つのテーマパラダイムへの対応

WP Rigは、一つのコードベースから以下の3種類のテーマを生成できる。

  • クラシックテーマ: 従来通りのPHPテンプレートファイルを使用する。
  • ユニバーサルテーマ: クラシックテーマとブロックテーマの機能を併用する。
  • ブロックテーマ: HTMLテンプレートファイルとtheme.jsonで構成される。

プロジェクトの初期化後、コマンドラインからnpm run configureを実行すると、対話形式でテーマの種類を選択できる。選択に応じて、必要なファイルが自動的に生成または変換される。

テーマレベルでのブロック開発

WP Rigの特徴的な機能の一つが、テーマ内でのカスタムブロック開発をサポートしている点だ。通常、カスタムブロックはプラグインとして開発されるが、テーマに密接に関連するブロック(例: 特化したナビゲーションブロック)をテーマ内に実装できる。

ただし、この方法で開発したテーマをWordPress.orgの公式テーマリポジトリに投稿することはできない。リポジトリのガイドラインでは、ブロックの提供はプラグインに限定されているためだ。クライアントワークや自社サイトでの利用が主な用途となる。

Ruiz氏はこの機能について、「境界線を曖昧にすることを厭わない」と表現した。テーマとプラグインの役割分担に縛られず、プロジェクトの要件に最適な技術的選択を可能にする姿勢が反映されている。

教育資源としてのWP Rig

教育資源としてのWP Rig

WP Rigの公式サイト(wprig.io)には、ツールの使い方だけでなく、WordPressテーマ開発そのものを学ぶための資源が豊富に用意されている。これはプロジェクトの重要な側面だ。

学習コンテンツの構成

サイトの「Learn」セクションには、以下のような教育資源が整理されている。

  • ビデオチュートリアル: YouTubeチャンネルで基礎から応用までを解説
  • 技術文書: CSS、JavaScript、PHPの各言語におけるベストプラクティス
  • サンプルコード: 実際のユースケースに基づいた実装例
  • 開発ガイド: ローカル環境構築からデプロイまでの手順

これらの資源は、単にWP Rigの使い方を教えるだけでなく、現代的なWeb開発の概念そのものを伝えることを目的としている。例えば、CSSのカスケードや詳細度、PHPの名前空間といった基礎概念も丁寧に説明されている。

コミュニティと貢献の機会

WP Rigはオープンソースプロジェクトであり、GitHub上で開発が進められている。バグ報告や機能提案はIssuesを通じて受け付けている。また、Discordサーバーでは開発者同士の交流が行われている。

Ruiz氏はポッドキャストで、コミュニティの重要性を強調した。「WordPress自体がコントリビューターに依存している。テーマ開発を学ぶ人が増え、やがてコアへの貢献者になる——そんな好循環を生み出したい」。WP Rigは、その入り口となることを目指している。

この記事のポイント

  • WP Rigはテーマ開発のスターターキットであり、現代的な開発ツールを統合している。
  • ローカル環境での開発を前提とし、Node.jsとComposerが必要だ。
  • クラシック、ユニバーサル、ブロックテーマの3パラダイムに対応する。
  • コード品質チェックや自動ビルドなど、チーム開発での標準化を支援する。
  • 教育資源が豊富で、テーマ開発の学習環境としても機能する。

出典

  • WP Tavern「#207 – Rob Ruiz on WP Rig and the Future of Theme Development」(2026年3月4日)