Админка интернет-магазина на Laravel: как выбрать Filament, Nova или готовую платформу

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

Выбор админки для интернет-магазина на Laravel начинается с работы сотрудников. Filament, Nova и готовые торговые платформы дают разную основу, но ни одно название не описывает ваш процесс целиком. Разберём, что показывать на демонстрации, как сравнить варианты и какие условия включить в задание подрядчику.

Начните с пяти операций, которые сотрудник выполняет каждый день

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

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

Чем отличаются Filament, Nova и торговая платформа

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

Laravel Nova — административная панель с управлением данными, фильтрами и действиями. Для конкретного магазина разработчик связывает её с моделью приложения и правами пользователей. Лицензию и условия её использования нужно включить в состав проекта отдельно; цену лицензии не стоит путать со стоимостью готовой админки.

Bagisto или Lunar дают торговую основу на Laravel. Это другой уровень готовности: обсуждаются уже товары, заказы и покупатели. Но нужно проверить, какие функции присутствуют в выбранной версии, что относится к расширениям и как будут подключаться российские оплаты, доставка и учёт.

Сравнивать только внешний вид панелей бесполезно. Попросите подрядчика выполнить одни и те же пять операций на ваших примерах. Если команда показывает лишь создание записи «Товар», она ещё не показала обработку покупки.

Каталог должен помогать управлять ассортиментом

В официальном демо Filament список товаров содержит изображение, название, наличие публикации, цену, артикул и количество. Это удобная точка для разговора о вашем каталоге: какие столбцы нужны сотруднику, по чему он ищет товар и какие действия выполняет сразу с несколькими позициями.

Дальше проверьте конкретные ситуации. У товара двадцать размеров и цветов: менеджер должен понимать, какой вариант он меняет. У категории есть обязательная характеристика: система должна объяснить, почему карточка не публикуется. Сезонную коллекцию снимают с продажи: нужно решить, что будет с её адресами, подборками и незавершёнными корзинами.

Массовые действия требуют понятного масштаба. «Выбрано 20 товаров» и «выбраны все 2 000 результатов фильтра» — разные операции. До изменения цен сотрудник должен видеть, какие позиции затрагиваются; после — отчёт о выполнении и исключениях. Отмена должна восстанавливать нужные поля, а не случайно возвращать старые остатки.

Редактирование карточки проверьте на собственном товаре

На экране из документации Bagisto видны основные поля товара и цена. В вашем магазине набор будет зависеть от категории, типа товара и источников данных. Полезно принести на демонстрацию карточку с неудобными особенностями: несколькими фотографиями, вариантом без наличия и характеристикой, которую нельзя оставить пустой.

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

Отдельный вопрос — параллельное редактирование. Два сотрудника открыли одну карточку, первый обновил цену, второй сохранил старую форму. Как система предотвратит потерю изменения? В Nova есть документированный механизм обнаружения конфликта изменений модели, Traffic Cop. Но его наличие в продукте не доказывает, что он включён и закрывает все операции конкретного магазина. На приёмке воспроизведите свой сценарий.

Согласуйте границу между админкой и 1С

Для каждого поля нужен источник истины. Например, остаток и базовая цена приходят из 1С, а продающее описание и порядок фотографий меняются на сайте. В админке это должно быть понятно: заблокированное поле сопровождается объяснением, откуда берутся данные и когда они обновлялись.

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

При ошибке импорта менеджеру обычно нужны название проблемной позиции, причина, время последней успешной обработки и ответственный. Полный технический журнал можно оставить разработчику. Обычная надпись «Ошибка 500» не помогает ни продолжить продажу, ни передать проблему по назначению.

Права задаются операциями, а не названиями должностей

«Администратор» слишком широкая роль для ежедневной обработки заказов. Выпишите разрешения: кто меняет контент, стоимость, оплаченный состав, возврат, пользователей и настройки интеграций. Доступ к выгрузке всей клиентской базы стоит обсуждать отдельно от просмотра одного заказа.

На официальном экране Bagisto роль менеджера заказов собирается из отдельных разрешений. Это пример структуры настройки, а не готовая универсальная матрица для вашей компании. На Laravel нужные ограничения проверяются в серверной логике приложения.

Для приёмки создайте три тестовые роли: работа с каталогом, обработка заказов и управление системой. Проверьте разрешённое действие и попытку выполнить запрещённое через прямой запрос. Скрытие раздела меню — только часть интерфейса. Выгрузки и фоновые задания тоже должны учитывать полномочия.

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

Оценивайте удобство через время и ошибки

Возьмём учебный пример, не статистику CAPS. Менеджер обрабатывает 40 заказов за день и тратит по шесть минут на перенос данных между экранами. За 22 рабочих дня это 88 часов. Если после изменения процесса перенос занимает две минуты, расчёт даёт около 29 часов. Потенциальная разница — примерно 59 часов в месяц.

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

Записывайте время, число подсказок и ошибки. Нельзя считать быстрым сценарий, в котором сотрудник пропустил проверку наличия. Цель демонстрации — убедиться, что человек получает правильный результат самостоятельно и понимает, что делать при отклонении.

Что должно быть в задании на разработку админки

• Роли и задачи. Кто работает в системе и какие операции выполняет.
• Данные. Поля, обязательность, варианты товаров и источники значений.
• Переходы. Что разрешено до оплаты, после оплаты и после отгрузки.
• Массовые операции. Область действия, предварительная проверка и отчёт.
• Исключения. Ошибка интеграции, конфликт прав, повтор действия, устаревшие данные.
• История. Какие изменения фиксируются и кто вправе их просматривать.
• Передача. Инструкция, обучение, исходники, лицензии и сопровождение.

Скачать сценарии демонстрации и приёмки админки. Таблица помогает сравнивать решения по одной задаче. Её можно отправить нескольким командам и попросить показать результат, а не только назвать технологию.

Когда стоит делать отдельную админку, а когда доработать готовую

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

Перед решением попросите команду назвать ограничения выбранного подхода. Как добавляется новый тип товара? Что произойдёт после обновления пакета? Можно ли передать проект другой команде без восстановления бизнес-правил по коду? Ответы важнее общего обещания «админка полностью настраивается».

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