WordPress.org

ニュース

WordPress 6.9 テストガイド

WordPress 6.9 テストガイド


以下は WordPress.org 公式ブログの記事「Help Test WordPress 6.9」の翻訳です。

誤字脱字誤訳などありましたらフォーラムまでお知らせください


📅 カレンダーに赤丸を ! WordPress 6.9は2025年12月2日にリリース予定です。2025年最後のメジャーリリースとなり、サイト編集の重要な改善、新しい開発者ツール、パフォーマンスの最適化を実現し、WordPress をより強力で、使って楽しいものにすることを目標にしています。

なぜ早期のテストが必要なのでしょう ? バグが早く見つかれば、それだけ何百万人ものユーザーのアップグレードがスムーズになるからです。5分のテストでも、午後の時間を丸々費やしたテストでも、ベータ版や RC 版でのテストは直接、リリースに影響を与えます。すべての報告がリリース前の磨き上げに役立ち、すべての貢献が品質を向上します !

💪 WordPress 6.9を一緒に作りましょう !

WordPress 6.9リリーススケジュールでマイルストーンの最新情報を確認できます。リアルタイムのアップデートやディスカッションについては、#core-test Slack チャンネルに参加してください。毎週開催のチームミーティングやテストスクラブに参加して、テストコミュニティに参加しましょう。

リリースの目標: WordPress 6.9では、より直感的なテンプレート管理、ノート (以前は「ブロックレベルコメント」「インラインコメント」と呼ばれていました) による共同コンテンツ作成の実現、新しいブロック、Interactivity API の更新と Abilities API の導入による開発者機能の拡張、ページ遷移の高速化、よりスマートなリソースハンドリングによるパフォーマンスの改善などに焦点を当てています。

📝 注意: WordPress 6.9には新しいデフォルトテーマはありません。これはリリースのペースと、ここ数年のブロックテーマの成熟度合いによって決定されました。

テストのコツ

WordPress では、テストに貢献するために認定ソフトウエアテスターやプロの品質保証技術者である必要はありません。普段のように WordPress を自分のニーズに合わせて使うだけです。何か問題が発生したり、期待通りに動作していないと感じたら是非、報告してください。

でも、期待される動作がわからない ? ご心配ありません ! WordPress Slack で会話に参加するか、Trac でチケットを作成してください。親切な WordPress のグローバル・コミュニティが、いつでもお手伝いします。

WordPress のベータ版 / RC 版をテストするための推奨事項

  • あなたにとって重要なコア機能をテストする: サイトを作成した目的に沿って使ってみてください。例えば、あなたがブロガー、ソーシャルプラットフォームの運営者、eコマースストアの管理者であれば、ステージングサイトを立ち上げてください (ステージングサイトについてよくわからない場合は、ホスティングプロバイダーに尋ねてください)。そして、ステージング環境で WordPress をアップデートし、いつものようにサイトを使い続けます。これで通常のワークフローに影響する問題を特定できます。アップデート後に発生した問題やトラブルもメモしておきましょう。

🚫 本番環境でテスト用ベータ版やRC 版をテスト、更新しないでください。

  • 以下のセクションで記述されている一般的なチェックリストを使用して、アップデート後にすべてが期待通りに機能することを確認してください。✅

ベータ版のテスト方法

WordPress の開発版またはベータ版をテストする方法にはいくつかあります。以下で説明する方法の中に正解も不正解もありません。自分にとって最も使いやすい、または便利な方法を自由に選んでください。

Playground

Playground を使用すると環境を構築することなく、WordPress のベータ版やリリース版を最も簡単かつ迅速にテストできます。

  • WordPress 6.9 リリース候補版3 (RC3) の Playground
    最新のベータ版の情報は https://wordpress.org/news/ に掲載され、その中に Playground へのリンクも紹介されています。
    日本語に切り替えるには、右上の歯車状のアイコンをクリックして「Playground Settings」を開き、「Language」で「Japanese」を選択し、「Apply Settings & Reset Playground」をクリックします。

ローカル環境

Localwp-env などのソフトウェアを使って、ローカル環境に WordPress サイトを作成できます。サイトの準備ができたら、 Beta Tester plugin をインストールして、WordPress のベータ版に切り替えてください。

セットアップ手順:

  1. Local をダウンロードしてインストールします。
  2. 新しい WordPress サイトを作成します。
  3. サイトが起動したら、WordPress Beta Tester プラグインを使用して、WordPress の開発版またはベータ版に切り替えます。このプラグインを使うと、WordPress のプレリリース版を簡単にインストールできます。
    使用方法:
    1. WordPress Beta Tester プラグインをインストールして有効化します。
    2. ツール > Beta Testing に移動します。
    3. テストしたい内容に応じて、Bleeding Edge または Point release with Nightlies オプションを選択します。
    4. 変更を保存 をクリックします。
    5. 変更が保存されると、更新通知が表示されます。WordPress のバージョンを更新してください。

