Сайт компании Fungiline.by

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

Я создаю кастомные проекты на Laravel, но этот магазин сделал на WordPress

Обычно я создаю кастомные решения на Laravel. Это моя основная экспертиза: сложные интеграции, нестандартная бизнес-логика, высокая нагрузка, продуманная архитектура. Но пару месяцев назад я взял проект на WordPress, потому что этого хотел клиент. Не потому что я пересматривал свои взгляды на инструменты — я просто честно оценил его задачу и сказал: «Да, здесь WP подойдёт, если делать качественно».

Я посмотрел его требования. Стандартный интернет-магазин: каталог товаров, корзина, оплата, доставка, авторизация по email и SMS, выгрузка в Google Shopping, Apple Pay, Samsung Pay, Webpay. Никакой уникальной математики, никаких сложных цепочек расчётов или уникального бизнес-флоу. Просто работающий магазин, который должен приносить деньги.

Написать это с нуля на Laravel — два-три месяца разработки и бюджет, который примерно раза в 3 превышал его предложение. При этом сам функционал абсолютно стандартный и кастомное решение убивало бы два главных бизнес-показателя: скорость интеграции и гибкость дизайна для A/B-тестов необходимых клиентов.

Я сел, посчитал стоимость владения, оценил риски. И принял решение: я делаю на WordPress.

Не потому что я разлюбил Laravel. А потому что нужно было закрыть задачу клиента, а не удовлетворять мои экспертные амбиции. Я — разработчик, если необходимо реализовать на том, что удобно - я реализую.

Почему я сразу отказался от NoCode-решений

Кстати, многие агентства в такой ситуации предложили бы клиенту Tilda или Webflow. Дескать, быстро, красиво, визуальный конструктор, никакого программирования. И клиент, который не разбирается в технологиях, часто ведётся на эту уловку.

Но я сразу сказал клиенту: не вариант.

Смотрите, в чём подвох этих дешёвых NoCode-решений. Они кажутся экономными, но это иллюзия. Ты платишь не за разработку, ты платишь за аренду чужого пространства. Перестаёшь платить подписку — сайт исчезает в тот же день. Никаких исходников, никакой базы данных, ничего. Ты просто теряешь свой бизнес, потому что какой-то сервис решил поднять цены или закрыть направление.

Я видел такое не раз. Клиенты приходят ко мне после Tilda с запросом: «Нам нужно перенести всё на нормальный хостинг, потому что мы выросли, а Tilda не даёт нам нужный функционал». И в итоге они платят дважды — сначала за аренду, потом за разработку с нуля.

И самое смешное, что агентства, которые предлагают NoCode, сами не умеют писать код. Поэтому они продвигают то, что умеют — нажимать кнопки в конструкторе. Звучит цинично, но это правда: за ними нет экспертизы, чтобы выбрать правильный инструмент. Они просто продают то, что доступно.

Поэтому я отмёл Tilda и Webflow сразу. Клиенту нужен был реальный проект, который он контролирует, а не красивая страничка на чужом сервере.

Как я делал этот проект

Я работал два месяца. Не неделю, не десять дней — полноценный двухмесячный цикл с анализом, проектированием, разработкой и тестированием. Я не люблю, когда делают быстро и грязно. Если уж браться за WP, то делать это по-человечески, с соблюдением всех правил промышленной разработки.

Первое, что я сделал — развернул окружения:

- Dev — локальная среда для экспериментов.

- Staging — полная копия prod-сервера.

- Production — туда ничего не попадало без двойной проверки.

Это не «можно и на prod-сервере понажимать». Это серьёзный проект, и я подошёл к нему серьёзно.

Дальше разложил задачи по порядку:

1. Установил премиум-тему WoodMart и создал дочернюю тему. Всю кастомизацию — изменение шаблонов карточки товара, корзины, страницы оформления заказа, писем-уведомлений, настроил хэдер — я зашил именно в дочернюю тему. Чтобы при обновлении родительской темы мои правки не затерлись.

2. Настроил авторизацию по email и SMS через плагины Rocket SMS и OTP Login. Всё штатно, интегрировал с формой входа WooCommerce, проверил очереди отправки кодов.

3. Поставил Conditional Shipping and Payments — гибкая настройка доставки в зависимости от суммы, региона, веса. Прописал сценарии, протестировал на всех кейсах.

4. Подключил выгрузку в Google Shopping — плагин WooCommerce Google Product Review Feed, настроил фиды, проверил, что товары улетают в Merchant Center и в МойСклад.

5. Добавил оплату через Apple Pay/Samsung Pay/WebPay, интеграция бесшовная, тестировал с реальными платежами на staging.

6. Поставил WP Rocket, сжал изображения через WoodMart Images Optimizer, включил кеширование на уровне сервера, настроил Memcached.

7. Всю SEO-базу выстроил через WordPress SEO Premium, прописал мета-теги, схемы разметки, карту сайта.

8. Настроил мониторинг: Uptime Robot, логи ошибок, ежедневные бэкапы через Duplicator и на самом сервере.

Это была полноценная работа, а не «быстро на коленке». Каждый шаг документировался, каждое решение согласовывалось с клиентом. Я работал как продуктовый разработчик, просто использовал другую экосистему.

Проблема номер один:

Самый большой минус WordPress, с которым я столкнулся, — это непредсказуемость обновлений.

Я не про «разработчиков, которые тыкают кнопки на prod». Я про то, что даже при идеальном процессе:

