Сравниваем Orchid, Laravel Admin, Laravel Nova и October CMS. Выбираем лучшую
Админ-панели для Laravel
Сибирикс

Админ-панели для Laravel

Выбираем лучшую
Проекты в web-разработке сегодня делятся на три основные группы:
1
Разработка на конструкторе (типа Tilda, Wix и т. д.). Хорошее решение для быстрого старта и маркетинга.
2
Проекты на коробочных CMS — Joomla, WordPress, 1С-Битрикс, и т. д., в которых есть множество модулей для типовых операций (порой — сомнительного качества). Решение подходит в основном для сайтов среднего уровня сложности и навороченности. Выход за пределы предусмотренного CMS, как правило трудоемок. Производительность — средняя.
Некоторые CMS вызывают раздражение у хороших разработчиков из-за технологической отсталости, локальности или агрессивного маркетинга Как следствие — все сложнее найти качественные кадры, готовые работать чисто под CMS. Следствие из следствия — хорошие программисты работающие с CMS стоят зачастую дороже разработчиков на «престижных» технологиях.
3
Проекты на фреймворках. Например, мы используем Laravel. Как правило, со сложной бизнес-логикой, личными кабинетами и т. д. Можно реализовать все, что угодно. Добиться максимальной производительности. Гибко, но цена гибкости — большое количество ручного труда, а значит — высокая стоимость разработки. Именно разработку на фреймворках предпочитают сами программисты. И бизнес, зачастую, не против.
Существуют успешные гибридные модели. Например, когда в рамках CMS интегрируются страницы из Tilda. Или комбинация CMS+Framework (мы часто используем этот подход на своих проектах).

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

Несколько лет назад, когда мы внедряли Laravel в студии, на первом же проекте встал вопрос — а на чём делать админку? Вручную — долго и дорого. По итогам ресерча, лучшим вариантом показался Voyager. Почему он нам понравился — по давности лет уже никто не вспомнит. Мы использовали его на десятках проектов, в том числе — добавляя серьезный кастомный функционал (вроде встроенной CRM-системы).

Время шло. Что-то устаревало. Что-то появлялось нового. Какие-то ограничения нас бесили. В общем настало время провести исследование заново. На этот раз мы решили задокументировать, что и почему нам понравилось. В этом материале разберём несколько популярных решений и покажем их нюансы изнутри. Выбор — как всегда, за вами.

Какие админки и как будем сравнивать

Мы взяли уже привычный нам Voyager и подобрали альтернативы. Чтобы их найти — набрали в гугл «самые популярные админки Laravel» и стали по-порядку их пробовать. Также смотрели на количество звезд рейтинга на GitHub, частоту релизов и скорость закрытия багов, найденных пользователями. В итоге отобрали:
  • Orchid; дополнительно глянули Laravel Admin — она ну очень похожа на Orchid, под капотом на фронте у нее чистый jQuery, но вот примеры все на китайском.
  • Laravel Nova — платная официальная админка от Laravel;
  • October CMS — не совсем админка, а полноценная CMS-ка.
Все выбранные админки внутри не похожи на Voyager: тот настраивается, как Битрикс, — кнопочками. Эти настраиваются в коде. Часто это — плюс: нет проблем с миграциями, потому что заказчик ничего не сможет случайно поменять (миграции нужны только для таблиц, создаваемых вручную).
Миграции похожи на контроль версий для вашей базы данных, позволяют вашей команде определять схемы базы данных приложения и совместно использовать их определение. Если вам когда-либо приходилось указывать товарищу по команде вручную добавить столбец в его схему локальной базы данных после применения изменений в системе управления версиями, то вы столкнулись с проблемой, которую решает миграция базы данных.

Из документации по Laravel
Для теста мы для каждой админки мы создавали структуру базы данных в виде древовидного каталога, где товары можно привязывать сразу к нескольким разделам, и у каждого товара есть SKU (товарные вариации, например — цвета). Как это выглядит: есть товар, даты, штатные названия из Laravel, символьный код и активность — можно отредактировать.

А теперь — посмотрим каждую поближе, а потом — сравним их по ключевым параметрам.

Voyager

Это очень простая админка. Функций из коробки — минимум. Привыкшие к навороченным админкам (вроде Битрикса) заказчики будут несколько удивлены его аскетичностью. Тем не менее, все что надо, где надо — прилеплено. А остальное можно дописать.

Фронтенд-часть Voyager написана на практически чистом JS + jQuery. Из плюсов — можно подключать любой JS. Бытовые мелочи: мультиязычность для контента есть, но переводы на русский внутри админки и публичной части хромают.

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

