Drupal 6または7からDrupal 8へのアップグレード時の既知の問題
Drupal 6から8
アグリゲーターカテゴリ
Drupal 8にはアグリゲーターカテゴリの概念がなくなり、そのためDrupal 8には移行されません。
許可されたプロトコル
Drupal 8では、プロトコルはコンテナパラメーター「filter_protocols」に保存されるようになりました。そのため、「filter_allowed_protocols」変数を変更した場合は、それをservices.ymlファイルに入力してください。
タクソノミー参照フィールドの許可されたボキャブラリ
Drupal 6では、特定のボキャブラリに適用可能なコンテンツタイプのリストはボキャブラリ設定で定義されます。Drupal 8では、許可されたボキャブラリはタクソノミー用語参照フィールドの設定で定義できます。この設定は現在移行されないため、Drupal 8ではすべてのボキャブラリを参照できます。アップグレード後、Drupal 8でタクソノミー用語参照フィールドの設定を手動で編集し、許可されたボキャブラリを選択できます。
[修正済み]日付形式
デフォルト、短い、中、長い形式のみが移行されます。その他の形式はデフォルトのフォールバック形式になり、移行後に再設定する必要があります。
編集フォームまたは表示ページに表示されないフィールド
混乱を招く可能性のあるもう1つの点は、成功したように見える移行を実行したが、その後編集フォームにフィールドが表示されない場合です。コンテンツタイプの管理ページに移動し、各コンテンツタイプの「フォーム表示の管理」タブを開きます。アップグレードで追加されたフィールドが編集フォームで非表示になっている場合があります。その場合は、それらを上にドラッグして表示させてください。同様に、ノード表示に表示されない場合は、Migrateによって追加されたフィールドが「表示の管理」タブで非表示になっている可能性があり、そこで表示する必要があるかもしれません。ユーザー定義フィールドのエンティティへの移行には、Migrate Plusモジュールが役立ちます。
ホームページが読み込まれずテーマが動作しない
移行の実行中、ページが白くなり、いくつかの要素だけが読み込まれることがあります。基本的に、これは壊れたテーマのように見えます。通常、/userにアクセスしてホームページに戻ると解決します。
メニューUI
menu_primary_links_sourceおよびmenu_secondary_links_source変数は、Drupal 8に対応するものがないため移行されません。
モジュールとテーマ
移行を開始する前に、新しいモジュールとテーマを有効にし、管理者テーマを設定する必要があります（存在する場合）。
ノードコンテンツタイプ
Drupal 6のデフォルト設定にはStoryとPageのコンテンツタイプがあります。Drupal 8のデフォルトコンテンツタイプはArticleとBasic Page（Drupal 6と同じくマシン名が'page'）です。
- これらのコンテンツタイプのマシン名が同じであるため、移行はDrupal 6のPageコンテンツタイプをDrupal 8のPageタイプにマッピングします。
- 移行はDrupal 8用にStoryコンテンツタイプを作成します。不要な場合は、Drupal 8のArticleコンテンツタイプを削除することを検討してください。詳細については、
#2236289: D6からの「ストーリー」ノードの移行がD8で新しいコンテンツタイプを作成する。を参照してください。
ノード翻訳
Drupal 6および7では、ノード翻訳は異なるノードに保存されていましたが、Drupal 8ではソース言語ノードと結合されるようになりました。移行システムがノード翻訳の結合を実行しますが、これは一部のリンクがもう存在しないノードを指す可能性があることを意味します。異なるIDを持つDrupal 6および7のノード翻訳に関連するデータの処理については、#2746527: [META]を参照してください。
翻訳されたノードのリビジョンはまだ移行されていないことに注意してください。詳細については、#2746541: [backport] D6およびD7のノードリビジョンをD8に移行を参照してください。
多言語Drupal 6からDrupal 8へのアップグレードの概要。
プロフィールカテゴリ
Drupal 6のプロフィールモジュールでグループ化されたフィールドは、Drupal 8ではグループ化されません。
プロフィールフィールド（リスト選択）
Drupal 8の結果フィールドの「許可された値」設定は、Drupal 6の許可された値のみではなく、すべてのユーザー選択値とDrupal 6の現在の許可値の組み合わせになります。
統計
アクセスログ設定と統計データはi18nとして移行されません。i18n統計データの統合はDrupal 8.5.2以降に移行されます。#2930101: i18n/統計 - 翻訳のノードカウンターが更新されない。を参照してください。
テキスト/入力形式
Drupal 8が認識しないフィルターフォーマットは、単に空文字列を返すフィルターであるfilter_nullとして移行されます。これは、未知のフィルターフォーマットを使用する入力形式は、コンテンツがデータベースにあるにもかかわらず、フィールドのコンテンツを表示しないことを意味します。これは混乱を招く可能性があります。#2618332: filter_nullによる欠落フィルターの置換のより良い処理および#2630578: D6アップグレードで重複した形式を参照してください。
Drupal 8が認識しないフィルターフォーマットには、悪名高いPHPコードフィルターや、Drupal 8のインストールで利用できないcontribモジュールによって提供されるその他のフィルターが含まれます。
PHPフィルターはDrupal 8コアではサポートされていません - これは非常に悪い習慣ですが、本当に必要な場合はPHPモジュールを使用できます。
この状況を修正するには、いくつかの代替手段があります：
- フィルターを提供するモジュールにDrupal 8バージョンがあるか確認し、インストールします
- 影響を受ける入力形式を編集して保存します。これによりformat_nullへの参照が削除され、コンテンツが表示されるようになります。元のフィルターが存在しないため、コンテンツはフィルタリングされず、置換されていないトークンが表示されたり、サイトがセキュリティ問題にさらされる可能性があることに注意してください
- コンテンツを編集して別の入力形式に変更します。これにより、前の項目と同じ問題が発生します
タイムゾーンと日付
Drupal 6は現地時間を計算するためにタイムゾーンオフセットを使用します。Drupal 7とDrupal 8はタイムゾーン名を使用します。残念ながら、オフセットをタイムゾーン名に変換するPHP関数timezone_name_from_abbr()は、サーバーで夏時間が有効かどうかによって異なるタイムゾーン名を生成します。たとえば、オフセット3600は、夏時間が無効の場合はEurope/Parisに変換され、夏時間が有効の場合はEurope/Londonに変換されます。移行は夏時間を無視するように設定されています。サーバー設定によっては、移行後にDrupal 8のタイムゾーン設定が間違っている可能性があります（#2353679: 欠落しているD6->D8移行変数: date_default_timezone）。
夏時間を使用するタイムゾーンでは、日付がDrupal 6と比較してDrupal 8で異なる解釈をされる可能性があります。たとえば、時間が真夜中頃の場合、日付が別の日として扱われる可能性があります。これは、特にパスを構築するために日付トークン（URLエイリアス、ファイルフィールドパスなど）が使用される場合に問題を引き起こします。2つの可能な解決策は#2926421: D6とD8の間の日付の不一致の処理に示されています。
URLエイリアス
新しいDrupal 8サイトで有効になっていない言語のURLエイリアスを移行する場合、新しいDrupal 8サイトでその言語を有効にするまで、どのエイリアスも機能しません。
Views
Viewsはまだ移行されていないため、Drupal 8で手動でビューを作成する必要があります。詳細については、#2500547: Drupal 6および7からのViewsのアップグレードパスとViews Migrationモジュールを参照してください。
ユーザーアクティビティブロックの設定
ユーザーアクティビティ設定は移行されません。これは、対応するビューのフィルター/アクセスセクションで手動で編集する必要があります（#2169327: ユーザーアクティビティブロック設定を移行）。
Drupal 7から8
[修正済み]タクソノミー用語の許可されたボキャブラリ
Drupal 7では、タクソノミー用語参照フィールドの許可されたボキャブラリは、タクソノミー用語参照フィールドの設定で定義されます。この設定は現在移行されないため、Drupal 8ではすべてのボキャブラリを参照できます。（#2763637: D7のタクソノミー用語フィールドが許可されたボキャブラリと共に移行されないを参照）。アップグレード後、Drupal 8でタクソノミー用語参照フィールドの設定を手動で編集し、許可されたボキャブラリを選択できます。
ブロックされたIPアドレス
Drupal 7のban_ipテーブルのid列は移行されません。
コメントタイプ
Drupal 7では、コメントはコンテンツタイプごとに異なるフィールドを持つことができます。通常、コメントには著者、件名、コメントのフィールドがあります。異なるD7コメントは異なるフィールドを持つ可能性があるため、移行では各コンテンツタイプに対して個別のD8コメントタイプが作成されます：
- コンテンツタイプFooにはcomment_node_fooコメントタイプがあります
- コンテンツタイプBarにはcomment_node_barコメントタイプがあります
唯一の例外はフォーラムのコメントです。D8のForumモジュールが有効な場合、comment_forumコメントタイプが自動的に作成されます。D7のフォーラムコメントはこのコメントタイプに移行されます。
重要な注意：Drupal 8の標準インストールプロファイルと記事コンテンツタイプ
Drupal 8サイトが標準インストールプロファイルを使用してインストールされた場合、Articleという名前のコンテンツタイプがあります。
- このコンテンツタイプには、commentという名前のコメントフィールドが付属します。
- 移行システムは、D8サイトが標準インストールプロファイルを使用してインストールされたと想定できません。そのため、comment_node_articleコメントタイプが作成され、D7の記事コンテンツタイプのコメントがこのコメントタイプに移行されます。
その結果、Articleコンテンツタイプには2つのコメントフィールドがあります：
- comment - D8標準インストールプロファイル由来で未使用
- comment_node_article - 移行システムによって作成
おそらく、Articleコンテンツタイプに2つのコメントフィールドを持ちたくないでしょう。そのため、Articleからcommentコメントフィールドを手動で削除する必要があります（admin/structure/types/manage/article/fields）。これを行った後、commentコメントタイプをどこでも使用していない場合は、コメントタイプも削除できます（admin/structure/comment）。
Drupal 8コアには現在コメントフィールドの削除に関連するバグがあるため、移行を実行する前にArticleコンテンツタイプから不要なコメントフィールドを削除することをお勧めします。#2906470: コメントフィールドインスタンスの削除後、comment_entity_statisticsのコメントとレコードが失われるを参照してください。
PHPコード
Drupal 8が認識しないフィルターフォーマットは、単に空文字列を返すフィルターであるfilter_nullとして移行されます。これは、未知のフィルターフォーマットを使用する入力形式は、コンテンツがデータベースにあるにもかかわらず、フィールドのコンテンツを表示しないことを意味します。
Drupal 8が認識しないフィルターフォーマットには、悪名高いPHPコードフィルターや、Drupal 8のインストールで利用できないcontribモジュールによって提供されるその他のフィルターが含まれます。
PHPフィルターはDrupal 8コアではサポートされていません - これは非常に悪い習慣ですが、本当に必要な場合はPHPモジュールを使用できます。
この状況を修正するには、いくつかの代替手段があります：
- フィルターを提供するモジュールにDrupal 8バージョンがあるか確認し、インストールします
- 影響を受ける入力形式を編集して保存します。これによりformat_nullへの参照が削除され、コンテンツが表示されるようになります。元のフィルターが存在しないため、コンテンツはフィルタリングされず、置換されていないトークンが表示されたり、サイトがセキュリティ問題にさらされる可能性があることに注意してください
- コンテンツを編集して別の入力形式に変更します。これにより、前の項目と同じ問題が発生します
プレーンテキストフィールド
Drupal 7での矛盾するテキスト処理設定
Drupal 7では、テキスト処理オプションはフィールドインスタンスの設定で定義されます。つまり、同じフィールドを2つ（以上）のコンテンツタイプで使用でき、テキスト処理オプションはあるコンテンツタイプでは「プレーンテキスト」、別のコンテンツタイプでは「フィルター済みテキスト」にすることができます。
Drupal 8には、Text（プレーン）とText（フォーマット済み）の別々のフィールドストレージタイプがあります。また、Text（プレーン、長文）とText（フォーマット済み、長文）もあります。ここで重要なのは、この選択がフィールドのストレージレベルで行われることです。つまり、プレーン/フォーマット済みの選択をコンテンツタイプごとに変更することはできません。
移行システムは何も想定しません。移行システムが矛盾するテキスト処理設定を検出した場合、これらのフィールドはログメッセージとともにスキップされます。サイトビルダーには2つのオプションがあります：
1. Drupal 7サイトでテキスト処理設定を変更して、テキストフィールドを使用するすべてのコンテンツタイプが同じテキスト処理設定を持つようにできます。
- 処理設定を調整する方法を選択する際は、クロスサイトスクリプティング（XSS）の潜在的なセキュリティ問題を回避するために注意してください。
- Drupal 7でフィールドが「プレーンテキスト」に設定され、信頼できないユーザーがそのフィールドにコンテンツを投稿できた場合、そのフィールドには悪意のある入力が含まれている可能性があります。フィールドがプレーンテキストに設定されていたため、Drupal 7サイトではこれはXSSを引き起こしませんでした。つまり、悪意のある入力は実行されませんでした。フィールドを今フィルター済みテキストに変更する場合は、テキスト形式が完全なHTMLなど、悪意のある入力を許可するものでないことを確認してください。
2. Drupal 8で2つの異なるフォーマット設定が必要な場合は、Drupal 7のフィールドを2つの別々のDrupal 8フィールドに分割する独自の移行を開発する必要があります。Drupal 8へのアップグレード時の移行のカスタマイズの詳細については、ここを参照してください：Drupal 8へのアップグレード時の移行のカスタマイズ。
Drupal 7の要約付きテキスト + プレーンテキストフォーマット設定
Drupal 7には、長文テキストと要約のフィールドタイプがあります。Drupal 8の対応するフィールドタイプは、Text（フォーマット済み、長文、要約付き）です。Drupal 7では、フィールドインスタンスの設定でテキスト処理がプレーンテキストであるように設定できます。Text（フォーマット済み、長文、要約付き）フィールドはDrupal 8では常にフォーマット済みテキストです。
移行システムは何も想定しません。移行システムがプレーンテキストフォーマット設定の「長文テキスト」と「要約」フィールドを検出した場合、フィールドはログメッセージとともにスキップされます。サイトビルダーには上記と同じ2つのオプションがあります：
1. Drupal 7でフィールドのフォーマット設定をプレーンテキストからフィルター済みテキストに変更します。
- 上記のクロスサイトスクリプティングに関する注意もここに適用されます。
2. 独自の移行パスを作成し、フィールドをDrupal 8に移行する方法の独自のロジックを作成します。Drupal 8へのアップグレード時の移行のカスタマイズの詳細については、ここを参照してください：Drupal 8へのアップグレード時の移行のカスタマイズ。
統計
アクセスログ設定と統計データはi18nとして移行されません。i18n統計データの統合はDrupal 8.5.2以降に移行されます。#2930101: i18n/統計 - 翻訳のノードカウンターが更新されないを参照してください。
Views
Viewsはまだ移行されていないため、Drupal 8で手動でビューを作成する必要があります。詳細については、#2500547: Drupal 6および7からのViewsのアップグレードパスとViews Migrationモジュールを参照してください。
潜在的なID競合（D6またはD7からDrupal 8）
問題
アップグレードの準備ページで説明されているように、アップグレードプロセスを実行する際、Drupal 8サイトは完全に空である必要があります。移行プロセスは、ソースサイトのIDをDrupal 8サイトにインポートするときに保持します。アップグレード前にDrupal 8サイトでコンテンツが作成された場合（例：nid 1のノード）、IDが競合する可能性が高いです。
潜在的なID競合の自動検出とユーザーへの警告に関する作業が現在進行中です。#2876085: アップグレード前に潜在的なID競合をチェックするを参照してください。現時点では、サイト管理者が可能な競合を注意深く検討する必要があります。ID競合を慎重に処理しないと、コンテンツや、タクソノミー用語やファイルなどの他のエンティティ要素が上書きされ、データが失われる可能性があります。また、参照オブジェクトが破損する可能性もあります。たとえば、コンテンツが間違ったタクソノミー用語にリンクされる可能性があります。
ID競合を引き起こす可能性のあるシナリオ
- アップグレード時にターゲットのDrupal 8サイトが既に使用されており、コンテンツが既に作成されていた。
- 初期移行が完了した。初期移行後、ソースサイトとターゲットサイトの両方でコンテンツやその他のオブジェクトが作成された。更新された/新しく作成されたコンテンツがソースサイトから移行されたとき、IDがDrupal 8サイトで作成されたコンテンツと競合する可能性がある。
- Drupal 8の宛先はクリーンな状態だったが、追加されたモジュールやカスタムモジュールがDrupal 8で有効化されたときに独自の使用のためにデータを追加した可能性がある。たとえば、Drupal 8のコアフォーラムモジュールは、一般討論カテゴリ用のタクソノミー用語を作成し、通常は新しいインストールでID #1を取得します。ソースデータにID 1のタクソノミー用語が含まれている場合、フォーラムの一般討論カテゴリ名を上書きします。
- ソースにはIDのないデータが含まれている可能性があるが、宛先ではIDが必要である。たとえば、Drupal 6はユーザー画像をIDのないアンマネージドファイルとして扱いますが、Drupal 8の宛先ではIDが必要です。移行中に、まだ移行されていないファイルと競合する可能性のあるIDを持つマネージドファイルフィールドが作成されます。
- 翻訳との潜在的なID競合は自動的に検出されません。
- 一度に完全なアップグレードを実行し、空のDrupal 8サイトにアップグレードする場合は、すべて問題ないはずです。
- 初期アップグレード後に部分移行を実行し、更新された/新しく作成されたコンテンツを移行する前にDrupal 8サイトに翻訳を追加した場合、2回目の移行がDrupal 8サイトで行われた翻訳を上書きする可能性があります。
解決策
競合要素のカスタム移行
問題のあるコンテンツに対して、問題のある要素の新しいIDを作成するように移行をカスタマイズできます。これは内部パス、場合によっては公開URLに影響することに注意してください。変更されたオブジェクトへのリンクの修正には特に注意してください。
オートインクリメント値の操作
Drupal 8の宛先に競合するデータがないが、移行プロセスが競合を引き起こす可能性がある場合、Drupal 8データベーステーブルのAUTO_INCREMENT値を操作して、作成されたエンティティのIDが他の移行されたエンティティの範囲に入らないようにできます。上記のユーザー画像の移行はこの例です。
データが上書きされる可能性を受け入れる
移行の実行を続行することは常に可能です。データが失われる可能性があるため、これは多くの場合望ましい解決策ではないでしょう。
多言語サイトのアップグレード（D6またはD7からDrupal 8）
Drupal 6およびDrupal 7の国際化（i18n）モジュールとDrupal 7のエンティティ変換モジュールからのすべての多言語移行には、Drupal 8サイトでコアのDrupal 8 Migrate Drupal Multilingual Module（migrate_drupal_multilingual）が有効になっている必要があります。