詳細な手順については、こちらのガイドをご覧ください。

WP-CLI 経由

コマンドラインツールを使いたい場合は、WP-CLI を使用して WordPress のベータ版を手軽にインストールできます。

手順 :

  1. 任意の方法でローカル環境に WordPress サイトを作成します。
  2. サイトのセットアップが完了したら、ターミナルを開き、WordPress のインストールディレクトリのルートに移動します。
  3. 次のコマンドを実行して、最新のベータ版に更新します:

wp core update --version=6.9-beta1 または wp core update --version=6.9-RC1

(必要に応じてバージョン番号を更新してください。)

この方法の利点は、異なるバージョン間をすばやく切り替えられるため、特定のビルドをより簡単にテストできることです。

ステージングサイトの使用

本番サイトのステージングサイトを作成し、WordPress のベータ版またはリリース候補版 (RC) に更新します。

これにより、本番サイトに影響を与えることなく、新しいバージョンを安全にテストできます。

すべてが期待どおりに動作することを確認してから、本番環境に更新を適用してください。

パッチのテスト

パッチをテストするには、ローカルで WordPress の開発バージョンをセットアップする手順に従ってください。

Playground の利用 – Playground を使えば、システムにソフトウェアをインストールしなくても簡単に個別の Core チケットをテストでき、どんな PR でも最も速くテストできます。

wordpress-develop または gutenberg リポジトリに特定の PR があり、ブラウザでその PR をテストしたい場合、以下のリンクを利用できます。PR 番号を入力するだけで、あとは自動で処理されます。

WordPress PR プレビューア。PR 番号または URL を入力してテストできます。詳細は「Powered by WordPress Playground」のリンクに記載されています。リポジトリ用に同様のプレビューアを構築したい場合は、GitHub のコードやドキュメントページを参照してください。

Gutenberg PR プレビューア。こちらも PR 番号または URL でブラウザ上ですぐにテストできます。同様に「Powered by WordPress Playground」にリンクがあり、他のリポジトリでも GitHub のコードやドキュメンテーションの参照が可能です。

一般的なテストのチェックリスト

更新された WordPress バージョンとサイトの互換性を素早くテストしたい場合は、以下の重要なチェック項目を確認してください。wp-config.php でデバッグ を有効にして、警告、エラー、または通知をキャプチャしてください。

  1. テーマとプラグインを最新バージョンに更新してください。
  2. テストしたいベータ版 / RC 版 / ナイトビルドに切り替えてください。
  3. サイトヘルスをチェックして、新しいエラーや警告がないことを確認してください。
  4. レイアウトの崩れや要素の配置ズレがないことを確認してください。
  5. リンクとパーマリンクをテストして、404エラーがないことを確認してください。
  6. 投稿、画像、メディアが正しく表示されることを確認してください。
  7. サイトマップと robots.txt ファイルが正常に機能していることを確認してください。
  8. 管理ダッシュボードにエラーなしで完全にアクセスできることを確認してください。
  9. サイトにカスタムブロックがある場合は、新しいブロックでコンテンツを作成し、既存のコンテンツを編集してください。
  10. 新しい投稿を作成してください:
    1. コンテンツを追加
    2. 異なるブラウザでの表示を確認
    3. レスポンシブモードでの表示を確認
    4. ブラウザやデバイスの種類に関係なく、機能部分が期待通りに動作することを確認
  11. 新しいページを作成してください:
    1. コンテンツを追加
    2. 異なるブラウザでの表示を確認
    3. レスポンシブモードでの表示を確認
    4. ブラウザやデバイスの種類に関係なく、機能部分が期待通りに動作することを確認
  12. ブラウザの開発者コンソールを開いた状態で動かし、エラー、警告、通知がないかチェックしてください。
  13. エラーログファイルを開いて、通知、警告、致命的なエラーをチェックしてください。
  14. ユーザーの権限グループと許可がこれまでどおり設定されていることを確認してください。
  15. 予約投稿や自動化されたタスク (バックアップなど) が意図した通りに機能することを確認してください。
  16. 統合されたすべてのサービス (支払いゲートウェイや分析ツールなど) が動作していることを確認してください。
  17. 異なるブラウザでサイトを開き、すべての機能が期待通りに動作することを確認してください。

