Interest.CivicTheme / Drupal
メニュー

テーマから探す

構築し、試し、学んだ記録。

CIVICTHEME JOURNAL 29

Drupal Core Update

·DrupalDrupal PostSet up

約15,700文字 読了目安：約32分

この記事の目次

Drupal Coreのアップデート内容

前記事で、Drupal Coreを10.3.5にアップデートしました。元々、10.3.3のアップデートから、短期間で10.3.4 > 10.3.5とアップデートするので、緊急アップデートと考え、内容を確認する際、Gitlabに記載されているコードを確認しました。アップデートを行う際に必ずしもコードによる変更の確認は必須ではないのですが、確認を行う事でよりDrupalに対する理解が深まります。

今回、10.3.5のアップデートが、10.3.3から10.3.4にアップデートした際にCasheCollectorクラスの初期化による競合の不具合を修正する目的で、10.3.4で修正した初期化を元のNullに戻しています。

10.3.3や10.3.4のアップデートが何を行ったのかが気になり、アップデートの内容が気になり調べてみたのでその内容を記事としてまとめてみます。

変更点が、アップデートのページに記載されているので、それを参考に調べてみます。

10.3.3が68件の変更、10.3.4が10件の変更、10.3.5が1件の変更となっています。

以下のアコーディオンメニューにそれぞれの変更点をまとめています。

10.3.3の変更内容を確認

68件の変更と多く、変更のIssueを見ても何を目的としての変更なのかが私の知識では理解しきれません。そこでGitHub Copilot先生にお願いします。質問がIssueとNoを入れずに回答をもらっていますので、アップデート内容に関わる議題の解説ではなく、質問である問題点に対する内容確認と対応策、コードの変更例、結論という一般的な答えが返って来ます。アップデートの変更内容が知りたいので、Copilotの回答を抜粋してコードを削除したものを解説で追加しています。この内容でも変更のIssueの意味はなんとなく理解出来ます。

アップデートした変更点の大半はテスト環境を整える変更となっています。その中で、処理速度に関わる変更点やエラー処理に関わる変更が多く、11.0がリリースされ、10.4のリリースを控えているので機能面の下位互換を意識したテスト環境を整えている内容が大半を占めているのかなというのが今回内容を確認してみた感想となります。

Drupalに限らず、CMSのCoreプログラムのアップデートによる変更内容とコードを全て確認したのは初めての事ですが、開発者の方は大変だなと感じる内容です。変更するPHP単体のコードだけを見ると、私でもなんとなく理解できるのですが、そのコード変更による多数リリースされているモジュールやテーマへの影響や、Drupal8などバージョン違いから10.0系へのアップデートの影響などを全て考慮している事や先にリリースする予定の機能なども考慮されていると考えると開発者の方に頭が下がります。

Gitlabに掲載されているコードは、私のような利用者だけでなく、モジュール開発者や、テーマの開発者などコントリビューターの方も閲覧し、互換や依存をテストする必要があるので、アップデートといっても、私自身が問題ないから大丈夫というものではないということが今回理解出来ました。

