Создание модульной CMS

Здравствуйте!
Прошу знающих людей помочь дельными советами.
Допустим, я собрался написать движок для какого-нибудь сайта. Как сделать так, чтобы в дальнейшем этот движок можно было максимально просто расширить, добавить какие-то новые функции? Другими словами, как написать такой движок, который бы можно было собирать самому из модулей? С чего начать?

C изучение того, что есть и определения CMF.

Для начала рекомендую почитать:

ссылка

также на том же интузиазме начал делать себе сайтец: ссылка

Если хотите могу поделиться исходниками, БД не использую по ненадобности)

П.С. Знающим себя в теме веба совершенно не считаю!

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

А вариантов "легко" подключения достаточно: начиная от простейшего "include", складывания в определеный каталог..... ну и тд и тп

Посмотри RoR, Django, CakePHP, typo3 и не изобретай велосипед

Начать нужно с ознакомление с паттерном MVC - имхо.
Дальше посмотреть архитектурно-удачные CMS (CMF), а не популярные.
Например очень популярная Joomla, имхо совсем не архитектурно-удачная.
Из тех, с которыми работал я, стоит обратить внимание на Symfony, ZendFramework, Mzz.
Это для начала.

Второй совет - делать прототипы системы. Не нужно в начале стремиться написать модули на все случаи жизни. В начале - минимум модулей. Уделайте больше всего времени ядру системы, архитектуре, вопросами взаимодействия между модулями. Это очень сложно на самом деле.

Также стоит сразу придумать какие-то изюминки своей CMS, чтобы был стимул писать её дальше. Для этого нужно перепробовать на себе не мало различный CMS. Когда-то давно мы сели за круглый стол, обсудить чего же нету в популярных CMS Оказалось много чего.. ну например:

- Централизованной системы развертывания и свертывания модулей
Некоторые CMS вообще ничего не могут делать с набором своих модулей. Только в ручную всё.

- API для быстрого создания инсталяций модулей
Ведь все модули инсталируются\деинсталируются в принципе по одной схеме. Так зачем разработчики модулей для CMS делают всё по своему и каждый раз по новому? Потому что нет ничего шаблонного в самой CMS для этого.

- Централизованного хранения текстовых данных.
В каждом модуле ведь должна быть локазизация данных, функции поиска этих данных. Так зачем в каждом модуле это изобретать по новому?

- Централизованное хранение категорий\разделов
Во многих модулях есть ветвление. Модуль новостей имеет категории, и модуль статьей также, да и модуль контента. Функции категорий также одинаковы у всех: дов.\удал.. любая вложенность, сортировка.. И всёравно во всех популярных CMS, разные разработчики своих модулей, делают всё по своему.. разрабатывая всё с нуля практически..

- Подключаемые модули..
Ну например возмем модули комментариев, или галлереии. Ведь комментарии могут быть совместно с любым другим модулем? И новости можно покомментировать и пользователя какого-то. Точно так же и галлерея изображений может быть и у пользователя и новости, и у объекта из
каталога товаров.. Ну и конечно же все популярные CMS имеют "свои" комментарии в каждом модуле и свои галлереи. Вместо того чтобы стремится к
унификации и централизации данных.

Это мы ещё до интерфейса не дошли.. там тоже много идей
работа с модулями системы через SOAP, генерация кода, генерация мапперов..

От всех этих печальных фактов, серезные коммерческие проекты и не создаются на CMS, а пишуться с нуля, за очень приличные суммы. Именно при разработке с нуля, в системе учитывают, что вот все комментарии из всех модулей будут у нас храниться здесь... А ведь это же можно было учесть и при разработке CMS, и предоставить API для всех модулей.

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

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

Желаю удачи в разработке!

P.S. сорри за археологию, просто в такой интересной теме, так ничего и не посоветовали конкретного.

RUSYA, спасибо большое за такой развернутый ответ и некоторые идейки! Теперь есть над чем подумать, что почитать и посмотреть.

