Drupal 7から9への移行の成功の背後にある科学（およびそれらの一部が失敗する理由）

あなたの会社の誰もがあなたが新しいシステムに移行することを余儀なくされたことを愛した（または少なくとも許容した）素晴らしいウェブサイトを覚えていますか？ そして、あなたがそうすることを信頼したチームは、彼らが噛むことができるよりも多分少し離れていますか？ かつては完全に見栄えが良く機能的なWebサイトであったものが、今では奇妙な問題、パフォーマンスの低下、または場合によってはほとんど使用できないサイトの混乱になっています。

これがおなじみのように聞こえ、Drupal 7（または6）サイトをDrupal 9（または8）にアップグレードした後に奇妙な問題が発生した場合は、この記事を最後まで読んでください。 Drupal 7（または6）をDrupal 9（または8）にアップグレードした後、サイト所有者が直面する一般的な問題とその解決方法について説明します。 これは、私たちが移行救助のためにやってきたときに私たちが目にするすべての問題をカバーするわけではありませんが、少なくとも夜に眠ることができるポイントにあなたを連れて行くはずです。

Drupal7から9へのアップグレード-基本的な課題

あなたがおそらくあなた自身に尋ねている最初の質問は、「なぜ？」です。 Drupal7からDrupal9へのアップグレード（Drupal 8は廃止されました）は、プラットフォームの観点からはそれほど難しいことではないようです。

さて、Drupal8はすべてを変えました。 CMSがより持続可能で、関連性があり、長期的にコツをつかむのがより簡単になるように、完全なアーキテクチャのオーバーホールが行われました。 オブジェクト指向プログラミング、Symfony、Twig、最新のPHPバージョンなどの最新のテクノロジーとフレームワークの採用により、Drupalの構築を支援する幅広いスキルに対応することで、Drupalコミュニティを飛躍的に成長させることができました。 つまり、DrupalWebサイトを構築および保守する専門家を見つけるのが簡単になりました。 すばらしいニュースは、最初の移行後にDrupalの将来のバージョン（Drupal8からDrupal9など）にアップグレードするのは非常に簡単で、再構築する必要がないことです。

しかし、目前の問題に戻ると、多くの組織はまだDrupal 7から9に移行しており、これにはWebサイトの完全な再構築が含まれます。 再構築自体は、現在のコンテンツ構造を維持せずに十分に複雑であるため、最も熟練した開発者に適合させることができます。 そして、ほとんどの場合、大規模なWebサイトには、直接のアップグレードパスを持たない複数の寄稿されたカスタムモジュールがある傾向があるため、さらに注意を払う必要があります。 これらすべてが一緒になって、エラーの無限の機会が開かれます。

このタイプの移行を試みていないチームにとって、多くの場合、最初のDrupal7から9への移行の間違いは準備不足です。 Drupalの移行を成功させるための最初の最も重要なステップは、現在のWebサイト構造の細部をすべて分析するために徹底的な移行監査を行うことです。 このレポートは、移行の影響を評価するのに役立つだけでなく、改善の領域に関する洞察も提供します。 次の最も重要なステップは、専門のDrupal開発パートナー（Drupalを毎日呼吸する人）に移行を許可するかどうかを決定することです。 整形外科医よりも心臓外科医がバイパス手術を行うことを好むのと同じように。 Drupalに焦点を当てた専門の会社がDrupalWebサイトを構築することで、移行を成功させることができます。

一般的なDrupal7から9への移行の課題

Drupal 6/7から8/9への移行後の最も一般的なフラストレーションの原因の1つは、問題に対処するときにどこから始めればよいかわからないことです。 コーディングスキルの有無にかかわらず、実際の問題がどこにあるかをどのように見つけますか？ 簡単-エラーログを確認してください。 ログの内容を理解しようとしているワームの別の缶を開いているように聞こえますが、以下で一般的なものについて説明します。

Drupal7からDrupal9への移行後に、Drupalサイトの所有者が直面する最も一般的な問題のいくつかに直接飛び込みましょう。

ウェブサイトはかろうじてアップ/壊れています

