Никаких фейковых урлов и тд не планирую. Наоборот — цель оставить «обычное» древо урлов, но не засоряя при этом корень. 
 (требуется выводить марки машин по адресу site.ru/марка, но не будешь же для этого в корне мешать сотни документов для них и системные страницы).
 
Т.е. контексты только для разделения ресурсов (и прав манагеров).
 
allow_forward_across_contexts — не помог. По-прежнему при заходе на документы дополнительного контекста, отображается дефолтный шаблон (хотя в параметрах ресурса указан другой).

Ага. И ни циклов, нифига. В Смарти это запросто:
 
<table>
    <tbody>
        <tr>
            <th>...
            ...</th>
        </tr>
        {foreach $rows as $row}
            <tr>..........</tr>
        {/foreach}
    </tbody>
</table>

Если речь о migx, то rtfm.modx.com/extras/revo/migx/migx.tutorials/migx.use-resource-specific-media-source-and-multifile-uploader
 А вообще цепляйте любую галерею, которая привязывает картинки к документам. Вроде щас что-то новое уже появилось. Но конечно выводить их нужно будет наверн через сниппет. Хотя мало ли какие варианты возможны.

а можно реализовать выбор сразу нескольких фото? (типа select multiple)?

Который раз: зачем вам эти сложности? Несколько контекстов, фейковые УРЛы и т.д. и т.п. С этим столько ненужных сложностей и неудобств возникает, плюс ресурсные затраты. Зачем? (вечный вопрос на эту вечную ненужную проблему).
 
Но если очень надо, смотрите как в шопкипере это реализовано. Там плагин для этого есть.
 
А если УРЛы не будут фейковыми, то просто переключаете настройку allow_forward_across_contexts в true, должно помочь.

Как это происходит у нас? Два варианта.
 Вариант 1.
 1. В ТВ версии фиксируем все изменения в гите git add .; git commit -am «comment»;
 2. На РВ накатываем изменения git pull;
 3. Очищаем кеш.
 
Вариант 2.
 Плагин newDesign (должен вызываться раньше, чем плагин modxSmarty).
 Делается копия скина Смарти-шаблона сайта с новым названием. Когда плагин активирован, включается другой скин сайта и кеш-префикс, и разработчик работает на боевом сайте, но никакие изменения в шаблонизации сайта не могут быть увидены простыми посетителями. Какой-нибудь новый процессор в системе они тоже никак не увидят. Таким образом на сайте ведется реальная работа с реальными данными, но сайт для неадминов работает в обычном режиме.
 Когда работа выполнена, проверена и готова к запуску, просто в системной настройке меняется название используемого шаблона на новый и все.

Здравствуйте.
 
Возникла следующая проблема — при создании разных контектов для визуального и правового разделения ресурсов, имеющих один корень (для примера: основной контекст «web» и дополнительный «company», все документы которых доступны по адресу site.ru/название_страницы).
 Все страницы не основного контекста определяются как «несуществующие» и по ссылке отображают шаблон главной страницы.
 
Подскажите, пожалуйста, как можно реализовать контексты для подобной задачи или задачи для контекстов, находящихся в рамках одного домена, но отличающихся родительским «контейнером» (пример: site.ru/название_страницы и site.ru/folder/название_страницы).
 
Заранее спасибо.

Как и обещалось отписываю о ходе обновы
 
Суть задачи: Есть 2 сайта рабочая версия (РВ) и тестовая версия (ТВ). На ТВ ведутся разработки приложения, тестируются, одобряются заказчиком и уж потом ставятся на РВ. Все чанки и сниппеты да и вообще максимально все что можно хранится в фалах и подключено как статика. До сегодня были обновления в рамках исправления багов или фиксов интерфейса, оптимизация и т.д. и решалось это все копированием файлов из ТВ на РВ.
 Сегодня созрела глобальная обнова по расширению функционала и стала задача обновить систему в «ленивом» режиме без ручной регистрации всех новых сниппетов. Системные файлы MODx не менялись и вообще к самому движку это не имеет отношения. Обновление нужно было провести так что бы не затронуть данные РВ поскольку на ней реально работают люди.
 
Процесс:
 1. Забекапился.
 2. Скопировал все (касающиеся нашего проекта) папки с файлами с ТВ на РВ.
 3. Взял базу с ТВ и выгрузил таблицы БД
 *_site_htmlsnippets — здесь записаны все чанки
 *_site_snippets — здесь записаны все сниппеты
 *_site_plugins — здесь плагины
 Ресурсы не брались поскольку в РВ версии существует лента новостей которая создает Ресурс для каждой новости. Поэтому ID ресурсов совпадать точно не будут
 Отсюда первая проблема, в коде использовались 2 ссылки на ресурс вида [[~1]] поправил руками
 4. Залил таблицы на РВ
 5. Добавил новые таблицы в БД
 7. Очистил кеш через фтп.
 8. Зашел в админку нашел проблему.
 Не все чанки сниппеты были видны. Причина в том что не перенес категории.
 Возврат на ТВ и вытащил еще 2 таблицы
 *_categories
 *_categories_closure
 
Все заработало и все показывает. Обнова прошла достаточно быстро и с экономила время. Ну дольше бы пришлось регать все руками.
 
Вывод лично для себя. При обновах проектов где нужно закинуть много чанков и сниппетов, вполне пригодная для работы схема.

ну к примере генератор таблиц имеет
 1. сам сниппет
 2. общий чанк table.tpl
 
<table .... >
[[+table.thead]]
<tbody>
[[+table.rows]]
</tbody>

3. чанк tablethaed.tpl
 4. чанк tablerow.tpl
 
3 и 4 чанки для таблиц разные ну и табличек пока что штук до сотни но толи еще будет…