Вопросы специалистов

Документация для специалистов

Песочница

Вопросы клиентов

Хотелки

Решения проблемы большой карты ресурсов, существующие на сегодняшний день

Организация хранения данных об изображениях галереи

Добавление новых полей в ордер

после установки ShopModxBox работает частично :(

Валидация username

Ссылка на соседние статьи в articles

Вопрос с многоуровневым меню как-то решился.... или нет?

Корректировка заявки

Пагинация

Взаимодействие ModxTalks и Xlexicon

Также есть способы обхода (не решения, а именно обхода) проблемы большой карты ресурсов:
 2.Хранение кэша в оперативной памяти (memCached)
 3.Раскидывание ресурсов по разным контекстам (не всегда удобно, поскольку при необходимости загружать одни и те же ресурсы в разных контекстах придётся либо плодить символические ссылки, либо использовать (OnPageNotFound + sendForward))

Эти варианты обхода практически бесполезны. Во-первых, проблема не только в хранении этого большого кеша, а в самой генерации кеша. Ведь каждый раз при сбросе кеша MODX должен в базе данных обойти все документы и нафигачить их в кеш. Когда у вас будет под сотню тысяч документов, средний сервер просто не справится с этой задачей, кеш соберется не полностью и сайт просто сломается (из-за попытки подгрузки невалидного php-кода). Во-вторых, раскидывая документы по разным контекстам, объем задач по генерации кеша не уменьшается, так что это только снижает объем загружаемого кеша при заходе на конкретный контекст, но нагрузка на сервер при генерации кеша хоть и не на много, но все же увеличится. В-третьих, сколько же вам контекстов понадобится, чтобы раскидать по ним пару сотен тысяч документов?
 В общем, на сегодня, эти проблемы решает только cacheOptimizer. И да, при обновлении MODX его надо переустанавливать, без этого никак. 
 Не знаю планируют ли разрабы MODX-а что-то придумать на этот счет, но я решение придумал еще в 2011-ом. Там конечно картинок уже нет и код местами плохочитаемый, но суть уловить можно.
 

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

Также есть способы обхода (не решения, а именно обхода) проблемы большой карты ресурсов:
 2.Хранение кэша в оперативной памяти (memCached)
 3.Раскидывание ресурсов по разным контекстам (не всегда удобно, поскольку при необходимости загружать одни и те же ресурсы в разных контекстах придётся либо плодить символические ссылки, либо использовать (OnPageNotFound + sendForward)) Эти варианты обхода практически бесполезны. Во-первых, проблема не только в хранении этого большого кеша, а в самой генерации кеша. Ведь каждый раз при сбросе кеша MODX должен в базе данных обойти все документы и нафигачить их в кеш. Когда у вас будет под сотню тысяч документов, средний сервер просто не справится с этой задачей, кеш соберется не полностью и сайт просто сломается (из-за попытки подгрузки невалидного php-кода). Во-вторых, раскидывая документы по разным контекстам, объем задач по генерации кеша не уменьшается, так что это только снижает объем загружаемого кеша при заходе на конкретный контекст, но нагрузка на сервер при генерации кеша хоть и не на много, но все же увеличится. В-третьих, сколько же вам контекстов понадобится, чтобы раскидать по ним пару сотен тысяч документов?
 В общем, на сегодня, эти проблемы решает только cacheOptimizer. И да, при обновлении MODX его надо переустанавливать, без этого никак. 
 Не знаю планируют ли разрабы MODX-а что-то придумать на этот счет, но я решение придумал еще в 2011-ом. Там конечно картинок уже нет и код местами плохочитаемый, но суть уловить можно. А вообще, тема кеширования в MODX на столько сложная, что вот так небольшими топиками о ней рассуждать почти нет смысла. Там книги писать можно.

Также есть способы обхода (не решения, а именно об

2.Чуть медленнее будет выполняться фильтрация и сортировка по TV этих изображений. Впрочем это проблема/особенность архитектуры modx (а вернее, т.н. универсальных БД), а никак не проблема выбранного варианта хранения данных изображений

Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/

2.Чуть медленнее будет выполняться фильтрация и сортировка по TV этих изображений. Впрочем это проблема/особенность архитектуры modx (а вернее, т.н. универсальных БД), а никак не проблема выбранного варианта хранения данных изображений Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/

2.Чуть медленнее будет выполняться фильтрация и со

Здравствуйте, Николай. В тему по Вашей ссылке задам вопрос. Недавно реализовывал то, о чём Вы там писали. Возможности значительно расширяются с подобным подходом. БлагоДарю Вас от всей Души! Однако, не удалось обращаться к своим данным из таблицы site_content, как к стандартным, через плейсхолдеры. К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал?
 

P.S.: Немножко дописывал Ваш плагин, который Вы указали на Хабре. Хотел сначало выложить куда-то и скинуть Вам, а потом подумал — зачем Вам нужен мой ГК. :) И раз уж пишу тут, всё-таки предложу. Если интересно — напишите, я выложу куда-нибудь.

Здравствуйте, Николай. В тему по Вашей ссылке задам вопрос. Недавно реализовывал то, о чём Вы там писали. Возможности значительно расширяются с подобным подходом. БлагоДарю Вас от всей Души! Однако, не удалось обращаться к своим данным из таблицы site_content, как к стандартным, через плейсхолдеры. К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал? P.S.: Немножко дописывал Ваш плагин, который Вы указали на Хабре. Хотел сначало выложить куда-то и скинуть Вам, а потом подумал — зачем Вам нужен мой ГК. :) И раз уж пишу тут, всё-таки предложу. Если интересно — напишите, я выложу куда-нибудь.

Здравствуйте, Николай. В тему по Вашей ссылке зада

ВАРИАНТ 1. Для каждого графического файла создаётся отдельный ресурс (типа «Документ» или «Статический ресурс») с TV-параметрами

Пожалейте тех, кому потом придется с такой галереей работать.

ВАРИАНТ 1. Для каждого графического файла создаётся отдельный ресурс (типа «Документ» или «Статический ресурс») с TV-параметрами Пожалейте тех, кому потом придется с такой галереей работать.

ВАРИАНТ 1. Для каждого графического файла создаётс

К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал?

Так вы в смарти-шаблоне попробуйте прописать {$modx->resource->logo}. Так же getdata-процессоры вернут массивы данных ресурсов, содержащих элемент logo. Собственно, мы плейсхолдеры особо не юзаем.

