Кудашев Сергей

И да и нет. В настройках можно задать в notfoundparamalert.parameters значение * и тогда плагин будет собирать все несуществующие страницы со всеми GET параметрами.

Но тут необходимо учитывать один момент, компонент заточен именно для сбора несуществующих страниц с GET параметрами, поэтому для срабатывания страница должна их содержать. В основе компонента используется метод объекта Request getParameters(), который вырезает из запроса все части запроса связанные с формированием URL страницы, поэтому страницы без GET параметров логироваться не будут.

На пальцах это выглядит так:
www.example.com/manger/ — не сработает, так как GET параметры отсутствуют
www.example.com/manger/?test=1 — сработает, так как GET параметр присутствует

И тут есть два варианта, если Вы хотите проверить работает ли компонент, то можете сами составить запрос на несуществующую страницу с нужными параметрами. Например в настройках notfoundparamalert.parameters устанавливаем в _open* и сами физически заходим на заведомо несуществующую страницу с данным GET параметром, например www.example.com/advertisingg.html?_openstat=FleD5yGst1ZxN. После этого проверяем залогировалось ли и тогда можно быть уверенным, что все посещения пользователей несуществующих страниц с аналогичной меткой будут залогированы.

Либо если Вы хотите собирать все несуществующие страницы, то можно установить logpagenotfound от одного из создателей MODX.

Рекомендовал бы заменить конструкцию в сниппете:

if (!$utmHeaders) {
    return 'Could not load utmHeaders class!';
}

на что-то подобное

if (!$utmHeaders) {
    $modx->log(modX::LOG_LEVEL_ERROR, 'Could not load utmHeaders class!');
    return '';
}

Смысла выводить текст с ошибкой посетителю нет, к тому же это может поломать верстку в зависимости от места, где мы будем вызывать сниппет. А о том, что что-то пошло не так, мы бы никогда не узнали в Вашем варианте :)

Да, это возможность указания глубины вложенности для определенного родителя. Так же он работает для «Быстро создать».

Уважаемый Sem, спасибо за исчерпывающий комментарий. По первому пункту действительно ошибся. По второму и третьему пунктам взял на вооружение. Хотя и знал про Настройку форм, но как-то не приходила в голову мысль убирать шаблоны.

P.S. не просто признавать, что изобрел велосипед, но в данном случае так и есть :) Спасибо, что указали на это.

По первому пункту действительно ошибся. Спасибо, что указали на это :)

Александр, как уже писал, лично мне не зашло ни одно из имеющихся решений, включая и Inherit Template. Но это дело вкуса :)

Из всех имеющихся решений Inherit Template действительно одно из лучших с точки зрения удобства, назначил TV и забыл. С другой стороны, лишняя TV, плюс она доступна для редактирования в родителе (что уже порождает возможность тыкнуть в нее любопытному менеджеру, хотя ее можно и скрыть через доступ), плюс возможность работы только с одним уровнем вложенности и, насколько я понимаю MODX и логику компонента, сделать мультивложенность на TV прямым путем не получится.

Итак, суть проблемы в том, что при создании документа в каком-то родителе ему присваивается шаблон соседних документов. Но это не точно! © Big Russian Boss

P.S. У самого были сомнения про эту картинку, но различное поведение указания шаблона при разных способах добавления документа просто не оставило мне шанса не пошутить подобным образом :)

Спасибо за наводку, но Ваше решение меня не подойдет. Во-первых оно вынуждает создавать TV, что плодит лишние сущность. Во-вторых, оно не оформлено в пакет, что в общем не очень хорошо с точки зрения масштабируемости :)

P.S. Алексей я никоим образом не придираюсь, но мне не понравилось ни одно из найденных решений, включая TemplateSelect, AutoTemplate, Inherit Template, а так же многочисленные безымянные решения на официальном форуме :) Именно поэтому реализовал свое видение решения данной проблемы.

Олег, не совсем понятно, зачем Вам это надо, но это можно легко сделать самому. В системных настройках pdotools проверяете, чтобы опции pdotools_fenom_modx и pdotools_fenom_php были включены. Создаете пустой чанк testChunk, именно пустой, потому что если контент из него будет рендериться, придется долго ждать. После чего замеряете или от момента начала обработки входящего запроса MODX или само время обработки цикла. Корректнее конечно второй вариант, но первый тоже можно поглядеть, ради интереса:

1. Посчитать время с момента начала обработки входящего запроса MODX:

{var $start = $modx->startTime}

{for $counter=1 to=10000}
   {include 'testChunk'}
{/for}

{$.php.microtime(true) - $start}

2. Посчитать время выполнения только в блоке обработки цикла:

{var $start = $.php.microtime(true)}

{for $counter=1 to=10000}
   {include 'testChunk'}
{/for}

{$.php.microtime(true) - $start}

Если не заметно, кто именно быстрее, увеличиваете значение to, пока не станет понятно :)

P.S. Насколько вижу insert немного пошустрее :) Только это хоть как-то заметно от 10000 вызовов поэтому на реальном проекте Вы вряд ли заметите разницу.

У Ильи не видел, видимо проглядел. Спасибо, взял на заметку :)

по тексту поста [[[[*isfolder:isnot=`1`:then=`$testChunk`]]]] как раз писать не надо :)

Да с include работает как надо. Спасибо :)

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

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

Сидит ворона с сыром, подходит лиса бьет бейсбольной битой, забирает сыр и уходит. Ворона сидит и думает: «Нормально так басню сократили!».

В любом случае спасибо, постараюсь воспользоваться советами о том, как можно сделать значительно короче.

P.S. не являюсь большим специалистом по Fenom, однако конструкция в шаблоне с включенным pdotools_fenom_parser:

{var $isfolder = '[[*isfolder]]'}
{if $isfolder > 0}
    Do nothing
{else}
    [[$testChunk]]
{/if}

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

Павел, можно. Я им пользуюсь почти на всех проектах, кстати, спасибо Илье :)

Но это не совсем правильно, водить пользователя с контекста через цепочку редиректов. Все таки с моей точки зрения объявление должно вести на страницу, которая сразу отдаст 200 ответ заголовка. Да и спасибо за идею, надо подумать есть ли смысл отслеживать аналогичные параметры при редиректе.

Если нужно, чтобы эта опция снова заработала до нового релиза, то необходимые исправления можно посмотреть тут. Всего одна строчка :)

Или ждать нового релиза, исправление уже добавили в новую ветку.

Если нужно, чтобы эта опция снова заработала до нового релиза, то необходимые исправления можно посмотреть тут. Всего одна строчка :)

Или ждать нового релиза, исправление уже добавили в новую ветку.

После данного обновления в Управлении Пакетами при Просмотре деталей перестала отображаться «Загруженная версия». В error.log пишется ошибка «You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'ASC, modTransportPackage.release_index DESC LIMIT 20' at line 1».

Проблема в том, что в данном обновлении в методе sortby из xpdoquery.class.php стал обязательным второй аргумент и старый код обрабатывающий пакеты перестал работать. Если кому-то нужно, чтобы эта опция заработала до нового релиза, то необходимые исправления можно посмотреть тут. Всего одна строчка :)