以下のアコーディオンメニューに、10.3.3で変更されたIssue、68件の変更内容を私自身が理解出来るようにまとめています。私自身の知識がそれほど高くなく内容の正確性は保証できませんので、閲覧する際、参考程度の閲覧とし判断は自己責任でお願いします。

  • 10.3.3 Issue 解説 1. to 15.

    1. Fix null $cid in CacheCollector classes
      https://www.drupal.org/project/drupal/issues/3471741
      1. CacheCollector クラスのコードを確認し、$cid が null になる可能性のある箇所を特定します。
      2. null チェックを追加し、適切なエラーハンドリングを行います。
      3. 必要に応じて、$cid が null でないことを保証するためのデフォルト値を設定します。
    2. Fix Content Translation tests that rely on UID1’s super user behavior
      https://www.drupal.org/project/drupal/issues/3439833
      1. UID1 のスーパーユーザーの動作に依存しているテストを特定します。
      2. テストを修正し、特定のユーザー権限を持つユーザーを作成して使用します。
      3. 必要に応じて、テストの前後にユーザーの作成と削除を行います。
        // このコードでは、UID1 のスーパーユーザーの動作に依存せず、特定の権限を持つユーザーを作成して使用するようにテストを修正しています。これにより、テストがより堅牢で再現性のあるものになります。
    3. Improve performance of the user.permissions.js script running in /admin/people/permissions.
      https://www.drupal.org/project/drupal/issues/3464530
      1. user.permissions.js スクリプトのパフォーマンスボトルネックを特定します。
      2. DOM 操作の最適化、イベントリスナーの効率化、不要な再計算の削減などの改善を行います。
      3. 改善後のスクリプトを提供します。
        // 改善点
      4. DOM クエリの最小化: テーブルやチェックボックスのキャッシュを使用して、DOM クエリの回数を減らしました。
      5. イベントデリゲーション: イベントリスナーを効率的に管理するために、イベントデリゲーションを使用しました。
      6. 不要な再計算の削減: 同じ列や行のチェックボックスを一度に更新することで、不要な再計算を削減しました。
        // これにより、/admin/people/permissions ページのパフォーマンスが向上します。
    4. getProcessPlugins() should explain why it has a $process parameter and why it’s optional
      https://www.drupal.org/project/drupal/issues/3458295
      1. getProcessPlugins() メソッドのコードを確認し、$process パラメータの役割を特定します。
      2. $process パラメータがオプションである理由を説明します。
      3. コード内にコメントを追加して、これらの点を明確にします。
        // $process パラメータの役割: $process パラメータは、特定のフィールドやプロパティがどのように処理されるべきかを定義するプロセス設定の配列です。各設定は、フィールドやプロパティに対して使用されるプラグインとその設定を定義します。
        // オプションである理由: $process パラメータが提供されない場合、メソッドはデフォルトのプロセス設定を使用します。これにより、呼び出し元が特定のプロセス設定を提供しなくても、メソッドが適切に動作することが保証されます。
        // このコメントと説明により、getProcessPlugins() メソッドの $process パラメータの役割とそのオプション性が明確になります。
    5. MigrateNoMigrateDrupalTest fails with missing classes in certain situations
      https://www.drupal.org/project/drupal/issues/3466289
      1. MigrateNoMigrateDrupalTest テストが失敗する原因を特定します。特に、クラスが見つからない状況を確認します。
      2. 必要なクラスが正しくロードされるように、テストのセットアップを修正します。
      3. クラスのオートローディングや依存関係の問題がないか確認します。
        // クラスの存在確認: setUp() メソッドで、必要なクラスが存在するかどうかを確認し、存在しない場合は例外をスローします。これにより、クラスが見つからない場合に早期に問題を検出できます。
        // 依存関係の確認: テストで使用するクラスが正しくロードされるように、必要なモジュール (migrate と my_module) を指定しています。
        // テストの実行: testMigrateNoMigrate() メソッドで、マイグレーションの実行と結果の検証を行います。
        // この修正により、MigrateNoMigrateDrupalTest がクラスの欠如によって失敗する問題が解決されるはずです。
    6. Speed up JSON:API ResourceTestBase
      https://www.drupal.org/project/drupal/issues/3468280
      1. JSON:API ResourceTestBase テストのパフォーマンスボトルネックを特定します。
      2. テストのセットアップやデータの準備を最適化します。
      3. 不要な処理を削減し、テストの実行時間を短縮します。
        // ユーザーと権限のキャッシュ: テストユーザーの作成とログインをセットアップで一度だけ行い、テストごとに繰り返さないようにしました。
        // コンテンツタイプのキャッシュ: コンテンツタイプが既に存在するかどうかをチェックし、存在しない場合のみ作成するようにしました。
        // テストエンティティの事前作成: テストで使用するエンティティをセットアップで事前に作成し、各テストで再作成しないようにしました。
        // これにより、JSON:API ResourceTestBase のパフォーマンスが向上し、テストの実行時間が短縮されるはずです。
    7. [patch to be ported] Split CKEditor5Test into two
      https://www.drupal.org/project/drupal/issues/3468237
      1. CKEditor5Test クラスを確認し、テストケースを2つの異なるクラスに分割します。
      2. 各テストクラスが独立して動作するように、必要なセットアップとテストメソッドを移動します。
      3. テストの重複を避け、各クラスが特定の機能をテストするようにします。
        // CKEditor5BasicTest クラス: 基本的な CKEditor 5 の機能をテストします。例えば、エディタが利用可能であることや、基本的なフィールドが存在することを確認します。
        // CKEditor5AdvancedTest クラス: 高度な CKEditor 5 の機能をテストします。例えば、プラグインやカスタムボタンなどの高度な機能を確認します。
        // これにより、テストがよりモジュール化され、特定の機能に焦点を当てたテストが可能になります。
    8. Improve Drupal\Core\Ajax\MessageCommand API documentation
      https://www.drupal.org/project/drupal/issues/3455342
      1. Drupal\Core\Ajax\MessageCommand クラスの現在の API ドキュメントを確認します。
      2. 各メソッドとプロパティの詳細な説明を追加し、使用例を提供します。
      3. ドキュメントを改善し、クラスの目的と使用方法を明確にします。
        // クラスの目的: MessageCommand クラスは、ユーザーにメッセージを表示するための AJAX コマンドを提供します。メッセージは、ステータス、警告、エラーのいずれかのタイプにすることができます。
        // プロパティ:
        // $message: 表示するメッセージの内容を保持します。
        // $type: メッセージのタイプを保持します。可能な値は ‘status’、‘warning’、’error’ です。
        // メソッド:
        // __construct($message, $type = ‘status’): メッセージとタイプを指定してオブジェクトを構築します。タイプは省略可能で、デフォルトは ‘status’ です。
        // render(): クライアント側の JavaScript が理解できる形式でコマンドをレンダリングします。
        // getMessage(): 表示するメッセージを取得します。
        // getType(): メッセージのタイプを取得します。
        // この改善されたドキュメントにより、MessageCommand クラスの目的と使用方法が明確になり、開発者がより理解しやすくなります。
    9. Views content language field default configuration should use field_language plugin
      https://www.drupal.org/project/drupal/issues/3459496
      1. Drupal Views のコンテンツ言語フィールドのデフォルト設定を確認します。
      2. field_language プラグインを使用するように設定を変更します。
      3. 必要に応じて、設定の変更を反映するコードを提供します。
        // hook_views_default_views_alter(): 既存のビューのデフォルト設定を変更します。特定のビュー (my_view) が存在し、その表示にコンテンツ言語フィールドが含まれている場合、そのフィールドのプラグインを field_language に変更します。
        // hook_views_data_alter(): ビューのデータ定義を変更し、コンテンツ言語フィールドが field_language プラグインを使用するように設定します。
        // このコードにより、Drupal Views のコンテンツ言語フィールドがデフォルトで field_language プラグインを使用するように設定されます。これにより、ビューの設定が一貫し、言語フィールドの表示が適切に行われるようになります。
    10. Change string ‘Modules to enable’ to {@inheritdoc} in comments
      https://www.drupal.org/project/drupal/issues/3467294
      1. コードベース内のコメントを検索し、‘Modules to enable’ という文字列を含むコメントを特定します。
      2. 該当するコメントを {@inheritdoc} に変更します。
      3. 変更を反映するコードを提供します。
        // {@inheritdoc}: ドキュメントコメントで使用されるタグで、親クラスやインターフェースからドキュメントを継承することを示します。これにより、重複したドキュメントを避け、コードの可読性を向上させます。
        // 変更点: protected static $modules プロパティと setUp() メソッドのコメントを {@inheritdoc} に変更しました。これにより、親クラスのドキュメントを継承し、コメントが簡潔になります。
        // この変更により、コードのコメントがより簡潔になり、親クラスのドキュメントを継承することで重複を避けることができます。
    11. Speed up UpdateSemverTestSecurityCoverageTest
      https://www.drupal.org/project/drupal/issues/3469583
      1. UpdateSemverTestSecurityCoverageTest テストのパフォーマンスボトルネックを特定します。
      2. テストのセットアップやデータの準備を最適化します。
      3. 不要な処理を削減し、テストの実行時間を短縮します。
        // ユーザーと権限のキャッシュ: テストユーザーの作成とログインをセットアップで一度だけ行い、テストごとに繰り返さないようにしました。
        // 設定のキャッシュ: 必要な設定が既に存在するかどうかをチェックし、存在しない場合のみ設定するようにしました。
        // テストの実行: testSecurityCoverage() メソッドで、セマンティックバージョニングのセキュリティカバレッジ設定が有効であることを確認します。
        // これにより、UpdateSemverTestSecurityCoverageTest のパフォーマンスが向上し、テストの実行時間が短縮されるはずです。
    12. PathLanguageTest should use API to set up language
      https://www.drupal.org/project/drupal/issues/3385838
      1. PathLanguageTest クラスを確認し、言語設定のセットアップ部分を特定します。
      2. 言語設定を手動で行っている部分を、Drupal の API を使用して設定するように変更します。
      3. 設定の変更を反映するコードを提供します。
        // setUpLanguages() メソッド: 言語設定を API を使用して行います。ConfigurableLanguage::createFromLangcode() メソッドを使用してフランス語とスペイン語を追加し、language.negotiation 設定を更新してパスプレフィックスを使用するように設定します。
        // テストの実行: testPathLanguageNegotiation() メソッドで、ノードのデフォルト言語とフランス語、スペイン語のパスを確認します。
        // この変更により、PathLanguageTest クラスが API を使用して言語設定を行うようになり、テストのセットアップがより効率的かつ信頼性の高いものになります。
    13. CommentTestBase/CommentTestTrait methods should be protected
      https://www.drupal.org/project/drupal/issues/3469824
      1. CommentTestBase クラスと CommentTestTrait トレイトのメソッドを確認します。
      2. パブリックメソッドを保護されたメソッドに変更します。
      3. 必要に応じて、メソッドのアクセス修飾子を変更するコードを提供します。
        // CommentTestBase クラス: メソッド createNodeWithComments と postComment を protected に変更しました。
        // CommentTestTrait トレイト: メソッド createCommentType と createComment を protected に変更しました。
        // これにより、これらのメソッドが外部から直接呼び出されることを防ぎ、テストクラス内でのみ使用されることを保証します。
    14. Speed up UpdateContribTest
      https://www.drupal.org/project/drupal/issues/3469709
      1. UpdateContribTest テストのパフォーマンスボトルネックを特定します。
      2. テストのセットアップやデータの準備を最適化します。
      3. 不要な処理を削減し、テストの実行時間を短縮します。
        // ユーザーと権限のキャッシュ: テストユーザーの作成とログインをセットアップで一度だけ行い、テストごとに繰り返さないようにしました。
        // 設定のキャッシュ: 必要な設定が既に存在するかどうかをチェックし、存在しない場合のみ設定するようにしました。
        // モジュールのシミュレーション: テストで使用するモジュールの存在をシミュレートし、実際のファイルシステム操作を最小限に抑えました。
        // これにより、UpdateContribTest のパフォーマンスが向上し、テストの実行時間が短縮されるはずです。
    15. TaxonomyTestTrait methods should be protected
      https://www.drupal.org/project/drupal/issues/3469823
      1. TaxonomyTestTrait トレイトのメソッドを確認します。
      2. パブリックメソッドを保護されたメソッドに変更します。
      3. 必要に応じて、メソッドのアクセス修飾子を変更するコードを提供します。
        // createVocabulary メソッド: ボキャブラリを作成するメソッドを protected に変更しました。これにより、トレイトを使用するクラス内でのみこのメソッドが使用されることを保証します。
        // createTerm メソッド: タクソノミータームを作成するメソッドを protected に変更しました。これにより、トレイトを使用するクラス内でのみこのメソッドが使用されることを保証します。
        // この変更により、TaxonomyTestTrait トレイトのメソッドが外部から直接呼び出されることを防ぎ、テストクラス内でのみ使用されることを保証します。

  • 10.3.3 Issue 解説 16. to 30.

    1. Split up jsonapi CommentTest
      https://www.drupal.org/project/drupal/issues/3469819
      // まず、CommentTest クラスを複数のテストクラスに分割するための計画を立てます。
      // 計画
      1. CommentTest クラスの各テストメソッドを確認する。
      2. テストメソッドを論理的にグループ化する。
      3. 各グループに対応する新しいテストクラスを作成する。
      4. 元の CommentTest クラスからテストメソッドを新しいクラスに移動する。
      5. 各新しいテストクラスで必要なセットアップとティアダウンメソッドを追加する。
        // これで、元の CommentTest クラスのテストメソッドを新しいクラスに分割しました。必要に応じて、他のテストメソッドも同様に分割してください。
    2. Update NPM packages flagged by yarn audit for 10.4.x and 10.3.x
      https://www.drupal.org/project/drupal/issues/3469840
      // DrupalプロジェクトのNPMパッケージを更新する際の手順と脆弱性の解消
    3. Speed up ContentModerationStateTest
      https://www.drupal.org/project/drupal/issues/3469163
      // ContentModerationStateTest の速度を向上
      // セットアップの最適化:
      1. 不要なモジュールの有効化を避け、必要最低限のモジュールのみを有効にします。
      2. テストデータの作成を最小限に抑えます。
        // キャッシュの利用:
      3. 可能な限りキャッシュを利用して、データベースアクセスを減らします。
        // 並列実行の検討:
      4. PHPUnitの並列実行機能を使用して、テストを並列に実行します。
        // 追加の最適化
      5. キャッシュの利用: テスト中に頻繁に使用されるデータをキャッシュすることで、データベースアクセスを減らします。
      6. データベースのリセットを最小限に: 各テストメソッドの前後でデータベースをリセットする回数を減らします。
    4. Speed up RevisionRevertFormTest
      https://www.drupal.org/project/drupal/issues/3469576
      // RevisionRevertFormTest の速度を向上
    5. Rename ConstraintsTest to UuidValidatorTest
      https://www.drupal.org/project/drupal/issues/2923168
      // ConstraintsTest クラスを UuidValidatorTest にリネーム
      1. ファイル名の変更:
        ConstraintsTest.php を UuidValidatorTest.php にリネームします。
      2. クラス名の変更:
        クラス名を ConstraintsTest から UuidValidatorTest に変更します。
      3. 名前空間の確認:
        名前空間が正しいことを確認します。
      4. テストメソッドの確認:
        テストメソッドが UUID バリデーションに関連していることを確認します
    6. Improve documentation of AttachmentsInterface methods
      https://www.drupal.org/project/drupal/issues/3451136
      // AttachmentsInterface のメソッドのドキュメントを改善するためには、各メソッドの目的、引数、戻り値、および例外について詳細に記述します。
      // 詳細な説明
      1. addAttachment メソッド:
        目的: 新しい添付ファイルを添付ファイルのリストに追加します。
        1-2. 引数:
        // $attachment (mixed): 追加する添付ファイル。ファイルパス、URL、その他の形式が考えられます。
        // 戻り値: なし
      2. removeAttachment メソッド:
        目的: 既存の添付ファイルを添付ファイルのリストから削除します。
        2-2. 引数:
        // $attachment (mixed): 削除する添付ファイル。addAttachment() で追加された形式と一致する必要があります。
        // 戻り値: なし
      3. getAttachments メソッド:
        目的: 現在管理されているすべての添付ファイルのリストを返します。
        3-2. 引数: なし
        戻り値:
      4. array: 添付ファイルの配列。各添付ファイルは addAttachment() で追加された形式になります。
        // これで、AttachmentsInterface のメソッドのドキュメントが改善されました。各メソッドの目的、引数、戻り値について詳細に記述することで、他の開発者がインターフェースを理解しやすくなります。
    7. Improve docblocks for views FieldHandlerInterface.php
      https://www.drupal.org/project/drupal/issues/2609432
      // FieldHandlerInterface.php のドキュメントブロックを改善するためには、各メソッドの目的、引数、戻り値、および例外について詳細に記述します。
      // 詳細な説明
      1. render メソッド:
        1-1. 目的: フィールドの出力をレンダリングします。
        1-2. 戻り値:
        1-3. string: フィールドのレンダリングされた出力。
      2. preRender メソッド:
        2-1. 目的: フィールドのレンダリング前に必要な準備や前処理を行います。
        2-2. 戻り値: なし
      3. query メソッド:
        3-1. 目的: フィールドを Views クエリに追加します。
        3-2. 戻り値: なし
        // これで、FieldHandlerInterface のメソッドのドキュメントが改善されました。各メソッドの目的、引数、戻り値について詳細に記述することで、他の開発者がインターフェースを理解しやすくなります。
    8. HtmlTag doc should be clear about escaping of #value
      https://www.drupal.org/project/drupal/issues/3215627
      // HtmlTag クラスのドキュメントを改善し、#value のエスケープについて明確にするための手順
      // HtmlTag クラスのドキュメントブロックを見直す:
      1. #value のエスケープに関する情報を追加します。
      2. #value がエスケープされるかどうか、どのようにエスケープされるかを明確に記述します。
      3. #value プロパティ:
        3-1. 説明: タグ内に配置されるコンテンツ。このコンテンツはXSS攻撃を防ぐために自動的にエスケープされます。生のHTMLを含める必要がある場合は、代わりに #markup プロパティを使用してください。
        3-2. 使用例:
        // これで、HtmlTag クラスのドキュメントが #value のエスケープについて明確になりました。他の開発者がこのプロパティの動作を理解しやすくなります。
    9. Convert EntityTypeDataTest to use EntityTestWithBundle
      https://www.drupal.org/project/drupal/issues/2938920
      // EntityTypeDataTest を EntityTestWithBundle を使用するように変換するための手順を以下に示します。EntityTestWithBundle は、エンティティのバンドルをサポートするテストケースを提供するため、エンティティのテストをより簡単に行うことができます。
      1. EntityTypeDataTest クラスを EntityTestWithBundle に変更:
        1-1. EntityTestWithBundle を継承するように変更します。
        1-2. 必要なセットアップとティアダウンメソッドを追加します。
      2. エンティティのバンドルを設定:
        2-1. テストで使用するエンティティのバンドルを設定します。
      3. テストメソッドを更新:
        3-1. EntityTestWithBundle のメソッドを使用して、エンティティの作成、更新、削除などの操作を行います。
        // 詳細な説明
      4. EntityTypeDataTest クラスの変更:
      5. KernelTestBase から EntityTestWithBundle に継承を変更します。
      6. 必要なモジュールに entity_test を追加します。
        // エンティティのバンドルを設定:
        createEntityBundle メソッドを使用して、テストで使用するエンティティのバンドルを設定します。
        // エンティティの作成と検証:
        // createEntity メソッドを使用してエンティティを作成し、その後エンティティのプロパティを検証します。
        これで、EntityTypeDataTest が EntityTestWithBundle を使用するように変換されました。これにより、エンティティのバンドルをサポートするテストケースが簡単に作成できるようになります。
    10. AssetResolverTest should use ::willReturnMap() for mocking
      https://www.drupal.org/project/drupal/issues/3468781
      // AssetResolverTest でモックを使用する際に、::willReturnMap() を使用することで、異なる引数に対して異なる戻り値を返すことができます。以下は、AssetResolverTest クラスで ::willReturnMap() を使用する方法の例です。
      // 手順
      1. モックオブジェクトの作成:
        // モックオブジェクトを作成します。
        // ::willReturnMap() を使用して、異なる引数に対して異なる戻り値を設定します。
      2. テストメソッドの更新:
        // モックオブジェクトを使用してテストメソッドを更新します。
        詳細な説明
      3. モックオブジェクトの作成:
        getMockBuilder を使用して AssetResolver クラスのモックオブジェクトを作成します。
        disableOriginalConstructor を使用して、オリジナルのコンストラクタを無効にします。
      4. ::willReturnMap() の使用:
        returnValueMap を使用して、引数に応じた戻り値を設定します。
        returnMap 配列には、引数とそれに対応する戻り値のペアを設定します。
      5. テストメソッドの更新:
        resolve メソッドを呼び出し、引数に応じた戻り値が返されることを確認します。
        // これで、AssetResolverTest クラスが ::willReturnMap() を使用するように改善されました。これにより、異なる引数に対して異なる戻り値を返すモックを簡単に設定できます。
    11. Optimize dblog tests
      https://www.drupal.org/project/drupal/issues/3469716
      // dblog モジュールのテストを最適化するためには、以下の手順を実行します。これにより、テストの実行時間を短縮し、効率を向上させることができます。
      // 手順
      1. セットアップの最適化:
        不要なモジュールの有効化を避け、必要最低限のモジュールのみを有効にします。
        テストデータの作成を最小限に抑えます。
      2. キャッシュの利用:
        可能な限りキャッシュを利用して、データベースアクセスを減らします。
      3. 並列実行の検討:
        PHPUnitの並列実行機能を使用して、テストを並列に実行します。
      4. データベースのリセットを最小限に:
        各テストメソッドの前後でデータベースをリセットする回数を減らします。
        // 追加の最適化
      5. キャッシュの利用: テスト中に頻繁に使用されるデータをキャッシュすることで、データベースアクセスを減らします。
      6. データベースのリセットを最小限に: 各テストメソッドの前後でデータベースをリセットする回数を減らします。
        // これで、dblog モジュールのテストが最適化されました。これにより、テストの実行時間が短縮され、効率が向上します。
    12. Speed up ExposedFormTest
      https://www.drupal.org/project/drupal/issues/3469623
      // ExposedFormTest の速度を向上させるためには、以下の手順を実行します。これにより、テストの実行時間を短縮し、効率を向上させることができます。
      // 手順
      1. セットアップの最適化:
        不要なモジュールの有効化を避け、必要最低限のモジュールのみを有効にします。
        テストデータの作成を最小限に抑えます。
      2. キャッシュの利用:
        可能な限りキャッシュを利用して、データベースアクセスを減らします。
        // 追加の最適化
      3. キャッシュの利用: テスト中に頻繁に使用されるデータをキャッシュすることで、データベースアクセスを減らします。
      4. データベースのリセットを最小限に: 各テストメソッドの前後でデータベースをリセットする回数を減らします。
        // これで、ExposedFormTest の速度を向上させるための手順が完了です。これにより、テストの実行時間が短縮され、効率が向上します。
    13. Speed up UpdateSemverTestSecurityAvailabilityTrait
      https://www.drupal.org/project/drupal/issues/3469580
      // UpdateSemverTestSecurityAvailabilityTrait の速度を向上させるためには、以下の手順を実行します。これにより、テストの実行時間を短縮し、効率を向上させることができます。
      // 手順
      1. セットアップの最適化:
        不要なモジュールの有効化を避け、必要最低限のモジュールのみを有効にします。
        テストデータの作成を最小限に抑えます。
      2. キャッシュの利用:
        可能な限りキャッシュを利用して、データベースアクセスを減らします。
      3. 並列実行の検討:
        PHPUnitの並列実行機能を使用して、テストを並列に実行します。
      4. データベースのリセットを最小限に:
        各テストメソッドの前後でデータベースをリセットする回数を減らします。
        // 追加の最適化
      5. キャッシュの利用: テスト中に頻繁に使用されるデータをキャッシュすることで、データベースアクセスを減らします。
      6. データベースのリセットを最小限に: 各テストメソッドの前後でデータベースをリセットする回数を減らします。
        // これで、UpdateSemverTestSecurityAvailabilityTrait の速度を向上させるための手順が完了です。これにより、テストの実行時間が短縮され、効率が向上します。
    14. Fix param docs identified by phpstan
      https://www.drupal.org/project/drupal/issues/3463440
      // phpstan によって識別されたパラメータドキュメントの修正を行うためには、以下の手順を実行します。これにより、コードの品質が向上し、ドキュメントが正確になります。
      // 手順
      1. phpstan の実行:
        phpstan を実行して、ドキュメントに関する警告やエラーを確認します。
      2. 警告やエラーの確認:
        phpstan の出力を確認し、パラメータドキュメントに関する問題を特定します。
      3. ドキュメントの修正:
        特定された問題に基づいて、ドキュメントブロックを修正します。
    15. Update docs to stop recommending FormattableMarkup
      https://www.drupal.org/project/drupal/issues/3405364
      // FormattableMarkup の使用を推奨しないようにドキュメントを更新するためには、代替手段として Markup クラスや t() 関数を使用する方法を示します。以下は、ドキュメントを更新する具体的な例です。
      // 手順
      1. FormattableMarkup の使用を推奨しない旨を記述:
        FormattableMarkup の使用を避ける理由を説明します。
        代替手段として Markup クラスや t() 関数を使用する方法を示します。
      2. コード例を更新:
        FormattableMarkup を使用しているコード例を Markup クラスや t() 関数を使用するように更新します。
        // 詳細な説明
      3. FormattableMarkup の使用を推奨しない旨を記述:
        FormattableMarkup の使用を避ける理由として、セキュリティ上の問題を説明します。特に、XSS攻撃のリスクがあるため、直接使用することは推奨されません。
      4. 代替手段の説明:
        Markup クラスや t() 関数を使用することで、より安全に文字列をフォーマットできることを説明します。
      5. コード例の更新:
        FormattableMarkup を使用しているコード例を Markup クラスや t() 関数を使用するように更新します。
        // これで、FormattableMarkup の使用を推奨しないようにドキュメントが更新されました。代替手段として Markup クラスや t() 関数を使用する方法を示すことで、より安全なコードを書くことができます。

  • 10.3.3 Issue 解説 31. to 45.

    1. Add additional test coverage for DialogRenderer::getTitleAsStringable()
      https://www.drupal.org/project/drupal/issues/3445469
      // まず、DialogRenderer::getTitleAsStringable() メソッドのテストを追加するための手順を考えます。
      // 手順
      1. テストクラスの作成: DialogRendererTest クラスを作成します。
      2. テストメソッドの追加: getTitleAsStringable メソッドのテストケースを追加します。
      3. モックの作成: 必要な依存関係をモックします。
      4. アサーションの追加: メソッドの戻り値が期待通りであることを確認します。
        // 疑似コード
      5. DialogRendererTest クラスを作成
      6. getTitleAsStringable メソッドのテストケースを追加
      7. DialogRenderer クラスのインスタンスを作成
        // 必要な依存関係をモック
        // メソッドを呼び出し、結果をアサート
        DialogRenderer::getTitleAsStringable() メソッドのテストを行うための基本的なユニットテストを示しています。必要に応じて、他のテストケースやモックを追加してテストカバレッジを拡張してください。
    2. Broken auto creation of machine name field
      https://www.drupal.org/project/drupal/issues/3428652
      // Drupalでマシンネームフィールドの自動生成が壊れている場合、その原因を特定し修正するための手順を以下に示します。
      // 手順
      1. 問題の特定: マシンネームフィールドが自動生成されない原因を特定します。
      2. コードの確認: マシンネームフィールドの自動生成に関連するコードを確認します。
      3. 修正: 問題を修正します。
      4. テスト: 修正が正しく機能することを確認するためのテストを追加します。
        // 疑似コード
      5. マシンネームフィールドの自動生成に関連するコードを確認
      6. 問題を修正
      7. 修正が正しく機能することを確認するためのテストを追加
        // このコードは、マシンネームフィールドの自動生成が正しく機能することを確認するための基本的なテストを示しています。必要に応じて、他のテストケースを追加してテストカバレッジを拡張してください。
    3. Speed up ElementTest
      https://www.drupal.org/project/drupal/issues/3469573
      // ElementTest の速度を向上させるためには、テストの実行時間を短縮するためのいくつかの戦略を考慮する必要があります。以下にその手順と具体的なコード例を示します。
      // 手順
      1. 不要な依存関係の削除: テストに必要のないモジュールやサービスのロードを避ける。
      2. モックの使用: 実際のサービスやエンティティの代わりにモックを使用して、テストの実行時間を短縮する。
      3. データベースアクセスの最小化: データベースアクセスを最小限に抑える。
      4. テストケースの分割: 大きなテストケースを小さなテストケースに分割して、個々のテストの実行時間を短縮する。
        // これらの手順を実行することで、ElementTest の速度を向上させることができます。テストの実行時間を短縮するために、必要に応じて他の最適化手法も検討してください。
    4. Speed up WorkspacesContentModerationStateTest
      https://www.drupal.org/project/drupal/issues/3468829
      // WorkspacesContentModerationStateTest の速度を向上させるためには、テストの実行時間を短縮するためのいくつかの戦略を考慮する必要があります。以下にその手順と具体的なコード例を示します。
      // 手順
      1. 不要な依存関係の削除: テストに必要のないモジュールやサービスのロードを避ける。
      2. モックの使用: 実際のサービスやエンティティの代わりにモックを使用して、テストの実行時間を短縮する。
      3. データベースアクセスの最小化: データベースアクセスを最小限に抑える。
      4. テストケースの分割: 大きなテストケースを小さなテストケースに分割して、個々のテストの実行時間を短縮する。
        // これらの手順を実行することで、WorkspacesContentModerationStateTest の速度を向上させることができます。テストの実行時間を短縮するために、必要に応じて他の最適化手法も検討してください。
    5. Speed up PageCacheTest
      https://www.drupal.org/project/drupal/issues/3469335
      // PageCacheTest の速度を向上させるためには、テストの実行時間を短縮するためのいくつかの戦略を考慮する必要があります。以下にその手順と具体的なコード例を示します。
      // 手順
      1. 不要な依存関係の削除: テストに必要のないモジュールやサービスのロードを避ける。
      2. モックの使用: 実際のサービスやエンティティの代わりにモックを使用して、テストの実行時間を短縮する。
      3. データベースアクセスの最小化: データベースアクセスを最小限に抑える。
      4. テストケースの分割: 大きなテストケースを小さなテストケースに分割して、個々のテストの実行時間を短縮する。
        // これらの手順を実行することで、PageCacheTest の速度を向上させることができます。テストの実行時間を短縮するために、必要に応じて他の最適化手法も検討してください。
    6. Reduce CPU request for Nightwatch job
      https://www.drupal.org/project/drupal/issues/3469070
      // Nightwatch.jsを使用したDrupalのテストジョブのCPUリクエストを削減するためには、テストの効率化とリソースの最適化が重要です。以下にその手順と具体的な方法を示します。
      // 手順
      1. テストの並列実行: テストを並列に実行して、全体の実行時間を短縮します。
      2. 不要なテストの削除: 実行する必要のないテストを削除または無効にします。
      3. テストの最適化: テストケースを最適化して、無駄な処理を減らします。
      4. リソースの制限: Nightwatchの設定でリソース使用量を制限します。
        // これらの手順を実行することで、Nightwatch.jsを使用したDrupalのテストジョブのCPUリクエストを削減し、効率的にテストを実行することができます。
    7. Allow child jobs to run as soon as phpcs and spellcheck are completed
      https://www.drupal.org/project/drupal/issues/3468848
      // DrupalのCI/CDパイプラインで、PHP CodeSniffer（PHPCS）とスペルチェックが完了したらすぐに子ジョブを実行するように設定するには、CIツール（例えばGitLab CIやGitHub Actions）を使用してジョブの依存関係を設定する必要があります。以下に、GitLab CIとGitHub Actionsの例を示します。
      // 説明
      1. GitLab CI:
        1-1. stages でジョブのステージを定義します。
        1-2. phpcs と spellcheck ジョブは lint ステージで実行されます。
        1-3. child_job ジョブは test ステージで実行され、needs キーワードを使用して phpcs と spellcheck ジョブが完了した後に実行されます。
      2. GitHub Actions:
        2-1. jobs で各ジョブを定義します。
        2-2. phpcs と spellcheck ジョブは並行して実行されます。
        2-3. child_job ジョブは needs キーワードを使用して phpcs と spellcheck ジョブが完了した後に実行されます。
        // これにより、PHPCSとスペルチェックが完了したらすぐに子ジョブが実行されるようになります。
    8. Speed up BigPipeRegressionTest
      https://www.drupal.org/project/drupal/issues/3468827
      // BigPipeRegressionTest の速度を向上させるためには、テストの効率化とリソースの最適化が重要です。以下にその手順と具体的な方法を示します。
      // 手順
      1. 不要な依存関係の削除: テストに必要のないモジュールやサービスのロードを避ける。
      2. モックの使用: 実際のサービスやエンティティの代わりにモックを使用して、テストの実行時間を短縮する。
      3. データベースアクセスの最小化: データベースアクセスを最小限に抑える。
      4. テストケースの分割: 大きなテストケースを小さなテストケースに分割して、個々のテストの実行時間を短縮する。
      5. キャッシュの活用: キャッシュを活用して、同じデータの再取得を避ける。
        // これらの手順を実行することで、BigPipeRegressionTest の速度を向上させることができます。テストの実行時間を短縮するために、必要に応じて他の最適化手法も検討してください。
    9. Split up EntityDefinitionUpdateTest
      https://www.drupal.org/project/drupal/issues/3469184
      // EntityDefinitionUpdateTest を分割してテストの実行時間を短縮するためには、テストケースを小さな単位に分割し、並行して実行できるようにすることが重要です。以下にその手順と具体的な方法を示します。
      // 手順
      1. テストケースの分割: 大きなテストケースを小さなテストケースに分割します。
      2. 共通セットアップの再利用: 共通のセットアップコードを再利用して、重複を避けます。
      3. 並行実行の設定: テストを並行して実行できるように設定します。
        // これらの手順を実行することで、EntityDefinitionUpdateTest を分割し、テストの実行時間を短縮することができます。テストの効率化とリソースの最適化を図るために、必要に応じて他の最適化手法も検討してください。
    10. Speed up DemoUmamiProfileTest
      https://www.drupal.org/project/drupal/issues/3468831
      // DemoUmamiProfileTest の速度を向上させるためには、テストの効率化とリソースの最適化が重要です。以下にその手順と具体的な方法を示します。
      // 手順
      1. 不要な依存関係の削除: テストに必要のないモジュールやサービスのロードを避ける。
      2. モックの使用: 実際のサービスやエンティティの代わりにモックを使用して、テストの実行時間を短縮する。
      3. データベースアクセスの最小化: データベースアクセスを最小限に抑える。
      4. テストケースの分割: 大きなテストケースを小さなテストケースに分割して、個々のテストの実行時間を短縮する。
      5. キャッシュの活用: キャッシュを活用して、同じデータの再取得を避ける。
        // これらの手順を実行することで、DemoUmamiProfileTest の速度を向上させることができます。テストの実行時間を短縮するために、必要に応じて他の最適化手法も検討してください。
    11. Speed up WorkspacesContentModerationStateTest
      https://www.drupal.org/project/drupal/issues/3468829
      // WorkspacesContentModerationStateTest の速度を向上させるためには、テストの効率化とリソースの最適化が重要です。以下にその手順と具体的な方法を示します。
      // 手順
      1. 不要な依存関係の削除: テストに必要のないモジュールやサービスのロードを避ける。
      2. モックの使用: 実際のサービスやエンティティの代わりにモックを使用して、テストの実行時間を短縮する。
      3. データベースアクセスの最小化: データベースアクセスを最小限に抑える。
      4. テストケースの分割: 大きなテストケースを小さなテストケースに分割して、個々のテストの実行時間を短縮する。
      5. キャッシュの活用: キャッシュを活用して、同じデータの再取得を避ける。
        // これらの手順を実行することで、WorkspacesContentModerationStateTest の速度を向上させることができます。テストの実行時間を短縮するために、必要に応じて他の最適化手法も検討してください。
    12. Allow child jobs to run as soon as phpcs and spellcheck are completed
      https://www.drupal.org/project/drupal/issues/3468848
      // CI/CDパイプラインで、PHP CodeSniffer（PHPCS）とスペルチェックが完了したらすぐに子ジョブを実行するように設定するには、CIツール（例えばGitLab CIやGitHub Actions）を使用してジョブの依存関係を設定する必要があります。以下に、GitLab CIとGitHub Actionsの例を示します。
      1. GitLab CI
        // GitLab CIでは、needs キーワードを使用してジョブの依存関係を設定できます。
      2. GitHub Actions
        // GitHub Actionsでは、needs キーワードを使用してジョブの依存関係を設定できます。
        // 説明
      3. GitLab CI:
        stages でジョブのステージを定義します。
        1-1. phpcs と spellcheck ジョブは lint ステージで実行されます。
        1-2. child_job ジョブは test ステージで実行され、needs キーワードを使用して phpcs と spellcheck ジョブが完了した後に実行されます。
      4. GitHub Actions:
        2-1. jobs で各ジョブを定義します。
        2-2. phpcs と spellcheck ジョブは並行して実行されます。
        2-3. child_job ジョブは needs キーワードを使用して phpcs と spellcheck ジョブが完了した後に実行されます。
        // これにより、PHPCSとスペルチェックが完了したらすぐに子ジョブが実行されるようになります。
    13. Standard Responsive Images recipe should have the Responsive image recipe type
      https://www.drupal.org/project/drupal/issues/3464771
      // Drupalで標準のレスポンシブ画像レシピがレスポンシブ画像レシピタイプを持つように設定するには、レスポンシブ画像スタイルとその設定を確認し、必要に応じて設定を追加または修正する必要があります。以下にその手順と具体的な方法を示します。
      // 手順
      1. レスポンシブ画像スタイルの確認: 既存のレスポンシブ画像スタイルを確認します。
      2. レスポンシブ画像スタイルの作成または修正: 必要に応じてレスポンシブ画像スタイルを作成または修正します。
      3. レスポンシブ画像スタイルの設定: レスポンシブ画像スタイルに適切な設定を追加します。
        // これらの手順を実行することで、標準のレスポンシブ画像レシピがレスポンシブ画像レシピタイプを持つように設定できます。必要に応じて、管理画面から設定を確認し、適切なブレークポイントと画像スタイルが設定されていることを確認してください。
    14. Reduce concurrency for build tests
      https://www.drupal.org/project/drupal/issues/3468832
      // Drupalのビルドテストの並行実行数を減らすことで、リソースの使用量を制御し、安定したテスト環境を維持することができます。以下に、GitLab CIとGitHub Actionsで並行実行数を制限する方法を示します。
      1. GitLab CI
        // GitLab CIでは、resource_group を使用して並行実行数を制限することができます。また、parallel キーワードを使用してジョブの並行実行数を設定することもできます。
      2. GitHub Actions
        // GitHub Actionsでは、concurrency キーワードを使用して並行実行数を制限することができます。
        // 説明
      3. GitLab CI:
        1-1. resource_group を使用して、同じリソースグループに属するジョブが同時に実行されないようにします。
        1-2. parallel キーワードを使用して、ジョブの並行実行数を設定します。
      4. GitHub Actions:
        2-1. concurrency キーワードを使用して、同じ並行実行グループに属するジョブが同時に実行されないようにします。
        2-2.matrix キーワードと max-parallel オプションを使用して、ジョブの並行実行数を制限します。
        // これにより、ビルドテストの並行実行数を制限し、リソースの使用量を制御することができます。
    15. JavaScript files added by AJAX responses are only optimized in maintenance mode
      https://www.drupal.org/project/drupal/issues/3452672
      // DrupalでAJAXレスポンスによって追加されたJavaScriptファイルがメンテナンスモードでのみ最適化される問題を解決するためには、JavaScriptファイルの最適化設定を確認し、適切に設定する必要があります。以下にその手順と具体的な方法を示します。
      // 手順
      1. パフォーマンス設定の確認: Drupalのパフォーマンス設定を確認し、JavaScriptファイルの最適化が有効になっていることを確認します。
      2. AJAXレスポンスの確認: AJAXレスポンスで追加されるJavaScriptファイルが正しく最適化されるように設定を確認します。
      3. カスタムモジュールの修正: 必要に応じて、カスタムモジュールでAJAXレスポンスを処理するコードを修正します。
        // これらの手順を実行することで、AJAXレスポンスによって追加されたJavaScriptファイルがメンテナンスモードでのみ最適化される問題を解決できます。必要に応じて、管理画面から設定を確認し、適切な設定が行われていることを確認してください。

  • 10.3.3 Issue 解説 46. to 60.

    1. APCu requirement for 32M is checking wrong value
      https://www.drupal.org/project/drupal/issues/3466399
      // まず、APCuの設定を確認し、Drupalが要求する32Mのメモリが正しく設定されているかを確認します。以下の手順で進めます。
      1. php.iniファイルを編集して、APCuの設定を確認します。
      2. apc.shm_sizeが32M以上に設定されていることを確認します。
      3. ApacheまたはPHP-FPMを再起動して設定を反映させます。
      4. Drupalのステータスレポートを確認して、APCuの設定が正しく認識されているかを確認します。
    2. Fix typehint of ContextDefinition’s $label constructor param
      https://www.drupal.org/project/drupal/issues/3465370
      // まず、ContextDefinitionクラスのコンストラクタの$labelパラメータの型ヒントを修正する手順を説明します。
      // 手順
      1. ContextDefinitionクラスのファイルを開く。
      2. コンストラクタの$labelパラメータの型ヒントを修正する。
      3. 修正後のコードを保存する。
        // 擬似コード
      4. ContextDefinitionクラスのファイルを探す。
      5. コンストラクタを見つける。
      6. $labelパラメータの型ヒントを修正する。
        //説明
      7. ?string $label = null とすることで、$labelパラメータがnullを許容する文字列型であることを示しています。
      8. これにより、$labelパラメータが省略可能であり、デフォルト値としてnullを持つことができます。
      9. この修正を行った後、コードを保存し、Drupalのキャッシュをクリアして変更を反映させます。
    3. Add tests for updates should not recommend a new branch if there are no stable releases
      https://www.drupal.org/project/drupal/issues/3461690
      // まず、Drupalのアップデート機能に対するテストを追加するための手順を説明します。具体的には、安定版リリースがない場合に新しいブランチを推奨しないことを確認するテストを追加します。
      // 手順
      1. テストクラスを作成する。
      2. テストメソッドを追加し、安定版リリースがない場合のシナリオを設定する。
      3. 新しいブランチを推奨しないことを確認するアサーションを追加する。
        // 擬似コード
      4. テストクラスを作成する。
      5. テストメソッドを追加する。
      6. モックを使用して、安定版リリースがない場合のシナリオを設定する。
      7. 新しいブランチを推奨しないことを確認するアサーションを追加する。
        // 説明
      8. UpdateManagerTestクラスを作成し、UnitTestCaseを継承します。
      9. testNoNewBranchRecommendedIfNoStableReleasesメソッドを追加し、安定版リリースがない場合のシナリオを設定します。
      10. getStableReleasesメソッドをモックして、空の配列を返すように設定します。
      11. shouldRecommendNewBranchメソッドがfalseを返すことを確認するアサーションを追加します。
    4. RouteCachingLanguageTest should use API to set up language
      https://www.drupal.org/project/drupal/issues/3385844
      // RouteCachingLanguageTestで言語を設定する際に、直接データベース操作を避け、DrupalのAPIを使用する方法を説明します。これにより、テストがより堅牢でメンテナンスしやすくなります。
      // 手順
      1. テストクラスを開く。
      2. 言語設定を行う部分を見つける。
      3. DrupalのAPIを使用して言語を設定するコードに置き換える。
        // 擬似コード
      4. テストクラスを開く。
      5. setUpメソッドまたはテストメソッド内で言語設定を行う部分を見つける。
      6. \Drupal::service(’language_manager’)->addLanguage()などのAPIを使用して言語を設定する。
        // 説明
      7. setUpメソッド内で、language_managerサービスを使用して新しい言語を追加します。
      8. addLanguageメソッドを使用して、フランス語（fr）を追加します。
      9. 言語設定を保存するために、configFactoryサービスを使用して設定を更新します。
        // この変更により、テストクラスがDrupalのAPIを使用して言語を設定するようになります。これにより、テストがより堅牢でメンテナンスしやすくなります。
    5. Convert IpAddressBlockingTest to a Unit and Kernel test and improve
      https://www.drupal.org/project/drupal/issues/3468435
      // IpAddressBlockingTestをユニットテストとカーネルテストに変換し、改善する手順を説明します。
      // 手順
      1. ユニットテストを作成する。
      2. カーネルテストを作成する。
      3. テストを改善する。
        // ユニットテストの作成
        ユニットテストでは、依存関係をモックして、IPアドレスのブロック機能をテストします。
        // カーネルテストの作成
        カーネルテストでは、実際のDrupal環境でIPアドレスのブロック機能をテストします。
        // 改善点
      4. 依存関係の注入: クラスの依存関係をコンストラクタで注入することで、テストが容易になります。
      5. 設定のモック: ユニットテストでは、設定をモックしてテストを行います。
        // 実際の環境でのテスト: カーネルテストでは、実際のDrupal環境でテストを行います。
    6. Shorten overall running time from CKeditor5 image tests
      https://www.drupal.org/project/drupal/issues/3467821
      // CKEditor5の画像テストの実行時間を短縮するためには、以下の手順を考慮します。
      1. テストの並列実行: テストを並列に実行することで、全体の実行時間を短縮します。
      2. 不要なテストの削除: 重複しているテストや不要なテストを削除します。
      3. テストデータの最適化: テストデータのセットアップを最適化し、必要最低限のデータのみを使用します。
      4. キャッシュの活用: テスト環境でキャッシュを有効にし、再利用可能なデータをキャッシュします。
        // これらの手順を実行することで、CKEditor5の画像テストの実行時間を短縮し、効率的にテストを行うことができます。
    7. Use API methods to create filter/editor in CKEditor5Test when not explicitly testing the UI
      https://www.drupal.org/project/drupal/issues/3467853
      // CKEditor5のテストでUIを明示的にテストしていない場合、APIメソッドを使用してフィルターやエディターを作成することで、テストの実行時間を短縮できます。以下に、APIメソッドを使用してフィルターやエディターを作成する方法を示します。
      // 手順
      1. テストクラスを開く。
      2. フィルターやエディターを作成する部分を見つける。
      3. APIメソッドを使用してフィルターやエディターを作成するコードに置き換える。
        // 説明
      4. FilterFormat::create()とEditor::create()を使用して、フィルターフォーマットとエディターをAPI経由で作成します。
      5. テストユーザーを作成し、必要な権限を付与します。
      6. ノード作成ページに移動し、CKEditor5の機能をテストします。
        // この方法により、UIを明示的にテストしていない場合でも、APIメソッドを使用して効率的にフィルターやエディターを作成できます。これにより、テストの実行時間を短縮し、テストの効率を向上させることができます。
    8. Fix Toolbar tests that rely on UID1’s super user behavior
      https://www.drupal.org/project/drupal/issues/3439910
      // UID1のスーパーユーザーの動作に依存するツールバーテストを修正するためには、特定の権限を持つテストユーザーを作成し、そのユーザーを使用してテストを実行するように変更します。これにより、テストがより現実的で堅牢になります。
      // 手順
      1. テストクラスを開く。
      2. UID1に依存している部分を見つける。
      3. 特定の権限を持つテストユーザーを作成し、そのユーザーを使用してテストを実行するように変更する。
        // 説明
      4. drupalCreateUserメソッドを使用して、必要な権限を持つテストユーザーを作成します。
      5. drupalLoginメソッドを使用して、そのユーザーでログインします。
      6. UID1に依存せずに、特定の権限を持つユーザーでツールバーのテストを実行します。
        // これで、UID1のスーパーユーザーの動作に依存しないツールバーテストが実行されるようになります。これにより、テストがより現実的で堅牢になります。
    9. Use API methods to create filter/editor in CKEditor5Test when not explicitly testing the UI
      https://www.drupal.org/project/drupal/issues/3467853
      // CKEditor5のテストでUIを明示的にテストしていない場合、APIメソッドを使用してフィルターやエディターを作成することで、テストの実行時間を短縮できます。以下に、APIメソッドを使用してフィルターやエディターを作成する方法を示します。
      // 手順
      1. テストクラスを開く。
      2. フィルターやエディターを作成する部分を見つける。
      3. APIメソッドを使用してフィルターやエディターを作成するコードに置き換える。
        // 説明
      4. FilterFormat::create()とEditor::create()を使用して、フィルターフォーマットとエディターをAPI経由で作成します。
      5. テストユーザーを作成し、必要な権限を付与します。
      6. ノード作成ページに移動し、CKEditor5の機能をテストします。
        // この方法により、UIを明示的にテストしていない場合でも、APIメソッドを使用して効率的にフィルターやエディターを作成できます。これにより、テストの実行時間を短縮し、テストの効率を向上させることができます。
    10. Shorten overall running time from CKeditor5 image tests
      https://www.drupal.org/project/drupal/issues/3467821
      // CKEditor5の画像テストの実行時間を短縮するためには、以下の手順を考慮します。
      1. テストの並列実行: テストを並列に実行することで、全体の実行時間を短縮します。
      2. 不要なテストの削除: 重複しているテストや不要なテストを削除します。
      3. テストデータの最適化: テストデータのセットアップを最適化し、必要最低限のデータのみを使用します。
      4. キャッシュの活用: テスト環境でキャッシュを有効にし、再利用可能なデータをキャッシュします。
        // これらの手順を実行することで、CKEditor5の画像テストの実行時間を短縮し、効率的にテストを行うことができます。
    11. Reduce CPU requirement and concurrency for unit tests
      https://www.drupal.org/project/drupal/issues/3467391
      // ユニットテストのCPU使用量と並列実行数を減らすためには、以下の手順を考慮します。
      1. 並列実行数の制限: テストの並列実行数を制限することで、CPU使用量を抑えます。
      2. リソース集約型テストの分離: リソース集約型のテストを分離し、必要に応じて個別に実行します。
      3. テストの最適化: テストの実行時間を短縮するために、テストデータのセットアップを最適化します。
        // これで、ユニットテストのCPU使用量と並列実行数を制限し、効率的にテストを実行することができます。
    12. Fix ‘risky’ tests
      https://www.drupal.org/project/drupal/issues/3466788
      // 「risky」テストは、テストが何もアサートしていない場合や、例外がキャッチされていない場合などに発生します。これを修正するためには、以下の手順を考慮します。
      1. アサーションの追加: テストが期待する結果を明示的にアサートします。
      2. 例外のキャッチとアサート: 例外が発生することを期待する場合、その例外をキャッチしてアサートします。
      3. 不要なコードの削除: テストに不要なコードが含まれている場合、それを削除します。
        // これで、riskyなテストが修正され、テストが期待する結果を明示的にアサートするようになります。
    13. Use API methods instead of form submissions in FilterFormatAccessTest::setUp()
      https://www.drupal.org/project/drupal/issues/3463547
      // FilterFormatAccessTest::setUp()メソッドでフォーム送信を使用する代わりに、APIメソッドを使用してフィルターフォーマットを設定する方法を説明します。これにより、テストの実行時間を短縮し、テストの信頼性を向上させることができます。
      // 手順
      1. テストクラスを開く。
      2. setUp()メソッド内でフォーム送信を使用している部分を見つける。
      3. APIメソッドを使用してフィルターフォーマットを設定するコードに置き換える。
        // 説明
      4. FilterFormat::create()を使用して、フィルターフォーマットをAPI経由で作成します。
      5. 管理者ユーザーを作成し、必要な権限を付与します。
      6. drupalLogin()メソッドを使用して、管理者ユーザーでログインします。
      7. フィルターフォーマットの設定ページにアクセスし、設定が正しく表示されていることを確認します。
        // これで、FilterFormatAccessTest::setUp()メソッドがAPIメソッドを使用してフィルターフォーマットを設定するようになり、テストの実行時間が短縮され、信頼性が向上します。
    14. Split OptionsFieldUiTest into two
      https://www.drupal.org/project/drupal/issues/3463908
      // まず、OptionsFieldUiTest クラスを2つのテストクラスに分割するための計画を立てます。
      // 計画
      1. OptionsFieldUiTest クラスを開きます。
      2. テストメソッドを機能ごとにグループ化します。
      3. 新しいテストクラスを作成し、適切なテストメソッドを移動します。
      4. 各テストクラスが必要なセットアップとティアダウンメソッドを持っていることを確認します。
      5. 新しいテストクラスの名前を決定します。
        // 実装
        // 以下のように、OptionsFieldUiTest クラスを OptionsFieldUiTestPart1 と OptionsFieldUiTestPart2 に分割します。
        // これで、OptionsFieldUiTest クラスを2つの新しいテストクラスに分割しました。それぞれのクラスが独自のテストメソッドを持ち、必要なセットアップを行います。
    15. Split up FormTest
      https://www.drupal.org/project/drupal/issues/3465855
      // FormTest クラスを分割するための計画を立てます。
      // 計画
      1. FormTest クラスを開きます。
      2. テストメソッドを機能ごとにグループ化します。
      3. 新しいテストクラスを作成し、適切なテストメソッドを移動します。
      4. 各テストクラスが必要なセットアップとティアダウンメソッドを持っていることを確認します。
      5. 新しいテストクラスの名前を決定します。
        // 実装
        FormTest クラスを FormTestPart1 と FormTestPart2 に分割します。
        // これで、FormTest クラスを2つの新しいテストクラスに分割しました。それぞれのクラスが独自のテストメソッドを持ち、必要なセットアップを行います。

  • 10.3.3 Issue 解説 61. to 68.

    1. FileFieldCreationTrait methods should be protected
      https://www.drupal.org/project/drupal/issues/3465880
      // FileFieldCreationTrait のメソッドを protected に変更するための計画を立てます。
      // 計画
      1. FileFieldCreationTrait ファイルを開きます。
      2. すべてのパブリックメソッドを探します。
      3. それらのメソッドのアクセス修飾子を protected に変更します。
        // 実装
        // FileFieldCreationTrait のメソッドを protected に変更します。
        // これで、FileFieldCreationTrait のメソッドが protected に変更されました。
    2. De-duplicate logic in ManageFieldsFunctionalTest
      https://www.drupal.org/project/drupal/issues/3465968
      // ManageFieldsFunctionalTest クラスの重複したロジックをリファクタリングして、コードの重複を減らすための計画を立てます。
      // 計画
      1. ManageFieldsFunctionalTest クラスを開きます。
      2. 重複しているロジックを特定します。
      3. 重複しているロジックを共通のメソッドに抽出します。
      4. 抽出したメソッドを適切な場所で呼び出すように変更します。
        // 実装
        // 重複したロジックを共通のメソッドに抽出します。
        // これで、重複したロジックが setUpField メソッドに抽出され、各テストメソッドで再利用されるようになりました。これにより、コードの重複が減り、メンテナンスが容易になります。
    3. FileOnTranslatedEntityTest should use API to set up language
      https://www.drupal.org/project/drupal/issues/3385846
      // FileOnTranslatedEntityTest クラスで言語のセットアップにAPIを使用するための計画を立てます。
      // 計画
      1. FileOnTranslatedEntityTest クラスを開きます。
      2. 言語のセットアップに関する既存のコードを特定します。
      3. 言語のセットアップにAPIを使用するようにコードを変更します。
        // 実装
        言語のセットアップにAPIを使用するように変更します。
        // これで、FileOnTranslatedEntityTest クラスが言語のセットアップにAPIを使用するようになりました。これにより、テストのセットアップがより簡潔で信頼性の高いものになります。
    4. DatabaseStorage, readMultiple throws error when receive empty array
      https://www.drupal.org/project/drupal/issues/3416525
      // DatabaseStorage クラスの readMultiple メソッドが空の配列を受け取ったときにエラーをスローしないように修正するための計画を立てます。
      // 計画
      1. DatabaseStorage クラスを開きます。
      2. eadMultiple メソッドを見つけます。
      3. メソッドの最初に空の配列が渡された場合に早期リターンするチェックを追加します。
        // 実装
        readMultiple メソッドを修正します。
        // これで、readMultiple メソッドが空の配列を受け取ったときにエラーをスローせず、空の配列を返すようになりました。これにより、メソッドの使用がより安全になります。
    5. The PECL UUID implementation can return invalid UUIDs
      https://www.drupal.org/project/drupal/issues/2613926
      // PECL UUID 実装が無効なUUIDを返す可能性がある場合、そのUUIDを検証するためのロジックを追加する必要があります。以下の計画に従って修正を行います。
      // 計画
      1. PECL UUID を使用してUUIDを生成する部分を特定します。
      2. UUIDの検証ロジックを追加します。
      3. 無効なUUIDが生成された場合にエラーハンドリングを行います。
        // 実装
        UUIDの生成と検証を行うコードを追加します。
        // これで、PECL UUID を使用して生成されたUUIDが無効な場合にエラーハンドリングを行うようになりました。Ramsey\Uuid\Uuid クラスを使用してUUIDの検証を行っています。これにより、無効なUUIDが使用されることを防ぎます。
    6. WebAssertTest fails on 10.x
      https://www.drupal.org/project/drupal/issues/3466822
      // WebAssertTest が Drupal 10.x で失敗する場合、テストの失敗原因を特定し、修正する必要があります。以下の計画に従って修正を行います。
      // 計画
      1. WebAssertTest クラスを開きます。
      2. 失敗しているテストメソッドを特定します。
      3. 失敗の原因を調査します（例: DOM 構造の変更、API の変更など）。
      4. テストコードを修正します。
        // これで、WebAssertTest が Drupal 10.x で失敗しないように修正されました。具体的な修正内容は、テストの失敗原因に依存しますので、適宜調整してください。
    7. Test-only job cannot be run due to wrong dependency
      https://www.drupal.org/project/drupal/issues/3467080
      // テスト専用のジョブが依存関係の問題で実行できない場合、その依存関係を修正する必要があります。以下の計画に従って修正を行います。
      // 計画
      1. テスト専用ジョブの設定ファイル（例: composer.json, drupal-ci.yml など）を開きます。
      2. 依存関係の問題を特定します。
      3. 必要な依存関係を追加または修正します。
      4. テスト専用ジョブを再実行して、問題が解決されたことを確認します。
        // これで、テスト専用ジョブが依存関係の問題で実行できない問題が修正されました。具体的な修正内容は、依存関係の問題に依存しますので、適宜調整してください。
    8. Fix strict type errors in test modules
      https://www.drupal.org/project/drupal/issues/3402007
      // Drupalのテストモジュールで発生する厳密な型エラーを修正するための計画を立てます。
      // 計画
      1. テストモジュールのコードを開きます。
      2. 厳密な型エラーが発生している箇所を特定します。
      3. 型宣言を追加または修正し、厳密な型エラーを修正します。
        // これで、テストモジュールの厳密な型エラーが修正されました。具体的な修正内容は、エラーの内容に依存しますので、適宜調整してください。

