Fi1osof 01 августа 2013 12 14
Давным-давно, когда я еще тоже пользовался чанками и сниппетами, я, как и многие другие, тоже использовал конструкции типа [[~[[+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-парсер отдыхает.
14 комментариев
den991
den99 03 августа 2013г в 03:27 #
не в тему, но касается парсера тоже.
тот же quip, например, вообще еще никем не был заменен (всякого рода modxtalks и tickets не рассматриваю), но тормозит систему так дико, что лучше его даже старый добрый тормозной phpthumbof работающий вообще даже с графикой.
подебажив quip немного видно, что там сплошняком парсер с тегами работает и именно это вызывает дикие тормоза (как, впрочем, и везде в modx). Даже такая фигня как выдача формы «quipreply» нагружает систему похлеще getresources.

отсюда вопрос, может парсер новый написать будет проще? не?
Fi1osof1
Fi1osof 03 августа 2013г в 09:45 #
тот же quip, например, вообще еще никем не был заменен
Самая масштабная замена, это discuss. Но я писал свой недобрый обзор. Все-таки это далеко от того, что хотелось бы иметь. Но там скидку большую надо делать на то, что он зародился за долго от появления последних интересных обновлений в MODX-е.
отсюда вопрос, может парсер новый написать будет проще? не?
Ну вот мы используем Smarty и радуемся. А замена родного парсера в MODX-е (полное его обновление) обсуждается. Не исключено, что не пройдет и года, и он появится.
den991
den99 03 августа 2013г в 11:49 #
ну тогда выдыхаем.
den991
den99 05 августа 2013г в 18:57 #
О, да да да, медленные чанки и парсер.
Похвастаюсь и тут, что я накопал. Как укорить работу парсера modx revo? Ответ просще, чем кажется.
modxclub.ru/blog/sandbox/175.html

Что интересно, для многих проектов этого решения может хватить с головой!
Fi1osof1
Fi1osof 05 августа 2013г в 20:17 #
Твое решение конечно же ускоряет работу (верю на слово), но ведь одно другому не мешает. Зачем лишнюю работу создавать там, где это не требуется?
den991
den99 05 августа 2013г в 20:22 #
Оба решения верны.
Обновление же PHP, о чем врядли кто-то даже подозревал, сильно поможет всем, кто еще не дорос до твоего уровня и копается в чанках, тегах, и супер-вложенных завихрениях. Это факт, могу за себя даже сказать, все с этого начинают.

Решение с обходом парсера вообще — само по себе бомба. Но НЕ ВСЕМ оно будет по зубам.

Так что тут просто два решения, и оба верны.
Fi1osof1
Fi1osof 05 августа 2013г в 20:57 #
И хорошо их делать оба :-)
den991
den99 06 августа 2013г в 00:26 #
den991
den99 06 августа 2013г в 00:47 #
О!
Для версии сайта для анонимусов еще третье надо сделать, а именно:
Установить xFPC

(ссылка, запасная)
и будет полный атас, почти как гугл.
den991
den99 06 августа 2013г в 08:09 #
a
almaks 15 июня 2015г в 12:04 #
Заменяю в Smarty шаблоне [[~[[*id]] ]] на {$object.uri} — вообще ничего не отображается:

{block name=header}
.....
<link rel='canonical' href="" />
.....
{/block}

Может настройки Настройки системы=>Параметры нужно как-то настраивать?
Fi1osof1
Fi1osof 15 июня 2015г в 13:54 #
А массив $object точно есть? И откуда? Он просто так не появляется. И в топике основная мысль — замена [[~[[*id]] ]] на [[*uri]].
a
als1984 15 июня 2015г в 23:53 #
но только сниппеты (getResource, getProducts и т.д. ) [[+url]] не поддерживают, wayfinder вроде поддерживает, у него [[+link]] есть, правда как он этот плейсхолдер получает я не знаю, исходник копать руки не дошли. Я как-то на одном из сайтов ссылки таким образом выводил
<a href="[[++site_url]]/catalog/[[+alias]].html">[[+pagetitle]]</a>
чтобы на основную страницу нагрузку снизить.
А
Андрей Балкин 07 августа 2015г в 12:32 #
Добрый день. Заметил такой баг в снипете при попытке
$modx->makeUrl(111);

Url формируется, но при этом все равно получаю ошибку — `111` was requested but no alias was located.

Чистил, проверял кэш context.cache.php, все alias на месте. Кто сталкивался, помогите?
Авторизуйтесь или зарегистрируйтесь (можно через соцсети ), чтобы оставлять комментарии.