👀 テスト中に注意すべきこと

  • すべてが直感的で使いやすかったですか ?
  • 遅い読み込みやラグなどのパフォーマンスの問題はありましたか ?
  • 異なるブラウザやデバイス間で視覚的な不整合やレイアウトの問題はありましたか ?
  • ドラッグアンドドロップ機能は期待通りに動作しましたか、特にパターンにおいて ?
  • プレビューモードは、公開後にコンテンツがどのように表示されるかを正確に反映していましたか ?
  • エディターで作成したものと、サイトで見たものは一致していましたか ?
  • アクセシビリティの問題はありましたか ? 例えば、
    • 色のコントラストやフォーカス管理は適切でしたか ?
    • キーボードのみを使用して適切に動作しましたか ?
    • スクリーンリーダーで動作しましたか ?
  • モバイルデバイスでスムーズに機能しましたか ?
  • 体験のどの側面が混乱させるものや苛立たしいものでしたか ?
  • 特に楽しんだり、感謝したりしたものは何でしたか ?
  • サイト構築とコンテンツ作成を簡単にするために、何があれば良かったでしょうか ?

主要な機能のテスト

ノート

ノート機能 (以前の「ブロックレベルコメント」「インラインコメント」) は、エディター内の個々のブロックに直接フィードバックを添付できる機能です。 Gutenberg 19.6で実験的に導入されましたが、現在ではインジケーター、スレッド管理用のサイドバー、公開済み投稿のサポートが加わり、ユーザビリティとアクセシビリティのために継続的な改良が加えられています。

🌟ボーナスポイント: Aki (濱野さん) がブロックの「Notes Data Generator」というプラグインを作成しました。このプラグインを使用すると、テスト用のユーザーとブロックコメントを追加し、簡単にノート機能をテストできます。

テスト手順

  1. ダッシュボードに移動します。
  2. 固定ページ、または投稿を開きます。
  3. 任意のブロックを挿入します。
  4. ブロックツールバーからブロック設定ドロップダウンをクリックします。
  5. ツールバー設定から「ノートを追加」をクリックし、ノートモーダルがサイドバーに開くことを確認します。
  6. ノートを追加します。
  7. ノートが正常に追加されたことを確認します。
  8. 追加のシナリオを検証します
    1. 空のブロック上のノート: 空のブロックにはノートを追加できません。
    2. ノートの編集と削除:
      • 既存のノートを編集し、変更が保存され、正しく表示されることを確認します。
      • ノートを削除し、サイドバーとブロックインジケーターから削除されることを確認します。
    3. ノートの解決と再開:
      • ノートを解決:ノートを解決済みとしてマークし、解決済み状態が表示されることを確認します。
      • 解決済みノートを再開し (オプションがある場合)、正しく復元されることを確認します。
    4. スレッド化されたノート: 既存ノートに返信を追加し、スレッド化が正常に機能することを確認します。
    5. インジケーターの可視性: コメントがあるブロックにのみノートインジケーターが表示されることを確認します。
    6. ブロックの切り替え: ノートのないブロックにフォーカスを移動し、サイドバーが適切に更新されることを確認します。
    7. 投稿の保存: 投稿を保存または更新し、再読み込み後もすべてのノートが保持されることを確認します。
    8. 公開済み投稿: 投稿を公開し、ノートが引き続きアクセス可能であることを確認します。
    9. アクセシビリティ: キーボードとスクリーンリーダーで操作し、ノートサイドバーとインジケーターが利用可能であることを検証します。

テストの様子

テスト中に問題や予期せぬ動作が発生した場合は、こちらに記録してください。詳細は #66377 を参照してください。

ブロックの非表示機能

WordPress 6.9では、サイト公開時に個々のブロックを非表示にしながら、エディター内では編集可能な状態を維持するオプションが導入されました。これにより、コンテンツやレイアウトの準備時に作成者の柔軟性が向上します。例えば、代替デザインのテスト、将来のセクションのためのスペースの確保、未完成のコンテンツの一時保全などが可能です。

ブロックの削除や除去とは異なり、非表示化は破壊しない操作です。ブロックはそのまま残され、いつでも編集可能で、必要に応じて即座に再表示できます。このアプローチにより、コンテンツ編集の安全性が向上し、共同作業ワークフローに適した環境が整います。

