Как указать ID корневого раздела в шаблоне дизайна TPL в макросе «content menu»?

Question

[perfiliy]

Здравствуйте, друзья!
Пожалуйте, я сразу покажу структуру сайта, а ниже будет суть проблемы:

Структура:

"Страница раздела" (допустим ее id1)
--"ПОДтраница раздела" (уровнем ниже в дереве структуры чем предыдущая страница)
----"Страница контента" (уровнем ниже в дереве структуры чем предыдущая страница)

Проблема в том, что я не могу в TPL-шаблоне "Страницы контента" найти способ автоматического указания в меню номера id корневой "Страницы раздела", чтобы появилось полноценное меню, со всеми нужными пунктами.

Глобальный макрос %parent_id% выдает только id предыдущей страницы, появляется урезанное меню, а нужно, чтобы выдавался id еще на 1 уровень выше, чем выдает %parent_id%.

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

Большое спасибо за помощь!

Answer 1

[Евгений]

Я вижу решение только через кастомный макрос:

$hierarchy = umiHierarchy::getInstance(); 
$allParents = $hierarchy->getAllParents($currentId)

На выходе вы получите массив из всех ID родительских страниц. Делаете array_reverse и обращаетесь к первому элементу.

Comments

[perfiliy]

Спасибо большое, Евгений. Ух, а вот тут - задачка!.. Я ориентируюсь в UMI на уровне готовых TPL-макросов, а дальше уже - всё.

[Евгений]

perfiliy, Если возникнут сложности в написании кастомного макроса - пишите. Подскажу

[perfiliy]

Евгений, спасибо большое. Если вы смогли бы помочь в формате "открыть такой-то файл, вставить после такой-то строки такой-то код", то я был бы счастлив, конечно.

[Евгений]

Вот этот код добавляете в файл где хранятся кастомы, к примеру это кастом для модуля 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]

Евгений, спасибище вам большущее! Наконец-то работает!

Permissions, как понимаю, это тот файл, который находится в этой же папке?

/** Группы прав на функционал модуля */
	$permissions = [
		/** Просмотр объектов и использование форм */
		'main' => [
			'geteditform',
			'getcreateform',
			'saveeditedobject',
			'getproperty',
			'getpropertygroup',
			'getpropertyofobject',
			'getpropertygroupofobject',
			'getallgroups',
			'getallgroupsofobject',
			'rss',
			'atom',
			'generatefeed',
			'getrssmeta',
			'getrssmetabypath',
			'getatommeta',
			'getatommetabypath',
			'checkiffeedable',
			'doselection',
			'getguideitems',
			'getParentCustom',
		],

так? :) просто опыта в этом у меня совсем нет.
это нормально, что и без прописывания названия функции у меня все заработало?

[Евгений]

perfiliy, Да я перепутал при добавлении своего кода именно в кастом "customMacros.php", разрешение давать не надо.

[perfiliy]

Евгений, понял, спасибо :)

[Евгений]

perfiliy, Эта вся выборка по сути идет из одной таблицы и строится иерархия страницы. Вы просто получаете по сути массив из ID страниц не обрабатывая даже их.

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

[perfiliy]

Евгений, да понял, что что-то не то написал, поэтому уже и удалить успел. А на другом шаблонизаторе я просто-напросто не смогу, а лицензия на ЮМИ уже несколько лет лежит без дела. В последних версиях разработчики пишут о существенном приросте производительности, вот решил посмотреть. Генерация стандартной страницы (коих будет большинство) 0.03 сек. Вроде бы не плохо. Но если посещаемость будет 10-15 тыс/сутки. Это вопрос. Хостинг самый обычный. Собственно говоря, я перевожу вот этот сайт на ЮМИ из-за больших ограничений самописного движка, мешающих его развитию. К этой больной теме я уже не один год подступаюсь, да все никак. Как вы думаете, хороша ли идея? И сильно ли увеличится скорость, если сделать на другом шаблонизаторе?

[Евгений]

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

Но при наличии PHP шаблонизатора в системе, все сиро еще проще, и прирост скорости есть (хоть и не большой). 10-15 тыс в сутки это не показатель, нужно смотреть не суточную а пиковую нагрузку на сайт, сколько одновременных подключений. Сайт в основном с текстовой информацией так что я думаю это не проблема