MaxSite CMS

Имеется задание: сделать сайт для журнала.
Имеется структура: Номера — рассказы — авторы. Плюс несколько дополнительных страничек а-ля статичные, плюс архивы с этими номерами на скачивание.
Дополнительно авторов нужно уметь сортировать в алфавитном порядке, а желательно ещё уметь показывать всех авторов на букву А, всех на Б и т.д. Естессно, номера по годам, рассказы по номерам, у авторов списки рассказов.

Имеются такие соображения:

• номера — это страницы с определённым типом.
• рассказы — дочерние к номерам страницы, предположительно, с другим типом.
• авторы — категории.

Что это даёт?

• Тогда на странице номера мы увидим входящие в него рассказы.
• На странице рассказа увидим, какому номеру он принадлежит, какие соседние рассказы печатались в этом номере, какой автор или какие авторы писали рассказ.
• А на странице автора увидим, какие рассказы он писал, в какие номера… и несколько слов о самом авторе в качестве description категории.

Метки в качестве авторов были забракованы за отсутствие нормальных (английских) слагов. Теоретически поле под слаг в метках есть, но вывод везде переделывать замаешься.

Другого способа связать между собой эти три сущности в рамках МаксСайта я не придумал.
В качестве альтернативы думалось о том, чтобы дерево рубрик — это были бы номера журнала по годам. Но тогда не придумал, как связать с ними авторов и рассказы. Один рассказ принадлежит одному номеру и одному или более автору, а авторы публикуют рассказы во многих номерах. Если б метки имели слаги, можно было бы ими метить рассказы.

Ещё можно отвязать эти сущности от МаксСайта, завести ещё несколько табличек, связав их необходимыми связями и сделать несколько плагинов для управления всей этой структурой и выводом её на сайте. В минусах написание не самого маленького и простого плагина.

Вопрос первый: к Максиму и тем, кто хорошо в базах разбирается. Как скажется на производительности структура: «несколько десятков или сотен страниц, у каждой до двух-трёх десятков дочек и всё это пронизано двумя-тремя сотнями (или чуть больше) рубрик»?

Вопрос второй: кто может предложить лучшее решение? Нынешнее предполагает только массы переименовываний в шаблоне, и может, в админке. Можно сделать через языковые файлы.

Я бы брал за основу мета-поля. Что-то вроде такого:

- номера — метаполе
- рассказы — определенный тип страниц
- авторы — метаполле

При создании записи-рассказа - просто отмечаем тип страницы, выбираем автора, ставим номер. Всё. Рубрики, метки - по прямому назначению.

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



Мелочь. Главное join использовать в разумных пределах. Часть стуруктуры можно заранее кэшировать. Ну и понято, если получится избежать рекурсии, то вообще проблем не будет.

Т.е. те же метки (теги), только в профиль, и с собственноручно составленными свойствами и работой с ними. Нечто типа


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


Понятно. В общем, я ещё подумаю (и попробую, куда же без этого), какое решение легче и гибче.

Метаполя при создании страниц можно вообще автоматизировать. Там ведь meta.ini, в которой можно вызывать PHP-функцию. Простор для творчества.

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

Эм… Поясни?
Свой блок с чем угодно, что на плагин взбредёт? Типа, как админ-анонс?
Это интересно. Хотя пока не представляю, для чего именно можно задействовать.

На секундочку: для пресловутых конкурсных сайтов я сделал так: создание рассказа или конкурса — взял плагин admin_page, переименовал его в admin_story и чуть-чуть изменил. Т.е. можно как обычную страницу составлять, а можно через тот плагин, там сразу выставляется тип страниц и т.п..
А главное, плагин на основе старого admin_page, того, где под редактором выводится список файлов из загрузки. Причём, не из корня uploads, а из каталога, который через мета-поле родительской страницы (конкурса) передаётся (сделать на аджаксе выбор каталога не додумался как).
Так вот, я хотел в том плагине задействовать динамические опции, чтобы выпадающим списком файлы каталога показывать, а не копировать из формы ниже. Но оказалось, что там чуть ли не отдельная реализация работы с опциями, а не из common_dir. И переписывать там надо достаточно. Так и заломало это делать.

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

Да и вообще, что-то не очень у меня получилось там свою функцию вызывать. Примерчик бы, как конкретно в том окружении это сделать. И где бы эту функцию писать так, чтобы не затереть при обновлении. Не прямо же в admin_page/edit.php


Кстати, а это мысль. Функция на тот хук цепляется, а в мета-поле вызывается.

Вот набросал пример (эдакая солянка), который поможет разобраться (или запутаться ) сразу во всех деталях.

Но прежде всего тебе нужно добавить в \application\maxsite\admin\plugins\admin_page\form.php хук, чтобы получилось так:


То есть добавили вот эту строчку



Дальше вот пример плагина myblock:



В каталоге плагина файл meta.ini:



То есть хук - это произвольный блок для страницы редактирования записи.

Фишки с meta (я их в блок вывел, но вообще это неверно - мета внизу стандартно идут) демонстрация работы с кастомной функцией.

Cпасибо, навскидку вроде всё понятно. Детальней буду разбираться завтра.

для номера:
meta_key: num-2006
meta_value: 12(40), Декабрь 2006
meta_desc: этот номер уникален тем, что… <img src="обложка">

для автора:
meta_key: auth-b
meta_value: Белоглазов Андрей.
meta_desc: Краткая биография… <img src="фото">

Страница «все номера»:
Выбрать все meta, где meta_key like num, DISTINCT.

Страница «все номера за 2006»:
Выбрать все meta, где meta_key = num-2006, DISTINCT.

Страница «номер такой-то»:
Вывести description (а как, учитывая DISTINCT?), выбрать все page.title, у которых мета — этот номер.
Под каждым page.title вывести меты авторов этих page. Это чтобы не изворачиваться и не делать DISTINCT выборку всех авторов, печатавшихся в этом номере.

Страница «все авторы»: выборка аналогичная всем номерам.

Страница «все авторы на букву Б»:
Выбрать все meta, где meta_key = auth-b, DISTINCT.

Страница автора:
Вывести description, выбрать все page.title, у которых мета — этот автор.
И ещё бы как-то извернуться и вывести все номера, в которых этот автор печатался.

И только со страницей рассказа всё предельно просто. Вывести текст. Вывести мету с номером. Вывести мету с автором\авторами.

И ещё как этим всем управлять… При вводе каждого рассказа вводить подробно всю мета-информацию по номеру и по автору — да ещё по строгим правилам.

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

Как-то так.

Я посмотрел _mso_sql_build_tag() и получается, что её можно изменить под получение любой мета. Там жестко зашито meta_key=tags, meta_table=page и meta_value=$slug. То есть можно сделать meta_key и meta_table произвольными и можно будет делать выборку по произвольному мета.