Как указать ID корневого раздела в шаблоне дизайна TPL в макросе «content menu»?
Здравствуйте, друзья!
Пожалуйте, я сразу покажу структуру сайта, а ниже будет суть проблемы:
Структура:
"Страница раздела" (допустим ее id1)
--"ПОДтраница раздела" (уровнем ниже в дереве структуры чем предыдущая страница)
----"Страница контента" (уровнем ниже в дереве структуры чем предыдущая страница)
Проблема в том, что я не могу в TPL-шаблоне "Страницы контента" найти способ автоматического указания в меню номера id корневой "Страницы раздела", чтобы появилось полноценное меню, со всеми нужными пунктами.
Глобальный макрос %parent_id% выдает только id предыдущей страницы, появляется урезанное меню, а нужно, чтобы выдавался id еще на 1 уровень выше, чем выдает %parent_id%.
То есть вручную я могу посмотреть в структуре этот id и в шаблоне указать его, но проблема в том, что этих разделов и страниц очень много. Не создавать же под каждую отдельную "Страницу контента", отдельный шаблон, чтобы изменить в нем только этот самый id в меню... Наверняка есть простое решение, которое в мою голову не постучало.
Евгений, спасибо большое. Если вы смогли бы помочь в формате "открыть такой-то файл, вставить после такой-то строки такой-то код", то я был бы счастлив, конечно.
Вот этот код добавляете в файл где хранятся кастомы, к примеру это кастом для модуля data ~/classes/сomponents/data/customMacros.php. (не забываем прописывать в permissions название функции)
public function getParentCustom($pageId = false) {
if(!$pageId) $pageId =cmsController::getInstance()->getCurrentElementId();
if($pageId) {
$hierarchy = umiHierarchy::getInstance();
$allParents = $hierarchy->getAllParents($pageId);
return $allParents[0]; // тут сами посмотрите какой индекс вам выводить, если надо примените
}
}
В самом коде вызываете его через: %data getParentCustom(%pid%)%
perfiliy, Эта вся выборка по сути идет из одной таблицы и строится иерархия страницы. Вы просто получаете по сути массив из ID страниц не обрабатывая даже их.
Просто странно говорить о нагрузки и бороться за каждую мс операции, если вы выбрали самый тяжелый шаблонизатор из имеющихся в UMI.
Евгений, да понял, что что-то не то написал, поэтому уже и удалить успел. А на другом шаблонизаторе я просто-напросто не смогу, а лицензия на ЮМИ уже несколько лет лежит без дела. В последних версиях разработчики пишут о существенном приросте производительности, вот решил посмотреть. Генерация стандартной страницы (коих будет большинство) 0.03 сек. Вроде бы не плохо. Но если посещаемость будет 10-15 тыс/сутки. Это вопрос. Хостинг самый обычный. Собственно говоря, я перевожу вот этот сайт на ЮМИ из-за больших ограничений самописного движка, мешающих его развитию. К этой больной теме я уже не один год подступаюсь, да все никак. Как вы думаете, хороша ли идея? И сильно ли увеличится скорость, если сделать на другом шаблонизаторе?
Если у вас последняя версия системы, то там и так нормальная скорость генерации страниц.
Многие не любят TPLS шаблонизатор, но у него просто большой порог вхождения (легок в изучении).
Но при наличии PHP шаблонизатора в системе, все сиро еще проще, и прирост скорости есть (хоть и не большой). 10-15 тыс в сутки это не показатель, нужно смотреть не суточную а пиковую нагрузку на сайт, сколько одновременных подключений. Сайт в основном с текстовой информацией так что я думаю это не проблема
