Архитектура CMS
Архитектура CMS
Всем привет. Наверняка у всех есть опыт или мысли по теме, буду благодарен, если поделитесь.
Итак, цель - разработать единую админку, из которой заполняются данные для миллиона разных фронтов.
Варианты:
Вариант 1:
WordPress. Четыре основные таблицы: post, category, meta, user. В post есть поле type, благодаря чему можно создавать любые кастомные сущности, в meta хранятся кастомные поля. Таблицы скрываются за АПИ, которое полиморфит типы (get_post) для конечного пользователя и разработчиков плагинов, благодаря чему можно писать плагины, которые работают с чем угодно.
Вариант 2:
OpenCat. Заранее предопределенные 10-100 таблиц, отдельное АПИ работы с каждой.
Вариант 3:
ModX. Все данные в виде дерева, на каждом сайте это дерево программируется под нужную структуру фронта индивидуально. Какое там АПИ - уже не вспомню.
Во всех вариантах вшит механизм сбора блоков для типовых страниц дизайна (везде по-разному называется).
Мне больше всего нравится WordPress.
Итак, цель - разработать единую админку, из которой заполняются данные для миллиона разных фронтов.
Варианты:
Вариант 1:
WordPress. Четыре основные таблицы: post, category, meta, user. В post есть поле type, благодаря чему можно создавать любые кастомные сущности, в meta хранятся кастомные поля. Таблицы скрываются за АПИ, которое полиморфит типы (get_post) для конечного пользователя и разработчиков плагинов, благодаря чему можно писать плагины, которые работают с чем угодно.
Вариант 2:
OpenCat. Заранее предопределенные 10-100 таблиц, отдельное АПИ работы с каждой.
Вариант 3:
ModX. Все данные в виде дерева, на каждом сайте это дерево программируется под нужную структуру фронта индивидуально. Какое там АПИ - уже не вспомню.
Во всех вариантах вшит механизм сбора блоков для типовых страниц дизайна (везде по-разному называется).
Мне больше всего нравится WordPress.
Re: Архитектура CMS
А для чего вам таквя супер-пупер админка на кучу сайтов? Я бы избегал таких решений так как такая махина будет слишком неповоротлива. Лучше под каждый сайт отдельно делать. Если функционал дублиоуется, пишите плагины.
Re: Архитектура CMS
Чтобы для каждого фронта не писать отдельное руководство по наполнению и разработке, чтобы каждый следующий программист не плевался ядом на предыдущего. Чтобы вообще вебмастер мог справиться.
Есть много причин, почему пишутся CMS. Платить приходится производительностью, тут вы верно заметили.
Re: Архитектура CMS
Вариант 4.
По-фреймворковски. Создается N модулей с собственными миграциями и КРУДами. Работа с данными происходит через виджеты и сервис (АПИ). В принципе, почти ничем не отличается от 2 варианта.
По-фреймворковски. Создается N модулей с собственными миграциями и КРУДами. Работа с данными происходит через виджеты и сервис (АПИ). В принципе, почти ничем не отличается от 2 варианта.
Re: Архитектура CMS
Не совсем понятно про что вы спрашиваете.
По то как спроектировать различные типы страниц (как один из видов контента)?
Тут вы сами себе художник, что придумаете так и будет.
Я например, по примеру друпала, имею вполне определенную(ваш вариант 2) таблицу page_tracker такого плана
page_type content_id lang title announce status created ...
Которая работает как индекс если выборка идет по материалам разных типов.
А уже как реализуется, управляется, хранится конкретный тип страницы, это уже его независимое дело.
Можно конечно и побольше абстракций нагородить, но чтобы оно смысл имело.
А вы планируете слоистую архитектуру в своей цмс?
По то как спроектировать различные типы страниц (как один из видов контента)?
Тут вы сами себе художник, что придумаете так и будет.
Я например, по примеру друпала, имею вполне определенную(ваш вариант 2) таблицу page_tracker такого плана
page_type content_id lang title announce status created ...
Которая работает как индекс если выборка идет по материалам разных типов.
А уже как реализуется, управляется, хранится конкретный тип страницы, это уже его независимое дело.
Если вы пишете на Yii2, то думаю , код , созданный по фреймворковски, только упростит вам задачу и поддержки и разработки.
Можно конечно и побольше абстракций нагородить, но чтобы оно смысл имело.
А вы планируете слоистую архитектуру в своей цмс?
Re: Архитектура CMS
Конкретного вопроса пока что нет. Хочу услышать советы о том, как найти компромис между скоростью натяжки верстки, производительностью и возможностями кастомизации для систем управления страницами сайта.
У такого подхода хорошая гибкость, но проблема с мета-модулями, которые сами по себе ничего не делают, не создают никаких сущностей. Например, просто генерируют XML карту сайта на основании всего, что есть в системе. Такой модуль ставится сам не знает куда и должен как-то понять структуру сайта. Если сделать как в Опенкарте (заранее предопределить основные таблицы) - получится неуниверсальное решение, но зато с высокой вероятностью того, что готовые плагины встанут хорошо*. В случае с модулями YII2 - из конструктора может быть собрано что угодно, но возникнет проблема с общими для вообще всего плагинами.Если вы пишете на Yii2, то думаю , код , созданный по фреймворковски, только упростит вам задачу и поддержки и разработки.
Я ядре - да. Но снаружи это все должно быть спрятано за очень простым АПИ.А вы планируете слоистую архитектуру в своей цмс?
* Давайте представим, что в OC нет VQMOD, а существует нормальная система плагинов.
Re: Архитектура CMS
Друпал не изучал. Очень хорошо выглядит, спасибо.maleks писал(а): ↑2017.04.16, 08:53 Я например, по примеру друпала, имею вполне определенную(ваш вариант 2) таблицу page_tracker такого плана
page_type content_id lang title announce status created ...
Которая работает как индекс если выборка идет по материалам разных типов.
А уже как реализуется, управляется, хранится конкретный тип страницы, это уже его независимое дело.
Re: Архитектура CMS
А что, эти вещи связаны?
Производительность зависит чисто от вас.
Возможности кастомизации , если мышкой и в админке, то придется постараться, а если из кода то пишите несвязанный код и всегда можно будет натюнить под конечный сайт.
Про верстку, это про возможности подменить шаблон на нужный, в Yii2 даже через алиасы это можно сделать.
Вам нужно вводить еще один уровень абстракции. ЦМС-ки - это системы более высокого уровня чем просто захардкоденый конечный сайт.pistol писал(а): ↑2017.04.16, 09:13 У такого подхода хорошая гибкость, но проблема с мета-модулями, которые сами по себе ничего не делают, не создают никаких сущностей. Например, просто генерируют XML карту сайта на основании всего, что есть в системе. Такой модуль ставится сам не знает куда и должен как-то понять структуру сайта.
Например есть модуль с типом страницы внутри.
Раз он в себе держит эти страницы, этот модуль может и сообщить XML сервису о том что в нем есть страницы и где их найти.
Т.е. получится например так:
По крону запустился XML сервис, с задачей перестройки карты сайта.
В ходе работы он от системы модулей запрашивает мета информацию о "хранилищах ссылок": урлах, priority, lastmod..
Re: Архитектура CMS
По моему опыту, чтобы написать какой-то кастомный фильтр по данным в CMS, приходится сильно жертвовать производительностью, либо не использовать API вообще, а написать все чистыми SQL запросами. Или чтобы отобразить какие-то данные для верстки, часто приходится писать портянки по построению нужных массивов на основании выбранных разными методами данных.
Чтобы модуль вставал куда угодно, слишком уж много этой мета-информации нужно вносить в него, слишком много он будет на себя брать, слишком многое указывать ядру. Ну, например, хочу я при удалении новости удалять и все комментарии к ней. А новости и комментарии - вообще разные модули, которые не знают друг о друге. Такие связи должны быть захардкожены как-то в ядре.Т.е. получится например так:
По крону запустился XML сервис, с задачей перестройки карты сайта.
В ходе работы он от системы модулей запрашивает мета информацию о "хранилищах ссылок": урлах, priority, lastmod..
Re: Архитектура CMS
Тут многое зависит от того что все таки вы решите делать - cms или cmf.
Я себе пошел вторым путем, поэтому на "Новость" я ставлю фиелд "Коммент", технически реализуется yii-шными поведениями.
Само поведение "Коммент" может цепляться к любому типу страниц.
И уже задания этого поведения например такие:
- на странице редактирования Новости, контролировать кол-во комментов в пагинаторе, возможность закрыть комменты и т.д.
- ну и соответственно при удалении новости генерится же yii-шное событие, на которое Коммент поведение тоже подписано.
Если же это CMS и все проблемы решать без кодинга, то чуток больше придется постараться, в behaviours() модели Новости смотреть что к ней навешано другими независимыми модулями.
Т.е. например Модуль комменты поставили, включили в админке, добавилась инфа что у него есть поведения, подключаемые к типам страниц.
Заходите в админке на настройки нужного типа страниц и включаете ему это "Коммент" поведение.
Re: Архитектура CMS
Да. В итоге я тоже пришел к событиям. Просто в конфиге подписываюсь на событие модуля:
Все это в принципе можно вынести в админку. Но тогда это будет действительно CMF, для пользователя CMS будет неочевидно, что если он не повесит такой-то обработчик на такое-то событие, то у него будет захламляться база. Ну и скорость разработки, опять же, страдает в ущерб универсальности и независимости модулей. Для CMS нужно хардкодить в ядре такое.
Код: Выделить всё
'on delete' => function($event) {
yii::$app->comments->deleteByOwner($event->owner_id);
}
Re: Архитектура CMS
По мне так есть два типа проектов - типовые сайты/магазины и кастомные бизнес-системы. Для первого - CMS. Для второго - фремворки. Городить свою cms - заведомо плохой вариант.
Re: Архитектура CMS
Для разработчика - это просто прокрастинация и праздное прожигание жизни.
Для вебстудии - дополнительный канал продаж и удержание клиентов, если есть бабки - многие пишут брендовую CMS.
Re: Архитектура CMS
А прокрастинация чего? Написания собственной CMS? Типа все равно когда-нибудь придется писать или пока не написал не станешь топовым разрабом?
Теперь понятно) Главное не надорваться только и довести проект до конца.
А зачем мультисайтовая? Что если одному клиенту нужна простая визитка, а другому веб-интерфейс с CRM? Или система чисто для визиток?
Re: Архитектура CMS
Когда был фрилансером, я писал свои CMS для удовлетворение любознательности по факту, потому что деньги были не так и важны и мог себе позволить. В конце все равно получался WordPress, только с багами и без плагинов сообщества)
Тут просто начать бы пока, до конца доведем)))Теперь понятно) Главное не надорваться только и довести проект до конца.
А зачем мультисайтовая? Что если одному клиенту нужна простая визитка, а другому веб-интерфейс с CRM? Или система чисто для визиток?
Я считаю, что CMS должна быть ориентирована на управление блоками и страницами сайта, иметь удобное АПИ для фильтрации этих страниц для вывода в любом изощренном дизайне. Даже понятия "новость" не должно быть, это уже вебмастер решит, какие страницы являются новостями а какие товарами. Такой подход очень нравится в WordPress. CRM, форум - отдельные системы.
Re: Архитектура CMS
Зачем оно вам надо, если сами выше сказали что создание своей цмс - это не более чем баловство и откладывание задачи поиска постоянки на дядю.
И альтернативы этому нет, т.к. если встретится задача создания современного(с управлением контента) сайта под ключ, наработок то у вас никаких нет, и побежал, как веб мастер новичек , просматривать чужие цмс-ки, что вдруг подойдет и конкурентами вам там будут другие веб мастера мышатники. Хотя нет, какой вы им конкурент, они на тех цмс-ках и плагинах собаку съели, они не новички.
Re: Архитектура CMS
Просто такая мета сейчас, канал продаж. Бесплатно давать сайт на собственной CMS и простом шаблоне, потом допродавать профессиональную разработку для тех, кто посерьезнее.maleks писал(а): ↑2017.04.17, 09:57Зачем оно вам надо, если сами выше сказали что создание своей цмс - это не более чем баловство и откладывание задачи поиска постоянки на дядю.
И альтернативы этому нет, т.к. если встретится задача создания современного(с управлением контента) сайта под ключ, наработок то у вас никаких нет, и побежал, как веб мастер новичек , просматривать чужие цмс-ки, что вдруг подойдет и конкурентами вам там будут другие веб мастера мышатники. Хотя нет, какой вы им конкурент, они на тех цмс-ках и плагинах собаку съели, они не новички.
Но это не тема холивара, лучше давайте про архитектуру холиварить
Re: Архитектура CMS
По теме - мне нравится 1 пункт. Делал бы я свою CMS - делал бы именно так.
-----
Не по теме ) - обычно, если запрос простой от заказчика, делается на CMS. Если запрос от заказчика сложный и чувствуете, что с CMS дольше возиться переделывать, чем сделать на фреймворке - делаете на нем.
А так на самом деле - сделать CMS для себя и ее продвигать клиентам - экономически идея выгодная, т.к. скорее всего они на поддержку сайт поставят именно вам и никуда не уйдут годами Но модули и темы писать будете сами, никто за вас работу не сделает.. В отличие от WP того же.
-----
Не по теме ) - обычно, если запрос простой от заказчика, делается на CMS. Если запрос от заказчика сложный и чувствуете, что с CMS дольше возиться переделывать, чем сделать на фреймворке - делаете на нем.
А так на самом деле - сделать CMS для себя и ее продвигать клиентам - экономически идея выгодная, т.к. скорее всего они на поддержку сайт поставят именно вам и никуда не уйдут годами Но модули и темы писать будете сами, никто за вас работу не сделает.. В отличие от WP того же.
Re: Архитектура CMS
Есть такая еще проблема у вебстудий типа нашей, где никого нет кроме программистов... Появляется новый сотрудник, программировать почти не умеет по факту. Просто вебмастер, собирающий на какой-то CMS сайты из лапши.обычно, если запрос простой от заказчика, делается на CMS. Если запрос от заказчика сложный и чувствуете, что с CMS дольше возиться переделывать, чем сделать на фреймворке - делаете на нем.
Спустя пару месяцев ссаной тряпкой не загнать в эту CMS, все делает на YII, даже 1 страничники Найти бы компромис между CMS и Фреймворком. Наверно, это CMF)
Re: Архитектура CMS
Смотрю CramftCMS. Блин, это прямо то, что я вынашивал в своих мыслях! WordPress без говнокода, админка супер. Осталось API изучить.