К примеру так [[*logo]], пришлось писать сниппет, который восполнил мои нужды (подтягивал данные полей отмеченных в параметре у указанного ресурса). Отсюда вопрос: так и должно быть, или я что-то не так сделал? Так вы в смарти-шаблоне попробуйте прописать {$modx->resource->logo}. Так же getdata-процессоры вернут массивы данных ресурсов, содержащих элемент logo. Собственно, мы плейсхолдеры особо не юзаем.

К примеру так [[*logo]], пришлось писать сниппет, 

C другой стороны, если «каждый графический файл будет иметь свою собственную страницу на сайте (с описанием, характеристиками, комментариями и пр.)», то разве это галерея? В моем понимании, в галерее создаются изображения, а тут получается, что создаются страницы.

C другой стороны, если «каждый графический файл бу

Вариант хороший. На первый взгляд, даже идеальный:
 а) никакие join'ы не требуются
 б) каждое поле индивидуально типизировано и проиндексировано — как следствие, сортировка и фильтрация будут выполняться максимально быстро и корректно (для строковых значений сравнение строковое, для числовых — числовое)
 в) данные занимают меньше места за счёт индивидуальной типизации (верно, только если оригинальные значения TV-параметров из стандартной таблицы с TV будут удаляться)
 

Но этот вариант не всегда реализуем. Как, например, в моём случае.
 У меня более десяти типов ресурсов, у каждого — по 15-20 TV. Итого — сотни TV. Сортировка и фильтрация выполняется по большинству из них. Да, можно все эти TV (по которым выполняется сортировка и фильтрация) автоматом закинуть в (site_content) и индивидуально типизировать на основе характеристик TV. И сделать всё это программно (имя поля = tv_{id}). В mySQL допускается 4 тысячи полей в таблице. Этого с головой хватит и на текущий, и на будущий функционал. Но проблема в том, что работать с этими полями без индексов не имеет смысла, а максимально допустимое число индексов в таблице mySQL — 64. Вот это ограничение и является определяющим. Даже если для некоторых полей создавать составные индексы, всё равно индексов понадобится более 100. К тому же со временем функционал будет только расширяться, добавляться новые типы ресурсов и новые TV-поля.
 

Сейчас у меня реализован следующий вариант:
 а) все TV-поля дублируются в поле (properties) таблицы ресурсов (в формате json) — это поле используется для выборки TV
 б) при фильтрации и сортировках подключаются через JOIN только те TV, которые участвуют в этих фильтрах/сортировках (как правило, их не более 3 за раз, а 3 JOIN'а выполняются вполне себе быстро)
 в) в случаях, когда ресурс имеет большое количество TV, а в конечной выборке необходимо получить 2-3 TV-ки, эти TV join'ятся (так быстрее: на json-декодирование большого числа TV нужно время), в остальных случаях для выборки использую поле (properties) с последующим json-декодированием

Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/ Вариант хороший. На первый взгляд, даже идеальный:
 а) никакие join'ы не требуются
 б) каждое поле индивидуально типизировано и проиндексировано — как следствие, сортировка и фильтрация будут выполняться максимально быстро и корректно (для строковых значений сравнение строковое, для числовых — числовое)
 в) данные занимают меньше места за счёт индивидуальной типизации (верно, только если оригинальные значения TV-параметров из стандартной таблицы с TV будут удаляться) Но этот вариант не всегда реализуем. Как, например, в моём случае.
 У меня более десяти типов ресурсов, у каждого — по 15-20 TV. Итого — сотни TV. Сортировка и фильтрация выполняется по большинству из них. Да, можно все эти TV (по которым выполняется сортировка и фильтрация) автоматом закинуть в (site_content) и индивидуально типизировать на основе характеристик TV. И сделать всё это программно (имя поля = tv_{id}). В mySQL допускается 4 тысячи полей в таблице. Этого с головой хватит и на текущий, и на будущий функционал. Но проблема в том, что работать с этими полями без индексов не имеет смысла, а максимально допустимое число индексов в таблице mySQL — 64. Вот это ограничение и является определяющим. Даже если для некоторых полей создавать составные индексы, всё равно индексов понадобится более 100. К тому же со временем функционал будет только расширяться, добавляться новые типы ресурсов и новые TV-поля. Сейчас у меня реализован следующий вариант:
 а) все TV-поля дублируются в поле (properties) таблицы ресурсов (в формате json) — это поле используется для выборки TV
 б) при фильтрации и сортировках подключаются через JOIN только те TV, которые участвуют в этих фильтрах/сортировках (как правило, их не более 3 за раз, а 3 JOIN'а выполняются вполне себе быстро)
 в) в случаях, когда ресурс имеет большое количество TV, а в конечной выборке необходимо получить 2-3 TV-ки, эти TV join'ятся (так быстрее: на json-декодирование большого числа TV нужно время), в остальных случаях для выборки использую поле (properties) с последующим json-декодированием

Если речь о десятках и более тысяч документов, то 

Если вся суть проекта крутится вокруг этой галереи, то такой подход предпочтительней. УРЛы, параметры индексации, ТВ-параметры и все такое.

Если вся суть проекта крутится вокруг этой галереи

И раз уж пишу тут, всё-таки предложу. Если интересно — напишите, я выложу куда-нибудь.

Чессказать времени совсем нет что-то смотреть. Сорри.

И раз уж пишу тут, всё-таки предложу. Если интересно — напишите, я выложу куда-нибудь. Чессказать времени совсем нет что-то смотреть. Сорри.

И раз уж пишу тут, всё-таки предложу. Если интерес

в) данные занимают меньше места за счёт индивидуальной типизации (верно, только если оригинальные значения TV-параметров из стандартной таблицы с TV будут удаляться)

В целом по проекту: сочувствую…

в) данные занимают меньше места за счёт индивидуальной типизации (верно, только если оригинальные значения TV-параметров из стандартной таблицы с TV будут удаляться) Они удаляются. В целом по проекту: сочувствую…

в) данные занимают меньше места за счёт индивидуал

Пожалейте тех, кому потом придется с такой галереей работать. 

Например, Василий, я уверен, выбрал бы именно такой вариант (отдельная таблица).
 А что там за проблемы возникнут при работе с такой галереей?

Пожалейте тех, кому потом придется с такой галереей работать. Например, Василий, я уверен, выбрал бы именно такой вариант (отдельная таблица).
 А что там за проблемы возникнут при работе с такой галереей?

Пожалейте тех, кому потом придется с такой галерее

то разве это галерея? В моем понимании, в галерее создаются изображения, а тут получается, что создаются страницы. 

Ну так комментарии к изображению, описание изображения, списки ресурсов, с которыми связано изображение и прочая информация, касающаяся конкретного изображения должна же на какой-то странице отображаться. Можно и для такой страницы создать один специальный ресурс+шаблон и выводить там запрошенное изображение со всей информацией. Но в плане SEO эффективнее будет оформить в виде таких страниц сами ресурсы, отвечающие за изображения. Других вариантов нет. Впрочем, это уже не суть важно, как это всё организовать. Кому как нравится. Важно то, как и где организовать хранение данных об изображениях.