1. サーバーの問題：サーバーにアクセスするための十分な権限がない場合、サーバーが危険にさらされる可能性があります。 エラーログを詳しく調べると、問題の原因を理解するのに役立ちます。 サーバーの問題である場合は、サーバーにアクセスするための十分な権限があることを確認してください。 スペース不足の問題が発生した場合は、ホスティングプロバイダーに連絡して、メモリ制限を増やしてください。 それでも問題が解決しない場合は、サーバーの問題について言及したチケットを提示してください。
2. カスタムコード： Drupal 6/7 Webサイトが予想よりも複雑だった場合、移行前にカスタムコードを評価して適切にマッピングする代わりに、単純なリフトとシフトが実行された可能性があります。 ページの読み込み時に起動するカスタム条件があり、それに関連付けられたカスタムコードが見つからない場合は、ページが壊れてしまいます。 最初に行うことは、移行監査でWebサイトを適切に評価したかどうかを確認することです（行った場合）。カスタムモジュールとコードを確認します。 問題の原因がカスタム条件であり、コードが欠落している場合は、Drupal開発者がカスタムコードの実装を作成する必要があります。 理想的には、コンテンツを移行する前にカスタムコードを作成しておく必要があります。
3. コア/貢献モジュール：コアまたは貢献モジュールで既知の問題が発生し、すでにソリューション/パッチが存在する場合があります。 少し調べれば、これを特定するのに役立ちます。 パッチを見つけて適用すれば、準備は完了です。
4. 古いバージョンのPHP/ライブラリ：新しいDrupalサイトで、コードが依存している古いバージョンのPHPまたはライブラリがまだ実行されている可能性があります。 Webサイトが最新バージョンのPHPおよびその他のライブラリを実装していることを確認してください。 また、すべてのシステム要件と構成が満たされているかどうかを確認してください。

ページを編集できない（権限の問題）

1. 500エラー： 500内部サーバーエラーが発生したためにページを編集できない場合は、さまざまな理由（設定ミス、コードの誤り、インデックスの誤り、集計など）が原因である可能性があります。 ただし、より一般的な理由の1つは、フィールド形式の不一致またはフィールドの欠落が原因である可能性があることです。 たとえば、Drupal 7サイトの日付フィールドが正しい形式に移行されていない場合、または値がDrupal 9形式に変換されていない場合、エラーがスローされます。 もう1つの例は、Drupal 7で[画像]フィールドを使用していたが、Drupal9では代わりにメディアフィールドを使用している場合です。 これを修正する最善の方法は、データを適切に保存するように移行スクリプトを修正することです。 編集するフィールドが少ない場合は、フックの更新を作成することもできます。
2. 403エラー：多くの場合、403エラーは権限の誤った転送が原因です。 権限が正しく設定されているかどうかを確認してください。 モジュールを使用してユーザーを管理している場合は、それがDrupal 9で使用可能かどうかを確認してください。フックやイベントサブスクライバーが、一部のユーザーへのアクセスを制限している場合があります。 これらの条件をチェックし、新しいインストールにも実装されていることを確認してください。
3. アクセス許可ページが応答していません： Drupalサイトがアクセス許可を処理するためのカスタムコードを実装している可能性があります。 このコードが新しいDrupal9サイトに実装されていない場合、権限ページを表示または編集（または両方）できない可能性があります。 場合によっては、ユーザーの役割とユーザープロファイルを適切に移行せずに、ユーザーが一括で移行される状況が見られます。 標準的な方法として、権限を移行する前に、開発者はカスタム権限を作成し、それらを人/権限からの役割に割り当てる必要があります。

悲惨なウェブサイトのパフォーマンス

