Обновление до PrestaShop 9: когда пора переходить и что проверить до миграции
Интернет-магазин работает.
Заказы приходят.
Каталог обновляется.
Оплата проходит.
И в этот момент появляется уведомление о новой версии PrestaShop.
Возникает логичный вопрос:
если всё работает, зачем вообще что-то обновлять?
Для обычного приложения ответ кажется простым: появилась новая версия — устанавливаем.
С интернет-магазином всё сложнее.
За несколько лет работы вокруг PrestaShop обычно появляется целая экосистема:
модули оплаты;
доставка;
интеграция с учётной системой;
CRM;
онлайн-касса;
аналитика;
SEO-модули;
индивидуальные доработки;
собственная тема.
Поэтому обновление CMS — это не просто замена файлов.
Это изменение платформы, от которой зависит работа всего магазина.
С выходом PrestaShop 9 и последующей ветки 9.1 вопрос стал особенно актуальным.
Разберёмся, когда обновление действительно имеет смысл и как подготовиться к нему без экспериментов на работающем магазине.
Что изменилось в PrestaShop 9
PrestaShop 9 — не косметическое обновление административной панели.
Внутри платформы произошли достаточно серьёзные технические изменения.
Одно из главных — переход на Symfony 6.4.
Для покупателя название фреймворка ничего не меняет. Но для разработчиков это важный переход на более современную архитектуру.
Также PrestaShop 9 получила новый Admin API, поддержку современных версий PHP, изменения в back office и множество внутренних обновлений.
Для магазина это создаёт более современную технологическую базу для дальнейшего развития.
Но именно масштаб внутренних изменений означает, что старые модули и индивидуальные доработки нельзя автоматически считать совместимыми.
А что изменилось в PrestaShop 9.1
В марте 2026 года появилась PrestaShop 9.1.
Одно из наиболее заметных изменений — Hummingbird 2.0 стал стандартной front-office темой для новых установок.
Это новая современная основа для разработки витрины интернет-магазина.
Важно правильно понимать этот момент.
Обновление существующего магазина до PrestaShop 9.1 не означает, что его дизайн автоматически превратится в Hummingbird.
У работающего магазина уже есть тема.
Она может быть стандартной, покупной или полностью индивидуальной.
И совместимость именно этой темы нужно проверять отдельно.
Нужно ли срочно обновлять работающий магазин
Нет.
Сам факт появления новой основной версии не означает, что каждый интернет-магазин должен немедленно перейти на неё.
Для коммерческого проекта стабильность важнее желания иметь максимальный номер версии.
Если магазин:
стабильно работает;
получает обновления безопасности;
использует совместимую версию PHP;
не ограничивает развитие бизнеса;
то миграцию можно планировать, а не проводить в спешке.
Но есть и обратная крайность.
Некоторые магазины годами работают на старой версии только потому, что:
«лучше ничего не трогать».
Со временем это превращается в технический долг.
Старая CMS требует старого PHP.
Новые модули перестают её поддерживать.
Разработчикам приходится поддерживать устаревшие решения.
Интеграции становятся сложнее.
А когда обновление наконец становится неизбежным, проект оказывается значительно больше, чем мог быть несколько лет назад.
Поэтому правильный вопрос звучит не:
«Нужно ли обновиться сегодня?»
а:
«Когда дальнейшее откладывание обновления станет дороже самой миграции?»
Сначала определите текущую версию магазина
Перед любым разговором об обновлении нужно понять исходную точку.
Переход с PrestaShop 9.0 на 9.1 и переход со старого магазина на PrestaShop 1.7 — совершенно разные проекты.
Чем старше исходная версия, тем больше промежуточных изменений накопилось.
Кроме номера PrestaShop нужно зафиксировать:
версию PHP;
версию базы данных;
тему;
установленные модули;
индивидуальные изменения;
внешние интеграции.
Получается технический паспорт магазина.
Без него невозможно нормально оценить сложность миграции.
Проверьте PHP
PrestaShop 9 больше не поддерживает старые версии PHP, которые использовались многими предыдущими поколениями магазинов.
Минимальная версия для PrestaShop 9 — PHP 8.1.
Для PrestaShop 9.1 официальная документация указывает поддержку PHP 8.1–8.5, при этом PHP 8.5 сейчас является рекомендуемой версией.
Но здесь появляется важный нюанс.
Совместимость ядра PrestaShop с определённой версией PHP ещё не означает совместимость всех модулей магазина с ней.
Например, CMS может прекрасно работать на новой версии PHP, а старый платёжный модуль — нет.
Поэтому PHP нельзя обновлять изолированно.
Проверяется вся связка:
PrestaShop + тема + модули + собственный код + PHP.
Составьте список модулей
Это один из самых важных этапов.
За несколько лет в магазине легко накапливается несколько десятков модулей.
Причём далеко не все из них действительно нужны.
Разделите их хотя бы на три группы.
Критические
Без них магазин не может нормально продавать.
Например:
оплата;
доставка;
касса;
интеграция с ERP;
обмен заказами;
важные функции checkout.
Важные
Магазин продолжит работать, но потеряет часть функциональности.
Например:
фильтры;
SEO;
аналитика;
бонусная система;
рекомендации.
Неиспользуемые
Установлены когда-то давно, но фактически больше не нужны.
Обновление — хороший повод избавиться от третьей группы.
Чем меньше неизвестного старого кода остаётся в магазине, тем проще его обслуживать дальше.
Не верьте только надписи «совместимо»
Предположим, разработчик модуля указал:
Compatible with PrestaShop 9.
Это хороший сигнал.
Но это ещё не тест конкретного магазина.
Модуль может конфликтовать:
с другим модулем;
с темой;
с override;
с изменённым checkout;
с конкретной версией PHP;
с индивидуальной доработкой.
Поэтому настоящая проверка совместимости происходит не в каталоге модулей.
Она происходит на копии магазина.
Отдельно проверьте тему
Тема интернет-магазина часто оказывается самым недооценённым риском.
Особенно если магазин создавался несколько лет назад и дизайн существенно дорабатывался.
Тема может переопределять шаблоны ядра, использовать собственный JavaScript, изменять страницы товаров, категории, корзину и оформление заказа.
После серьёзного обновления CMS отдельные шаблоны могут продолжать отображаться, но работать неправильно.
Это опаснее явной ошибки.
Белую страницу заметят сразу.
А кнопку, которая перестала работать только на iPhone при определённом варианте доставки, можно обнаружить через неделю по падению заказов.
Поэтому после обновления недостаточно открыть главную страницу и сказать:
«Вроде всё работает».
Нужно пройти реальные пользовательские сценарии.
Найдите все overrides и индивидуальные доработки
PrestaShop позволяет достаточно глубоко изменять стандартное поведение магазина.
За годы работы разработчики могли:
изменить контроллер;
переопределить класс;
добавить собственный hook;
изменить шаблон;
дописать JavaScript;
изменить логику цены;
добавить поля заказа.
Проблема возникает, если документации по этим изменениям нет.
Новый разработчик видит обычный магазин.
Но внутри оказывается несколько лет точечных исправлений.
Перед миграцией такие изменения желательно инвентаризировать.
Нужно понять:
что было изменено;
зачем;
используется ли это сейчас;
существует ли в новой версии стандартное решение той же задачи.
Иногда старую доработку вообще не нужно переносить.
Проверьте интеграции
Современный интернет-магазин редко работает самостоятельно.
Он может обмениваться данными с:
1С;
CRM;
ERP;
службами доставки;
платёжными системами;
маркетплейсами;
телефонией;
аналитикой;
мобильным приложением.
После обновления нужно убедиться, что обмен продолжает работать в обе стороны.
Особенно опасны тихие ошибки.
Например, заказы на сайте создаются нормально, но перестают попадать в учётную систему.
Или остатки продолжают обновляться, но цены — уже нет.
Внешне магазин работает.
Проблема обнаруживается только через несколько часов или дней.
Никогда не начинайте с рабочего магазина
Это главное правило.
Обновление коммерческого магазина нельзя использовать как тест совместимости.
Для проверки создаётся staging-копия.
То есть отдельная версия магазина, максимально близкая к боевой:
та же база;
та же тема;
те же модули;
те же настройки;
те же доработки.
И уже на ней проводится обновление.
Если возникает ошибка, покупатели её не видят.
Можно изучить логи, исправить проблему, повторить процесс и понять, сколько времени потребуется на настоящую миграцию.
Официальная документация PrestaShop также рекомендует тестировать обновление в staging-среде до применения на production.
Backup — это не просто ZIP с файлами
Перед обновлением нужна полноценная резервная копия.
Минимально:
файлы магазина;
база данных.
Но наличие backup ещё ничего не гарантирует.
Главный вопрос:
можно ли из него восстановиться?
Архив может оказаться повреждённым.
В дампе базы могут отсутствовать таблицы.
Копия может быть сделана несколько месяцев назад.
Поэтому хороший backup — это не файл с названием backup.zip.
Это проверенный путь возврата магазина в рабочее состояние.
Что тестировать после обновления
Проверка должна имитировать реальную работу.
Начните с витрины.
Откройте:
главную;
категорию;
карточку товара;
поиск;
фильтры;
личный кабинет.
Затем соберите заказ.
Добавьте товар в корзину.
Измените количество.
Примените промокод.
Авторизуйтесь.
Попробуйте гостевой заказ.
Выберите доставку.
Выберите оплату.
Завершите заказ.
После этого перейдите в back office.
Проверьте:
появился ли заказ;
правильно ли рассчиталась сумма;
сохранилась ли доставка;
сработала ли оплата;
изменился ли остаток;
отправились ли уведомления;
ушёл ли заказ во внешнюю систему.
Это уже намного ближе к настоящему тестированию.
Проверьте мобильную версию отдельно
Desktop и mobile нельзя считать одним тестом.
На смартфоне могут проявиться совершенно другие проблемы:
не открывается меню;
фильтр перекрывает страницу;
кнопка корзины исчезает;
модальное окно нельзя закрыть;
checkout ломается из-за клавиатуры;
платёжный виджет выходит за пределы экрана.
Поэтому хотя бы основные сценарии нужно пройти на реальном смартфоне.
Не только в режиме эмуляции браузера.
Проверьте SEO после миграции
Техническое обновление CMS может неожиданно затронуть поисковый трафик.
После миграции стоит проверить:
URL товаров и категорий;
canonical;
robots.txt;
sitemap;
метатеги;
микроразметку;
редиректы;
страницы пагинации;
HTTP-коды.
Особенно важно убедиться, что старые URL не изменились без необходимости.
Если товар раньше находился по одному адресу, а после обновления получил другой, поисковику потребуется заново разобраться со страницей.
При большом каталоге такие изменения могут затронуть тысячи URL.
Обновление CMS не должно случайно превращаться в миграцию всей SEO-структуры.
Проверьте скорость
Новая версия сама по себе не гарантирует быстрый магазин.
PrestaShop 9 получил современную техническую основу, а Hummingbird создавался как более современная и производительная база для storefront.
Но реальная скорость конкретного магазина зависит от значительно большего числа факторов:
темы;
модулей;
изображений;
базы данных;
кэша;
сервера;
сторонних скриптов;
аналитики.
Поэтому производительность нужно измерять до и после миграции.
Иначе невозможно понять, стало лучше или хуже.
Не переносите технический мусор автоматически
Большое обновление — хороший момент для уборки.
В старом магазине могут оставаться:
неиспользуемые модули;
старые темы;
тестовые файлы;
ненужные overrides;
забытые cron-задачи;
устаревшие интеграции;
таблицы давно удалённых модулей.
Не всё из этого нужно тащить в новую версию.
Иногда правильная миграция — это не точное воспроизведение старой системы.
Это перенос необходимого функционала с отказом от накопившегося технического долга.
Обновление или новый магазин?
Для очень старого проекта иногда появляется другой вариант.
Вместо последовательного обновления можно создать новый магазин на актуальной версии и перенести в него данные.
Например:
каталог;
категории;
клиентов;
заказы;
SEO-структуру;
контент.
После этого необходимые интеграции и функции настраиваются заново.
Такой подход требует больше подготовки, но иногда оказывается чище, чем попытка протащить через несколько поколений CMS десятилетний набор модулей и overrides.
Универсального ответа нет.
Решение зависит от состояния конкретного проекта.
Когда обновление особенно стоит планировать
Есть несколько сигналов.
Сервер приходится держать на старом PHP
Современные библиотеки и сервисы постепенно прекращают поддержку устаревших версий.
Это начинает ограничивать весь проект.
Нужный модуль больше не поддерживает вашу версию
Сначала таких модулей один.
Потом несколько.
Через некоторое время любое развитие требует обходных решений.
Обновления становятся всё сложнее
Чем дольше накапливается технический долг, тем дороже следующий большой переход.
Планируется серьёзная доработка магазина
Если впереди новый дизайн, мобильное приложение, интеграция или крупный функциональный проект, иногда логично сначала привести основу в актуальное состояние.
Поддерживать старый код становится дорого
В какой-то момент экономия на обновлении превращается в постоянную переплату за обслуживание устаревшей архитектуры.
Когда лучше не спешить
Есть и обратные ситуации.
Не стоит начинать крупную миграцию:
за неделю до высокого сезона;
перед большой рекламной кампанией;
в день запуска акции;
без рабочего backup;
без тестовой среды;
когда никто не знает, как устроены интеграции.
Даже если технически обновление возможно, момент может быть выбран неправильно.
У интернет-магазина есть бизнес-календарь.
Технические работы должны его учитывать.
Практический план перехода
Хорошая миграция обычно выглядит примерно так:
1. Аудит текущего магазина.
Версия CMS, PHP, сервер, тема, модули, overrides, интеграции.
2. Проверка совместимости.
Определяется, что можно обновить, что нужно заменить, а что потребуется доработать.
3. Создание backup.
Копируются файлы и база данных.
4. Создание staging.
Разворачивается тестовая копия.
5. Обновление тестовой копии.
Все ошибки фиксируются и устраняются.
6. Функциональное тестирование.
Каталог, поиск, аккаунт, корзина, checkout, оплата, доставка, интеграции.
7. Проверка SEO и производительности.
Сравнивается состояние до и после.
8. План production-обновления.
Определяется окно работ и процедура отката.
9. Обновление рабочего магазина.
Только после успешной репетиции.
10. Повторная проверка.
Сразу после запуска контролируются реальные заказы, платежи, обмены и ошибки.
Главная идея проста:
production-обновление должно быть повторением уже проверенной процедуры, а не первым экспериментом.
Что даёт PrestaShop 9 владельцу магазина
Большинство технических изменений новой версии покупатель никогда не увидит напрямую.
И это нормально.
Ценность современной платформы проявляется не только в новых кнопках.
Актуальная архитектура облегчает дальнейшую разработку, использование современных версий PHP, поддержку новых модулей и интеграций.
PrestaShop 9 также получил новый Admin API, а ветка 9.1 сделала Hummingbird 2.0 стандартной темой для новых установок.
Это создаёт более современную основу для следующих лет развития платформы.
Но переход имеет смысл только тогда, когда он проведён контролируемо.
Как это связано с Ewonta
Готовые интернет-магазины Ewonta работают на базе PrestaShop, поэтому проект остаётся полноценным магазином с собственной базой, файлами, модулями и возможностью дальнейшей доработки.
Такая открытость даёт свободу развития.
Но она же означает, что реальный магазин со временем становится индивидуальной системой.
Именно поэтому обслуживание PrestaShop — это не только установка обновления ядра.
Нужно учитывать тему, модули, доставку, оплату, интеграции и собственный код.
Для этого у Ewonta отдельно предусмотрена техническая поддержка магазинов: обслуживание, помощь с модулями, настройками и дальнейшим развитием.
Главное: обновлять нужно не номер версии
Цель миграции — не получить цифру 9 в административной панели.
Цель — сохранить магазин технически актуальным, безопасным и пригодным для дальнейшего развития.
Иногда правильное решение — обновиться сейчас.
Иногда — сначала заменить несколько старых модулей.
Иногда — запланировать миграцию после сезона.
А для очень старого проекта разумнее может оказаться перенос на новую установку.
Но худший сценарий почти всегда один и тот же:
годами ничего не обновлять, пока технический долг не превратит обычную миграцию в аварийный проект.
Поэтому переход на PrestaShop 9 лучше начинать не с кнопки «Обновить».
Начинать нужно с аудита магазина.