Коли платформа не говорить мовою вашого бізнесу, ви пишете модулі, які говорять.

Каталог, який PrestaShop не міг змоделювати.

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

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

Бриф був прямим: побудувати e-commerce-поверхню, що пасує цьому бізнесу, а не бізнес, що пасує платформі.

П'ять модулів, що зробили PrestaShop вільним у домені.

Ми розширили PrestaShop 1.7.4 — PHP 5.6, Symfony 3.4, Doctrine, MySQL, Smarty — п'ятьма зробленими на замовлення модулями, кастомною темою й брендово коректними PDF-шаблонами рахунків. Жоден із модулів не був узятий із маркетплейсу. Усі п'ять написані з нуля під конкретну форму домену.

Модуль музичного плеєра надав кожному цифровому товару відтворювану ідентичність: метадані треку, повну тривалість, налаштовуваний час обрізання семплу, що встановлюється артистом для кожного треку, і вбудований у сторінку плеєр із перемоткою. Артист вирішує, скільки програється до оформлення замовлення. Це рішення — бізнес-правило; воно живе в моделі даних, а не в JavaScript-хаках поверх дефолтного шаблону товару.

Модуль профілю автора зробив композиторів і дикторів повноцінними сутностями з власними сторінками профілю, біографіями й дискографіями. Трек знає свого автора. Сторінка автора перелічує його треки. Цей зв'язок можна опитувати й керувати ним з адмін-панелі.

Модуль конструктора головної сторінки надав маркетинговій команді структуровану поверхню — блоки заголовків, банери, CTA — яку вони могли редагувати, не торкаючись теми. Модуль product-block обробляв куровані вітрини головної сторінки за категоріями. Модуль умов надав юридичному відділу самообслуговувану поверхню для керування умовами використання. У поєднанні з односторінковим потоком SuperCheckout і регіональною платіжною інтеграцією CM-CIC оформлення замовлення збирало email у точці продажу й проводило розрахунок через регіональний процесинг клієнта без кастомного платіжного шлюзу.

Кастомні PDF-шаблони рахунків — 877 рядків, брендово коректні — обробляли чеки на боці сервера. Клієнт отримує чек, що виглядає як бренд, у якого він щойно купив.

F · 01Модуль музичного плеєра

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

F · 02Модуль профілю автора

Композитори й диктори як повноцінні адмін-сутності зі сторінками профілю, біографіями й дискографіями. Треки посилаються на авторів; сторінки авторів перелічують треки.

F · 03Модуль конструктора головної сторінки

Структуровані блоки заголовків, банери й CTA, які маркетингова команда редагує з адмін-панелі — без доступу до теми, без чергового інженера.

F · 04Модуль product-block

Куровані вітрини товарів на головній сторінці, упорядковані за категоріями. Оператор вирішує, що з'являється на головній сторінці, не торкаючись шаблону.

F · 05Односторінкове оформлення + регіональна оплата

Односторінковий потік SuperCheckout із регіональним платіжним процесингом CM-CIC і збором email через Mailchimp у точці продажу. Цифрове й фізичне в одному кошику, одному оформленні замовлення.

F · 06PDF-рахунки у стилі бренду

Генерація рахунків на боці сервера — 877 рядків кастомних шаблонів. Чеки, що виглядають як бренд, у якого клієнт щойно купив.

Розширюйте платформу; не переписуйте її.

Спокуса на проєкті на кшталт цього — дійти висновку, що платформа неправильна, і почати спочатку. PrestaShop не знає, що таке точка обрізання прев'ю — отже, перейдіть на кастомний Symfony-застосунок, потягніться до headless-стеку, наводьте аргументи за зовсім іншу платформу.

Ніщо з цього не було виправданим. Система модулів PrestaShop існує саме для цього. Платформа обробляє керування каталогом, опрацювання замовлень, складський облік, податки, мультивалютність і десятиліття граничних випадків e-commerce, які нецікаво переписувати. Прогалиною було доменне моделювання — метадані аудіо, сутності авторів, редагована головна сторінка — і ця прогалина була саме правильного розміру для п'яти модулів.

“

Розширюйте платформу лише там, де її словник неправильний. Усюди, де він правильний, дайте їй виконувати роботу.

”

Чотири місяці, з листопада 2018-го до березня 2019-го, 356 комітів. Обсяг розширення було відкалібровано проти того, що платформа вже добре обробляла. Модулі ізольовані й добре окреслені. Решта — це PrestaShop. Це обмеження — настільки ж дисципліна, як і рішення: якщо ви розширюєте лише там, де відповідність справді неправильна, система, яку успадковує наступний інженер, лишається читабельною.

Платформа, що говорила мовою бренду.

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

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

356 комітів, 4 місяці, 5 кастомних модулів. Оператор запустився за графіком і керував каталогом із першого дня без інженерної підтримки.