По сути, админка реализует 5 базовых операций над таблицами базы данных (BREAD):
  • B — browse — просмотр списка сущностей,
  • R — read — посмотр конкретной сущности,
  • E — edit — редактирование записи,
  • A — add — добавление,
  • D — delete — удаление.
Всё, что не касается контента, BREAD и ролей — настраивается в файлах конфигурации.

В Voyager есть главная страница, по типу рабочего стола в Битриксе, с которой довольно удобно работать. Реализован функционал для создания древовидного меню, где для каждого пункта задается текст + ссылка. Потенциально меню можно сделать многоуровневым, но на деле лучше не создавать вложенность больше 4-й — визуально под такое меню мало места. Меню можно использовать в админке/публичке, а ещё — задавать для него свои шаблоны.

Представления колонок таблиц, форм и логику можно переопределять. Также можно добавлять действия с сущностями.

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

В Voyager используются две отдельные сущности:

  1. Меню — хранятся в базе данных в отдельных таблицах;
  2. BREAD — хранит в себе настройки того, как должны выводиться списки таблиц и поля, как эти таблицы должны редактироваться и так далее.

Соответственно, при добавлении поля в базу данных помимо обычной миграции нужно дополнительно сделать миграцию для BREAD, чтобы все изменения появились на проде. Это не совсем удобно:

  1. на это нужно дополнительное время;
  2. можно забыть или потерять какие-то изменения (например, если заказчик сам что-то поменяет в коде).
Для BREAD есть отдельный пакет, который накатывает такую миграцию: он сохраняет изменения в файл, на проде вся таблица очищается, и поверх неё накатываются данные из этого файла. Для миграции меню нет отдельных пакетов — нужно писать её с нуля, или переносить все изменения вручную.

Последние крупные изменения в Voyager были в августе 2021 года. Потом появилась новая версия 1.5.0, в которой было 2 строчки: «мы что-то выпилили» и «мы что-то добавили». Свежий релиз выкатили в ноябре 2021, где пофиксили один баг. При этом у них уже давно висят 200+ незакрытых issue (это может быть задача, отзыв, ошибка, вопрос, предложение пользователей) и 92 пул-реквеста (это запрос на интеграцию изменений из одной ветки в другую). Форков (копий репозитория) — тоже очень много.
Вердикт: админка достаточно легкая в настройке, есть нюансы, с которыми придется мириться. Возможностей из коробки достаточно, возможностей кастомизации — тоже.

Orchid

Orchid — админка с открытым исходным кодом, которая поддерживается комьюнити. Лежит на GitHub, распиленная на несколько репозиториев. Количество issue и пул-реквестов, по сравнению с Voyager, раза в 4 меньше.

Под капотом — Bootstrap, в качестве JS по умолчанию jQuery, плюсом есть неведомый Hot Wired с очень медленной загрузкой документации. Но никто не запрещает использовать, например, Vue. Есть Select2.

Весь код админки хранится в отдельной папке. Настройку Orchid легко сделать в PHP-классах без использования CSS или JS. Можно настроить PHP-классами свои кнопки и методы, которые нужно вызвать, если пользователь совершает определенное действие. Например, переопределять авторизацию, роут до главной страницы админки, скрипты, стили, иконки, путь до хранилища. Поиск можно реализовать через Laravel Scout.

Боковое меню нужно настраивать. Как и базовые панели форм, текстовые страницы, почты, пароли, disabled-поля, чекбоксы, радиобаттоны — всё это тоже настраивается вручную. Дата-пикеры есть штатные браузерные, а есть кастомные с JS на борту.

Дополнительные штуки: маски для телефонов, кастомные дата-пикеры, мультиселекты с поиском, чекбоксы, свитчеры, загрузка фотографий (единичная и множественная), вывод карт (не Гугл или Яндекс, а опенсорсная Leaflet).
Работа с товаром в админке Orchid
Интерфейс для работы с файлами выглядит практически как битриксовый: есть одна большая таблица с файлами, в которой хранится вся информация о них (что это за файлы, какого они размера, какой у них тип). Дополнительно есть расшивочная таблица: можно указывать, что в такой-то модели хранятся данные, вот её ID для их привязки.

Если использовать Orchid из «коробки», то всё придется писать руками: каждую кнопку, поле, роут, методы сохранения или удаления форм. Для списков — один класс, для редактирования — другой класс, для фильтрации данных — ещё один, и ещё куча других под разные типы данных (текст, число, дата, чекбокс).

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

