Василий Наумкин

1. Они так и должны выводиться, по menuindex. Но нужно понимать, что выводится не дерево, а именно категории, и к ним уже добираются раздельно их родители.
То есть, отсортированы по menuindex именно категории, без своих родителей.

2. Если у ресурсов указана дата отмены публикации, то нужно использовать поле unpub_date, а не createdon.

Ну я не знаю, может начать всё-таки с getTickets, который выводит тикеты и поддерживает все нужные плейсхолдеры и параметры?

mFilter2 не может работать со всеми сниппетами на свете. Они должны, как минимум, иметь параметр &returnIds=`1`, при включении которого будет возвращен список подходящих id ресурсов.

Ну и я вообще не понимаю, как именно могут фильтроваться результаты сниппетов TicketLatest (смысл которого выводить последние тикеты или комменты, в порядке их появления) или pdoCrumbs (который выводит хлебные крошки в строго определённом порядке).

На мой взгляд, если возникают подобные идеи — на сайте что-то очень не так.

Вывести, если оно уже получено сниппетом, примерно так же как и раньше:

{$tvname}

А получить прямо из шаблона или чанка можно так

{$modx->getObject('modResource', 15)->getTVValue('tvname')}

Если ресурса с id 15 нет, то будет ошибка. Поэтому, безопаснее вот так:

{set $resource = $modx->getObject('modResource', 15)}
{if $resource}
	{$resource->getTVValue('tvname')}
{/if}

Не знаю, так повелось.

Большинство функционала Tickets нагло позаимствовано с Хабра, а там с этим строго.

Какие id,class должны быть

Посмотри в родных чанках галереи, это несложно.

А где здесь вообще FancyBox?

Этот сайт похож на блог?

Он сделан на Tickets.

То, что сначала нужно установить стабильную версию, я потом её обновить — нормально. Сейчас действительно доступны 2 ветки, причем вторую для рабочих сайтов устанавливать не рекомендуют.

А вот косяк с раздвоением поправил.

Да там 10 разу уже всё поменялось, так что не получится.

Скоро будет платное дополнение для вывода погоды с Яндекс, можно будет прикупить.

Что-то мне надоело угадывать, что ты имел в виду.

Давай дальше сам.

Ну а эта конструкция, по твоему, как-то магически данные получает, без запросов в БД?

Бери плейсхолдер [^t^], делай разные запросы и замеряй производительность.

Это же наоборот круто, больше не будет пустых или кривых тегов, от которых может повеситься парсер MODX.

В конце концов, любые изменения оформления сайта — это разработка, и её нужно проверять.

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

Что там, что там в итоге вызывается метод MODX и дальше всё время уходит ему. Поэтому используй что удобнее.

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

Нет, ты неправильно понимаешь.

Раньше &cache_key указывал только префикс для кэша — директорию куда его складывать. Сейчас префикс по умолчанию default, если указывается свой &cache_key. Если не указывается, то для pdoPage генерируется ключ по старому алгоритму, который отправляет его в кэш ресурса.

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

Но, если вдруг тебе необходимо на разных страницах сайта выводить один и тот же контент, с одной и той же постраничной навигацией, то теперь можно сделать и так:

[[!pdoPage?
	&parents=`0`
	&ajaxMode=`default`
	&cache=`1`
	&cache_key=`pdopage/page1-[[!#request.page]]`
]]

Еще раз повторяю — раньше такого не было, ты просто менял директорию для хранения кэша, а внутри там всё равно были пути к ресурсам.

Сейчас всё гораздо круче:

Ибо когда +300 страниц, и на каждой странице (?page=) будет время 3-10 секунд

У нас здесь тысячи страниц выводятся без кэша — и нет проблем. Как так?

Подтверждаю. Видимо, Chrome обновился =)

Не нужно указывать cache_key для pdoPage.

Нашел в чем дело, в новой версии будет исправлено.

А пока можно просто переписать на Fenom вот так:

{$modx->getChunk($modx->resource->id == 1 ? 'chunk1' : 'chunk2')}

Да, похоже парсер MODX где-то успевает подлезть.

Попробую разобраться.

Нет, Fenom работает как PHP. Если условие не срабатывает — ничего внутри не запускается.

Можно смело делать вот так:

{if $.get.test == 1}
    [[!pdoResources?
        &parents=`0`
    ]]
{else}
    [[!pdoMenu?
        &parents=`0`
    ]]
{/if}

И проверять страницу, передавая параметр ?test=1 или ?test=0

А пример у тебя неверный, не знаю, где ты такое вычитал.