то разве это галерея? В моем понимании, в галерее создаются изображения, а тут получается, что создаются страницы. Ну так комментарии к изображению, описание изображения, списки ресурсов, с которыми связано изображение и прочая информация, касающаяся конкретного изображения должна же на какой-то странице отображаться. Можно и для такой страницы создать один специальный ресурс+шаблон и выводить там запрошенное изображение со всей информацией. Но в плане SEO эффективнее будет оформить в виде таких страниц сами ресурсы, отвечающие за изображения. Других вариантов нет. Впрочем, это уже не суть важно, как это всё организовать. Кому как нравится. Важно то, как и где организовать хранение данных об изображениях.

то разве это галерея? В моем понимании, в галерее 

В смысле, я что-то не то делаю? Или проект на modx труднореализуем?

В целом по проекту: сочувствую… В смысле, я что-то не то делаю? Или проект на modx труднореализуем?

В целом по проекту: сочувствую… В смысле, я что-то

Он просто труднореализуем:) Не важно на чем. Но не безнадежен.

Он просто труднореализуем:) Не важно на чем. Но не

Моя реплика относится к «Для каждого графического файла создаётся отдельный ресурс (типа «Документ» или «Статический ресурс») с TV-параметрами» — у Василия я кину на страницу 100 файлов и готово, а тут 100 раз «создать ресурс» — «открыть файл-браузер» — «загрузить картинку» — «выбрать картинку» — «сохранить ресурс».
 

У Василия вариант 2 получается, потому что ms2Gallery рассчитана на то, чтобы на странице ресурса вывести много картинок. И я бы тоже выбрал вариант 2, но в вашем случае получается, что отдельная страница на картинку, куча характеристик, комментарии — то есть скорость работы с картинками в ms2Gallery нивелируется скоростью заполнения характеристик для каждой картинки. То есть для пользователя будет почти одинаково, что вариант 1, что вариант 2, зато для вас быстрее будет сделать вариант 1.


Моя реплика относится к «Для каждого графического файла создаётся отдельный ресурс (типа «Документ» или «Статический ресурс») с TV-параметрами» — у Василия я кину на страницу 100 файлов и готово, а тут 100 раз «создать ресурс» — «открыть файл-браузер» — «загрузить картинку» — «выбрать картинку» — «сохранить ресурс». У Василия вариант 2 получается, потому что ms2Gallery рассчитана на то, чтобы на странице ресурса вывести много картинок. И я бы тоже выбрал вариант 2, но в вашем случае получается, что отдельная страница на картинку, куча характеристик, комментарии — то есть скорость работы с картинками в ms2Gallery нивелируется скоростью заполнения характеристик для каждой картинки. То есть для пользователя будет почти одинаково, что вариант 1, что вариант 2, зато для вас быстрее будет сделать вариант 1.

Моя реплика относится к «Для каждого графического 

а) все TV-поля дублируются в поле (properties) таблицы ресурсов (в формате json) — это поле используется для выборки TV

Есть еще вариант дублировать их в отдельную таблицу (:

а) все TV-поля дублируются в поле (properties) таблицы ресурсов (в формате json) — это поле используется для выборки TV Есть еще вариант дублировать их в отдельную таблицу (:

а) все TV-поля дублируются в поле (properties) таб

Чем сложнее проект, тем меньше потенциальных конкурентов

Чем сложнее проект, тем меньше потенциальных конку

