Семь лет на одной кодовой базе: кастомная e-commerce-платформа для оператора wellness-ретритов.

Что пришлось делать кастомным и почему.

Каталог оператора wellness-ретритов не укладывается в дефолты e-commerce. Ретрит — это не товар, а привязанный к датам бандл, объединяющий проживание, питание и обучение в одну покупаемую единицу. Ведущий инструктор — не автор товара; он и есть причина, по которой гость бронирует. Модули санскритской лексики и философии бренда — не блог; это контентный слой, который соседствует с витриной и придаёт решению о покупке контекст.

Мы построили платформу на PrestaShop 1.7.4 в конце 2018 года, с четырьмя предметно-ориентированными модулями и сильно переработанной дефолтной темой. Модуль retreat-bundles моделировал предложения с несколькими датами и компонентами, с выбором дат и конфигурацией компонентов — в экосистеме PrestaShop ничего близкого не было. У модуля изучения санскрита были собственные таблицы базы данных, фронтенд-маршруты и админ-панель: поверхность лексики и философии, которую оператор мог редактировать независимо от каталога. Модуль реселлеров отслеживал партнёрские B2B-агентства с записями о контактах, стране и валюте.

Поток оформления был переопределён — 67 переопределений классов и контроллеров на пике — потому что у покупок ретритов другие правила валидации, чем у оформления физических товаров. Нельзя купить два места на ретрит, не выбрав даты. Нельзя оставить поле компонента пустым и перейти к оплате.

Мелочи, которые удержали платформу в живых.

Со второго по шестой год обошлось без драмы. Смены платёжных провайдеров. Правки под GDPR. Добавление перевозчиков. Обновления PHP-рантайма, встроенные на протяжении всего сотрудничества. Время от времени новые тексты, новые форматы ретритов, новые B2B-партнёры, подключённые через модуль реселлеров. Тот вид поддержки, который не попадает на страницу проекта, но и есть настоящее содержание семилетнего сотрудничества.

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

Платформа выжила потому, что на ней были те же люди. Когда смена платёжного провайдера требовала изменений в переопределении оформления, правку вносил тот инженер, который это переопределение написал. Когда обновление PHP-рантайма ломало два конструктора модулей, мы знали, какие конструкторы проверять. Институциональное знание о кодовой базе имеет накопительную ценность, которая проявляется только тогда, когда что-то ломается, — а что-то в итоге всегда ломается.

F · 01Тип товара «бандл ретрита»

Привязанные к датам многокомпонентные бандлы (проживание, питание, обучение), смоделированные в кастомном модуле PrestaShop. Готового эквивалента нет.

F · 02Контентный слой изучения санскрита

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

F · 03Слой B2B-реселлеров

Отслеживание партнёрских агентств с записями о контактах, стране и валюте. Бронирования идут через модуль реселлеров, не затрагивая поток публичной витрины.

F · 04Кастомный поток оформления

67 переопределений классов и контроллеров на пике, моделирующих специфичные для ретритов правила валидации — выбор дат, конфигурацию компонентов, — которых дефолтное оформление не обеспечивает.

F · 05Непрерывная поддержка

Семь лет смен платёжных провайдеров, правок под GDPR, обновлений доставки и обновлений PHP-рантайма — всё это выполнено командой, написавшей исходные модули.

F · 06Миграция мажорной версии в процессе

PrestaShop 1.7.4 → 1.7.8.11 завершено в продакшене; 1.7.8.11 → 8.2.3 на поздней стадии staging. Каждое переопределение перепроверено, каждый модуль прошёл проверку совместимости с PHP 8.x. Миграция — та работа, которой и заслуживается роль хранителя.

Миграция, которая идёт сейчас.

Окончание поддержки PrestaShop 1.7 вынудило сделать выбор в 2025 году: сменить платформу или мигрировать. Смена платформы означает выбросить семь лет работы над предметно-ориентированными модулями и начать заново на новом стеке. Мы обосновали миграцию. Оператор согласился.

Миграция идёт в два этапа. Первый — PrestaShop 1.7.4 → 1.7.8.11 — состоялся раньше и уже в продакшене. Второй — 1.7.8.11 → 8.2.3 — это более тяжёлый скачок: PrestaShop 8 перевёл больше представлений на Twig и изменил систему переопределений настолько, что все 67 переопределений классов и контроллеров нужно перепроверить или отрефакторить. Каждый кастомный модуль требует прохода на совместимость с PHP 8.x.

Один только октябрь 2025 года дал 245 коммитов в ветке миграции на 8.2.3. Работа идёт в отдельном staging-окружении с зеркалом продакшен-данных. Каждый поток оформления, каждая конфигурация бандла ретрита, каждый маршрут санскритского контента тестируется против новой версии до того, как откроется окно переключения. Миграция методична и нетороплива, потому что аудиторский след, который она оставляет, важен не меньше, чем обновлённый код.

“

Причина, по которой миграция возможна — и укладывается в бюджет, — в том, что команда, выполняющая её, написала исходные модули. Мы не открывали для себя эту сложность; мы ею уже владели.

”

Аргумент в пользу той же команды для обновления.

Семь лет. Одна команда на всём протяжении. Миграция мажорной версии сейчас на поздней стадии staging.

Платформа, сегодня находящаяся в продакшене, работает на PrestaShop 1.7.8.11 с модулем retreat-bundles, поверхностью изучения санскрита, слоем B2B-реселлеров и кастомным потоком оформления — всё в целости. Ветка 8.2.3 — следующий шаг: миграция, которая сопротивляется тому, чтобы её трактовали как недельный спринт, и та часть, которую никто не закладывает в план в начале работы над кастомной платформой.

Ценность долгого сотрудничества на кастомной платформе — не в первоначальной разработке. Первую версию может построить кто угодно. Ценность — в накопленном контексте: в знании, какое переопределение является несущим, какое допущение модуля разлетится под новой версией фреймворка, от какого PHP-класса зависит шаг оплаты так, как документация не упоминает. Этот контекст не передаётся новой команде в брифе на миграцию. Он живёт в людях, написавших код. Миграция, которая сейчас в staging, возможна — и выживаема — потому что той же команде принадлежит исходный код.