- У меня есть dev, staging, prod.

- Я читаю changelog каждого плагина.

- Я тестирую каждое обновление на staging'е.

- Я прогоняю регрессионные тесты (ручные, потому что автоматизация на WP — это отдельный ад).

Но проблема в том, что обновления выходят часто. У WP ядро обновляется каждые пару недель. Плагины — кто когда. И каждый раз это минимум 2–3 часа моей работы: залить на staging, проверить все ключевые сценарии, убедиться, что ничего не сломалось, и только потом выкатить на prod.

На одном из обновлений у меня упал Conditional Shipping. Я нашёл это на staging — хорошо. Но потратил вечер на то, чтобы разобраться, что именно сломалось, написать разработчику плагина, получить ответ «мы исправим в следующем патче» и принять решение — либо откатывать версию плагина, либо ждать. Я откатил. Главная сложность имея решение на Wordpress: обновление —> проверка —> починка —> снова обновление.

На Laravel я этого не испытываю. Да, там тоже нужно обновлять зависимости, но это происходит реже, и я чётко знаю: если тесты проходят, то в проде всё будет работать. Потому что я сам пишу логику, я сам отвечаю за совместимость, а не надеюсь на то, что разработчик плагина из Болгарии учтёт мой кейс.

Проблема номер два:

Когда на WP стоит 10–15 плагинов, ты перестаёшь понимать, где начинается и заканчивается ответственность каждого из них. Conditional Shipping пересекается с логикой WooCommerce, которая пересекается с темой, которая пересекается с Elementor.

Если на Laravel я могу в любой момент открыть код, поставить breakpoint и понять, почему цена не пересчиталась — на WP это превращается в детектив. Я лезу в базу, смотрю мета-поля, пытаюсь понять, какой из плагинов перехватил хук и изменил данные.

И это не «WP плохой». Это просто цена экосистемы, где всё строится на хуках, фильтрах и глобальных переменных. Можно к этому привыкнуть, но это сложно поддерживать и дорого передавать другому разработчику.

Проблема номер три:

Подписки, которые никто не считает, сам WordPress — бесплатный. Но бизнес платит за:

1) Премиум-тему WoodMart — и каждый год за продление.

2) Elementor Pro — подписка, но можно использовать с ограничениями бесплатную версию.

3) WP Rocket — подписка.

4) WordPress SEO Premium — подписка.

5) Плагин для выгрузки в Google — подписка.

6) Rocket SMS и OTP Login — тоже подписка.

И так далее...

Я насчитал около $700–800 в год на подписки. Это не критично, когда магазин приносит хорошую выручку. Но когда бизнес только стартует — это заметная статья расходов.

И здесь же подвох: если не продлять подписки — ты не получаешь обновлений. А если не обновляться — рискуешь безопасностью и совместимостью. Клиент попадает в зависимость, из которой сложно выйти без полной миграции.

На Laravel подписок нет. Есть только хостинг и периодическая поддержка, если бизнес-логика меняется. Всё остальное — Ваше навсегда.

Бонусная история: про поддержку хостинга

Отдельно хочу рассказать показательный случай, который случился уже после запуска.

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

Каково же было моё удивление, когда я получил от клиента паническое сообщение: «Сайт сломался, ничего не работает!».

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

А теперь представьте: домен был кириллический. Его там и так хранился в разном формате — где-то как есть, где-то в Punycode (это когда буквы превращаются в непонятную латиницу с xn--), где-то с www, где-то без, где-то с https, где-то с http. А они просто взяли и заменили всё одним махом.

В итоге полетели:

- ссылки на картинки в контенте,

- JSON-поля в мета-таблицах WooCommerce,

- сериализованные массивы с настройками плагинов,

- ссылки в опциях темы.

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

И вот вам главный вывод: если даже поддержка крупного хостинга не может грамотно перенести WP-сайт — что говорить про обычного предпринимателя, который решает всё делать сам? WordPress даёт иллюзию простоты, но цена ошибки здесь очень высокая. Малейший неправильный шаг — и всё ломается так, что без разработчика не разобраться.

Я всегда объясняю это клиентам честно:

1) Выбирайте Wordpress, если бюджет ограничен, сроки горят, и Вы готовы платить за поддержку каждый месяц.

2) Выбирайте Laravel, если хотите сделать один раз и забыть. Если у Вас нестандартная логика. Если Вы планируете масштабироваться и не хотите зависеть от сторонних разработчиков плагинов.

И никаких NoCode-конструкторов типа Tilda и Webflow я не рассматриваю вообще. Потому что это не разработка — это аренда чужого забора. Вы украсили его, повесили табличку, а хозяин в любой момент может попросить Вас съехать. Без кода, без базы, без контроля над своим бизнесом.

Моя позиция

Я не фанат технологий, я фанат работающих решений. Если клиенту нужно быстро и дёшево — я беру Wordpress, но объясняю цену этого выбора. Если нужно надёжно и масштабируемо — я предлагаю Laravel.

Агентства, которые толкают всем подряд Webflow или Tilda, просто не умеют делать иначе. Они продают то, чему научились за неделю на YouTube. У меня другой подход: я выбираю инструмент под задачу, а не пихаю всех в одну коробку.

В этом проекте WP победил по скорости старта. Но в долгосроке побеждает Laravel. Потому что его проще поддерживать, проще развивать, и он не требует постоянных регрессионных тестов после каждого обновления.