man

Мало кто знает про такой класс как modContextResource. А ведь он есть, и что самое интересное, работает. Это позволяет документ определить сразу в нескольких контекстах (несколько записей Документ-Контекст). Тогда этот документ будет виден и в других контекстах, прям как родной (точнее в $modx->context->aliasMap). Это необходимо, чтобы корректно ссылки формировались и документ при заходе в контекст находился.
То есть не надо плодить несколько документов. Надо просто документы, которые должны быть видны в нескольких контекстах, определять в нужные. И тогда все будет по фэншую.

Куда уж нам смердам до тебя. Величие твое расходится вокруг волнами и оседает на нас благодатью.

P.S. И не думай, что я «идею» подсмотрел у тебя. Поверь на слово, это не так. Я далеко не все твои топики читаю.

И мысли такой не было. Да и Боб Рей со своим refreshCache вряд ли так думает.
Да и без разницы мне чего ты и за сколько делаешь. У меня нет ни желания ни права указывать. Мой комментарий выше не для тебя был (ты вроде обещал их игнорировать). Мы все делаем компоненты для пользователей. Им и выбирать. Смысла в перепалке не вижу.

Как-то так
Расширяем tpl.msEmail блоком в нужном месте

{block 'info'}

{/block}

Выводим в чанке tpl.msEmail.new.manager то что нужно

{block 'info'}
<h2>Контактные данные</h2>
<p>Имя:     <b>[[+address.receiver]]</b></p>
<p>Телефон: <b>[[+address.phone]]</b></p>
<p>e-mail:  <b>[[+user.email]]</b></p>
<p>Комментарий: <b>[[+address.comment]]</b></p>
</div>


<h2>Адрес доставки</h2>
<p>Индекс:     <b>[[+address.index]]</b></p>
<p>Регион: <b>[[+address.region]]</b></p>
<p>Город:  <b>[[+address.city]]</b></p>
<p>Улица: <b>[[+address.street]]</b></p>
<p>Дом: <b>[[+address.building]]</b></p>
<p>Квартира: <b>[[+address.room]]</b></p>

<p>Оплата: <b>[[+payment.name]]</b></p>
<p><b>[[+order.comment]]</b></p>
<p><b>[[+delivery.price]]</b></p>
{/block}

Все плейсхолдеры можно увидеть с пустым tpl
docs.modx.pro/components/minishop2/snippets/msgetorder

В FormIt есть хук FormItSaveForm. Он пишет отправленные данные в базу. Также есть компонент, который их оттуда выводит (ставится автоматом с FormIt) с функцией выгрузки в CSV.

Никакой разницы. Все нормальные дополнения используют
MODX_CORE_PATH
MODX_ASSETS_URL
MODX_ASSETS_PATH
MODX_MANAGER_URL и т.д.

Хочется составлять и обновлять список — на здоровье. Каждый тратит своё время как хочет.

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

Проблемы могут быть только с собственными сниппетами, которые хардкодят префикс вот так

$res = $modx->query("SELECT * FROM modx_users WHERE...");

вместо

$res = $modx->query("SELECT * FROM {$modx->config['table_prefix']}_users WHERE...");

или даже

$res = $modx->query("SELECT * FROM {$modx->getTableName('modUser')} WHERE...");

это если есть xPDO модель для этой таблицы

Здравствуйте. Опыт есть. Могу предложить полную интеграцию по протоколу SOAP. Все изменения в 1с и заказы с сайта будут приходить мгновенно. Цена и сроки только после более подробного общения.

Добрый день.
Да согласен с комментариями выше, что подойдет этот компонент (modimporter) либо MSklad.
Я раньше по старинке делал выгрузку в формате XML заказов для того, чтобы 1С по распианию забирал эту выгрузку. Но стороны 1С нужен был 1С специалист, которые делал обработку этого. Точно также и с выгрузкой остатков, цен и прочего со стороны 1С… если что обращайтесь.
Программист ModX. Написание собственных решений, сниппетов, плагинов и пр. Опыт большой. Оплата поэтапно, по факту.
Skype: x-stylus,
x-stylus собачих mail точека ru

По-моему, надо указать

&processTVs=`1`

Ведь pdoPage не знает, чего вы хотите — получить чистое значение из базы или обработанное MODX-ом значение ТВ-шки

Fenom не нужен этот модификатор, потому что он сам по себе понимает %.

{$idx % 3 ? 'mr' : ''}