Оценка обновления Magento - это процесс сбора информации об изменениях, внесенных в установку, которую вы собираетесь обновить, проверки того, могут ли эти изменения вызвать проблему, а затем оценки того, сколько времени потребуется для их устранения.

Все модификации можно буквально разделить на внеядерные и внутриядерные.

Внесистемные модификации - это те, которые не будут перезаписаны при обновлении. Это сторонние расширения, основные файлы помещаются в локальную область (приложение/код/локальный/Маг) и пользовательскую тему .

Изменения в ядре применяются непосредственно к файлам ядра Magento (приложение/код/ядро), файлам локализации (приложение/локаль/en_US), шаблонам ядра и некоторым вещам, таким как javascripts, внешние библиотеки, которые редко настраиваются, тем не менее, должны быть приняты во внимание.

Вне ядра Модификации

Сторонние расширения

Во время обновлений сторонние расширения являются основным источником проблем. Это означает, что чем больше расширений, тем больше времени вам понадобится для их анализа.

Первое, что нужно проверить, - это то, что функциональность, предоставляемая расширением, еще не реализована в версии Magento, до которой вы обновляетесь. Например, некоторые расширения, такие как Yoast_CanonicalUrl, Mxperts_CustomerAddress или Fontis_Wysiwyg широко использовались в Magento 1.3.x.x и старше, но теперь являются частью основного Magento функциональность и больше не требуется.

Тогда неплохо проверить (спросить своего клиента), действительно ли вам нужны все те расширения, которые у вас есть. Возможно, вы установили некоторые расширения, но никогда по-настоящему не использовали их. Так что на этом этапе хорошо бы провести своего рода очистку.

Тогда важно проверить совместимость каждого из оставшихся расширений с версией Magento, до которой вы обновляетесь. В случае, если некоторые расширения несовместимы и никакие аналогичные расширения не являются доступный у вас будет трудный выбор: либо потерять некоторые функции, либо изменить существующие расширения, чтобы сделать их совместимыми.

Примечание: Не изменяйте стороннее расширение напрямую, а создайте новое расширение, которое расширит устаревшее, а затем установит зависимость в загрузочном XML-файле нового расширения.

После всего проделанного может быть предоставлен фактический анализ каждого из оставшихся расширений. Он всегда должен начинаться с изучения файла etc/config.xml. Есть 3 вещи, на которые нужно обратить внимание:

• Перезапись класса сама по себе не является чистой техникой, но в некоторых случаях другого пути нет. Поэтому, если переписанный класс был изменен в новой версии Magento, это может стать потенциальной проблемой.
• Обновления макета с меньшей вероятностью вызовут проблемы с вашим обновлением, но все же, если расширение ссылается на блок, который устарел в более новой версии Magento, вам придется это сделать вокруг.
• Обновления SQL являются сильно недооцененным источником проблем во время обновлений. Проблема возникает, когда стороннее расширение создает внешний ключ, ссылающийся на какое-либо поле в таблице Magento по умолчанию. В результате это поле заблокировано от изменений. И затем, если собственный сценарий установки попытается обновить это поле, он завершится беззвучно. После этого каждый следующий сценарий установки, ссылающийся на это поле, приведет к сбою вашего обновление.

Приложение/код/локальный/Маг

После того, как вы закончили со своими расширениями, пришло время взглянуть на ваш каталог app/code/local/Mage. Здесь вы найдете измененные файлы ядра, перемещенные в область local. Каждый из них наверняка будет стоить вам седых волос, потому что вы никогда не знаете (если это не вы их туда положили), что там было изменено и по какой причине. Поэтому вам нужно сравнить каждый из них с источником и перенести добавленную функциональность в соответствующий файл нового версия.

Пользовательская тема

Последняя внесистемная модификация - это пользовательская тема. Это может показаться несущественным, но на самом деле это серая зона. Базовая тема Magento изменяется от версии к версии, и каждая пользовательская тема должна имитировать некоторые из этих изменений. К сожалению, нет серебряной пули, чтобы определить, что искать и что нужно перенести. Так что просто будьте готовы к некоторым серьезным сюрпризам и незначительным придиркам после вашего обновление.

Модификации в ядре

В совершенном мире их нет. Но когда вы получили установку Magento после того, как ею злоупотребили сторонние разработчики, которые предлагают многое по дешевке, вы можете ожидать чего угодно. Таким образом, изменения в ядре - это те, которые будут перезаписаны в процессе обновления. В большинстве случаев это не приведет к каким-либо ошибкам, но в результате вы потеряете функциональность, которая была добавлена таким жестоким способом.

Единственный способ обнаружить изменения в ядре - сравнить все файлы вашей установки Magento с чистыми файлами той же версии. Я рекомендую делать это с помощью git. Почему? Просто потому, что он будет хорошо обрабатывать все новые строки и пробелы.

Даже если ваша установка Magento не находится в git, вы все равно можете скопировать файлы в отдельный каталог, а затем запустить git init. Затем сделайте начальную фиксацию, скопируйте "чистые" файлы Magento и запустите git status. Вы получите что-то вроде это:

Теперь в зависимости от количества измененных файлов вы можете запускать git diff для каждого файла или для всего пакета сразу. Это даст вам исчерпывающую информацию обо всех внесенных изменениях в ядро. Если у вас есть какая-либо визуализация git, такая как PhpStorm, ваша жизнь намного проще:

Я предлагаю сделать git diff > changes.txt, чтобы у вас всегда был список изменений вручную.

Имея список основных модификаций, вы можете оценить, что должны быть перенесены в новую версию и сколько времени потребуется для этого.

Теперь я хотел бы дать несколько советов по фактическому обновлению. Этот процесс хорошо документирован, поэтому я не буду писать, какие команды запускать и где нажимать. Однако я хочу сделать акцент на нескольких важных вещах:

• Мы предполагаем, что вы обновляете свою среду разработки. Запуск обновления на рабочем сервере - это самоубийство.
• Не позволяйте им меняться все, что находится в производстве, пока вы обновляете. Поместите свой Magento под контроль версий или даже временно заблокируйте файлы от записи.
• Отключите все сторонние расширения, но обратите внимание, какие из них были отключены изначально, чтобы вы не включали их впоследствии.
• Проверьте, запущен ли на сервере скрипт очистки Magento. В противном случае усеките все таблицы, начинающиеся с dataflow_*, log_*, report_*.
• Вернитесь к теме по умолчанию во время обновления.

После обновления сценария завершено:

• Ссылка на changes.txt, которую вы сделали перед переносом всех изменений в ядре, которые действительно заслуживают переноса.
• Перенести app/code/local/Mage изменения, обнаруженные до обновления.
• Один за другим включайте сторонние расширения.
• Верните свою тему и всесторонне сравните результат с рабочим сервером.
• Разверните в производство, как только вы будете довольны результатом.

Заключение

Я знаю, что все это звучит пугающе, но если вы регулярно обновляетесь, поддерживаете чистоту своего ядра и устанавливаете расширения только от поставщиков, которым вы действительно доверяете, и только если они вам действительно нужны, вы не столкнетесь с большинством трудностей, описанных в этой статье. Поддерживайте свою экосистему Magento здоровой, и вы будете вознаграждены.

Постскриптум

В очень сложных случаях имеет смысл начать все сначала с новой установки последней версии Magento и поэтапно перенести тему и функциональность вашего магазина. Это определенно будет потребуется время, но в конце концов у вас будет здоровая система Magento с полным пониманием того, что происходит.