Всегда пожалуйста, рад был помочь.

Если необходимо бысрое решение то можно так сделать:

в базе есть таблица типа pages в ней лежит заголовок,контент и поле ТИП
Если страница - статический контент то например это поле принимаем 1 а если модуль 2

ну а потом делаем проверку
...........
$data=mysql_fetch_array($res);
$type=$data;
if ($type==2) include("./includes/".$data); else $page_content=$data;


Ну а потом выводишь переменную $page_content (при этом все что надо вывсети в подключенном модуле тоже записывается в эту переменную).

Это самый прямой и легкий спосб. Управление модуялми сводится к управлению записями в базе данных ну и выгрузка модулей в папку includes.

Но если ты захотел разработать реальную CMS то прийдется сесть и много времени рисовать структуру - что куда идет, где обрабатывается при этом закрыв комп на ключ.
Ибо сначала все продумать а потом начинать реализовывать.

Цитата ("AVD_studio"):

Если необходимо бысрое решение то можно так сделать:

в базе есть таблица типа pages в ней лежит заголовок,контент и поле ТИП
Если страница - статический контент то например это поле принимаем 1 а если модуль 2

ну а потом делаем проверку
...........
$data=mysql_fetch_array($res);
$type=$data;
if ($type==2) include("./includes/".$data); else $page_content=$data;
Ну а потом выводишь переменную $page_content (при этом все что надо вывсети в подключенном модуле тоже записывается в эту переменную).
Это самый прямой и легкий спосб. Управление модуялми сводится к управлению записями в базе данных ну и выгрузка модулей в папку includes.

Это ужасный совет

Цитата:

много времени рисовать структуру - что куда идет, где обрабатывается при этом закрыв комп на ключ.
Ибо сначала все продумать а потом начинать реализовывать.

Это отличный совем

А что в нем ужастного?
Аргументы. Хочу узнать свои ошибки на начальном уровне

Цитата ("AVD_studio"):

Если необходимо бысрое решение то можно так сделать:
в базе есть таблица типа pages в ней лежит заголовок,контент и поле ТИП
Если страница - статический контент то например это поле принимаем 1 а если модуль 2

ну а потом делаем проверку
...........
$data=mysql_fetch_array($res);
$type=$data;
if ($type==2) include("./includes/".$data); else $page_content=$data;
Ну а потом выводишь переменную $page_content (при этом все что надо вывсети в подключенном модуле тоже записывается в эту переменную).

Это самый прямой и легкий спосб. Управление модуялми сводится к управлению записями в базе данных ну и выгрузка модулей в папку includes.

Ну смотрите:
$type = $data - здесь уже нету значения, так как выше, в переменную $data мы берем обычный массив из результирующего идентификатора mysql, а не ассоциативный. Если мы хотим, чтобы в $data у нас попало значение поля type из mysql-таблиц, то надо извлекать ассоциативный массив. Для этого используется функция mysql_fetch_assoc().
Далее, мне непонятен сам алгоритм, а конкретнее вот это "Если страница - статический контент то например это поле принимаем 1 а если модуль 2".
Какой смысл делать такое отделение - страница и модуль? Может быть лучше просто сделать модуль, например, "Структура сайта". Далее вызывать функцию, которая будет отображать контент какой-нибудь страницы. Что-нибудь вроде $structure->GetContent($page_id). То есть та же самая статическая страница - параметр к функции модуля.
Вообще, как уже советовали выше, почитайте про MVC

Цитата ("Spree"):

Ну смотрите:
$type = $data - здесь уже нету значения, так как выше, в переменную $data мы берем обычный массив из результирующего идентификатора mysql, а не ассоциативный. Если мы хотим, чтобы в $data у нас попало значение поля type из mysql-таблиц, то надо извлекать ассоциативный массив. Для этого используется функция mysql_fetch_assoc().

