성공적인 Drupal 7에서 9로의 마이그레이션 뒤에 숨겨진 과학(그리고 그 중 일부가 실패한 이유)

회사의 모든 사람이 새로운 시스템으로 마이그레이션해야 하는 것을 좋아하는(또는 최소한 허용한) 훌륭한 웹 사이트를 기억하십니까? 그리고 당신이 그렇게 믿었던 팀이 그들이 씹을 수 있는 것보다 더 많은 것을 씹을 수 있습니까? 한 때 완벽하게 보기 좋고 기능적인 웹 사이트였을 수도 있는 웹사이트가 이제는 기괴한 문제, 성능 저하 또는 때때로 거의 사용할 수 없는 사이트로 엉망이 됩니다.

이것이 친숙하게 들리고 Drupal 7(또는 6) 사이트를 Drupal 9(또는 8)로 업그레이드한 후 이상한 문제가 발생한다면 이 기사를 끝까지 읽으십시오 . Drupal 7(또는 6)을 Drupal 9(또는 8)로 업그레이드한 후 사이트 소유자가 직면하는 일반적인 문제와 해결 방법에 대해 알아보겠습니다. 이것은 우리가 이주 구조를 위해 방문할 때 보게 되는 모든 문제를 다루지는 않겠지만 적어도 밤에 잠을 잘 수 있는 지점까지는 이르게 해야 합니다.

Drupal 7에서 9로 업그레이드 - 기본 과제

아마도 당신이 스스로에게 묻는 첫 번째 질문은 "왜?"일 것입니다. Drupal 7에서 Drupal 9로 업그레이드(Drupal 8은 이제 중단됨)는 플랫폼 관점에서 그리 어렵지 않아야 하는 것 같습니다.

음, Drupal 8은 모든 것을 바꿨습니다. CMS가 더 지속 가능하고 관련성이 있으며 장기적으로 더 쉽게 사용할 수 있도록 아키텍처를 완전히 정비했습니다. 객체 지향 프로그래밍, Symfony, Twig, 최신 PHP 버전 등과 같은 최신 기술 및 프레임워크의 채택으로 Drupal 커뮤니티는 Drupal 구축에 도움이 되는 광범위한 기술을 수용함으로써 기하급수적으로 성장할 수 있었습니다. 즉, 이제 Drupal 웹사이트를 구축하고 유지 관리할 전문가를 찾는 것이 더 쉬워졌습니다. 좋은 소식은 초기 마이그레이션 후 Drupal의 향후 버전(예: Drupal 8에서 Drupal 9로)으로 업그레이드하는 것이 매우 쉽고 다시 빌드할 필요가 없다는 것입니다.

그러나 당면한 문제로 돌아가서 많은 조직이 여전히 웹사이트의 완전한 재구축을 포함하는 Drupal 7에서 9 로 마이그레이션하고 있습니다. 재구성 자체는 가장 노련한 개발자에게 적합할 수 있는 현재 콘텐츠 구조를 유지하지 않고도 충분히 복잡합니다. 그리고 대부분의 경우 대규모 웹사이트에는 직접적인 업그레이드 경로가 없는 여러 기여 및 사용자 지정 모듈이 있는 경향이 있으므로 더 많은 주의가 필요합니다. 이 모든 것이 함께 오류에 대한 무한한 기회를 엽니다.

이러한 유형의 마이그레이션을 시도하지 않은 팀의 경우 Drupal 7에서 9로의 첫 번째 마이그레이션 실수는 준비 부족입니다. 성공적인 Drupal 마이그레이션을 위한 첫 번째이자 가장 중요한 단계는 현재 웹사이트 구조의 모든 세부 사항을 분석하기 위해 철저한 마이그레이션 감사를 수행하는 것 입니다. 이 보고서는 마이그레이션의 의미를 평가하는 데 도움이 될 뿐만 아니라 개선 영역에 대한 통찰력도 제공합니다. 다음으로 가장 중요한 단계는 전문 Drupal 개발 파트너(매일 Drupal을 호흡하는 사람)가 마이그레이션을 수행하도록 허용할지 여부를 결정하는 것입니다. 심장 외과 의사가 정형 외과 의사보다 우회 수술을 선호하는 것과 같습니다. Drupal 웹사이트를 구축하기 위해 전문 Drupal 중심 회사를 갖는 것은 성공적인 마이그레이션으로 이어질 것입니다.

