Какие функции Вы хотели бы видеть в СMS? Имеется ввиду основные функции/возможности, а не возможности подключаемые через модули, т.к. они будут практически неограничены.

Сам CMS его ядро должно нести в себе то, что польхователь не видит.
Т.е.
1. Ведение лог файлов о ошибках.
2. Авторизация / регистрация, ограничение доступа.

Цитата(Mal @ 17.6.2005, 17:54)

2. Авторизация / регистрация, ограничение доступа.

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

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

2) Реестр с данными всех настраевоемых модулей. т.е. например мы имеем класс в котором есть несколько свойств. Значения по умолчанию в этом классе используются как режим safe_mode для предотвращения сбоев, а данные с которыми работает класс определяются из общего реестра который можно определить ввиде таблицы БД... например...

Имя_модуля | Переменная | Значение

таким образом мы обеспечим более гипкую возможность внесения изменений во множество свойств.

по моему вместо рееста, следует иметь по конфиг файлу или даже несколько к каждому модулю

Цитата(Irokez @ 17.6.2005, 22:12)

по моему вместо рееста, следует иметь по конфиг файлу или даже несколько к каждому модулю

Это затруднит их изменения... с БД будет проще работать... чем мы сделаем 500 файлов с настройками...

Цитата(Master @ 17.6.2005, 21:26)

Это затруднит их изменения... с БД будет проще работать... чем мы сделаем 500 файлов с настройками...

не надо перегибать, не 500 конечно же
с файлами как раз таки проще работать, чем править запросами ;)

Цитата(Irokez @ 17.6.2005, 21:29)

с файлами как раз таки проще работать, чем править запросами ;)

всё таки лучше с базой, пусть всё будет в одном месте

Wowa
на будущее - граммотный инсталятор

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

На счет настроек мое мнение таково:
Хранить все конфиги в XML файле.
Один глобальный конфиг для всей системы в целом. Для модулей конфигурационный файл будет лежать в домашней директории этого модуля.

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

Хотелось бы предусмотреть в CMS использование Web-сервисов. Где это может пригодиться? Ну к примеру если этот движок будет использовать какой нибудь оптовый магазин который захочет предоставить своим клиентам, у которых есть свои интернет магазины, данные по товарам которые есть у него в наличии или будут.
Но это правда для тех кто принимает заказы а потом уже закупает все необходимое у торговца.

Да много где еще можно использовать.

Цитата(IZ @ 20.6.2005, 17:59)

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

Здесь большая закавыка. Можно сделать очень гибкую систему прав, как в Novell eDirectory или MS Active Directory, даже в PEAR есть что то подобное. Но это дело очень тормознутое что бы поднимать при каждом запросе. У себя я сделал сущности: право(дерево), юзеры+связка с правом, роли + связка с правом, связка юзеры - роли. В итоге поднимаем эффективные права юзера парой больших запросов с кучей LEFT JOIN'ов при логине. Затем создаёться сессия в которой кешируються все права. Конечно по эффективности летает, но проблемы в апдейтах прав, что бы изменения вступили в силу юзеру нужно перелогиниться. Ещё косвенные дыры в безопасности может быть из-за сессий. Сессии поднимаю свои на БД. Плюсы подхода в реальной гибкости, можно определять(декларировать) любые права (с каждым новым модулем), настраивать гостевых и мультилогин юзеров. Много что можно

Гораздо проще сделать таблицу в которой все возможные права в колонках. Если юзер имеет право, то ставим ему не null. Метод очень быстрый и не требует кеширования, так например сама MySQL с правами работает. Из минусов не расширяемость такой системы прав, все права должны быть определенны. А прав в большой системезачастую очень много. Также хочеться не задавать кучу прав, а отдать узел дерева прав, так что все подузлы и листья автоматом принимаються. Тогда если дать модератору право на /root/modules, где в узле все узлы с личными правами модулей, то при добавлении нового модуля модератор автоматом получить все новые права, никаких действий со сотороны админа не требуеться.

А я просто создал таблицу, в которой:

Код

ИД ЮЗЕРА ИЛИ ГРУППЫ              РАЗРЕШЕННОЕ ДЕЙСТВИЕ ...

Все, что не разрешено - запрещено.

Цитата(Wowa @ 20.6.2005, 23:21)

А я просто создал таблицу, в которой:

К примеру созал ты новую примочку - гостевую книгу. В системе появились новые права: постить в книгу(книга у нас вообще абстрактный блог, много где используеться), редактировать, удалять, редактироваьт чужие и т.п.

Получаеться нужно проапдейтить прова всех существующих юзеров при добавлении примочки?

Цитата(Sardar @ 20.6.2005, 23:29)

Получаеться нужно проапдейтить прова всех существующих юзеров при добавлении примочки?

юзеры разделены на группы. А проапдейтить права нескольких групп - чепуха.
Добавлено @ 00:33
Даже если групп много, то все равно. Т.к. слишком много их быть не может и нет необходимости в этом..
Добавлено @ 00:35

Цитата(Sardar @ 20.6.2005, 23:29)

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

Не важно. Записываешь в таблицу каждое разрешенное действие для каждой группы. Система должна быть очень сложна с разветвленной системой доступа и многими группами, чтобы начались тормоза.

Цитата(Mal @ 17.6.2005, 18:54)

2. Авторизация / регистрация, ограничение доступа.

Очень хороший для этих целей класс: phpGACL: http://phpgacl.sourceforge.net/
Есть перевод доков на русский: http://php.russofile.ru/ru/translate/rights/phpgacl/

Цитата

PhpGACL – это набор функций, который позволяет определить права доступа к произвольным объектам (например, страницам, базам данных и так далее) другим объектам (например, пользователями, удаленными хостами и так далее). Это предполагает подробный контроль доступа с простым управлением и высокой скоростью.