mysql_fetch_array вернет нужный результат, но при этом в массиве будет два элемента, один с номером $data, другой $data, что в свою очередь приводит к выделению большего количества памяти.
Поэтому, как вы и сказали, лучше всего юзать mysql_fetch_assoc

Сколько не юзаю mysql_fetch_assoc и fetch_array - всегда исользовал первый когда знаю что одна запись передается а вторую когда знаю что две.

По поводу type. Это поле нужно для того чтобы понять присединить модуль или выкинуть на экран контент с базы.
Ты можешь это поле не использовать а просто сделать модуль который дергает с базы контент, вариантов море. Поэтому и существуютразличия в движках.
Но если хотите сказать что это работать не будет - говорю смело работает, причем нормально причем не на одном проекте.
Основной - ссылка
Поповоду непоняток в коде напишу так - то я написал основніе моменты, предполгая что то что не указал понятно и без того.
Если надо могу привести более полны код.

Вопрос Ве3: а почему будет в выводе $data?: киньте ссылку где сказано что mysql_fetch_assoc бістрее чем mysql_fetch_array?

Цитата ("RUSYA"):

сели за круглый стол, обсудить чего же нету в популярных CMS Оказалось много чего.. ну например:
реализовать в своей CMS.

Все, что вы написали - присутствует в jooomla (покрайней мере, в 1.5x). Насчет серьезности и бесплатных cms: На мой взгляд, проект, над которым работает большее количество квалифицированых программистов по любому выигрывает, ибо кто-то да заметит дырку в коде, кто-то да придумает как оптимальнее зделать этот запутанный фрагмент... Да и тестирование: у бесплатных cms большой круг пользователей, что не может не сказаться на продукте. На мой взгляд, "своя" cms нужна только при
1) специфичность поставленной задачи
2) простота сайта: если содержимое сайта в 5 раз меньше архива со скриптом cms, можно задуматься о целесообразности :-)
3) Желание заказчика явно выделиться (если он не внемлет доводам)
Профессионализм привлеченных программистов зачастую сложно определить заказчику, не разбирающемуся в тех деталях: оно работает, красиво выглядит - беру. Внешняя легкость в освоении таких языков как php дает возможность предлагать на рынке свои услуги людям, не разбирающимся в безопастности и еще во многих тех вещях, что требуются для создания такого сложного продукта. Сама постановка вопроса в этой теме говорит об этом: человек, не знающий как организовать межмодульное взаимодействие, уже хочет писать свою cms, и возможно будет предлагать ее заказчикам...
Хух... Теперь можете пинать :-)

Цитата ("aleksey_s"):

Цитата ("RUSYA"):

сели за круглый стол, обсудить чего же нету в популярных CMS Оказалось много чего.. ну например:
реализовать в своей CMS.

Все, что вы написали - присутствует в jooomla (покрайней мере, в 1.5x). Насчет серьезности и бесплатных cms: На мой взгляд, проект, над которым работает большее количество квалифицированых программистов по любому выигрывает, ибо кто-то да заметит дырку в коде, кто-то да придумает как оптимальнее зделать этот запутанный фрагмент... Да и тестирование: у бесплатных cms большой круг пользователей, что не может не сказаться на продукте. На мой взгляд, "своя" cms нужна только при
1) специфичность поставленной задачи
2) простота сайта: если содержимое сайта в 5 раз меньше архива со скриптом cms, можно задуматься о целесообразности :-)
3) Желание заказчика явно выделиться (если он не внемлет доводам)
Профессионализм привлеченных программистов зачастую сложно определить заказчику, не разбирающемуся в тех деталях: оно работает, красиво выглядит - беру. Внешняя легкость в освоении таких языков как php дает возможность предлагать на рынке свои услуги людям, не разбирающимся в безопастности и еще во многих тех вещях, что требуются для создания такого сложного продукта. Сама постановка вопроса в этой теме говорит об этом: человек, не знающий как организовать межмодульное взаимодействие, уже хочет писать свою cms, и возможно будет предлагать ее заказчикам...
Хух... Теперь можете пинать :-)