テスト手順

  1. 投稿、固定ページ、またはテンプレートに移動します。
  2. ブロックを選択し、ツールバー設定から「非表示」コントロールをクリックします。
  3. ブロックが表示されなくなり、「表示」コントロールがオンになっていることを確認します。
  4. フロントエンドを確認すると、ブロックが非表示になっているはずです。
  5. 次に、非表示設定をオフにします。
  6. ブロックがエディターとフロントエンドに再表示されます。
  7. ネストしたブロック: グループ、またはカラムブロック内に複数のブロックを配置し、親ブロックを非表示にします。
    1. すべての内部ブロックが非表示になっていることを確認してください。
  8. 複数インスタンス: ページ内の異なるブロックを非表示にし、選択したブロックのみがフロントエンドから除外されていることを確認します。

テストの様子

詳細については #71203 PR を参照してください。関連する問題を発見した場合は、こちらで報告してください。

📈 パフォーマンス / アセットチェック

非表示ブロックはフロントエンドに表示されてはならず、関連するCSS / JSも積極的に使用されるべきではありません。オプションとして、開発者ツールの「ネットワーク」タブまたは「CSSカバレッジ」でこれを確認してください。表示ブロックはこれまで通り読み込まれなければなりません。小さなページではカバレッジの差異が微妙な場合もありますが、重要な点は非表示ブロックがフロントエンドのマークアップやアセットを追加しないことです。詳細は #9213 PR を参照してください。同様に確認を行いたい場合は、このコメントの手順に従ってください。

allowedBlocks サポートとユーザーインターフェース

この機能強化により、ユーザーはグループブロック内に挿入可能な子ブロックを視覚的に制御できるようになりました。これは従来、コード経由でのみ可能でした。この更新により、ブロックインスペクターの「詳細」パネルに「許可ブロックの管理」オプションが追加され、モーダルインターフェースを通じてブロックタイプの有効化、無効化が可能になりました。コンテンツ管理は効率化され、意図しないブロックの挿入が防止されるほか、他のコンテナブロックでの広範な利用に向けた基盤が整いました。

テスト手順

  1. ダッシュボードに移動します。
  2. 投稿または固定ページを開きます。
  3. グループブロックを挿入します。
  4. グループブロックを選択した状態で、ブロックインスペクターを開きます。
  5. グループブロックの「詳細」パネルを展開します。
  6. 「許可されたブロックの管理」ボタンを探します。
  7. クリックします。さまざまな種類のブロックがリストされた新しいモーダルが表示されることを確認してください。
  8. そのモーダル内で:
    • ブロックを検索できることを確認します。
    • 一部のブロックの選択を解除します (例: 「段落」、「画像」を無効化)。
    • 適用ボタンをクリックするとモーダルが閉じます。
  9. 次に、グループブロックのコンテナ領域内で子ブロックを挿入します:
    • 許可されているブロックはインサーター内に表示され、正常に挿入できます。
    • 許可されないブロックはインサーターに表示されません。

テストの様子

関連する問題を発見した場合は、こちらからお気軽にご報告ください。

どこでもコマンドパレット

WordPress 6.9では拡張コマンドパレットが導入されました。エディターとダッシュボードの両方で利用可能です。これでサイトの異なる領域に素早く移動して操作を実行する汎用的な方法が提供されました。サイドバーメニューの実行や複数回のクリックは必要ありません。コマンドパレットに入力するだけで、検索、特定の画面への移動、アクションの直接実行が可能です。

コマンドパレットはデフォルトで有効化されているため、追加の設定は不要です。

テスト手順

  1. ダッシュボードに移動します。
  2. コマンドパレットを開きます。
    • キーボードショートカットを使用してみてください (Mac: Cmd + K / Windows: Ctrl + K)。
    • どの画面 (ダッシュボード、投稿、ページ、サイトエディタ、テンプレートなど) からでも開くことを確認します。

さまざまな使用例

  1. ナビゲーション先の検索
    • 「Posts / 投稿」「Pages / ページ」「Plugins / プラグイン」「Templates / テンプレート」などと入力します。
    • 該当のエリアへ直接移動できることを確認します。
  2. アクションの実行
    • 「Add new post / 新規投稿を追加」「Add new page / 新規ページを追加」「Editor / エディター」などのコマンドを入力します。
    • サイドバー経由せずにアクションが実行されることを確認します。
  3. コンテキストの認識
    • サイトエディターから: テンプレート編集に関連するコマンドを確認します。
    • 投稿編集画面から: 「Preview in new tab / 新しいタブでプレビュー」などのコマンドを確認します。
    • コンテキストに応じて結果が変わることを確認します。
  4. 権限グループと許可
    • コマンドパレットが WordPress の権限 / 許可フィルタリングを尊重し、管理者専用コマンドが、編集者やその他の権限グループの検索結果に表示されないことを確認します。
  5. UI とユーザビリティ
    • コマンドパレットがレスポンシブであり、他の WordPress UI と視覚的に一貫していることを確認します。

テストの様子

