Локализация аттрибутов сильная

Да, например, выбор автора публикации.
Было бы приятнее, если бы это сразу был select, а не просто поле для числа.

В Orchid это реализовано. Но там свои минусы, в частности, нужно ручками создавать модель админ юзера и явно указывать, что в панели хочешь использовать именно её, а не дефолтного пользователя.

зачем создавать отдельно юзера (Модель под админ пользователей), если есть система ролей (уже заложена в orchid), все пользователи равны, а admin ровнее и с определённой ролью, которая дает доступ в панель.

В моём случае базовый пользователь очень кастомизирован, а админу эти лишние поля ни к чему. Поэтому решил развести по разным моделям.

в ларавел-админ это тоже делается на изи🤷‍♂️

Ну да, но это самому колхозить надо.

не надо ничего "колхозить", все через настройки делается
и модель используемую в Dashboard можно подменить через настройки, и посредников, и gurad, проблемы разделить нет, и колхоза нет

gurad, models заменяются через config и все работает

вот только почему замену моделей для примера в конфиг не добавили не понятно

По умолчанию там будет поле числа, после генерации контроллера через консольную команду.
Но можно поменять на select. Например, у нас есть публикации, и категории. У публикаций есть отношение belongsTo  к модели Category с ключом category_id, тогда для формы публикаций, вот такой код  даст нам селектор категории для публикации:

$form->select('category_id', 'Category')->options(Category::all()->pluck('name', 'id'))->required();

вот так это выглядит

Отношения Many-to-Many тоже работают хорошо, и удобно.
Например, Many-to-Many с pivot таблицей тестировал. Публикации и теги.
Выглядит вот так.

И самое главное, запросы оптимизированы, в отличии от других админок. Даже для Many-to-Many отношений. К примеру в листинге публикаций мы хотим вывести количество тегов привязанных к каждой публикации. В других админках это порождало кучу запросов к БД (да что говорить, я показывал примеры тут, когда даже для отношений с одним и тем же внешним ключом повторялись одинаковые запросы), а вот в "Laravel admin" вот такой запрос к БД формируется для этого:

select `tags`.*, `tag_post`.`post_id` as `pivot_post_id`, `tag_post`.`tag_id` as `pivot_tag_id` from `tags` inner join `tag_post` on `tags`.`id` = `tag_post`.`tag_id` where `tag_post`.`post_id` in (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20)

P.S. И этот запрос можно еще оптимизировать, но не забываем, что это админка и все и так не плохо.

@icemont вы так глубоко капнули - было бы здорово потом почитать весь путь и итог

Есть какие-нибудь ресурсы по solid в laravel? Не примеры типа тонкий контроллер, репозиторий с запросом в 1 строку, а посложнее что-нибудь, логики побольше...

почти все это есть в доке ларавел-админ, из бесплатных имхо одна из лучших (орчид правда пока не крутил)

Я видел сообщение про SOLID и Laravel

Ну-ну, в наследство прилетел проект. И как Вы решете выбор полиморфных? Заказчик хочет с полным листингом сущности а не только одного поля.

И расскажите как Вы quil к ней прикрутили, что бы картинки по человечески сохранять а не в теле html

а, quill не юзал, кстати, у меня ckeditor, и там все норм

а вот полиморфные да, нативно не поддерживаются или поддерживаются костылями, об этом даже в доке сказано, но видимо мне пока именно полиморфные связи в админке не нужны были