Ну так потому среди проектов большинство таких : натянуть тудато, дописать модуль туда-то.

Цитата ("AVD_studio"):

Вопрос Ве3: а почему будет в выводе $data?: киньте ссылку где сказано что mysql_fetch_assoc бістрее чем mysql_fetch_array?

ссылка

Benchmark on a table with 38567 rows:

mysql_fetch_array
MYSQL_BOTH: 6.01940000057 secs
MYSQL_NUM: 3.22173595428 secs
MYSQL_ASSOC: 3.92950594425 secs

mysql_fetch_row: 2.35096800327 secs
mysql_fetch_assoc: 2.92349803448 secs

As you can see, it's twice as effecient to fetch either an array or a hash, rather than getting both. it's even faster to use fetch_row rather than passing fetch_array MYSQL_NUM, or fetch_assoc rather than fetch_array MYSQL_ASSOC. Don't fetch BOTH unless you really need them, and most of the time you don't.

Теперь, понял, спасибо Ве3

Цитата:

Все, что вы написали - присутствует в jooomla (покрайней мере, в 1.5x).

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

Далее - имхо...
А вообще, jooomla явно не пример для подражания. Начиная от разделения по файлам, заканчивая ООП и паттерном MVC.
В jooomle часто, где прямо в коде html генерируется и выводится. В жумле не удобные шаблоны, не прослеживается четкий MVC. В жумле я так же не видел не фабрики, не глобального хранилища. Вообщем ООП там местами и не много... И не удивительно, думали из говно-мамбы сразу конфета жумла будет?
Я незнаю, может я ошибаюсь, с жумлой я очень поверхностно знаком.. ну отпадает какое либо желания, знакомится подробнее, когда открываю например
\home\joomla\www\modules\mod_archive.php
и боже, что это? M, V, или С ? Где ООП? Какой-то кусок марсианского кода... Пробуем дальше.. малоли, может не та папка?
\joomla\www\includes
а это что? Судя по всему файлы которые должны инклудится, куда и зачем.. не совсем понятно, но и это пол беды, если бы сходу видеть что из кучи этой файлов является ядром системы, а что рюшечками и функционалом "про запас"...

А теперь откройте ZendFremwork, который явно пример для подражания, как следует делать в "стиле ООП".. откройте Symfony.. вот оно MVC, всё логично и понятно... Аналогично Mzz..
Лично я не воспринимаю жумлу, собственно как slaed, smallNuke, phpNuke... все их в одну корзину для мусора.

Цитата:

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

Да... выигрывает.. Прямо вот именно отбирают наиболее квалифицированных, сертифицированных.. все они сидят в одном офисе в приделах одной компании, у всех их есть тим-лидеры, архитекторы, тестеры... Да? На самом деле каждый васёк, который в состоянии что-то там написать, может добавить и свой модуль в эту общую корзину для мусора... Главное чтобы его мусор не обвалился при первом запуске. При этом таких васьков "большое количество", ими никто не управляет, кто в лес кто по дрова... что каждый хочет, тот и пишет.. Читали в детстве про рыбу, рака и щуку? Они тоже одну повозку в разные стороны тянули...
Это примерно, тоже самое, что сравнивать комъюнити Linux'a и Windows'a. Microsoft же не позволяет всяким васькам добавлять что-то в дистрибутивы ОС? Пересобирать ядра системы, что-то там менять..? А в Linux'e - пожалуйста... Хотя скажу, что последнее время (лет 5) Linux поднялся на какой-то новый уровень что-ли... Новый дистрибутивы которые ставятся с пол толчка, прямо радуют.. Но вспомним например тот же Red Hat.. коих версий от васьком ой как много, и все одна мертвее другой... )