일반적인 Drupal 7-9 마이그레이션 과제

Drupal 6/7에서 8/9로 마이그레이션한 후 가장 흔한 좌절의 원인 중 하나는 문제를 다룰 때 어디서부터 시작해야 할지 모르는 것입니다. 코딩 기술이 있든 없든 실제 문제가 어디에 있는지 어떻게 알 수 있습니까? 간편함 - 오류 로그를 확인하십시오. 나는 당신이 로그가 말하는 내용을 이해하기 위해 또 다른 웜 캔을 여는 것처럼 들리지만 아래에서 일반적인 것들을 안내할 것입니다.

Drupal 7에서 Drupal 9로 마이그레이션한 후 Drupal 사이트 소유자가 직면하는 가장 일반적인 문제 중 일부를 바로 살펴보겠습니다.

웹사이트가 간신히 작동/손상됨

1. 서버 문제: 서버에 액세스할 수 있는 권한이 충분하지 않으면 서버가 손상될 수 있습니다. 오류 로그를 자세히 살펴보면 문제가 발생한 위치를 이해하는 데 도움이 됩니다. 서버 문제인 경우 서버에 액세스할 수 있는 충분한 권한이 있는지 확인하십시오. 공간 부족 문제가 발생하면 호스팅 제공업체에 문의하여 메모리 제한을 늘리십시오. 그래도 문제가 해결되지 않으면 서버 문제를 언급하면서 티켓을 제출하세요.
2. 사용자 지정 코드: Drupal 6/7 웹사이트가 예상보다 더 복잡한 경우 마이그레이션 전에 사용자 지정 코드를 평가하고 적절하게 매핑하는 대신 단순한 리프트 앤 시프트가 수행되었을 가능성이 있습니다. 페이지가 로드될 때 실행되는 사용자 정의 조건이 있고 연결된 사용자 정의 코드를 찾지 못하면 페이지가 깨집니다. 가장 먼저 해야 할 일은 마이그레이션 감사에서 웹사이트를 제대로 평가했는지 확인하는 것입니다(한 경우). 문제가 사용자 정의 조건 때문에 발생하고 코드가 누락된 경우 Drupal 개발자가 사용자 정의 코드 구현을 생성해야 합니다. 이상적으로는 콘텐츠를 마이그레이션하기 전에 사용자 지정 코드를 생성해야 합니다.
3. Core/Contrib 모듈: 때로는 이미 솔루션/패치가 있는 기여 모듈 또는 핵심에서 알려진 문제가 발생할 수 있습니다. 약간의 조사가 이것을 식별하는 데 도움이 될 수 있습니다. 패치를 찾아 적용하면 바로 사용할 수 있습니다.
4. 오래된 PHP 버전/라이브러리: 새 Drupal 사이트는 여전히 이전 버전의 PHP 또는 코드가 의존하는 라이브러리를 실행 중일 수 있습니다. 웹사이트가 최신 버전의 PHP 및 기타 라이브러리를 구현하는지 확인하세요. 또한 모든 시스템 요구 사항 및 구성이 충족되는지 확인하십시오.

페이지를 편집할 수 없음(권한 문제)

