Давным-давно, когда я еще тоже пользовался чанками и сниппетами, я, как и многие другие, тоже использовал конструкции типа [[~[[+id]] ]] (часто используется в чанках, формирующих данные на списки документов) или [[~[[*id]] ]]. При чем этот синтаксис пришел к нам еще со времен самых первых MODx.
Если кто не знает, объясню, что здесь происходит: Это двойная конструкция. По плейсхолдеру [[+id]] или [[*id]] MODX-парсер получает id документа. Далее этот id уже замещает указанный плейсхолдер, и получается тег-ссылка, к примеру [[~1]]. И вот уже эту ссылку MODX-парсер окончательно парсит, определяя указанный id документа и получает ссылку, выполняя $modx->makeUrl(id документа). Операция это довольно-таки затратная, а вызовов на странице может быть довольно много.
Но ведь уже прошло очень много времени, и MODX серьезно развился, и давно уже все документы имеют атрибут uri (адрес страницы). Так вот, если у вас есть возможность (если в получаемых данных есть параметр uri), используйте его. Я давно уже его использую, и пока еще не было случая, чтобы возвращаемый адрес был не правильным. К примеру, вместо [[~[[*id]] ]] вы можете использовать [[*uri]] (то есть ссылка на текущий документ. В текущем документе эта конструкция всегда будет работать). А [[~[[+id]] ]] заменить на [[+uri]]. Это снизит нагрузку на парсинг этих тегов более чем в два раза (во-первых, на один тег меньше, а во-вторых не используется $modx->makeUrl()).
В Smarty я же вообще все данные в списках документов получаю через list-процессоры из shopModx-а. Так вот там я в цикле когда набиваю данные документов, я давно уже не использую конструкции {link id=$object.id} (и уж тем более не использую [[~{$object.object_id}]]). Я просто пишу {$object.uri} и все. И MODX-парсер отдыхает.
не в тему, но касается парсера тоже.
тот же quip, например, вообще еще никем не был заменен (всякого рода modxtalks и tickets не рассматриваю), но тормозит систему так дико, что лучше его даже старый добрый тормозной phpthumbof работающий вообще даже с графикой.
подебажив quip немного видно, что там сплошняком парсер с тегами работает и именно это вызывает дикие тормоза (как, впрочем, и везде в modx). Даже такая фигня как выдача формы «quipreply» нагружает систему похлеще getresources.
отсюда вопрос, может парсер новый написать будет проще? не?
тот же quip, например, вообще еще никем не был заменен
Самая масштабная замена, это discuss. Но я писал свой недобрый обзор. Все-таки это далеко от того, что хотелось бы иметь. Но там скидку большую надо делать на то, что он зародился за долго от появления последних интересных обновлений в MODX-е.
отсюда вопрос, может парсер новый написать будет проще? не?
Ну вот мы используем Smarty и радуемся. А замена родного парсера в MODX-е (полное его обновление) обсуждается. Не исключено, что не пройдет и года, и он появится.
ну тогда выдыхаем.
О, да да да, медленные чанки и парсер.
Похвастаюсь и тут, что я накопал. Как укорить работу парсера modx revo? Ответ просще, чем кажется.
modxclub.ru/blog/sandbox/175.html
Что интересно, для многих проектов этого решения может хватить с головой!
Твое решение конечно же ускоряет работу (верю на слово), но ведь одно другому не мешает. Зачем лишнюю работу создавать там, где это не требуется?
Оба решения верны.
Обновление же PHP, о чем врядли кто-то даже подозревал, сильно поможет всем, кто еще не дорос до твоего уровня и копается в чанках, тегах, и супер-вложенных завихрениях. Это факт, могу за себя даже сказать, все с этого начинают.
Решение с обходом парсера вообще — само по себе бомба. Но НЕ ВСЕМ оно будет по зубам.
Так что тут просто два решения, и оба верны.
И хорошо их делать оба :-)
Заменяю в Smarty шаблоне [[~[[*id]] ]] на {$object.uri} — вообще ничего не отображается:
{block name=header} ..... <link rel='canonical' href="" /> ..... {/block}
Может настройки Настройки системы=>Параметры нужно как-то настраивать?
А массив $object точно есть? И откуда? Он просто так не появляется. И в топике основная мысль — замена [[~[[*id]] ]] на [[*uri]].
но только сниппеты (getResource, getProducts и т.д. ) [[+url]] не поддерживают, wayfinder вроде поддерживает, у него [[+link]] есть, правда как он этот плейсхолдер получает я не знаю, исходник копать руки не дошли. Я как-то на одном из сайтов ссылки таким образом выводил
<a href="[[++site_url]]/catalog/[[+alias]].html">[[+pagetitle]]</a>
чтобы на основную страницу нагрузку снизить.
Добрый день. Заметил такой баг в снипете при попытке
$modx->makeUrl(111);
Url формируется, но при этом все равно получаю ошибку — `111` was requested but no alias was located.
Чистил, проверял кэш context.cache.php, все alias на месте. Кто сталкивался, помогите?