Оцінка оновлення Magento - це процес збору інформації про модифікації, застосовані до інсталяції, яку ви збираєтесь вносити в сучасний термін, перевіряючи, чи можуть ці зміни викликати проблему, а потім оцінювати, скільки часу потрібно, щоб обійти їх.
Усі модифікації можуть бути буквально розділені на безпрофільні та основні .
Поза основні модифікації - це ті, які не будуть перезаписані оновленням. Це сторонні розширення , основні файли, розміщені в локальному масштабі (додаток / код / локальний / маг) та спеціальна тема .
Зміни в основному застосовуються безпосередньо до основних файлів Magento (додаток / код / ядро), файлів локалізації (app / locale / en_US), основних шаблонів і деяких речей, таких як javascripts , зовнішні бібліотеки, які рідко налаштовані, але все-таки повинні бути враховані. .
Позакласні модифікації
Розширення третьої сторони
Під час оновлень сторонні розширення є основним джерелом проблем. Що означає більше розширень, вам більше часу знадобиться для їх аналізу.
Перше, що потрібно перевірити, - чи функціональність, що надається розширенням, ще не реалізована у версії Magento, до якої ви модернізуєтесь. Наприклад , деякі розширення , наприклад Yoast_CanonicalUrl, Mxperts_CustomerAddressабо Fontis_Wysiwygбули широко використані в Magento 1.3.xx і старше , але в даний час є частиною основної функціональності Magento і більше не потрібно.
Тоді корисно перевірити (запитайте свого клієнта), чи справді вам потрібні всі ці розширення. Можливо, ви встановили деякі розширення, але ніколи не використовувались. Тож у цей момент добре зробити своєрідне очищення.
Тоді важливою справою є сумісність кожного з розширень, що залишилися, з версією Magento, до якої ви модернізуєтесь. Якщо деякі розширення не сумісні та немає подібних розширень, у вас буде важкий вибір: або втратити певну функціональність, або змінити існуючі розширення, щоб зробити їх сумісними.
Примітка. Не змінюйте безпосередньо розширення сторонніх розробників, а створюйте нове розширення, яке розширить застаріле, а потім встановіть залежність у XML завантаження з нового розширення.
Після всіх тих, хто зробив, може бути наданий фактичний аналіз кожного з розширень, що залишилися. Він завжди повинен починатися з перевірки etc/config.xmlфайлу. Треба шукати 3 речі:
- Переписування класів - це не сама чиста техніка, але в деяких випадках іншого способу немає. Тож якщо змінити переписаний клас у новій версії Magento це може стати потенційною проблемою.
- Оновлення макетів менш імовірно спричинить проблеми з оновленням, але все ж якщо розширення посилається на блок, який застарів у новій версії Magento, вам доведеться це обійти.
- Оновлення SQL є сильно заниженим джерелом проблем під час оновлення. Проблема виникає, коли стороннє розширення створює зовнішній ключ, посилаючись на якесь поле в таблиці Magento за замовчуванням. В результаті це поле блокується від модифікацій. І тоді, якщо нативний скрипт встановлення спробує оновити це поле, він вийде з ладу. Після цього кожна наступна сценарій встановлення, що посилається на це поле, призведе до краху оновлення.
додаток / код / локальний / Mage
Після закінчення розширень настав час поглянути на ваш 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 EcoSystem здоровою, і ви отримаєте нагороду.
Post Scriptum
У дуже складних випадках має сенс почати все із нової установки найновішого Magento та поетапно перенести тему та функціональність магазину. Це, безумовно, потребує часу, але врешті-решт у вас буде здорова система Magento з повною обізнаністю про те, що відбувається.