関連する問題を発見した場合は、こちらからお気軽にご報告ください。

コンテンツ作成の改善

ドラッグ & ドロップ – ドラッグチップではなくブロック自体を移動

この改善により、「ドラッグチップ (ゴーストプレースホルダー)」の代わりに、ドラッグ中に実際のブロックが直接移動するようになりました。ドラッグ中はブロックがわずかに縮小され (スケールダウン) 、カーソルとともにスムーズに移動し、アニメーションが付与されることで、より滑らかで直感的なビジュアル体験を実現します。

テスト手順

  1. ダッシュボードに移動します。
  2. 投稿または固定ページを開きます。
  3. 段落、見出し、画像、引用ブロックなどを組み合わせて追加します。
  4. ブロックのドラッグハンドルを使用して、エディターキャンバス内の新しい位置にドラッグします。
  5. ブロックを別の位置にドロップします。
  6. 確認事項 :
    1. ブロックがアニメーションとともにスムーズに移動すること。
    2. ドラッグ中にブロックがわずかに縮小されること。
    3. 視覚的スタイルとアニメーションが維持されること。
    4. フリッカーやジャンプのような動作がないこと。
  7. ブロック移動後に元に戻す / やり直し機能が正常に動作すること。
  8. ネストされたブロックでもドラッグがスムーズに機能すること。

テストの様子

この改善の目的は、より自然で正確、かつモダンなドラッグ & ドロップ体験を提供し、全体的な操作性を向上させ、編集フローを改善する WordPress の努力に沿うことにあります。詳細については PR #67470 を参照してください。ブロックのドラッグ中にビジュアルの乱れ、ずれ、または予期しない動作を発見した場合は、再現手順とともにこちらへ報告してください。

新しいブロック

デザインの可能性を広げ、カスタマイズ性を強化するために、WordPress 6.9 ではアコーディオンブロック、タームクエリーブロック、テキストの伸縮、数式ブロック など新しいブロックが複数追加されました。これらの追加により、ユーザーはサードパーティプラグインに依存せず、より表現豊かで柔軟なサイト構築が可能になります。

アコーディオンブロック

アコーディオンブロックは、コンテンツを折りたたみ可能なセクションに整理でき、FAQ、リスト、グループ化した情報をコンパクトに表示するのに便利です。

アコーディオンブロックを追加すると、デフォルトで2つのアコーディオン項目が生成されます。各項目にはアコーディオン見出しアコーディオンパネルが含まれ、任意のブロックを挿入できます。ユーザーは項目の追加、削除、並べ替え、スタイル設定が可能で、コンテンツ内に異なるブロックをネストできます。フロントエンドでは、項目を展開または折りたたんでインタラクティブな表示を実現します。

テスト手順

  1. 投稿または固定ページに移動します。
  2. アコーディオンブロックを挿入します。
  3. アコーディオン項目アコーディオン見出しアコーディオンパネルと共に追加されることを確認します。
  4. アコーディオンパネル内の項目プレースホルダーを編集し、コンテンツを追加します。
  5. 保存し、項目が期待通りに展開、折り畳まれることを確認します。
  6. 並べ替えの確認
    • アコーディオン項目を上下に移動します。
    • 編集画面とフロントエンドの両方で順序が正しく更新されることを確認します。
  7. スタイリングと設定
    • ブロックレベルのスタイル設定 (色、タイポグラフィ、背景など) を適用します。
    • スタイルが全アイテムに一貫して反映されることを確認します。
  8. アコーディオンブロックの複製を検証します。
  9. 既存のアイテムを削除し、ブロックが期待通りに機能し続けることを確認します。

テストの様子


関連する問題が発生した場合は、こちらまでご報告ください。

タームクエリーブロック

この新しいタームクエリーブロックはクエリーブロックに似ていますが、投稿ではなくタームを対象とします。新しいタームテンプレートブロックを含むように設計されていて、これは各タームを表示するための、タームデータを含む内部ブロックを保持します。シンプルなタームリストブロックとは異なり、高度なレイアウト、ネストしたコンテンツ、動的なタームレンダリングが可能です。

ターム名ブロック

このブロックは主にタームクエリブロック内で使用され、ターム名を表示します。レイアウトの柔軟性を高め、タームへのリンク追加オプションもあります。

ターム数ブロック

このブロックは主にタームクエリブロック内で使用され、ターム数を表示します。