Но есть отдельный пакет Crud — он сам делает кнопки, роуты, сохранение и удаление, остаётся только настроить поля. То есть можно создать единственный класс, прописать в нём поля, которые нужно выводить на списки и на редактирование, и настроить, как эти значения будут сохраняться.

Настраивать вручную можно всё, что угодно (почти):

  • аутентификацию — поставить авторизацию через логин, например;
  • добавлять плагины для Quill через JS или подсовывать свои стили через штатные средства Quill;
  • создавать кастомные страницы через PHP-классы.

Также можно настроить:
  • как называется каждый пункт в меню, какая там иконка и прочие мелочи;
  • какие поля будут выводиться при редактировании (чек-бокс, инпут и т. д.);
  • какие правила валидации будут применяться при сохранении данных;
  • какие колонки будем выводить на списки, а какие — на фильтрацию;
  • по каким колонкам можно сортировать;
  • легенды для полей;
  • кастомные фильтры.
Из коробки доступен только обычный фильтр по строкам. Если нужно отфильтровать список по зависимой сущности — например, список SKU по названию товара, то ничего не получится. По ID фильтр сработает, но это неудобно.

Казалось бы, ответ очевидный — напиши сам, как надо, но: искать нужно по переданной колонке, а передавать ее динамически возможности нет, так как список работающих колонок зашивается в коде фильтра. Каждый раз, когда для какой-то таблицы нужно сделать фильтр, придётся добавлять колонку. Выглядит эта история очень странно, но альтернативных решений нет.
Вердикт: неплохой конструктор в стиле «собери все сам» (даже базовые страницы для редактирования элементов таблиц придётся делать вручную). Код под капотом аккуратный, разбираться несложно. Плюс — много инструментов для кастомизации страниц.

Laravel Nova

Официальная админка от разработчика Laravel, закрытая и платная (а с оплатами из России сейчас все сложно). По ощущениям, её документация слегка отстаёт от релизов, а сама она выглядит сыроватой. Демо-версии нет, каких-то адекватных примеров — тоже.

Написана на чистом Vue. Настраивается классически: через файлы конфигураций и свой ServiceProvider. Из коробки нет русского языка, но добавить его недолго.

Возможностей для кастомизации страниц немного. Например, чтобы создать какую-то страницу, задать лэйаут, вывести какие-то поля или формы, здесь нет никаких PHP-классов, как у Orchid. Но при этом из коробки предоставляется самое необходимое: редактирование полей, например. Здесь точно так же можно вывести только то, что написано в коде, и управлять этим выводом: редактировать, посмотреть или удалить.
А вот с редактированием меню — провал: Nova просто по умолчанию достает все пункты меню, основываясь на созданных ресурсах для таблиц базы данных. Дополнительных возможностей для редактирования меню нет.

Изображения прикрепляет максимально неудобно: просто добавляет URL сохраненного изображения в таблицу — для адекватной работы это поле придётся кастомить.

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

Удобных фильтров нет (как и у Orchid). Если вам надо фильтровать сразу по нескольким полям -- ничего не получится. Вместо этого — строка поиска, которая ищет по всем полям, которые указываешь. Также есть динамические фильтры, которые потенциально можно накидывать на разные колонки, но при этом почему-то нет обычного текстового поля: там есть только селект, дата-пикер и чек-бокс.
Фильтры в Laravel Nova
Из прикольного — штука под названием Action, в которой можно писать кастомные события. Например, если хочется применить описание к нескольким товарам, его можно выбрать и применить. Вуаля! Эти действия можно сделать отложенными. Полезно, например, если есть несколько заказов, которые нужно пачкой отправить в 1С.
Вердикт: меньше писанины с кодом, чем в Orchid, но в некоторых местах вручную придётся делать больше. Инструментов для кастомизации админки меньше, но и изучать их не придется.

October CMS

October CMS основан на LTS (Long Term Support) версиях Laravel, которые обновляются редко. Предыдущей была версия, вышедшая в 2019. По текущей только начали выкатывать поддержку.

Когда-то был бесплатным, сейчас — от $ 19 разово, можно запросить демо. С оплатами из России также всё сложно. Есть бесплатный форк WinterCMS, но на старой версии (для Laravel 6). Также есть официальный магазин, где можно найти недостающие модули или плагины, также за деньги.

Много языков из коробки — русский входит в комплект.

October написан на jQuery, но можно дописывать свой JS. Авторизация в админпанели — только штатная (email + пароль), и как её закастомить, документация умалчивает. Для настройки админки есть широкий спектр параметров (в файлах конфигурации и в базе данных).

