Да да да, вы всё правильно прочитали, ещё одна система управления содержимым, можете сразу доставать кирпич и идти в комментарии поджигая свой факел.
Когда я только впервые писал первые статьи о фреймфорке slim, то мне многие в комментариях на хабре советовали попробовать Laravel, что я считай сразу же сделал. Cказать, что мне он понравился, ничего не сказать. Но так как я работал в сфере разработки сайтов, где требовалось скорость, было сложно найти оправданный аргумент использовать его, единственный выход было создании пакета администрирование в свободное время, что позволило бы использовать любимые технологии.
В начале
Первым же делом, я отказался, от свойственных для CMS решений вроде: “Тем оформления”, “Плагинов” и “Контроля маршрутизации”. Просто давайте сразу на чистоту, не так часто рабочему сайту нужна смена оформления, а плагин так или иначе должен ставить разработчик, которому composer будет милее. Редактор шаблонов или других параметров тоже нет, так как в действительности это конфликтовало с системой контроля версий.
Основные моменты
Первым делом, была разработана схема при которой, каждый разработчик мог внести какие-то изменения в логику или расширить её. Размышлять пришлось достаточно долго, так как идеального варианта наверное не существует, и был выбран подход, где вначале создаётся форма которая имеет вкладки, каждая такая вкладка независима, она понятия не имеет, что существует другая и при отправки формы, данные по очереди приходят в каждую вкладку. Тем самым каждый может создавать сколь угодно этих вкладок, добавляя всё больше параметров в форму.
Например у нас есть форма пользователя, где по умолчанию указано две вкладки с общей информацией и правами доступа, с помощью добавления новых форм (зарегистрированных с помощью событий) мы можем расширить и добавить различную информацию, при этом в коде вы будете видеть только вьюшку формы и действие которое надо сделать с полученной моделью. Такой подход позволяет расширять уже стандартные вкладки и чётче подстраиваться под необходимые нужды.
Пример формы, которую можно расширить
Поле этого надо было начинать думать, о том как хранить данные. Размышляя о структуре, сложно было не заметить, что на большинстве сайтов (Которые разрабатывала компания), данные по структуре были очень сильно похожие, да и иногда требовался хранения перевода. Это дало мне повод задуматься о EAV формате, но ответ на вопрос как хранить, я нашёл у разработчиков из соседнего отдела, они использовали не реляционные базы данных для мобильных приложений. Перенеся это на MySQL и PostgreSQL, система уже использовала JSON тип, для хранения данных, продолжая вопрос хранения и простоты использования, воспроизвёл wordpress структуру, то есть создал таблицу записи, а данные хранились в ней в JSON формате. Для проведения манипуляций использовалось отдельное поле обозначающее его тип. С помощью которого, можно было бы управлять самой записью.
То есть разработчику, необходимо было описать поля, которые он хотел бы отобразить на редактирование и в каком виде, а форма построиться сама. Так же можно указать валидацию, или модули, модули?—?это те самые формы о которых я рассказывал выше.
Пример управления записью
namespace DummyNamespace;
use Orchid\Behaviors\Many;
class DummyClass extends Many
{
/**
* @var string
*/
public $name = '';
/**
* @var string
*/
public $slug = '';
/**
* @var string
*/
public $icon = '';
/**
* Slug url /news/{name}.
* @var string
*/
public $slugFields = '';
/**
* Rules Validation.
* @return array
*/
public function rules()
{
return [];
}
/**
* @return array
*/
public function fields()
{
return [];
}
/**
* Grid View for post type.
*/
public function grid()
{
return [];
}
/**
* @return array
*/
public function modules()
{
return [];
}
}
Поля и поведения указываются отдельно, что позволяет использовать лишь ключ, например в записи мы хотим wysing редактор, а значением будет класс. Это позволяет менять редактор с summernote на tinymce или ckeditor почти в один клик.
'types' => [
App\Core\Behaviors\Many\DemoPost::class,
],
'fields' => [
'textarea' => Orchid\Fields\TextAreaField::class,
'input' => Orchid\Fields\InputField::class,
'tags' => Orchid\Fields\TagsField::class,
'robot' => Orchid\Fields\RobotField::class,
'place' => Orchid\Fields\PlaceField::class,
'datetime' => Orchid\Fields\DateTimerField::class,
'checkbox' => Orchid\Fields\CheckBoxField::class,
'path' => Orchid\Fields\PathField::class,
'code' => Orchid\Fields\CodeField::class,
'wysiwyg' => \Orchid\Fields\SummernoteField::class,
],С помощью данных решений, разработчик буквально за минуты построить CRUD, для множества типов данных, а изменять добавляя новые параметры, требуется лишь внесение новых значений в их описании.
Пример формы добавления записи
Отдельный момент, касающийся дизайна, на начало разработки, да и скорее всего даже сейчас, практически каждая панель администрирования использовала AdminLTE, не хочу говорить, что она плоха или ещё что либо, но если честно?—?она надоела, поговорив с дизайнером о цене, понял, что это не мой вариант. Единственным выходом была сеть, тогда я пошёл искать красивые PSD макеты, и нашёл Dashboard60 UI Kit, купив его, я начал не в точности или даже грубо воспроизводить основные моменты (Что бы не получить по ушам).
На этом этапе вся “уникальность” заканчиваться, и начинаются стандартные вещи:
- Разделение прав доступа на основе ролей
- Виджеты
- Теггирование
- Загрузка файлов
- Меню
- Настройки
Итог
Если подвести итоги, то система, будет интересна только тем, кто уже работал с Laravel и хочет с его помощью сделать “простые сайты” с быстрым стартом, это можно увидеть даже на этапе установки, что отличается от многих других похожих приложений, которые делают свой стартер пакет для развёртывания, Orchid же идёт в качестве пакета, то есть сначала необходимо развернуть сам фреймворк и уже после добавлять пакет в зависимости.
Весь код опубликован на github.com.
Комментарии (34)
KirEv
23.07.2017 14:15-4Не хочу показаться белой вороной, но когда занимался разработкой сайтов, терпеть не мог множества зависимостей и т.п., пытался использовать ларавел, люмен, и тп… в результате сайт в несколько страниц после всех телодвижений занимал приличное количество места и содержал внушительное количество файлов…
когда вся эта возня надоела, сделал простую вещь:
— простой роутинг (ЧПУ)
— несколько элементарных классов
— создание из консоли нужных форм (круд) указывая в внешнем файле нужные поля и их параметры
— базовое разграничение прав без идиотизма аля: Васе открыть возможность редактировать только фотографии записи, но не заголовок и контент.
— админа на основе бутстрап
таким образом все сводилось к созданию нескольких файлов с описанием полей, урл-шаблона адреса и т.п., запускал скрипт — и остальное для админки и т.п. генерировалось в виде рнр-скриптов на основе описаний в файле.
в итоге код самой цмс без бутстрапа занимал менее 100кб и количество файлов менее 30ти =)
создания сайта занимала минут 5 в виде:
— скопируй и распакуй zip
— создай БД
— опиши нужные поля и роутинги (чтобы только то что нужно)
— запусти скрипт генерации рнр
все получалось чисто, без зависимостей, также без проблем переносилось все сгенерированное… тупо копи-пастом, очень просто и удобно.tushev
23.07.2017 17:07-5Что то похожее и у меня. Только мне приходится разрабатывать не сайты, а скорее веб-приложения.
Много раз пытался перейти на популярные фреймворки и добавлять к ним кучу разных плагинов, библиотек. Весило это все очень много, а использовалась лишь малая часть их функционала. И самое обидное, что во всем этом зоопарке регулярно не хватало фишек которые мне удобны и приходилось все это допиливать.
В итоге плюнул и написал собственный PHP-фремворк который делает то что мне требуется в большинстве приложений. С ним же сразу в комплекте идут JavaScript/CSS компоненты типа CKEditor, Bootstap итп, Фреймоворк занимается роутингом, авторизацией, имеет компактную обертку над SQL базами данных… и кучу мелочей с которыми мне приходится постоянно сталкиваться. Там же функционал для быстрого построения CRUD редакторов баз данных, который путем описания позволяет строить древовидные и табличные редакторы.
Менюшки, навигацию, авторизацию тоже делает движок, хотя при необходимости стандартное поведение можно переопределить.
Подключается к проектам через симлик. Я постоянно чуть чуть дорабатываю фремворк работая над своими приложениями и доработки фреймворка автоматически распространяются на остальные проекты. Так получается оперативнее чем постоянно использовать отдельный git для фреймворка.
В общем, для создания нового приложения, ставятся симлинки на фреймворк, настраивается конфигурационный файл, после чего начинаем писать контроллеры, представления и модели в отдельной директории приложения.
Как ни печально, но у меня этот подход оказывается более эффективным чем классический.
demin
23.07.2017 22:33Вот уже как пять лет автор верен своему подходу https://habrahabr.ru/post/150762/
dcc0
23.07.2017 18:11Примерно такая же ситуация. Фактически за день написал сайт: регистрация, авторизация, разграничение прав, создание персональной анкеты и еще некоторый целевой функционал.
Перенос сайта осуществляется за три операции, копирование файлов, правка config, экспорт и импорт БД. Все.
Редактирование бренда сайта осуществляется с помощью правки style.css, header.html, footer, html.
Если на скорость, то можно за 20 минут сделать новый сайт с новым брендом на нем.
Vadiok
23.07.2017 21:54+2Перенос сайта осуществляется за три операции, копирование файлов, правка config, экспорт и импорт БД. Все.
Это ведь практически везде так можно, не только у вас. Но с композером, можно еще и не только так.
Вопрос в том, что если с вашим сайтом придется работать другому разработчику. Есть ли документация? Как насчет обновлений безопасности, багфиксов?
Советую глянуть мнение Александра Макарова, одного из основных разработчиков фреймворка Yii, по поводу того, стоит ли писать свою реализацию компонентов или использовать чужую:
https://youtu.be/EfL8lsUTlFo?t=9209 — ошибки Yii 2.0
https://youtu.be/EfL8lsUTlFo?t=10271 — конкретно, в чем разумнее подход Laravel по сравнению с подходом Yii.
Fesor
24.07.2017 10:59занимал приличное количество места и содержал внушительное количество файлов…
А на что это вообще влияет? Типа вы по FTP деплоили? тогда да. больно.
создания сайта занимала минут 5 в виде:
да и так 5 минут занимает, можно даже круче — написать один раз на ансиблах всяких плэйбук который будет этим за вас заниматься, есть даже готовые.
r-moiseev
23.07.2017 14:42-2К сожалению, все попытки сделать CMS на Laravel/Symfony/ (подставьте свой вариант) разбиваются о вордпресс.
Как бы круто технически ни была исполнена ваша цмска, вы ничего не сделаете с вп, у которого есть плагины для всего. Натурально, в любой непонятной ситуации ищи плагин, и найдешь несколько на выбор.
И, к сожалению, я даже не вижу кандидатов на то, чтобы эту ситуацию переломить.oxidmod
23.07.2017 15:22-2Я довольно давно думаю о composer-based системе плагинов. По идее композер разруливает кучу проблем с совместимостью/версионированием. Toran или аналоги позволяют развернуть готовую инфраструктуру для такого себе плагин-стора в перспективе.
smarteq
24.07.2017 06:04Что изменится если WP заменить на Joomla в вашем посте? Правильно — ничего.
Я не пытаюсь дать старт холивару «Своя CMS vs Популярная», речь о другом совсем.
У каждого решения есть свои достоинства и недостатки, это думаю понятно всем.
Лично я не раз оказывался в ситуациях когда разработка на CMS шла как по накатанной только до определенного момента, дальше начинались ситуации в которых архитектура используемого продукта начинала идти в разрез с пожеланиями и требовать бОльших трудозатрат чтобы это реализовать, чем если бы я это делал сборной солянкой из фреймворка и набора любимых библиотек. Что я этим хотел сказать? Всего лишь то, что слухи о всемогуществе и удобстве CMS сильно преувеличены, а «серебряной пули» нет и не будет.
А что касается данной CMS — обязательно попробую в ближайшие выходные или типа того.
Как минимум с целью оценить технические решения, примененные автором.r-moiseev
24.07.2017 10:32+1Я не собирался холиварить о CMS. WP приведен в качестве примера как наиболее популярная. Хотел лишь затронуть момент что именно сделало их популярными. Сайты в интернете делают не только разработчики,. Возможность натыкать себе сайт без соответствующих навыков является отличительной особенностью CMS как класс.
smarteq
25.07.2017 05:50> Сайты в интернете делают не только разработчики
Вопрос терминологии кого считать разработчиками, а кого нет. Как по мне так как раз не разработчики пользуются конструкторами сайтов. Если домохозяйка разобралась с установкой WP и прикручиванием к нему шаблонов/плагинов, её вполне можно записывать в ряды начинающих вебмастеров. Поскольку разницей между ней и студентом, который первый раз поставил вордпресс, а через полтора года начнет пилить «свою CMS» формально в момент установки WP никакой )))
Movimento5Litri
27.07.2017 11:01Ага, понаставишь плагинов и вордпресс превращается в
элегантногофранкинштейна из которого лезут кишки, уязвимости да бекдоры и который нельзя обновить.
CuamckuyKot
23.07.2017 23:05Идея разработчику — зашлите Jeffrey Way (Laracasts.com) ссылку на систему (с сопроводительным письмом). Может, он захочет запилить видео про Вашу систему.
vlreshet
24.07.2017 09:14+3Просто давайте сразу на чистоту, не так часто рабочему сайту нужна смена оформления, а плагин так или иначе должен ставить разработчик, которому composer будет милее. Редактор шаблонов или других параметров тоже нет, так как в действительности это конфликтовало с системой контроля версий.
Господи, 5 из 5, просто 5 из 5! Я не пробовал запускать вашу систему, но за это решение апплодирую вам стоя. Никогда не понимал этого прикола с «плагинами», «расширениями», и т.д. в CMSках. Да один хрен обычный пользователь не сможет их поставить (особенно если там нужны ещё настройки), и будет кого-то нанимать, зато если надо сделать свой плагин/кастомизировать систему, то это выливается в тонны боли, потому что всё или захардкожено, или тянется из кучи мест сразу, или надо создавать кучу boilerplate кода для минимальных действий. Ну и опять таки, потом все эти кастомизации либо хранятся в базе, что не комильфо по ряду причин, либо хранятся в виде файлов (которые постоянно перестраиваются) что ломает систему контроля версий.r-moiseev
24.07.2017 11:03Из моего опыта сайтом часто занимается человек который способен поставить плагин и его настроить. Даже подверстать тему, но такой человек почти всегда мягко скажем не долюбливает cli и composer для него это уже космические технологии.
Fesor
24.07.2017 11:12такой ситуация была 10 лет назад, на сегодняшний день потворствовать подобному не стоит. Обучение займет 30 минут, и в целом дает больше возможностей и контроля.
Animatorshik
24.07.2017 14:32А какой шаблонизатор используется: blade или twig?
tatu
24.07.2017 14:33В нутри Blade, но вы сможете использовать любой, так как Ochird не диктует жестких правил на этот счёт
jonic
25.07.2017 01:41о, это чем то похоже на мой велосипед, только у меня фронт на Backbone и универсальный код загрузки списка/единичной записи и сохранением с раскладкой по моделям/коллекциям учитывая внешние ключи и доступы
CuamckuyKot
Получилось очень здорово! Хочется похвалить разработчика за проявленное терпение и получивший результат.
Было бы здорово на официальном сайте добавить нечто типа Fancybox для картинок. А то просто в новом окне открываются.