1. 500 오류: 500 내부 서버 오류가 발생하여 페이지를 편집할 수 없는 경우 다양한 이유(잘못 구성, 잘못된 코드, 잘못된 인덱싱, 집계 등)가 원인일 수 있습니다. 그러나 보다 일반적인 이유 중 하나는 필드 형식이 일치하지 않거나 필드가 누락되었기 때문일 수 있습니다. 예를 들어 Drupal 7 사이트의 날짜 필드가 올바른 형식으로 마이그레이션되지 않았거나 값이 Drupal 9 형식으로 변환되지 않은 경우 오류가 발생합니다. 또 다른 예는 Drupal 7에서는 이미지 필드를 사용했지만 Drupal 9에서는 미디어 필드를 대신 사용하는 경우입니다. 이 문제를 해결하는 가장 좋은 방법은 마이그레이션 스크립트를 수정하여 데이터를 올바르게 저장하는 것입니다. 편집할 필드가 몇 개 없는 경우 후크 업데이트를 생성할 수도 있습니다.
2. 403 오류: 종종 403 오류는 잘못된 권한 전송으로 인해 발생합니다. 권한이 올바르게 설정되었는지 확인하십시오. 모듈을 사용하여 사용자를 관리하는 경우 Drupal 9에서 사용할 수 있는지 확인하십시오. 때로는 일부 사용자에 대한 액세스를 제한하는 후크 또는 이벤트 구독자가 있을 수 있습니다. 이러한 조건을 확인하고 새 설치에서도 구현되었는지 확인하십시오.
3. 권한 페이지가 응답하지 않음: Drupal 사이트가 권한을 처리하기 위해 일부 사용자 정의 코드를 구현하고 있을 수 있습니다. 이 코드가 새로운 Drupal 9 사이트에서 구현되지 않으면 권한 페이지를 보거나 편집(또는 둘 다)하지 못할 수 있습니다. 때때로 사용자가 역할과 사용자 프로필을 적절하게 마이그레이션하지 않고 대량으로 마이그레이션되는 상황을 봅니다. 표준 관행으로 권한을 마이그레이션하기 전에 개발자는 사용자 지정 권한을 생성하고 이를 사람/권한의 역할에 할당해야 합니다.

비참한 웹 사이트 성능

1. 불필요한 모듈: 모듈은 Drupal 사이트의 빌딩 블록이므로 마이그레이션도 원할 것입니다. 그러나 때때로 우리는 모든 종류의 문제를 일으킬 수 있는 오래된 불필요한 Drupal 7 모듈이 Drupal 9로 옮겨지는 것을 봅니다. 특히 그들이 귀하의 사이트에 부담을 줄 수 있기 때문입니다. 다음은 일부 모듈을 마이그레이션할 필요가 없는 몇 가지 이유입니다.
   • 모듈(또는 그 기능)은 이미 Drupal Core로 이동했습니다. 예를 들어, 미디어 기여 모듈은 Drupal 8.5에서 코어로 이동하여 기여 모듈을 사용할 필요가 없습니다.
   • 그 기능은 간단하며 다른 사용자 정의 모듈에 삽입할 수 있습니다. 예를 들어, node::postSave 모듈이 하나 또는 두 개의 콘텐츠 유형에만 사용되어 노드가 생성된 후 사용자가 어디로 가야 하는지 선택하는 경우 대신 코드를 사용자 정의 모듈로 이동할 수 있습니다.
   • 모듈에 대한 요구 사항을 재평가해야 합니다. 때로는 사용성의 작은 변화가 웹사이트 성능을 크게 향상시킬 수 있습니다. 예를 들어, 콘텐츠 마케팅 팀이 크고 분산되어 있지 않는 한 모든 웹 사이트에는 실제로 콘텐츠 조정 모듈이 필요하지 않습니다. Drupal의 핵심 편집 워크플로 기능(Draft, Publish)은 복잡하고 세부적인 워크플로가 필요하지 않은 대부분의 비즈니스 요구 사항에 충분합니다.
   • 때로는 하위 모듈이 모듈과 함께 설치되지만 거의 사용되지 않습니다. 이러한 하위 모듈은 제거해야 합니다.
