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

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日)