Столкнулся с проблемой.

Сайт состоит из страниц (неформализованный текст), а также дополнительных модулей типа новости, галерея etc.
притом дополнительные модули могут находится на любом уровне вложенности
сайт/раздел/подраздел/галерея
или
сайт/раздел/новости

Как лучше организовать хранение информации в бд + как лучше сделать разбор урла?

Pokoinik, таблица разделов/категорий с неограниченным уровнем вложенности через id и parent_id.

Я думаю реализовать следующее:
в цмс не использовать модреврайт,
а потом дописать расширение которое будет рендерить ссылки вида
index.php?component=news&id=10 в /news/2007/event/

Добавлено через 1 минуту и 43 секунды
+ а в бд хранить полное дерево сайта, с указанием того какой компонент где лежит

Я год назад столкнулся с такой же проблемой.
При ее решеии пришел к следующему варианту:
- использую мод rewrite, что бы перехватить обращение к файлам и разделам сайта и обработать их с помощью одного скрипта (в принципе его можно и не использовать, если перехватыват запросы чем то другим);
- использую таблицу БД, в которой храняться правила для сайта
    path - путь на который распространяется правило
    fmask - файл или шаблон имени файла на которые распространяется правило
    type - тип правила (че оно делает)
    и в нагрузку 2 числовых и 2 строковых параметра;
- адрес запроса по той таблице проверяется поэтапно начиная с корня, а затем добавляя по каталогу пути приходим к конечному адресу;
- правила вышестоящих разделов могут наследоваться вложенными.

В итоге получил следующие приимущества:
- сайт может иметь произвольную очень структуру;
- может быть супер многомодульным;
- если для модуля правила определены в таблице, то реальный файл адреса может вообще отсутствовать;
- в файлах с информацией можно хранить только реальный контент, а все оформление и панельки приобращении к файлу может пришивать скрипт ядра;
- если сам контент определить в отдельную папку и правильно настроить сервер на доступ только к ней, конечному пользователю будет очень трудно "уранить" такой сайт, испортить контент пожалуйста, а вот повредить само ядро сложновато.

Безусловно 



А дальше в пхп разбирать $_GET. Все остальное пихать в $_POST
Хранение в базе? Все просто: OWNER, SUBOWNER ... Т.е. ID ближайшего родителя и ID самого первого.

я видел различные CMS и в них люди по разному решают такую задачу,
кто то делает поле альтернативный адрес + rewrite,
кто то делает сложную структуру с вложениями,
а некоторые отдельные личности делают CMS на файлах.

Советую посмотреть реализацию роутера от Zend'а: Zend/Controller/Router.

Дерево с генерацией type-in адресов типа site.com/razdel/podrazdel/galereya.htm , однозначно.
Саму галерею (или какой там ещё внешний скрипт) вызывать спец.вставкой в код требуемого узла дерева.
Например, у меня в LiveTree ( http://Wgent.com/LIVETREE.htm ) в коде может присутствовать множество макровставок, таких, как {URL:раздел/подраздел/галерея}, {LIST:раздел/тип_подраздела} и, в частности, {SCRIPT:path/gallery.php?parameter1=value1&parameter2=value2&etc}
Пришлось, конечно, немножко повозиться с ob_get_contents(), с глобальными переменными типа $HTTP_GET_VARS, $_SESSION, до сих пор не решил проблему с getenv("SCRIPT_NAME"), но зато теперь почти любой чужой скрипт включаю в дерево одной строчкой (плюс правкой его конфигов в плане полного изничтожения шапки и переделки темплейтов)  

Это сообщение отредактировал(а) maxbrown - 16.6.2008, 11:49

Что за атавизмы Вы используете?!



А константа __FILE__ не годится?

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

Это не я getenv("SCRIPT_NAME") вместо __FILE__ использую. Это вызываемый скрипт может её использовать в лучшем случае (в худшем он поюзает таки-константу __FILE__, и тогда дело вообще труба.)

P.S. Вызываемый скрипт - чужой, огромный и заранее не известный.

Это сообщение отредактировал(а) maxbrown - 17.6.2008, 02:03

maxbrown, а, понятно. Работаем с черным ящиком?
Я бы, по правде говоря, посоветовал включить STRICT режим, отключить совместимость с ZE1 и запретить олдовые супермассивы.