Magento 업그레이드 예상은 최신 설치에 적용된 수정 사항에 대한 정보를 수집하여 해당 수정 사항으로 인해 문제가 발생할 수 있는지 확인한 후 문제 해결에 소요되는 시간을 평가하는 프로세스입니다.
모든 수정은 그대로로 나눌 수 있습니다 오프 코어 와 의 코어 .
오프 코어 수정은 업그레이드로 덮어 쓰지 않는 수정입니다. 이들은 타사 확장 , 로컬 범위 (app / code / local / Mage)에 배치 된 핵심 파일 및 사용자 정의 테마 입니다.
에서 코어 수정 젠토에 직접 적용되는 핵심 파일 (응용 프로그램 / 코드 / 코어), 현지화 파일 (응용 프로그램 / 로케일 / ko 페이지), 핵심 템플릿 과 같은 몇 가지 자바 스크립트 , 외부 라이브러리 고려되어야 거의가 그럼에도 불구하고 정의되지 않습니다 .
오프 코어 수정
타사 확장
업그레이드 중에 타사 확장이 문제의 주요 원인입니다. 이는 더 많은 확장 프로그램을 분석 할 때 더 많은 시간이 필요함을 의미합니다.
가장 먼저 확인해야 할 것은 확장에서 제공하는 기능이 업그레이드하려는 Magento 버전에서 아직 구현되지 않았는지입니다. 예를 들어 Yoast_CanonicalUrl, Mxperts_CustomerAddress또는 일부 확장 Fontis_Wysiwyg은 Magento 1.3.xx 이하에서 널리 사용되었지만 이제는 핵심 Magento 기능의 일부이므로 더 이상 필요하지 않습니다.
그런 다음 확장 프로그램이 모두 필요한지 확인 (고객에게 문의)하는 것이 좋습니다. 설치 한 확장이있을 수 있지만 실제로 사용되지는 않습니다. 따라서이 시점에서 일종의 정리를하는 것이 좋습니다.
그런 다음 확인해야 할 중요한 사항은 나머지 각 확장명과 업그레이드하려는 Magento 버전의 호환성입니다. 일부 확장이 호환되지 않고 사용 가능한 유사한 확장이없는 경우 일부 기능을 잃어 버리거나 기존 확장을 수정하여 호환되도록 어려운 선택을 할 수 있습니다.
참고 : 타사 확장을 직접 수정하지 말고 오래된 확장을 확장 한 새 확장을 만든 다음 새 확장의 부트 스트랩 XML에 종속성을 설정하십시오.
모든 작업이 완료된 후 나머지 각 확장에 대한 실제 분석을 제공 할 수 있습니다. 항상 etc/config.xml파일 검사로 시작해야 합니다. 찾아야 할 3 가지가 있습니다.
- 클래스 재 작성 은 그 자체로는 깨끗한 기술이 아니지만 어떤 경우에는 다른 방법이 없습니다. 따라서 새 버전의 Magento에서 클래스를 다시 작성하면 잠재적 인 문제가 될 수 있습니다.
- 레이아웃 업데이트 는 업그레이드에 문제를 일으키지 않지만 확장 프로그램이 최신 Magento 버전에서 더 이상 사용되지 않는 블록을 참조하는 경우이 문제를 해결해야합니다.
- SQL 업데이트 는 업그레이드 과정에서 과소 평가 된 문제의 원인입니다. 타사 확장 프로그램이 기본 Magento 테이블의 일부 필드를 참조하는 외래 키를 만들 때 문제가 발생합니다. 결과적으로이 필드는 수정되지 않습니다. 그런 다음 기본 설치 스크립트가이 필드를 업데이트하려고하면 자동으로 실패합니다. 그 후에이 필드를 참조하는 모든 다음 설치 스크립트가 업그레이드를 중단시킵니다.
앱 / 코드 / 로컬 / 마법사
확장 프로그램을 완료 한 후에는 app/code/local/Mage디렉토리를 살펴볼 차례 입니다. 여기에서 수정 된 코어 파일이 local범위 로 이동되었습니다 . 그들 각각은 당신이 흰 머리카락을 고를 것입니다. 왜냐하면 당신이 거기에 수정 된 것이 무엇인지, 왜 그런지 알 수 없기 때문입니다. 따라서 각각을 원점과 비교하고 추가 된 기능을 새 버전의 해당 파일로 마이그레이션해야합니다.
커스텀 테마
마지막 번 오프 오프 코어 수정은 사용자 정의 테마입니다. 이것은 큰 문제는 아니지만 실제로는 회색 영역입니다. Magento 기본 테마는 버전마다 수정되고 있으며 각 사용자 지정 테마는 이러한 수정 중 일부를 모방해야합니다. 불행히도 찾아야 할 것과 마이그레이션해야 할 것을 결정하는 은색 총알은 없습니다. 따라서 업그레이드 후 몇 가지 중요한 놀라움과 작은 nitpicking을 준비하십시오.
핵심 수정
완벽한 세상에는 아무도 없습니다. 그러나 Magento 설치를 써드 파티 개발자가 악용 한 후 저렴한 가격으로 많은 것을 제공하면 무엇이든 기대할 수 있습니다. 따라서 코어 내 수정은 업그레이드 프로세스 중에 덮어 쓰게 됩니다. 대부분의 경우 오류가 발생하지 않지만 결과적으로 이러한 잔인한 방식으로 추가 된 기능은 손실됩니다.
코어 내 수정을 감지하는 유일한 방법은 Magento 설치의 모든 파일을 동일한 버전의 클린 파일과 비교하는 것입니다. git으로하는 것이 좋습니다. 왜? 모든 줄 바꿈과 공백을 잘 처리하기 때문에 간단합니다.
Magento 설치가 git에없는 경우에도 파일을 별도의 디렉토리에 복사 한 다음 git init를 실행할 수 있습니다. 그런 다음 초기 커밋을 수행하고 "깨끗한"Magento 파일을 복사 한 후 실행하십시오 git status. 다음과 같은 것을 얻을 것입니다 :
이제 수정 된 파일 수에 따라 git diff각 파일 또는 전체 배치에서 한 번에 실행할 수 있습니다 . 이렇게하면 모든 코어 내 수정 사항에 대한 포괄적 인 참조가 제공됩니다. phpStorm과 같은 git 시각화가 있다면 인생이 훨씬 쉽습니다.
git diff > changes.txt항상 손으로 수정 목록을 작성하는 것이 좋습니다 .
핵심 수정 사항 목록이 있으면 새 버전으로 전송해야 할 내용과이를 수행하는 데 얼마나 많은 시간이 필요한지 추정 할 수 있습니다.
이제 실제 업그레이드에 대한 조언을 드리고자합니다. 이 프로세스는 잘 문서화되어 있으므로 실행할 명령과 클릭 위치를 작성하지 않습니다. 그러나 몇 가지 중요한 사항에 악센트를 만들고 싶습니다.
- 개발 환경에서 업그레이드한다고 가정합니다. 프로덕션 서버에서 업그레이드를 실행하는 것은 자살입니다.
- 업그레이드하는 동안 프로덕션 환경에서 변경하지 마십시오. Magento를 버전 관리 또는 임시 잠금 파일 쓰기 금지 상태로 두십시오.
- 타사 확장 프로그램을 모두 사용 중지하지만 초기에 사용하지 않도록 설정 한 확장 프로그램을 확인하여 나중에 사용하지 않도록 설정합니다.
- 서버에서 Magento 정리 스크립트가 실행 중인지 확인하십시오. 그렇지 않으면로 시작하는 모든 테이블을 절단
dataflow_*, log_*, report_*.
- 업그레이드시 기본 테마로 되돌립니다.
업그레이드 스크립트가 완료된 후 :
changes.txt실제로 마이그레이션 할 가치가있는 모든 코어 내 수정을 마이그레이션하기 전에 수행 한 참조를 참조하십시오 .app/code/local/Mage업그레이드 전에 발견 된 수정 사항을 마이그레이션하십시오 .- 하나씩 확장하여 타사 확장을 사용합니다.
- 테마를 다시 설정하고 결과를 프로덕션 서버와 종합적으로 비교하십시오.
- 결과에 만족하면 프로덕션에 배포하십시오.
결론
나는 이것이 모두 무서운 것처럼 들리지만 정기적으로 업그레이드하고 핵심을 깨끗하게 유지하고 정말로 신뢰할 수있는 공급 업체의 확장 프로그램을 설치하고 정말로 필요한 경우에만이 기사에서 설명하는 어려움을 겪지 않을 것입니다. Magento EcoSystem을 건강하게 유지하면 보상을받을 수 있습니다.
포스트 스크립트
매우 복잡한 경우 최신 Magento를 새로 설치하여 모든 것을 시작하고 상점 테마와 기능을 단계별로 마이그레이션하는 것이 좋습니다. 이것은 확실히 시간이 걸리지 만 결국 당신은 무슨 일이 일어나고 있는지에 대한 완전한 인식과 함께 건강한 마 젠토 시스템을 갖게 될 것입니다.