テスト手順

  1. ダッシュボードに移動します。
  2. テンプレートにタームクエリブロックを挿入します。
  3. ターム名とターム数がデフォルトで追加されていることを確認します。
  4. インスペクターコントロールが正しくレンダリングされることを確認します。
  5. 異なるタクソノミー選択を設定します (例: カテゴリー、タグ、カスタムタクソノミー)。
  6. タームクエリ
    1. 「ターム名をリンクにする」設定があり、期待通りに動作することを確認します。
  7. ターム数
    1. 正しいターム数が表示されることを確認します。
    2. 括弧の種類を変更できることを確認します。
    3. カウントと括弧の種類がエディターとフロントエンドに表示されることを確認します。
  8. ブロックを含むテンプレートが正常に保存できることを確認します。
  9. 追加シナリオを検証し、期待通りに動作することを確認します。
    1. ネストしたレイアウトをテストします。
    2. 空のタームのトグルをテストします。
    3. ターム名とタームカウントの両方の異なるスタイリングオプションをテストします。

テストの様子

関連する問題が発生した場合は、こちらまでご報告ください。

数式ブロックとインライン数式書式

WordPress 6.9では、新しい数式ブロックとインライン数式書式によるネイティブ数式がサポートされます。この機能により、ユーザーは独立したブロックとして、またはテキスト内に埋め込む形で、アクセシブルな数式を追加できます。数式はアクセシビリティと互換性を高めるため MathML 形式で保存され、編集しやすいよう元の LaTeX 入力も保持されます。サードパーティ製プラグインを使わなくても、教育コンテンツや技術文書向けの組み込みソリューションが提供されます。エディターのバンドルサイズはわずかに増加しますが、数式を扱う作成者にとって柔軟性とアクセシビリティが大幅に向上します。

テスト手順

  1. ダッシュボードに移動します。
  2. 固定ページ、または投稿を開きます。
  3. 新しい数式ブロックを追加します。
  4. LaTeX 形式の式「\frac{d}{dx}(x^3 + 2x^2 - 5x + 7)」を入力し、ブロックの外側をクリックします。
  5. 確認: エディターが式を整形した数式として表示するはずです。また、フロントエンドでも数式が正しく表示されます。
  6. 式を新しいものに編集し、エディターとフロントエンドの両方で正しく表示されることを確認します。
  7. インライン数式リッチテキスト形式の確認
    1. 同じ投稿に段落ブロックを挿入します。
    2. 「オイラーの恒等式」と入力し、インライン数式形式を適用します(フォーマットツールバーからインライン数式オプションを選択)。次に「e^{i\pi} + 1 = 0」と入力します。
  8. 外側をクリックして、文中のインラインレンダリングを確認します。
  9. 保存し、フロントエンドでプレビューします。インライン数式が周囲のテキストフローを崩さずにインライン表示されることを確認します。

テストの様子

テスト中に問題を発見した場合は、こちらまでご報告ください。

段落ブロックと見出しブロックの「テキストを合わせる」オプション

段落ブロックと見出しブロックに「テキストを合わせる」機能が追加され、テキストがコンテナ内に動的に拡大縮小して収まるようになりました。これにより目を引く見出しやスタイリッシュな段落を柔軟に作成できます。手動でフォントサイズを調整する必要はありません。

訳注: ベータ中に不具合が見つかったため、この機能は削除されました。代わりにブロックのバリエーションが提供されています。

テスト手順

  1. ダッシュボードに移動します。
  2. 固定ページ、または投稿を開きます。
  3. 段落ブロックを挿入します。
  4. インスペクター設定から「タイポグラフィ」パネルをタップします。
  5. 「テキストを合わせる」トグルまたはコントロールが利用可能であることを確認します。
  6. 「テキストを合わせる」を有効にし、ブロック内にテキストを追加します。
  7. テキストがコンテナの有効な幅に合わせて自動的にサイズ変更されることを確認します。
  8. ブラウザウィンドウのサイズを変更するか、ブロックの幅を調整し、テキストが動的に対応し続けることを確認します。
  9. 見出しブロックで同じ手順を繰り返し、同様の動作を確認します。
  10. フロントエンドでテキストのスケーリングが正しく維持されることも確認します。

テストの様子

テスト中に問題を発見した場合は、こちらまでご報告ください。

所要時間ブロック

所要時間ブロックは Gutenberg 15.3リリースで初めて導入され、現在は安定版となりました。所要時間ブロックはエディターとフロントエンドの両方で予測可能な動作を保証し、投稿や固定ページに対して信頼性の高い推定所要時間を提供します。