Есть еще вариант дублировать их в отдельную таблицу (: 

Тогда для каждого типа ресурсов придётся свою таблицу создавать с TV (из-за ограничения на число индексов в одной таблице). Ну а коли для каждого типа ресурсов будет своя таблица, то и сами ресурсы логично будет хранить в этих таблицах. А коли ресурсы будут храниться в отдельных таблицах, тогда и modx не нужен.

Есть еще вариант дублировать их в отдельную таблицу (: Тогда для каждого типа ресурсов придётся свою таблицу создавать с TV (из-за ограничения на число индексов в одной таблице). Ну а коли для каждого типа ресурсов будет своя таблица, то и сами ресурсы логично будет хранить в этих таблицах. А коли ресурсы будут храниться в отдельных таблицах, тогда и modx не нужен.

Есть еще вариант дублировать их в отдельную таблиц

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

А еще тем выше риски, издержки и т.п., и соответст

В своём проекте я не использую какие-либо сторонние сниппеты и компоненты (кроме компонентов для работы с комментариями), поскольку ни один компонентов не обеспечивает требуемого функционала проекта. Даже элементарно хлебные крошки, пагинация, баннеры, псевдонимы, uri, ajax-подгрузка, редиректы, SEO и многое другое — всё это реализовано собственным кодом с индивидуальной логикой. Соответственно, и сабжевый вопрос подразумевает написание собственного интерфейса для загрузки изображений (но только для загрузки). Именно поэтому, я и не рассматриваю здесь возможность использования сторонних компонентов в качестве критерия выбора. Ну а собственный интерфейс для загрузки изображений будет обеспечивать возможность загрузки и одного изображения, и нескольких одновременно (с указанием характеристик для каждой из них).


В своём проекте я не использую какие-либо сторонни

У Василия вариант 2 получается, потому что ms2Gallery рассчитана на то, чтобы на странице ресурса вывести много картинок.

И в вариантах 1 тоже просто вывести много картинок на странице. Только браться они будут не из одной папки на диске (соответствующей одному ресурсу), а из нескольких (зависит от физической организации папок с изображениями) — т.е. делаем выборку требуемых ресурсов-изображений по их TV-характеристикам и получаем url'ы физических файлов.
 

В случае с ms2Gallery — там ведь нет характеристик у каждого изображения? И связь изображений с ресурсами М:1, а у меня — М: М

У Василия вариант 2 получается, потому что ms2Gallery рассчитана на то, чтобы на странице ресурса вывести много картинок. И в вариантах 1 тоже просто вывести много картинок на странице. Только браться они будут не из одной папки на диске (соответствующей одному ресурсу), а из нескольких (зависит от физической организации папок с изображениями) — т.е. делаем выборку требуемых ресурсов-изображений по их TV-характеристикам и получаем url'ы физических файлов. В случае с ms2Gallery — там ведь нет характеристик у каждого изображения? И связь изображений с ресурсами М:1, а у меня — М: М

У Василия вариант 2 получается, потому что ms2Gall

Придумал решение. Поскольку я не использую поле parent, то кэш ресурсов мне вообще и не нужен. Соответственно, после генерации файла context.cache.php (или при первой (после генерации карты) загрузке страницы) плагинами его можно подрезать. А именно — почистить подмассив 'resourceMap' (а всё остальное оставить) и перезалить этот файл. В итоге при загрузке страниц сайта будет подгружаться маленький файлик с config, webLinkMap, eventMap и policies.

Придумал решение. Поскольку я не использую поле pa

Это не решает проблемы большой нагрузки при генерации кеша.

Это не решает проблемы большой нагрузки при генера

У вас не сохраняются ваши поля в заказах, или вообще заказы не сохраняются?

У вас не сохраняются ваши поля в заказах, или вооб

Заказы сохраняются, не сохраняются мои поля.

Забыл добавить, если их добавить через базу то они выводятся, но не меняются

Забыл добавить, если их добавить через базу то они

Это потому что мап-файл не обновили.

Спасибо за помощь. Я правил но другой.
 Все работает.

Спасибо за помощь. Я правил но другой.
 Все работа

Пожалуйста.

На странице shopmodx.modxclub.ru/download/ есть FAQ.
 

Все страницы, кроме главной, не найдены. 404
 Не настроена подмена УРЛов. Переименуйте в корне сайта файл ht.access в .htaccess (с точкой). В большинстве случаев должно помочь.

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

На странице shopmodx.modxclub.ru/download/ есть FAQ. Все страницы, кроме главной, не найдены. 404
 Не настроена подмена УРЛов. Переименуйте в корне сайта файл ht.access в .htaccess (с точкой). В большинстве случаев должно помочь. Понятней спрашивайте гугл, и будет вам счастье.

На странице shopmodx.modxclub.ru/download/ есть FA

Прошу прощенья, забыл добавить… первое, что было сделано мной это прочтение FAQ и переименование в корне сайта файла ht.access в .htaccess (с точкой). Увы это не помогло. файлов на которые ссылается фронт физически нет в указанных каталогах. сайт cg19559.tmweb.ru/magazin/ :(

Прошу прощенья, забыл добавить… первое, что было с

файлов на которые ссылается фронт физически нет в указанных каталогах. сайт cg19559.tmweb.ru/magazin/ :(

Файлов этих и не должно быть. Это же ЧПУ. Все, что там должно быть — это файл index.php
 Но .htaccess — это для сервера apache. А у вас заголовки идут от nginx. Если у вас nginx не в связке с апачем работает, надо настраивать подмену УРЛов для nginx. Гуглите. Так же советую запрос в саппорт написать, если у вас не выделенный сервер (что скорее всего), а шаредхостинг.

файлов на которые ссылается фронт физически нет в указанных каталогах. сайт cg19559.tmweb.ru/magazin/ :( Файлов этих и не должно быть. Это же ЧПУ. Все, что там должно быть — это файл index.php
 Но .htaccess — это для сервера apache. А у вас заголовки идут от nginx. Если у вас nginx не в связке с апачем работает, надо настраивать подмену УРЛов для nginx. Гуглите. Так же советую запрос в саппорт написать, если у вас не выделенный сервер (что скорее всего), а шаредхостинг.

файлов на которые ссылается фронт физически нет в 

Вот спасибо! А у меня этот nginx из головы вон :) Теперь понял куда смотреть, еще раз спасибо.

Вот спасибо! А у меня этот nginx из головы вон :) 

$alreadyExists = $this->modx->getObject('modUser',array('username' => $username));
            if ($alreadyExists) {
                $this->addFieldError('username', "Username already taken. Please choose another. ");
                return $contractor; 
                
            }

Разобрался, кто заинтересован, предлагаю такое решение

$alreadyExists = $this->modx->getObject('modUser',array('username' => $username));
            if ($alreadyExists) {
                $this->addFieldError('username', "Username already taken. Please choose another. ");
                return $contractor; 
                
            } Разобрался, кто заинтересован, предлагаю такое решение

$alreadyExists = $this->modx->getObject('modUser',

Да, там действительно не хватает проверки пользователя по логину. Создал себе тикет.

Да, там действительно не хватает проверки пользова

Добавьте в чанк, отвечающий за HTML header(то что внутри тегов ...) код: 
 />


Добавьте в чанк, отвечающий за HTML header(то что 

Воспользуйся плагином siblingNav:
 1) Установи его
 2) В шаблоне статьи, там где нужно разместить ссылки на предыдущую и следующую статьи помести код:
 

[[!siblingNav? &showHidden=`1` &limit=`1` &sortBy=`{"publishedon":"ASC"}`]]
[[+sn.first]][[+sn.prev]][[+sn.prevlinks]][[+sn.self]][[+sn.nextlinks]][[+sn.next]][[+sn.last]]

Если сортировка неправильная, то вместо ASC ставь DESC.
 Получится такой вид, как на картинке: 
 http://nimb.ws/duswvQ
 Это поможет тебе убедиться, что все работает
 3) Из второй строки кода, который я привел, удали ненужные теги. Например если, не нужно отображать ссылки на первую и последнюю страницу — удаляй [[+sn.first]] и [[+sn.last]]
 Для оставшихся тегов пропиши шаблоны в вызов плагина. То есть в первой строке перед закрывающимися скобками ставишь пробел и добавляешь параметры:
 

&rowTpl=`siblings.RowTpl` &selfTpl=`siblings.SelfTpl` &prevTpl=`siblings.PrevTpl` &nextTpl=`siblings.nextTpl` &firstTpl=`siblings.firstTpl` &lastTpl=`siblings.lastTpl`

4) Cоздай чанки с соответствующими именами(siblings.RowTpl, siblings.PrevTpl, и т.д.). Что туда писать можно подсмотреть в тех чанках, что идут по умолчанию (они лежат в папке /core/components/siblingnav/elements/chunks).
 Например в siblings.nextTpl:
 

<li>
	[[+_isactive:is=`1`:then=`
	<a class="btn next" href="[[~[[+id]]]]">Следущая »</a>  
	`:else=`
	''
	`]]	
</li>

Если хочется использовать названия статей вместо «Следущая» или «Предыдущая», то используй плейсхолдер [[+pagetitle]]
 5) С помощью CSS приведи ссылки в божеский вид(убирай буллиты, если использовал тег , делай кнопками, используя классы, располагай в одну строчку и т.д.)

Воспользуйся плагином siblingNav:
 1) Установи его
 2) В шаблоне статьи, там где нужно разместить ссылки на предыдущую и следующую статьи помести код: [[!siblingNav? &showHidden=`1` &limit=`1` &sortBy=`{"publishedon":"ASC"}`]]