2. 동일한 아키텍처 복제: 마이그레이션에서 단순히 들어 올리고 이동하고 먼지를 제거하는 것이 더 쉽지만 좋은 접근 방식은 거의 없습니다. 특히 구형(Drupal 6/7) 아키텍처가 지저분하고 덜 견고하다면 더욱 그렇습니다. 비즈니스 로직/요구사항의 변경은 완전한 재설계가 필요할 수도 있습니다. 철저한 현장 감사를 통해 유지해야 하는 모듈과 안전하게 제거할 수 있는 모듈을 정확히 알려줍니다.

타사 통합이 더 이상 작동하지 않음

1. 오래된 API 버전: 웹사이트가 Salesforce, Marketo, Mailchimp 등과 같은 다른 타사 도구에 연결된 경우 잘못 실행된 마이그레이션이 이러한 통합의 작동 방식에 영향을 줄 수 있습니다. Drupal 통합 모듈에서 호출하는 API가 이전 버전인 경우가 많습니다. 유일한 수정 사항은 통합이 최신 버전의 타사 API로 작성되어야 한다는 것입니다.
2. 통합 모듈 문제: 통합 모듈 에서 타사 API가 올바르게 호출되고 있는지 확인해야 합니다. 매개변수가 적절하게 전달되고 있습니까? 설정 및 검색 방법을 확인하십시오. 해당 통합 모듈의 문제 대기열을 확인하십시오. 적용해야 하는 패치가 있을 수 있습니다. API가 Drupal 9에 제대로 이식되었는지 확인하려면 적절한 테스트를 수행해야 합니다.

기타 일반적인 문제 및 수정 사항

1. 모듈 설치: 항상 작곡가를 사용하여 모듈을 설치하십시오. 이것은 유효하지 않거나 사용할 수 없는 종속성으로 인한 오류를 방지합니다.
2. 마이그레이션 소스 불일치: 마이그레이션 소스가 무엇이든(CSV, Database, JSON, XML) 소스 필드가 대상 필드와 일치하는지 확인하십시오. CSV를 소스로 사용하는 경우 가져오기 순서를 염두에 두십시오. 콘텐츠 유형 매핑의 우선 순위는 중요합니다.
3. 이미지 경로: 여러 번 사용자는 CKEditor 콘텐츠 내에서 직접 이미지를 추가합니다. 이러한 이미지는 일반적으로 다른 미디어 파일이 있는 위치와 위치가 다르기 때문에 마이그레이션할 때 항상 지정된 경로로 이동하지 않습니다. 세심하게 계획된 마이그레이션이 이 문제를 처리해야 합니다.
4. SEO: Drupal 7에서 9로의 부주의한 마이그레이션은 웹사이트의 SEO에 여러 가지 영향을 줄 수 있습니다. 가장 중요한 문제 중 하나는 끊어진 링크입니다. 변경 사항으로 인해 수많은 링크가 끊어질 수 있으므로 기존 URL 구조 및 탐색이 보존되었는지 확인하십시오. 도로에 충돌이 없는지 확인하려면 완전한 SEO 감사를 수행해야 합니다.
5. Drupal 7 스타일: 개발자가 Drupal 8에서 가져온 변경 사항에 적응하는 대신 Drupal 7과 동일한 코딩 스타일을 사용하기 때문에 Drupal 7에서 Drupal 9로의 마이그레이션 문제(특히 성능 문제)가 자주 나타납니다. 예, (a) 종료 방법 페이지 캐시는 Drupal 8과 매우 다릅니다. (b) Drupal 8에는 구성 관리 기능이 내장되어 있지만 올바른 방식으로 구현되지 않거나 모든 환경에서 잘 유지되지 않는 경우가 많습니다. (c) Drupal 8 프로젝트가 여전히 절차적 코드 스타일을 구현하는 경우도 있습니다.