テスト手順

  1. ダッシュボードに移動します。
  2. 新しい固定ページ、または投稿を追加します。
  3. 所要時間ブロックを挿入します。
  4. デフォルトで時間が範囲表示されることを確認します。
  5. サイドバーの設定を使用して、時間ブロックと文字数ブロックを切り替えられることを確認します。
  6. 投稿をプレビューまたは公開します。
  7. フロントエンドに同じ値が表示されることを確認します。
  8. 編集時の更新確認:
    1. 段落を追加または削除します。
    2. ブロックがリアルタイムで更新されるのを確認します。
    3. 編集を保存して再読み込みします。
    4. 表示される時間、文字数は、コンテンツ変更時に動的に更新され、再読み込み後も正確な値を維持します。

テストの様子

この新しいブロックをテスト中に問題を発見した場合は、こちらまで報告してください。

ボーダー半径サイズのプリセット

WordPress 6.9 では、Gutenberg 21.5で追加されたボーダー半径サイズプリセットが導入されました。これは、開発者が名前付きの半径値セットを定義し、ボーダー半径に対応するブロックにユーザーがそれを適用できるようにするテーマツールです。

詳細やサンプルについては、WordPress Developer Blog「WordPress 6.9 におけるボーダー半径サイズプリセット」を参照してください。

この機能により、テーマ作者は theme.json を通じて再利用可能なボーダー半径プリセットを定義でき、ブロックエディター上で各コーナーごとに適用することが可能になります。

なお、この機能にはブログ記事内で説明されている既知の制限事項があります。詳細については、該当チケットを確認してください。

ソーシャルリンク: カスタムアイコンの拡張性

この機能拡張により、開発者はブロックバリエーションを使用して、ソーシャルアイコンブロック内にカスタムソーシャルアイコンを登録できるようになりました。これまでは、カスタムソーシャルアイコンを追加するには独自コードやサードパーティ製プラグインが必要でした。

WordPress 6.9では:

  • 開発者は Ko-fi、IMDb、Letterboxd、Signal、YouTube Music、Dropbox などの新しいソーシャルアイコンを簡単に登録できます。
  • ユーザーは、ソーシャルアイコンブロック内でこれらのカスタムアイコンを選択して表示できます。
  • これにより、カスタムブロックの作成やプラグインへの依存を減らし、アイコン間で一貫したスタイルと動作を維持できます。

詳細な実装ガイドは、WordPress Developer Blog「カスタムソーシャルアイコンの登録」に関する記事を参照してください。

テスト手順:

  1. カスタムソーシャルリンクのバリエーションを登録します。この記事を参照してください。
  2. 投稿を作成します。
  3. ソーシャルリンクブロックを追加し、登録したカスタムバリエーションを挿入します。
  4. 投稿を保存してプレビューします。
  5. カスタムバリエーションがエディターとフロントエンドの両方で正しく表示されていることを確認します。

テストの様子

関連する問題を確認した場合は、こちらから報告してください。

開発者向けの更新

DataViews と DataForm の更新

DataViews および DataForm コンポーネントの更新には、新しいフィールドタイプと新しいフィルター演算子が含まれます。

これらは基盤的な変更で、破壊的な非互換性は起こさないはずですが、既にこのコンポーネントを使用している画面 (特にサイトエディターの「ページ」「パターン」「テンプレート」画面) に影響を与える可能性があります。

これらの画面の機能をテストし、問題が発生した場合は、Gutenberg リポジトリに問題を記録してください。また、WordPress 6.9向け DataViews & DataForm イテレーション追跡 issue へのリンクも助かります。

Abilities API の導入

Abilities API は、定義済みの説明、入力、出力を備えた呼び出し可能な Abilities のレジストリを提供します。統一されたリソースレジストリを通じて、WordPress の機能を AI システム、特に開発者向けに利用可能にすることを目的としています。

これは開発者向け API であるため、テストは以下のようなカスタムプラグインを使用して行います: https://github.com/wptrainingteam/wp-abilities-test

テスト手順

PHPでのカスタム Abilities のテスト

  1. wp_register_ability を使用してカスタム ability を作成する (ドキュメント)
  2. wp_get_abilities を使用して登録済みの全 ability を取得する (ドキュメント)
  3. wp_get_ability を使用してカスタム ability を取得する (ドキュメント)
  4. ability の execute メソッドを使用してカスタム ability を実行する (ドキュメント)

Abilities REST エンドポイントのテスト (ドキュメント)

Abilities API のすべてのルートでは、認証済みユーザーが必要です。ローカルテストでは、管理者ユーザーによるアプリケーションパスワードの使用をお勧めします。

  1. すべての Abilities のリスト (ドキュメント)
  2. Ability の取得 (ドキュメント)
  3. Ability の実行 (ドキュメント)

