Архитектура CMS

Обсуждаем, как правильно строить приложения
Ответить
Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Архитектура CMS

Сообщение pistol » 2017.04.15, 16:08

Всем привет. Наверняка у всех есть опыт или мысли по теме, буду благодарен, если поделитесь.

Итак, цель - разработать единую админку, из которой заполняются данные для миллиона разных фронтов.

Варианты:

Вариант 1:
WordPress. Четыре основные таблицы: post, category, meta, user. В post есть поле type, благодаря чему можно создавать любые кастомные сущности, в meta хранятся кастомные поля. Таблицы скрываются за АПИ, которое полиморфит типы (get_post) для конечного пользователя и разработчиков плагинов, благодаря чему можно писать плагины, которые работают с чем угодно.

Вариант 2:
OpenCat. Заранее предопределенные 10-100 таблиц, отдельное АПИ работы с каждой.

Вариант 3:
ModX. Все данные в виде дерева, на каждом сайте это дерево программируется под нужную структуру фронта индивидуально. Какое там АПИ - уже не вспомню.

Во всех вариантах вшит механизм сбора блоков для типовых страниц дизайна (везде по-разному называется).

Мне больше всего нравится WordPress.

anton_z
Сообщения: 436
Зарегистрирован: 2017.01.15, 15:01

Re: Архитектура CMS

Сообщение anton_z » 2017.04.16, 05:52

А для чего вам таквя супер-пупер админка на кучу сайтов? Я бы избегал таких решений так как такая махина будет слишком неповоротлива. Лучше под каждый сайт отдельно делать. Если функционал дублиоуется, пишите плагины.

Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Re: Архитектура CMS

Сообщение pistol » 2017.04.16, 07:05

anton_z писал(а):
2017.04.16, 05:52
А для чего вам таквя супер-пупер админка на кучу сайтов? Я бы избегал таких решений так как такая махина будет слишком неповоротлива. Лучше под каждый сайт отдельно делать. Если функционал дублиоуется, пишите плагины.
Чтобы для каждого фронта не писать отдельное руководство по наполнению и разработке, чтобы каждый следующий программист не плевался ядом на предыдущего. Чтобы вообще вебмастер мог справиться.

Есть много причин, почему пишутся CMS. Платить приходится производительностью, тут вы верно заметили.

Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Re: Архитектура CMS

Сообщение pistol » 2017.04.16, 07:14

Вариант 4.
По-фреймворковски. Создается N модулей с собственными миграциями и КРУДами. Работа с данными происходит через виджеты и сервис (АПИ). В принципе, почти ничем не отличается от 2 варианта.

Аватара пользователя
maleks
Сообщения: 1764
Зарегистрирован: 2012.12.26, 12:56

Re: Архитектура CMS

Сообщение maleks » 2017.04.16, 08:53

Не совсем понятно про что вы спрашиваете.
По то как спроектировать различные типы страниц (как один из видов контента)?

Тут вы сами себе художник, что придумаете так и будет.
Я например, по примеру друпала, имею вполне определенную(ваш вариант 2) таблицу page_tracker такого плана
page_type content_id lang title announce status created ...
Которая работает как индекс если выборка идет по материалам разных типов.
А уже как реализуется, управляется, хранится конкретный тип страницы, это уже его независимое дело.
pistol писал(а):
2017.04.16, 07:14
Вариант 4.
По-фреймворковски.
Если вы пишете на Yii2, то думаю , код , созданный по фреймворковски, только упростит вам задачу и поддержки и разработки.
Можно конечно и побольше абстракций нагородить, но чтобы оно смысл имело.

А вы планируете слоистую архитектуру в своей цмс?

Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Re: Архитектура CMS

Сообщение pistol » 2017.04.16, 09:13

maleks писал(а):
2017.04.16, 08:53
Не совсем понятно про что вы спрашиваете.
По то как спроектировать различные типы страниц (как один из видов контента)?

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

