Надвигается у меня такой вот проект: сайт-каталог журнала фантастики.
Чем он характерен. Есть три типа сущностей: номер, публикация, автор. Номеров, кстати, много — за пять лет. Каждая сущность — это вполне себе обычная нода. Т.е. текст, немного картинок. Ну, может быть, какие-то дополнительные поля по аналогии с шестерёнкой иконки ноды. Самая соль во взаимосвязи.
Номера должны иметь иерархию год←месяц←номер. Каждая публикация должна принадлежать определённому номеру (а лучше, если есть возможность и нескольким, чтоб не нужно было разбивать повесть на несколько нод). Каждая публикация должна иметь больше нуля авторов. К номеру может быть приложен pdf для скачивания (хотя в принципе, есть намёки на то, что на эти pdf потребуется по платной подписке организовать доступ).

Итого, требуется возможность посмотреть все номера, все номера за определённый год, содержание любого номера, страницу любого автора, а также все произведения, всех соавторов и все номера, где этот автор публиковался. Другие подобные списки тоже приветствуются и могут понадобиться.

С плагинописательством под когир только знакомлюсь (разбираю уроки, читаю документацию). На любой традиционной CMS эту структуру можно реализовать примерно следующим образом: номера — это дерево категорий (узлы дерева, а узлы верхнего уровня — это года). И хорошо, если в движке можно для категории длинное описание сделать, которое оформить как ноду номера. Авторы — это теги. Любая страница может иметь однин или больше тег, все произведения автора соответственно — страница тега. Опять же, за счёт описания, метаполя или ещё чего-то такого… Или просто сделать отдельную страницу автора, помеченную тегом и не входящую ни в какую категорию, и чтобы при заходе на тег она была самой верхней.

Вы спросите: зачем же когир, если так просто получается на каком-нибудь другом движке? Отвечу: я хочу получше изучить когир. А хорошо изучить движок невозможно просто почитывая оф-сайт да раз в несколько месяцев ставя на локалку на полчаса экспериментов. Для этого нужно на движке сделать проект, который потребует перебрать кучу существующих плагинов, если их сотни и тысячи (это для движков уровня друпала и компании), потребует написать свои плагины, поизворачиваться с нестандартным применением и так далее. Важное замечание: это не должен быть проект с жёсткими сроками и материальной ответственностью. Поэтому когда у меня такие проекты встречаются, я стараюсь делать их на ещё не освоенных технологиях.

В общем, натолкните на мысль, как правильней будет делать такой проект на когире. Самое начальное, что крутится в голове, это создание одной шестерёнки или более, которые в свою очередь при инсталяции делают ALTER TABLE `nodes` ADD, добавляют одну-две таблицы для отслеживания связей и т.п. (не вижу в существующей структуре ничего для мета-информации нод, ничего напоминающего CCK). Каталоги нужного вида выводить силами своей шестерёнки. Как-то так.

Как очень хреновый вариант — переписать стандартные шестерёнки, чтобы назывались они не «блоги», «юзеры», «теги» (и вызывались по урлам не «community», «user», «tags»), а реализующими нужную мне структуру. Но не хотелось бы так поступать — это же полная потеря совместимости.

Как довольно средний вариант — брать эти шестерёнки и копипастить свои по образу и подобию.

Также в существующем варианте не вижу (может, плохо смотрю?) ничего для организации иерархии, но в то же время где-то на сайте встречал упоминание, что во второй версии движка будет API для работы с деревьями. В связи с чем у меня отвлечённый вопрос: не лучше ли подождать второй версии движка, или как там будет с совместимостью? Попутно вопросы: почему pages выделены в отдельную сущность, если можно оставить ноды и только добавить колонку типа (тогда если понадобится новый тип страниц — не проблема добавить без добавления новой таблички)? Почему нет дерева категорий? Не догадались, посчитали нецелесообразным или ещё что-то?

Примерно так. Что скажете?