10.3.4の変更内容を確認

10.3.3の内容確認が、CopilotにIssue Noを入れずに確認し、アップデートの確認といった内容の答えをもらえなかった反省から、10.3.4はIssue Noを入れて質問しています。10.3.3の解説より、アップデートが何を目的としているかは理解しやすいと思います。

そもそも、アップデートの内容を確認しようと考えたのが、アップデートが日を置かずに来たことが理由であります。10.3.4は10.3.3の変更で生じる不具合を直したり戻すために行ったアップデートかなというのが私の感想となります。一部StableからDevに戻す処理なども行っています。

  • 10.3.4 Issue 解説

    1. twig/twig has a possible sandbox bypass <v3.14.0
      https://www.drupal.org/project/drupal/issues/3473195
      #3473195は、twig/twigライブラリにおけるサンドボックスバイパスの脆弱性に関するものです。この問題は、特定の条件下でTwigテンプレートエンジンがサンドボックスの制約を回避し、不正なコードが実行される可能性があることを示しています。
    2. Remove references to ApcClassLoader (removed in Symfony 4)
      https://www.drupal.org/project/drupal/issues/3472092
      #3472092は、Symfony 4で削除されたApcClassLoaderへの参照を削除することに関するものです。この変更は、コードベースを最新のSymfonyバージョンに対応させるために必要です。
    3. Fix null $cid in CacheCollector classes
      https://www.drupal.org/project/drupal/issues/3471741
      #3471741は、CacheCollectorクラスで$cidがnullになる問題を修正することに関するものです。この問題は、キャッシュID（$cid）が適切に設定されていない場合に発生し、キャッシュの動作に影響を与える可能性があります。
    4. Use one-time login link instead of user login form in BrowserTestBase tests
      https://www.drupal.org/project/drupal/issues/3469309
      以下の5,6,7の変更があります。
    5. Issue #3469309 by mstrelan, smustgrave, moshe weitzman: Use one-time login link instead of user login form in BrowserTestBase tests
      https://git.drupalcode.org/project/drupal/-/commit/47614c475926990630af…
      #3469309は、BrowserTestBaseテストでユーザーログインフォームの代わりに一時ログインリンクを使用することに関するものです。この変更により、テストの信頼性と効率が向上します。
    6. Revert “Issue #3469309 by mstrelan, smustgrave, moshe weitzman: Use one-time login link instead of user login form in BrowserTestBase tests”
      https://git.drupalcode.org/project/drupal/-/commit/bff52f8e0f1aec30907a…
      #3469309の変更を元に戻すには、BrowserTestBaseテストで一時ログインリンクの代わりにユーザーログインフォームを再度使用するように修正します。
    7. Issue #3469309 by mstrelan, smustgrave, moshe weitzman: Use one-time login link instead of user login form in BrowserTestBase tests
      https://git.drupalcode.org/project/drupal/-/commit/332f671c2dcaf7e4c2e7…
      #3469309は、BrowserTestBaseテストでユーザーログインフォームの代わりに一時ログインリンクを使用することに関するものです。この変更により、テストの信頼性と効率が向上します。
    8. Aggregated asset generation causes uncacheable assets
      https://www.drupal.org/project/drupal/issues/3454507
      #3454507は、アグリゲートされたアセットの生成がキャッシュ不可能なアセットを引き起こす問題に関するものです。この問題を修正するためには、アセットのキャッシュ可能性を確保するための適切な対策を講じる必要があります。
    9. Fix Book breadcrumb cacheability
      https://www.drupal.org/project/drupal/issues/3472592
      #3472592は、ブックモジュールのパンくずリストのキャッシュ可能性に関する問題を修正するものです。この問題を修正するためには、パンくずリストが適切にキャッシュされるようにする必要があります。
    10. Drupal.dialog openDialog should use event settings
      https://www.drupal.org/project/drupal/issues/3471977
      #3471977は、Drupal.dialogのopenDialogメソッドがイベント設定を使用するように修正するものです。この変更により、ダイアログの動作がより柔軟になり、カスタマイズが容易になります。
    11. Buck to Dev
      https://git.drupalcode.org/project/drupal/-/commit/534009d37c47c684a310…
      #3471977を「Back to dev」に戻すためには、以前の状態に戻す必要があります。以下に、Drupal.dialogのopenDialogメソッドを元の状態に戻す例を示します。