Если вы пишете на Yii2, то думаю , код , созданный по фреймворковски, только упростит вам задачу и поддержки и разработки.
У такого подхода хорошая гибкость, но проблема с мета-модулями, которые сами по себе ничего не делают, не создают никаких сущностей. Например, просто генерируют XML карту сайта на основании всего, что есть в системе. Такой модуль ставится сам не знает куда и должен как-то понять структуру сайта. Если сделать как в Опенкарте (заранее предопределить основные таблицы) - получится неуниверсальное решение, но зато с высокой вероятностью того, что готовые плагины встанут хорошо*. В случае с модулями YII2 - из конструктора может быть собрано что угодно, но возникнет проблема с общими для вообще всего плагинами.
А вы планируете слоистую архитектуру в своей цмс?
Я ядре - да. Но снаружи это все должно быть спрятано за очень простым АПИ.

* Давайте представим, что в OC нет VQMOD, а существует нормальная система плагинов.

Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Re: Архитектура CMS

Сообщение pistol » 2017.04.16, 09:23

maleks писал(а):
2017.04.16, 08:53
Я например, по примеру друпала, имею вполне определенную(ваш вариант 2) таблицу page_tracker такого плана
page_type content_id lang title announce status created ...
Которая работает как индекс если выборка идет по материалам разных типов.
А уже как реализуется, управляется, хранится конкретный тип страницы, это уже его независимое дело.
Друпал не изучал. Очень хорошо выглядит, спасибо.

Аватара пользователя
maleks
Сообщения: 1764
Зарегистрирован: 2012.12.26, 12:56

Re: Архитектура CMS

Сообщение maleks » 2017.04.16, 09:46

pistol писал(а):
2017.04.16, 09:13
Конкретного вопроса пока что нет. Хочу услышать советы о том, как найти компромис между скоростью натяжки верстки, производительностью и возможностями кастомизации для систем управления страницами сайта.
А что, эти вещи связаны?
Производительность зависит чисто от вас.
Возможности кастомизации , если мышкой и в админке, то придется постараться, а если из кода то пишите несвязанный код и всегда можно будет натюнить под конечный сайт.
Про верстку, это про возможности подменить шаблон на нужный, в Yii2 даже через алиасы это можно сделать.
pistol писал(а):
2017.04.16, 09:13
У такого подхода хорошая гибкость, но проблема с мета-модулями, которые сами по себе ничего не делают, не создают никаких сущностей. Например, просто генерируют XML карту сайта на основании всего, что есть в системе. Такой модуль ставится сам не знает куда и должен как-то понять структуру сайта.
Вам нужно вводить еще один уровень абстракции. ЦМС-ки - это системы более высокого уровня чем просто захардкоденый конечный сайт.
Например есть модуль с типом страницы внутри.
Раз он в себе держит эти страницы, этот модуль может и сообщить XML сервису о том что в нем есть страницы и где их найти.
Т.е. получится например так:
По крону запустился XML сервис, с задачей перестройки карты сайта.
В ходе работы он от системы модулей запрашивает мета информацию о "хранилищах ссылок": урлах, priority, lastmod..

Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Re: Архитектура CMS

Сообщение pistol » 2017.04.16, 10:20

maleks писал(а):
2017.04.16, 09:46
pistol писал(а):
2017.04.16, 09:13
Конкретного вопроса пока что нет. Хочу услышать советы о том, как найти компромис между скоростью натяжки верстки, производительностью и возможностями кастомизации для систем управления страницами сайта.
А что, эти вещи связаны?
По моему опыту, чтобы написать какой-то кастомный фильтр по данным в CMS, приходится сильно жертвовать производительностью, либо не использовать API вообще, а написать все чистыми SQL запросами. Или чтобы отобразить какие-то данные для верстки, часто приходится писать портянки по построению нужных массивов на основании выбранных разными методами данных.
Т.е. получится например так:
По крону запустился XML сервис, с задачей перестройки карты сайта.
В ходе работы он от системы модулей запрашивает мета информацию о "хранилищах ссылок": урлах, priority, lastmod..
Чтобы модуль вставал куда угодно, слишком уж много этой мета-информации нужно вносить в него, слишком много он будет на себя брать, слишком многое указывать ядру. Ну, например, хочу я при удалении новости удалять и все комментарии к ней. А новости и комментарии - вообще разные модули, которые не знают друг о друге. Такие связи должны быть захардкожены как-то в ядре.