1. 不要なモジュール：モジュールはDrupalサイトの構成要素であるため、モジュールも移行する必要があります。 しかし、古い不要なDrupal7モジュールがDrupal9に移動され、あらゆる種類の問題が発生することがあります。 特に彼らはあなたのサイトを圧迫する可能性があるので。 一部のモジュールを移行する必要がない理由は次のとおりです。
   • モジュール（またはその機能）はすでにDrupalCoreに移動しています。 たとえば、メディア寄稿モジュールはDrupal 8.5のコアに移動しました。これにより、寄稿モジュールを使用する必要がなくなります。
   • その機能はシンプルで、別のカスタムモジュール内に挿入できます。 たとえば、node :: postSaveモジュールを1つまたは2つのコンテンツタイプにのみ使用して、ノードの作成後にユーザーが移動する場所を選択する場合、代わりにコードをカスタムモジュールに移動できます。
   • モジュールの要件を再評価する必要があります。 場合によっては、ユーザビリティを少し変更するだけで、Webサイトのパフォーマンスが大幅に向上することがあります。 たとえば、コンテンツマーケティングチームが大きく分散している場合を除いて、すべてのWebサイトにコンテンツモデレーションモジュールが必要なわけではありません。 Drupalのコア編集ワークフロー機能（ドラフト、公開）は、複雑で詳細なワークフローを必要としないほとんどのビジネス要件に十分対応できます。
   • 場合によっては、サブモジュールがモジュールと一緒にインストールされますが、使用されることはめったにありません。 このようなサブモジュールは削除する必要があります。
2. 同じアーキテクチャを複製する：移行から手を持ち上げてシフトし、ほこりを払う方が簡単ですが、それが良いアプローチになることはほとんどありません。 特に、古い（Drupal 6/7）アーキテクチャが乱雑で、堅牢性が低い場合。 ビジネスロジック/要件の変更には、完全な再アーキテクチャも必要になる可能性があります。 徹底的なサイト監査により、どのモジュールを保持する必要があり、何を安全に排除できるかが正確にわかります。

サードパーティの統合は機能しなくなりました

1. 古いAPIバージョン： WebサイトがSalesforce、Marketo、Mailchimpなどのさまざまなサードパーティツールに接続されている場合、不適切に実行された移行は、これらの統合の動作に影響を与える可能性があります。 多くの場合、Drupal統合モジュールで呼び出しているAPIは古いバージョンです。 唯一の修正は、統合を最新バージョンのサードパーティAPIで作成する必要があることです。
2. 統合モジュールの問題：統合モジュールでサードパーティのAPIが正しく呼び出されているかどうかを確認する必要があります。 パラメータは適切に渡されていますか？ それらがどのように設定および取得されるかを確認してください。 その統合モジュールの発行キューを確認してください。 適用する必要のあるパッチが利用可能である可能性があります。 APIがDrupal9に適切に移植されていることを確認するには、適切なテストを行う必要があります。

その他の一般的な問題と修正

1. モジュールのインストール：モジュールのインストールには、常にcomposerを使用してください。 これにより、無効/使用できない依存関係によるエラーを回避できます。
2. 移行元の不一致：移行元（CSV、データベース、JSON、XML）に関係なく、移行元のフィールドが移行先のフィールドと一致していることを確認してください。 ソースとしてCSVを使用している場合は、インポートの順序を覚えておいてください。コンテンツタイプをマッピングする際の優先順位が重要です。
3. 画像パス：多くの場合、ユーザーはCKEditorコンテンツ内に直接画像を追加します。 これらのイメージは、通常、他のメディアファイルが配置されている場所とは場所が異なるため、移行時に常に指定されたパスに移動するとは限りません。 綿密に計画された移行により、この問題に対処する必要があります。
4. SEO： Drupal 7から9への移行を怠ると、WebサイトのSEOにさまざまな影響を与える可能性があります。 最も重要な問題の1つは、リンク切れです。 変更を加えると大量のリンクが壊れることがあるため、既存のURL構造とナビゲーションが保持されていることを確認してください。 道路に段差がないことを確認するために、完全なSEO監査を行う必要があります。
5. Drupal 7スタイル：開発者がDrupal 8によってもたらされた変更に適応する代わりに、Drupal 7と同じコーディングスタイルを使用するため、Drupal7からDrupal9への移行の問題（特にパフォーマンスの問題）が発生することがよくあります。ページキャッシュはDrupal8では大きく異なります。 （b） Drupal 8には構成管理が組み込まれていますが、多くの場合、適切な方法で実装されていないか、すべての環境で適切に維持されていません。 （c） Drupal8プロジェクトがまだ手続き型コードスタイルを実装している場合もあります。