[[+sn.first]][[+sn.prev]][[+sn.prevlinks]][[+sn.self]][[+sn.nextlinks]][[+sn.next]][[+sn.last]] Если сортировка неправильная, то вместо ASC ставь DESC.
 Получится такой вид, как на картинке: 
 http://nimb.ws/duswvQ
 Это поможет тебе убедиться, что все работает
 3) Из второй строки кода, который я привел, удали ненужные теги. Например если, не нужно отображать ссылки на первую и последнюю страницу — удаляй [[+sn.first]] и [[+sn.last]]
 Для оставшихся тегов пропиши шаблоны в вызов плагина. То есть в первой строке перед закрывающимися скобками ставишь пробел и добавляешь параметры: &rowTpl=`siblings.RowTpl` &selfTpl=`siblings.SelfTpl` &prevTpl=`siblings.PrevTpl` &nextTpl=`siblings.nextTpl` &firstTpl=`siblings.firstTpl` &lastTpl=`siblings.lastTpl` 4) Cоздай чанки с соответствующими именами(siblings.RowTpl, siblings.PrevTpl, и т.д.). Что туда писать можно подсмотреть в тех чанках, что идут по умолчанию (они лежат в папке /core/components/siblingnav/elements/chunks).
 Например в siblings.nextTpl: <li>
	[[+_isactive:is=`1`:then=`
	<a class="btn next" href="[[~[[+id]]]]">Следущая »</a>  
	`:else=`
	''
	`]]	
</li> Если хочется использовать названия статей вместо «Следущая» или «Предыдущая», то используй плейсхолдер [[+pagetitle]]
 5) С помощью CSS приведи ссылки в божеский вид(убирай буллиты, если использовал тег , делай кнопками, используя классы, располагай в одну строчку и т.д.)

Воспользуйся плагином siblingNav:
 1) Установи его

Забыл еще параметр parents. Если я правильно понял, то ты хочешь, чтобы новости и статьи были одной коллекцией? Тогда указывай в параметрах parents=`10,12`, где 10 b 12 это id контейнеров «Новости» и «Статьи»

Забыл еще параметр parents. Если я правильно понял

<base href="[[!++site_url]]" />

Андрей, спасибо огромное за развернутый ответ! Да, воспользовался этим замечательным сниппетом! Немного пришлось помучаться с направлением сортировки — по замыслу, две предыдущие новости должны выводиться так: более новая выше, а вторая, которая ниже, более древняя! Подумал и разобрался… сейчас все в ажуре!) 
 Ещё раз — благодарю…

Андрей, спасибо огромное за развернутый ответ! Да,

Спасибо. Ну, там всего два варианта, зачем мучиться? :) ASC и DESC.

Спасибо. Ну, там всего два варианта, зачем мучитьс

Вот сам вызов сниппета: 
 

<ul>
[[!siblingNav? 
   &showHidden=`1`
   &prevTpl=`snprevtpl`
   &limit=`2`
   &nextTpl=`snnexttpl`
   &selfTpl=`snselftpl`
]]
[[+sn.next]][[+sn.self]][[+sn.prevlinks]]
</ul>

По задумке, он должен выводить маркированный список из 4 пунктов. Сверху вниз: ссылка на следующую новость, название текущей статьи, ссылка на предыдущую новость, ссылка на пред-предыдущую!))) Все получилось, но — две нижние ссылки были поменяны местами — сверху была более старая ссылка, а ниже — более новая… по задумке нужно было наоборот!
 При попытке добавить параметр 

, все строки целиком менялись местами, т.е., след.новость шла нижней строкой и т.д…
 Методом тыка пришел к такому вызову:
 

[[!siblingNav? 
   &showHidden=`1`
   &prevTpl=`snprevtpl`
   &limit=`2`
   &nextTpl=`snnexttpl`
   &selfTpl=`snselftpl`
   &sortBy=`{"menuindex":"DESC"}`
]]
[[+sn.prev]][[+sn.self]][[+sn.nextlinks]]

Тогда всё заработало как надо…
 

Да, и объясните, пожалуйста, в чанке есть строка 

, что это за параметр и почему там цифра 1? Я порыл в гугле, но найти не смог, к сожалению!