Аватара пользователя
maleks
Сообщения: 1764
Зарегистрирован: 2012.12.26, 12:56

Re: Архитектура CMS

Сообщение maleks » 2017.04.16, 10:36

pistol писал(а):
2017.04.16, 10:20
Ну, например, хочу я при удалении новости удалять и все комментарии к ней. А новости и комментарии - вообще разные модули, которые не знают друг о друге. Такие связи должны быть захардкожены как-то в ядре.
Тут многое зависит от того что все таки вы решите делать - cms или cmf.
Я себе пошел вторым путем, поэтому на "Новость" я ставлю фиелд "Коммент", технически реализуется yii-шными поведениями.
Само поведение "Коммент" может цепляться к любому типу страниц.
И уже задания этого поведения например такие:
- на странице редактирования Новости, контролировать кол-во комментов в пагинаторе, возможность закрыть комменты и т.д.
- ну и соответственно при удалении новости генерится же yii-шное событие, на которое Коммент поведение тоже подписано.

Если же это CMS и все проблемы решать без кодинга, то чуток больше придется постараться, в behaviours() модели Новости смотреть что к ней навешано другими независимыми модулями.
Т.е. например Модуль комменты поставили, включили в админке, добавилась инфа что у него есть поведения, подключаемые к типам страниц.
Заходите в админке на настройки нужного типа страниц и включаете ему это "Коммент" поведение.

Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Re: Архитектура CMS

Сообщение pistol » 2017.04.16, 10:44

Да. В итоге я тоже пришел к событиям. Просто в конфиге подписываюсь на событие модуля:

Код: Выделить всё

'on delete' => function($event) {
    yii::$app->comments->deleteByOwner($event->owner_id);
}
Все это в принципе можно вынести в админку. Но тогда это будет действительно CMF, для пользователя CMS будет неочевидно, что если он не повесит такой-то обработчик на такое-то событие, то у него будет захламляться база. Ну и скорость разработки, опять же, страдает в ущерб универсальности и независимости модулей. Для CMS нужно хардкодить в ядре такое.

anton_z
Сообщения: 436
Зарегистрирован: 2017.01.15, 15:01

Re: Архитектура CMS

Сообщение anton_z » 2017.04.17, 02:00

По мне так есть два типа проектов - типовые сайты/магазины и кастомные бизнес-системы. Для первого - CMS. Для второго - фремворки. Городить свою cms - заведомо плохой вариант.

Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Re: Архитектура CMS

Сообщение pistol » 2017.04.17, 06:29

anton_z писал(а):
2017.04.17, 02:00
По мне так есть два типа проектов - типовые сайты/магазины и кастомные бизнес-системы. Для первого - CMS. Для второго - фремворки. Городить свою cms - заведомо плохой вариант.
Для разработчика - это просто прокрастинация и праздное прожигание жизни.
Для вебстудии - дополнительный канал продаж и удержание клиентов, если есть бабки - многие пишут брендовую CMS.

anton_z
Сообщения: 436
Зарегистрирован: 2017.01.15, 15:01

Re: Архитектура CMS

Сообщение anton_z » 2017.04.17, 08:27

pistol писал(а):
2017.04.17, 06:29
Для разработчика - это просто прокрастинация и праздное прожигание жизни.
А прокрастинация чего? Написания собственной CMS? Типа все равно когда-нибудь придется писать или пока не написал не станешь топовым разрабом?
pistol писал(а):
2017.04.17, 06:29
Для вебстудии - дополнительный канал продаж и удержание клиентов, если есть бабки - многие пишут брендовую CMS.
Теперь понятно) Главное не надорваться только и довести проект до конца.
А зачем мультисайтовая? Что если одному клиенту нужна простая визитка, а другому веб-интерфейс с CRM? Или система чисто для визиток?

Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Re: Архитектура CMS

Сообщение pistol » 2017.04.17, 08:48