Есть файловый менеджер, но как получить доступ к этим файлам, помимо прямого пути, документация умалчивает.
Есть шаблонизатор Twig. Через конфигурационные файлы YAML (язык для хранения данных в человекопонятном формате) можно настраивать отображение списков, форм для моделей. Также можно добавлять свои виджеты для создания кастомных полей форм и колонок в таблицах сущностей.

А ещё October предлагает растащить проект на плагины, в каждом из которых прописать свою логику, например: каталог — отдельно, ecommerce — отдельно, и так далее. Плагины могут настраивать свое меню, но не могут влиять на чужие.

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

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

Из всех админок тут, пожалуй, самые клевые фильтры: тут и типы полей для фильтра любые, и искать October из коробки умеет по отношениям. Одно смущает: фильтры пишутся YAML-файлом, поэтому отлаживать процесс сложнее: типизации и подсказок в редакторе не будет.
Вердикт: классные фильтры, но странные навороты разработчиков там, где можно было идти проторенным путём. Если любите решения с вывертом и готовы за них платить за рубеж — вэлкам.

На десерт: сравнительная таблица админ-панелей для Laravel

October CMS Laravel Nova Orchid Voyager
Доступы Разграничение пользователей по ролям и деление на группы. Групп нет: любой пользователь из штатной таблицы Users получает полный доступ в админку. Ограничения доступа придётся делать вручную. Из коробки доступны таблицы с пользователями и таблица с ролями (плюс таблица расшивки, чтобы настроить их взаимоотношения). Из стандартного: доступ в админку, управление через медиаменеджер, доступ к редактированию пользователей и ролей. Есть группы пользователей, можно добавлять свои права. Нет разграничения пользователей по типу контента: любой пользователь может вставлять любой контент (скрипты, embed, и т.д.).
Связи между сущностями Штатные решения Laravel для связей разработчики отвергли и написали своё. Из документации до конца неясно, как это работает и как получить программный доступ к настройкам. Есть штатные HasMany, BelongsTo и т.д. Древовидной структуры — нет. С большим объемом данных справляется нормально. Штатные для Laravel отношения вроде HasMany, BelongsTo и т.д. Стандартно через HasMany, HasOne, BelongsToMany, BelongsTo и т.д.; в админке дублируются связи (через создание полей в Bread), можно задать «обязательные» связи. Древовидных структур нет.
Формы Для сущностей в базе данных формы описываются YAML-файлом с описанием всех полей и их атрибутов. Для публички форм нет, всё придётся делать руками. Самих по себе форм нет. Зато есть стопка классов для определения полей редактирования сущностей таблиц — можно кастомить через наследование. Есть свои формы для добавления или редактирования. Также есть FormBuilder, с которым можно создавать формы без привязок к сущностям БД, но с аплоадом файлов придется разбираться. Формы для контента генерируются по описанию BREAD-сущностей. Форм для публички нет, приходится использовать сторонние решения.
Фильтры списков и сортировки Отличный функционал фильтрации из коробки: любые типы полей и даже поиск по отношениям. Неудобный функционал фильтрации из коробки: только по одной колонке. Есть простой фильтр, сложный придётся писать руками, используя неудобный механизм с добавлением колонок. Сортировки работают штатно в алфавитном порядке. Есть простой фильтр (поле, операция сравнения <, >, =, like и значение). Бывают баги из-за разных вариантов реализации: с рендерингом на сервере и рендерингом на клиенте через js. Сортировки — по значению выводимых полей (по колонке).
Редактор текста Вместо одного из привычных текстовых редакторов — своя реализация. Но можно кастомизировать стили через админ-панель и список разрешённых html-тегов. Из коробки доступен Trix editor со стандартным набором функций для модификации текста. На вид — выходец из Windows 98, редактирования исходного кода нет, возможностей для кастомизации, собственно, тоже. Есть поле для визуального редактирования Markdown. Есть обычный — для визуального редактирования (SimpleMDE), есть классический — для редактирования как html (Quill). Есть широкий набор возможностей для построения графиков. Встроенный редактор текста TinyMCE (относительно свежей версии) с джентльменским набором функций: параграфы, списки, таблицы, изображения, редактирование в режиме html-кода. Можно подключить плагины от TinyMCE.
Письма, почта, шаблоны Есть редактор шаблонов в админке и отправка тестового письма. Ничего готового нет. Ничего готового нет. Только через стандартные уведомления Laravel.
Можно посмотреть по ссылке.