Вот сам вызов сниппета: <ul>
[[!siblingNav? 
   &showHidden=`1`
   &prevTpl=`snprevtpl`
   &limit=`2`
   &nextTpl=`snnexttpl`
   &selfTpl=`snselftpl`
]]
[[+sn.next]][[+sn.self]][[+sn.prevlinks]]
</ul> По задумке, он должен выводить маркированный список из 4 пунктов. Сверху вниз: ссылка на следующую новость, название текущей статьи, ссылка на предыдущую новость, ссылка на пред-предыдущую!))) Все получилось, но — две нижние ссылки были поменяны местами — сверху была более старая ссылка, а ниже — более новая… по задумке нужно было наоборот!
 При попытке добавить параметр &sortBy=`{"menuindex":"DESC"}` , все строки целиком менялись местами, т.е., след.новость шла нижней строкой и т.д…
 Методом тыка пришел к такому вызову: [[!siblingNav? 
   &showHidden=`1`
   &prevTpl=`snprevtpl`
   &limit=`2`
   &nextTpl=`snnexttpl`
   &selfTpl=`snselftpl`
   &sortBy=`{"menuindex":"DESC"}`
]]
[[+sn.prev]][[+sn.self]][[+sn.nextlinks]] Тогда всё заработало как надо… Да, и объясните, пожалуйста, в чанке есть строка [[+_isactive:is=`1`:then=` , что это за параметр и почему там цифра 1? Я порыл в гугле, но найти не смог, к сожалению!

Вот сам вызов сниппета: <ul>
[[!siblingNav? 
   &s

1) Путаница с порядком сортировки возникает из-за того, что у тебя направление статей от старой к новым — снизу вверх, а автор сниппета держал в голове при написании, наверное, слева направо.
 Управлять этим можно либо поменяв местами плейсхолдеры next и prev, либо как ты сделал — меняя порядок сортировки(возрастание/убывание).
 2) 1 и 0 — это true и false.
 Если есть что отображать в шаблоне, то сниппет кладет в _isactive единицу, если нет — то ноль. Это позволяет делать активные ссылки, если есть контент и неактивные, если нет.
 [[+sn.first]] — если текущая статья близко «старому» концу списка(третья при твоем limit=2), то от сниппета в шаблон firsttpl(если б ты его создал и использовал) придет _isactive=0 и на месте плейсхолдера [[+sn.first]] на странице отобразится неактивная ссылка(тот код, что в ветке else). 
 [[+sn.prev]] — если текущая статья близко к «старому» концу списка(предпоследняя или последняя при твоем limit=2), то в шаблон snprevtpl придет значение _isactive=0 и на месте плейсхолдера [[+sn.prev]] отобразится код ветки else
 

[[+sn.next]] и [[+sn.last]] — аналогично. Если текущая статья близко к «новому» краю списка, то в шаблоны, отвечающие за вывод HTML кода в эти плейсхолдеры приходит _isactive=0 и при рендеринге шаблонов snnexttpl и snlast(если б он у тебя был) на страницу попадает код из веток else.
 

[[+sn.prevlinks]] и [[+sn.nextlinks]] — в эти плейсхолдеры подставляется код, отрендеренный с помощью чанка core/components/siblingnav/elements/chunks/snrow.chunk.html. Ты и его можешь переопределить своим чанком, если воспользуешься параметром &rowTpl.
 [[+sn.self]] — за вывод в него отвечает чанк core/components/siblingnav/elements/chunks/snself.chunk.html, который можно переопределить с помощью параметра selfTpl. Но с этим ты разобрался.

1) Путаница с порядком сортировки возникает из-за того, что у тебя направление статей от старой к новым — снизу вверх, а автор сниппета держал в голове при написании, наверное, слева направо.
 Управлять этим можно либо поменяв местами плейсхолдеры next и prev, либо как ты сделал — меняя порядок сортировки(возрастание/убывание).
 2) 1 и 0 — это true и false.
 Если есть что отображать в шаблоне, то сниппет кладет в _isactive единицу, если нет — то ноль. Это позволяет делать активные ссылки, если есть контент и неактивные, если нет.
 [[+sn.first]] — если текущая статья близко «старому» концу списка(третья при твоем limit=2), то от сниппета в шаблон firsttpl(если б ты его создал и использовал) придет _isactive=0 и на месте плейсхолдера [[+sn.first]] на странице отобразится неактивная ссылка(тот код, что в ветке else). 
 [[+sn.prev]] — если текущая статья близко к «старому» концу списка(предпоследняя или последняя при твоем limit=2), то в шаблон snprevtpl придет значение _isactive=0 и на месте плейсхолдера [[+sn.prev]] отобразится код ветки else [[+sn.next]] и [[+sn.last]] — аналогично. Если текущая статья близко к «новому» краю списка, то в шаблоны, отвечающие за вывод HTML кода в эти плейсхолдеры приходит _isactive=0 и при рендеринге шаблонов snnexttpl и snlast(если б он у тебя был) на страницу попадает код из веток else. [[+sn.prevlinks]] и [[+sn.nextlinks]] — в эти плейсхолдеры подставляется код, отрендеренный с помощью чанка core/components/siblingnav/elements/chunks/snrow.chunk.html. Ты и его можешь переопределить своим чанком, если воспользуешься параметром &rowTpl.
 [[+sn.self]] — за вывод в него отвечает чанк core/components/siblingnav/elements/chunks/snself.chunk.html, который можно переопределить с помощью параметра selfTpl. Но с этим ты разобрался.

1) Путаница с порядком сортировки возникает из-за 

А я ж в первой инструкции писал про сортировку — если порядок неправильный, просто DESC вместо ASC.

А я ж в первой инструкции писал про сортировку — е

Да, я помню! Как и писал уже — после перенаправления сортировки пришлось менять местами плейсхолдеры вывода предыдущих и последующих новостей…

Да, я помню! Как и писал уже — после перенаправлен

Это потому что у тебя сортировка по menuindex, а я писал о publishedon. menuindex — это позиция ресурса в контейнере в дереве ресурсов слева. Articles скрывает элементы в дереве, отображая их вместо этого в таблице. Статьи у тебя идут в том же порядке, что и в этой таблице — это хорошо. Но, если ты добавишь статью с датой публикации, например прошлым годом, то она будет все равно отображаться первой, с articles ты лишаешься возможности перетаскивать ресурсы и управлять значением menuindex. Используя publishedon, ты можешь поменять дату публикации, открыв и отредактировав статью и передвинуть ее на сайте в прошлое, c menuindex — нет.

Это потому что у тебя сортировка по menuindex, а я

В десятый раз перечитал «космос-обсуждение». Может в коде процессора поменять настройки (уровень)? Убейте не могу найти файл с процессором меню. Где он лежит в папке PROCESSOR все пересмотрел… или его там и нет и добавлять нужно? Help…

В десятый раз перечитал «космос-обсуждение». Может

Добрый день.
 Многоуровневое, имеется ввиду более чем 2 уровня? Или более чем один? Просто бутстрап сам по себе не особо любит менюшки более чем двух уровней.

Добрый день.
 Многоуровневое, имеется ввиду более 

Из коробки ShopModxBox не заточен под несколько уровней меню. В целом это решается (когда-то была задача и выполняли ее), но на практике это костылем считается. В оффдоке бутстрапа я даже не нашел примеров мультикатегорий. getbootstrap.com/components/#navbar Сторонние решения не стал прикручивать, ибо ядро. Если кто подскажет православную верстку многоуровнего меню на бутстрапе, я доработаю менюху в сборке.

Из коробки ShopModxBox не заточен под несколько ур

Спасибо! Жаль… нужно собственно 3 уровня, чтобы в одной категории было несколько категорий, а уже в них товар. Например
 Главная
 Телевизоры
 SONY
 42SC500V
 50PV600E
 …
 PANASONIC
 32PVR
 42PAN
 … 
 Приемники 
 TOSHIBA
 и т.д.
 А вот здесь с Александром Марковым вы Николай обсуждали эту тему… и вроде у Александра что-то получилось? Он нигде решение свое не выкладывал?
 И еще вопрос, если богоугодного решения пока нет, то чтобы прикрутить временно стороннее решение (тот же pdomenu)правильно я понимаю нужно в базовом tpl вот эту строчку {include «inc/menu/mainmenu/menu.tpl»} закоментить, а новую от pdomenu вставлять и т.д.?
 

Спасибо! Жаль… нужно собственно 3 уровня, чтобы в 

Надежда, никто на эти вопросы не ответит. Это вопросы индивидуального программирования.

Надежда, никто на эти вопросы не ответит. Это вопр

День добрый.
 А как вам такое решение -http://geedmo.github.io/yamm3/?
 По-моему, очень даже православное и аккуратное. А главное — рабочее, уже в нескольких проектах использовал.

День добрый.
 А как вам такое решение -http://geed

Это к вопросу многоуровневой меню бутстрапа. Ну а при крутить pdoresources или getresources, думаю, проблем нет. Но если надо — скину пример

Это к вопросу многоуровневой меню бутстрапа. Ну а 

А вот здесь с Александром Марковым вы Николай обсуждали эту тему… и вроде у Александра что-то получилось? Он нигде решение свое не выкладывал?

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

А вот здесь с Александром Марковым вы Николай обсуждали эту тему… и вроде у Александра что-то получилось? Он нигде решение свое не выкладывал? Это там уже у Саши надо спрашивать. Он не выкладывал, но может что наработал да поделится.

А вот здесь с Александром Марковым вы Николай обсу

Будем посмотреть при оказии.

> Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/
 > Но этот вариант не всегда реализуем. Как, например, в моём случае.
 > В целом по проекту: сочувствую… 

Некоторые TV всё-таки пришлось разместить в таблице ресурсов. А именно — числовые поля. И только те числовые, по которым выполняется фильтрация (на больше/меньше) и сортировка. Т.к.:
 а) во всех остальных случаях фильтрация и сортировка вполне себе нормально отработает и по строковым TV (с использованием индекса)
 б) с числовыми TV-полями при выполнении сортировки и фильтрации (на больше/меньше) пришлось бы выполнять преобразование на лету и как следствие, полный перебор БЕЗ использования индексов
 в) в нашем распоряжении имеется всего 44 индекса (64 минус 20 стандартных), соответственно, все TV в таблицу ресурсов не закинешь. Закидываю только необходимый минимум (числовая сортировка/фильтрация)
 

Но логику, описанную в статье, немного изменил (под свой проект):
 1.Числовые TV не перемещаю в таблицу ресурсов, а копирую. Памяти уходит больше, но упрощается логика + повышается безопасность (если что «поломается», всегда можно восстановить значения из стандартных TV)
 2.Схему (modx->map) дополняю новыми полями также на лету, но не вручную, а программно — на основе структуры таблицы в БД (использую генератор xPDOGenerator)
 3.Описание индексов новых полей в (modx->map) не помещаю, т.к. индексы xpdo нужны только для генерации таблиц в БД (или нужны для чего-то ещё ?)
 

 — Таким образом, получилась гибридная система TV-параметров:
 1.Для выборки TV используется поле (properties)
 2.Для фильтрации и сортировки по числовым полям используются собственные поля в таблице ресурсов (числовое сравнение)
 3.Для фильтрации и сортировки по строковым полям — TV-поля подключаются через join (строковое сравнение)
 

При такой организации TV:
 а) и выборку большого числа TV можно будет сделать довольно быстро (без кучи JOIN'ов)
 б) можно быстро (с использованием индекса) выполнять фильтрацию и сортировку как по строковым полям (строковое сравнение), так и по числовым полям (числовое сравнение), исключая преобразование типов на лету
 в) можно не заморачиваться тем, что в таблице ресурсов остаётся всего 44 индекса для собственных полей (для числовых полей, по которым выполняется фильтрация/сортировка, их всем хватит)

> Если речь о десятках и более тысяч документов, то это поможет: habrahabr.ru/post/253737/
 > Но этот вариант не всегда реализуем. Как, например, в моём случае.
 > В целом по проекту: сочувствую… Некоторые TV всё-таки пришлось разместить в таблице ресурсов. А именно — числовые поля. И только те числовые, по которым выполняется фильтрация (на больше/меньше) и сортировка. Т.к.:
 а) во всех остальных случаях фильтрация и сортировка вполне себе нормально отработает и по строковым TV (с использованием индекса)
 б) с числовыми TV-полями при выполнении сортировки и фильтрации (на больше/меньше) пришлось бы выполнять преобразование на лету и как следствие, полный перебор БЕЗ использования индексов
 в) в нашем распоряжении имеется всего 44 индекса (64 минус 20 стандартных), соответственно, все TV в таблицу ресурсов не закинешь. Закидываю только необходимый минимум (числовая сортировка/фильтрация) Но логику, описанную в статье, немного изменил (под свой проект):
 1.Числовые TV не перемещаю в таблицу ресурсов, а копирую. Памяти уходит больше, но упрощается логика + повышается безопасность (если что «поломается», всегда можно восстановить значения из стандартных TV)
 2.Схему (modx->map) дополняю новыми полями также на лету, но не вручную, а программно — на основе структуры таблицы в БД (использую генератор xPDOGenerator)
 3.Описание индексов новых полей в (modx->map) не помещаю, т.к. индексы xpdo нужны только для генерации таблиц в БД (или нужны для чего-то ещё ?) — Таким образом, получилась гибридная система TV-параметров:
 1.Для выборки TV используется поле (properties)
 2.Для фильтрации и сортировки по числовым полям используются собственные поля в таблице ресурсов (числовое сравнение)
 3.Для фильтрации и сортировки по строковым полям — TV-поля подключаются через join (строковое сравнение) При такой организации TV:
 а) и выборку большого числа TV можно будет сделать довольно быстро (без кучи JOIN'ов)
 б) можно быстро (с использованием индекса) выполнять фильтрацию и сортировку как по строковым полям (строковое сравнение), так и по числовым полям (числовое сравнение), исключая преобразование типов на лету
 в) можно не заморачиваться тем, что в таблице ресурсов остаётся всего 44 индекса для собственных полей (для числовых полей, по которым выполняется фильтрация/сортировка, их всем хватит)

> Если речь о десятках и более тысяч документов, т

И здесь как всегда проблема с индексами возникает. Если, например, в таблице ресурсов мы создаём числовое поле (sCount) и индекс idx_sCount по этому полю, то при выполнении запросов, в которых выполняется фильтрация и по полю published (или deleted), и по числовому полю (sCount) (не важно, в какой последовательности), то MySQL будет использовать индекс published, а не idx_sCount (как этого следовало бы ожидать) — это приведёт к почти полному перебору всех ресурсов (если положить, что почти все ресурсы являются опубликованными). Аналогично и с (deleted).
 При этом если в таблице будет индекс по обоим этим полям, то MySQL выберет именно этот индекс (как и должно быть).
 

Решить проблему можно 3 способами:
 1.Для каждого запроса указывать необходимый индекс. Сложности этого способа очевидны:
  — сложна реализация (xpdo индексы не поддерживает)
  — необходимый индекс придётся указывать для каждого запроса и при изменении имени или структуры индекса придётся все эти запросы пересматривать
 

2.Для собственных полей указывать составные индексы, начинающиеся со стандартных полей и заканчивающиеся собственными полями (например: idx_published_sCount, idx_classKey_deleted_published_sCount). Но в этом случае часть существующих запросов может начать тормозить, поскольку при наличии 2, 3 и более индексов, начинающихся со стандартных полей, MySQL на некоторых запросах (предположительно, с конструкцией IN + может зависеть и от версии MySql) начинает очень долго выбирать оптимальный индекс: modxclub.ru/topics/vyiborka-iz-%28modtemplatevarresource%29-sushhestvennoe-uskorenie-pri-yavnom-ukazanii-indeksa-1759.html#comment-7177
 

3.Для собственных полей указывать составные индексы, начинающиеся с собственных полей и заканчивающиеся стандартными (например: idx_sCount_published, idx_sCount_classKey_deleted_published). В этом случае эти индексы MySQL будет рассматривать в качестве возможных только в тех запросах, в которых используются наши собственные поля. И при этом в тех запросах, в которых присутствуют условия и по стандартным полям, и по нашим полям, будет использовать именно эти (наши) составные индексы, а не простые стандартные.

И здесь как всегда проблема с индексами возникает. Если, например, в таблице ресурсов мы создаём числовое поле (sCount) и индекс idx_sCount по этому полю, то при выполнении запросов, в которых выполняется фильтрация и по полю published (или deleted), и по числовому полю (sCount) (не важно, в какой последовательности), то MySQL будет использовать индекс published, а не idx_sCount (как этого следовало бы ожидать) — это приведёт к почти полному перебору всех ресурсов (если положить, что почти все ресурсы являются опубликованными). Аналогично и с (deleted).
 При этом если в таблице будет индекс по обоим этим полям, то MySQL выберет именно этот индекс (как и должно быть). Решить проблему можно 3 способами:
 1.Для каждого запроса указывать необходимый индекс. Сложности этого способа очевидны:
  — сложна реализация (xpdo индексы не поддерживает)
  — необходимый индекс придётся указывать для каждого запроса и при изменении имени или структуры индекса придётся все эти запросы пересматривать 2.Для собственных полей указывать составные индексы, начинающиеся со стандартных полей и заканчивающиеся собственными полями (например: idx_published_sCount, idx_classKey_deleted_published_sCount). Но в этом случае часть существующих запросов может начать тормозить, поскольку при наличии 2, 3 и более индексов, начинающихся со стандартных полей, MySQL на некоторых запросах (предположительно, с конструкцией IN + может зависеть и от версии MySql) начинает очень долго выбирать оптимальный индекс: modxclub.ru/topics/vyiborka-iz-%28modtemplatevarresource%29-sushhestvennoe-uskorenie-pri-yavnom-ukazanii-indeksa-1759.html#comment-7177 3.Для собственных полей указывать составные индексы, начинающиеся с собственных полей и заканчивающиеся стандартными (например: idx_sCount_published, idx_sCount_classKey_deleted_published). В этом случае эти индексы MySQL будет рассматривать в качестве возможных только в тех запросах, в которых используются наши собственные поля. И при этом в тех запросах, в которых присутствуют условия и по стандартным полям, и по нашим полям, будет использовать именно эти (наши) составные индексы, а не простые стандартные.

И здесь как всегда проблема с индексами возникает.

РЕШЕН вопрос оказывается. В одном из постов уважаемый ВДВ описал это сверх простое решение, но оно осталось не замеченным. А решение на мой взгляд гениальное. Я всего четыре последние строки добавил к его решению (в CSS) чтобы выезжающие подпункты сдвигались в сторону и красивее было. В результате 3-х уровневое меню отлично работает. Итак, нужно сделать следующее:
 1. Настройка-наборы параметров-для MainMenu ставим уровень 3. Здесь же можно выключить те п.меню из которых выезжать ничего не должно {«parent:not in»:[5,110,196]}
 2. В шаблон menu.tpl добавляем шаблон для подпунктов и убираем data атрибут для открытие по клику.
 

{block menu_params}
       {$params = [
        "parentRowTpl" => '@CODE <li[[+wf.id]] class="dropdown">
            <a href="[[+wf.link]]" title="[[+wf.title]]" [[+wf.attributes]] class="dropdown-toggle">[[+wf.linktext]] <span class="caret"></span></a>
            [[+wf.wrapper]]
        </li>',
        "rowTpl" =>'@CODE <li class="dropdown">
<a href="[[+wf.link]]" title="[[+wf.title]]" [[+wf.attributes]]>[[+wf.linktext]]</a>
</li>',
        "outerClass" => 'nav navbar-nav',
        "innerClass" => 'dropdown-menu'
    ]}
{/block}

3. В файлик assets/components/modxsite/templates/shopmodx/bundle/styles/styles.css чтобы меню раскрывалось при наведении мыши и чтобы оно было сдвинуто относительно 2-го уровня в конец дописываем
 

.dropdown:hover > .dropdown-menu {    
    display: block;
}
.dropdown-menu .dropdown .dropdown-menu {   
    left: 200px;
    top:-0px;
}


И ВСЁ!!! Собственно дальше можно менять эти left, top еще что-то добавлять для красоты.
 

РЕШЕН вопрос оказывается. В одном из постов уважаемый ВДВ описал это сверх простое решение, но оно осталось не замеченным. А решение на мой взгляд гениальное. Я всего четыре последние строки добавил к его решению (в CSS) чтобы выезжающие подпункты сдвигались в сторону и красивее было. В результате 3-х уровневое меню отлично работает. Итак, нужно сделать следующее:
 1. Настройка-наборы параметров-для MainMenu ставим уровень 3. Здесь же можно выключить те п.меню из которых выезжать ничего не должно {«parent:not in»:[5,110,196]}
 2. В шаблон menu.tpl добавляем шаблон для подпунктов и убираем data атрибут для открытие по клику. {block menu_params}
       {$params = [
        "parentRowTpl" => '@CODE <li[[+wf.id]] class="dropdown">
            <a href="[[+wf.link]]" title="[[+wf.title]]" [[+wf.attributes]] class="dropdown-toggle">[[+wf.linktext]] <span class="caret"></span></a>
            [[+wf.wrapper]]
        </li>',
        "rowTpl" =>'@CODE <li class="dropdown">
<a href="[[+wf.link]]" title="[[+wf.title]]" [[+wf.attributes]]>[[+wf.linktext]]</a>
</li>',
        "outerClass" => 'nav navbar-nav',
        "innerClass" => 'dropdown-menu'
    ]}
{/block} 3. В файлик assets/components/modxsite/templates/shopmodx/bundle/styles/styles.css чтобы меню раскрывалось при наведении мыши и чтобы оно было сдвинуто относительно 2-го уровня в конец дописываем .dropdown:hover > .dropdown-menu {    
    display: block;
}
.dropdown-menu .dropdown .dropdown-menu {   
    left: 200px;
    top:-0px;
} И ВСЁ!!! Собственно дальше можно менять эти left, top еще что-то добавлять для красоты.