anton_z писал(а):
2017.04.17, 08:27
pistol писал(а):
2017.04.17, 06:29
Для разработчика - это просто прокрастинация и праздное прожигание жизни.
А прокрастинация чего? Написания собственной CMS? Типа все равно когда-нибудь придется писать или пока не написал не станешь топовым разрабом?
Когда был фрилансером, я писал свои CMS для удовлетворение любознательности по факту, потому что деньги были не так и важны и мог себе позволить. В конце все равно получался WordPress, только с багами и без плагинов сообщества)
Теперь понятно) Главное не надорваться только и довести проект до конца.
А зачем мультисайтовая? Что если одному клиенту нужна простая визитка, а другому веб-интерфейс с CRM? Или система чисто для визиток?
Тут просто начать бы пока, до конца доведем)))

Я считаю, что CMS должна быть ориентирована на управление блоками и страницами сайта, иметь удобное АПИ для фильтрации этих страниц для вывода в любом изощренном дизайне. Даже понятия "новость" не должно быть, это уже вебмастер решит, какие страницы являются новостями а какие товарами. Такой подход очень нравится в WordPress. CRM, форум - отдельные системы.

Аватара пользователя
maleks
Сообщения: 1764
Зарегистрирован: 2012.12.26, 12:56

Re: Архитектура CMS

Сообщение maleks » 2017.04.17, 09:57

pistol писал(а):
2017.04.17, 08:48
Тут просто начать бы пока, до конца доведем)))
Зачем оно вам надо, если сами выше сказали что создание своей цмс - это не более чем баловство и откладывание задачи поиска постоянки на дядю.
И альтернативы этому нет, т.к. если встретится задача создания современного(с управлением контента) сайта под ключ, наработок то у вас никаких нет, и побежал, как веб мастер новичек , просматривать чужие цмс-ки, что вдруг подойдет и конкурентами вам там будут другие веб мастера мышатники. Хотя нет, какой вы им конкурент, они на тех цмс-ках и плагинах собаку съели, они не новички.

Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Re: Архитектура CMS

Сообщение pistol » 2017.04.17, 10:15

maleks писал(а):
2017.04.17, 09:57
pistol писал(а):
2017.04.17, 08:48
Тут просто начать бы пока, до конца доведем)))
Зачем оно вам надо, если сами выше сказали что создание своей цмс - это не более чем баловство и откладывание задачи поиска постоянки на дядю.
И альтернативы этому нет, т.к. если встретится задача создания современного(с управлением контента) сайта под ключ, наработок то у вас никаких нет, и побежал, как веб мастер новичек , просматривать чужие цмс-ки, что вдруг подойдет и конкурентами вам там будут другие веб мастера мышатники. Хотя нет, какой вы им конкурент, они на тех цмс-ках и плагинах собаку съели, они не новички.
Просто такая мета сейчас, канал продаж. Бесплатно давать сайт на собственной CMS и простом шаблоне, потом допродавать профессиональную разработку для тех, кто посерьезнее.

Но это не тема холивара, лучше давайте про архитектуру холиварить :)

Аватара пользователя
Йож
Сообщения: 571
Зарегистрирован: 2015.08.26, 03:05

Re: Архитектура CMS

Сообщение Йож » 2017.04.21, 20:21

По теме - мне нравится 1 пункт. Делал бы я свою CMS - делал бы именно так.
-----
Не по теме :)) - обычно, если запрос простой от заказчика, делается на CMS. Если запрос от заказчика сложный и чувствуете, что с CMS дольше возиться переделывать, чем сделать на фреймворке - делаете на нем.

А так на самом деле - сделать CMS для себя и ее продвигать клиентам - экономически идея выгодная, т.к. скорее всего они на поддержку сайт поставят именно вам и никуда не уйдут годами ;) Но модули и темы писать будете сами, никто за вас работу не сделает.. В отличие от WP того же.

Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Re: Архитектура CMS

Сообщение pistol » 2017.04.22, 10:04

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

Спустя пару месяцев ссаной тряпкой не загнать в эту CMS, все делает на YII, даже 1 страничники :) Найти бы компромис между CMS и Фреймворком. Наверно, это CMF)

Аватара пользователя
pistol
Сообщения: 216
Зарегистрирован: 2014.07.12, 15:18
Откуда: Курган
Контактная информация:

Re: Архитектура CMS

Сообщение pistol » 2017.04.22, 10:13

Смотрю CramftCMS. Блин, это прямо то, что я вынашивал в своих мыслях! WordPress без говнокода, админка супер. Осталось API изучить.

Ответить