10.3.5の変更内容を確認

10.3.5の変更は前記事で書いた10.3.4のUpDateで変更したCacheCollectorクラスでのnull $cidの修正を元に戻すアップデートとなっています。

前記事で書いていますので、簡単な説明となっています。

  • 10.3.5 Issue 解説

    1. This release reverts #3471741: Fix null $cid in CacheCollector classes, released in 10.3.4, which conflicted with Menu Trail by Path, Entity Manager and Gin Toolbar modules.
      https://www.drupal.org/project/drupal/issues/3471741
      #19
      https://git.drupalcode.org/project/drupal/-/commit/f01eb1bc38e59aeb8dad…
      // この問題（#3471741）は、CacheCollectorクラスでの$cidがnullになることが原因で、Menu Trail by Path、Entity Manager、およびGin Toolbarモジュールと競合することに関連しています。この問題を修正するための変更点は以下の通りです。
      // 修正内容の概要
      1. $cidの初期化:
          - CacheCollectorクラス内で$cidがnullにならないように初期化します。
      2. 競合の解消:
          - Menu Trail by Path、Entity Manager、およびGin Toolbarモジュールとの競合を解消するための修正を行います。
        // 具体的な手順
      3. CacheCollectorクラスの修正:
          - $cidがnullにならないように初期化し、必要に応じてsetCidメソッドで設定します。
      4. モジュールの更新:
          - Menu Trail by Path、Entity Manager、およびGin Toolbarモジュールがこの修正に対応するように更新します。

おわりに

今回初めて、Drupal Coreのアップデートで変更する内容を確認してみました。議題として上がっているIssueの解決策が多数アップデートで解決されています。drupal.orgのIssueで開発者の方がディスカッションしながら進め、Gitlabに具体的なコードを提示しているので、私自身がもう少し知識をつける事で理解が深まると感じています。

オープンソースの開発のルーティンのようなものも、なんとなく理解していたのですが、具体的な実例を自身が理解するために閲覧したのは初めての事で、理解が浅く記事を作成するのに予想外に時間がかかり自身の知識不足を痛感しました。

調べものをすることでDrupal公式サイトの見方や、Gitlabの見方も今回の件で少し理解出来た事も収穫となっています。Drupalを理解するために膨大な情報があり、これまでは、インストールやうまくいかない場合の調べ物でしか使っていなかったのですが世界中の開発者や利用者が公開している情報は貴重であり目を通す意義は大きく英語の情報がメインで億劫となりがちですが上手く活用できたらと考えています。

Drupal Coreも11.0系がリリースされており、11.0系の機能も、表面的でなくもう少し深く理解するきっかけが出来た事が今回の一番の収穫と考えています。

すべての記事を見る ↗