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

Що мало бути кастомним і чому.

Каталог оператора велнес-ретритів не вкладається в дефолти e-commerce. Ретрит — це не товар, а прив'язаний до дат комплект, що поєднує проживання, харчування й навчання в єдину одиницю для купівлі. Провідний інструктор — не автор товару; він є причиною, через яку гість бронює. Модулі санскритської лексики й філософії бренду — це не блог; це шар контенту, що стоїть поруч із вітриною й надає рішенню про купівлю його контекст.

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

Процес оформлення замовлення було перевизначено — 67 перевизначень класів і контролерів на піку — бо купівля ретритів має інші правила валідації, ніж оформлення фізичних товарів. Не можна купити два місця на ретриті, не обравши дати. Не можна залишити поле компонента порожнім і перейти до оплати.

Дрібниці, що тримали платформу живою.

Роки з другого по шостий не були драматичними. Заміни платіжних провайдерів. Коригування під GDPR. Додавання служб доставки. Оновлення середовища виконання PHP, упроваджувані впродовж усієї співпраці. Час від часу новий текст, нові формати ретритів, нові B2B-партнери, підключені через модуль реселерів. Той вид обслуговування, що не потрапляє на сторінку проєкту, але є справжнім змістом семирічної співпраці.

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

Платформа вижила, бо над нею були ті самі люди. Коли заміна платіжного провайдера вимагала змін у перевизначенні оформлення замовлення, зміну робив інженер, який написав це перевизначення. Коли оновлення середовища виконання PHP зламало два конструктори модулів, ми знали, які конструктори перевіряти. Інституційне знання про кодову базу має кумулятивну цінність, що проявляється лише тоді, коли щось ламається — а щось рано чи пізно завжди ламається.

F · 01Тип товару «комплект ретриту»

Прив'язані до дат комплекти з кількох компонентів (проживання, харчування, навчання), змодельовані в кастомному модулі PrestaShop. Готового еквівалента не існує.

F · 02Шар контенту для вивчення санскриту

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

F · 03B2B-шар реселерів

Відстеження партнерських агенцій із записами контактів, країни й валюти. Бронювання маршрутизуються через модуль реселерів без втручання в потік публічної вітрини.

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, можлива — і її можна пережити — бо та сама команда володіє оригінальним кодом.