Postman を利用するテスター用に、ローカルテストで使用可能な Postmanコレクションがあります。リクエスト URL フィールド内の {{baseURL}} 変数をローカルWordPress 環境の URL に、認証タブ内の {{applicationUsername}}{{applicationPassword}} 変数をそれぞれユーザー名とアプリケーションパスワードに置き換えてください。

6.9で提供されるコア Abilities のテスト

  • core/get-site-info – WordPress で設定されたサイト情報を返します。デフォルトでは全フィールドを返しますが、オプションでフィルタリングしたサブセットを返すこともできます。
  • core/get-user-info – パーソナライゼーション、監査、アクセス認識の動作をサポートするため、現在認証されているユーザーの基本プロフィール詳細を返します。
  • core/get-environment-info – 診断と互換性確認のため、サイトの実行環境に関するコア詳細を返します (環境、PHP ランタイム、データベースサーバー情報、WordPress バージョン)。

3つのコア abilities のリスト、取得、実行を PHP 内で (ドキュメント)、そして REST API を使用して (ドキュメント) テストしてください。

Interactivity API の改良

クライアントサイドナビゲーションでの新スタイルとスクリプトモジュールのサポート

この更新では、Interactivity API クライアントサイドナビゲーションを拡張し、新しいスタイルシートマネージャー、複数のインポートマップをサポートするスクリプトモジュールマネージャーを導入しました。さらに、領域ベースのナビゲーションによるフルページナビゲーション共有ロジックを復元しました。また、異なるブロックを持つページ間を移動する際のスタイルの欠落も修正しています。

テスト手順

  1. サイトエディターで、ホームページテンプレートに移動します。
  2. クエリーブロックで「ページ再読み込みを強制」設定が無効になっていることを確認します。
  3. 投稿テンプレート内に画像ブロックを追加します。
  4. スタイルを変更し、画像を丸くします。
  5. 存在しないホームページのページ (例 ページ2)にアクセスし、「結果がありません」ブロックが表示されることを確認します。
  6. 前のページリンクをクリックします。
  7. 画像の角が丸く表示されるはずです。

WordPress 6.9 向け Interctivity API のイテレーション

この追跡 issue には、Interactivity API に対する一連の小さなバグ修正と利便性の向上が含まれています。

テスト手順

  1. 追跡 issue を開き、完了済みとマークされた一連のリンクされた課題、またはマージ済みとマークされたプルリクエストを選択します。
  2. issue、またはプルリクエスト内のテスト手順に従って修正をテストします。

Block Bindings の更新

WordPress6.9で利用可能になる主な機能は次のとおりです。

それぞれの更新をテストするには、リンクされた GitHubの Pull Request に記載されているテスト手順に従ってください。

HTML API の更新

これらの更新には、HTML API 自体の内部的な改良に加えて、HTML API の実装による WordPress コアが HTML を処理、解析する方法の改善に関する変更も含まれます。

この変更は、次の WordPress コア関数に影響します。

これらの関数が引き続き期待どおりに動作することを確認するため、HTML API の更新前後でテストを行ってください。

また、WordPress 6.9では新たに WP_Block_Processor クラスが導入されました。このクラスは、WP_HTML_Tag_Processor が HTML を解析する方法と同様に、ブロックマークアップを順に処理するための仕組みを提供します。WP_Block_Processor クラスの詳細およびインラインドキュメントについては、関連する Pull Request (PR) を参照してください。

フィードバックの報告先

問題を見つけたが、バグなのか、どこに報告すればベストなのかわからない場合は、WordPress.org alpha / beta フォーラムで共有してください。WordPress Alpha / Beta / RC でバグを見つけたと確信がある場合は、自動更新のロールバックについては Core Trac、その他の機能については Gutenberg GitHub リポジトリで報告してください。

有用な報告ガイドラインについては、テストハンドブックのテスト報告セクションを参照し、バグ報告に関するコアチームのガイドラインを参照してください。

更新履歴

1.0.0 – 初回投稿

1.0.1 – コマンドパレットのテスト手順と Abilities API JavaScript クライアントの重複箇所を削除しました。

1.0.2 –Block Bindings の編集 UI を削除しました。

この投稿の事前レビューにご協力いただいた @wildworks@bph@annezazu, @ellatrix@akshayar@muddassirnasim に感謝いたします。

また、投稿作成に協力してくださった @psykro にも感謝します。


この翻訳は WordCamp Kansai 2025 コントリビューターデイに参加したメンバーを中心に行われました。

@spheredesign, @pixelium, @woonami, @atachibana,
@kimipooh, @torikumo, @satake0121, @stein2nd, @nukaga, @sailorrabbit

オンラインで参加された方は WordSlack で連絡ください。

カテゴリー

購読する