Вот для интереса сделал на тестовом сайте:

s26240.h8.modhost.pro/manager/
s26240
lC6YU7NlRxFt

MODX 2.8.2, php 7.4, всё работает. Может в ТВшке что то не так заполнено?

нет, так тоже не работает. Точнее работает

[[+tagis]]

, но выводит конечно просто цифры
А вот с

[[+tagis:tvLabel]]

ничего.

Найду в чем дело, отпишусь тут )

Задай пустой tvPrefix и будет работать:

[[pdoResources?
        &tpl=`itemarh`
        &limit=`100`
        &parents=`7`
        &offset=`1`
        &includeTVs=`tagis`
        &tvPrefix=``
]]

В чанке:

[[+publishedon:date=`%d.%m.%Y`]] / [[+tagis:tvLabel]]

внешняя программа про order_id ничего не знает
а если полезет в папочку с десятком файлов=новых заказов — увидит их там распарсит себе и удалит из папочки.

Можно просто создать обращение к какому-то файлу. /assets/custom/ms2xml.php?order=2&hash=d3s3
И уже там обрабатывать запрос:

$msOrder = $modx->getObject('msOrder', $order_id);
$msProducts = $msOrder->getMany('Products');

Все нормально работает. Возможно у вас просто кэш.

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

Неа, не работает, тоже вот столкнулся.
Если интересно, вот вызов

[[pdoResources?
        &tpl=`itemarh`
        &limit=`100`
        &parents=`7`
        &offset=`1`
        &includeTVs=`tagis`
]]

и в чанке

[[+publishedon:date=`%d.%m.%Y`]] / [[+tv.tagis:tvLabel]]

Просто выводит

1||2||4

и даже не указание разделителя в параметрах вывода не реагирует

Все зависит, для чего это нужно. Может и не стоит сразу генерировать файл, если он никуда отправляться не будет.

Жесть и боль ) Вот прям сочувствую.
Я так думаю это касается ~ 90% работающих в сфере сайтов.
Обычно при таком подходе народ моментально выгорает; да и учиться нет особого смысла — только под конкретную ситуацию.

Есть modx->parseChunk(), возвращает строку, её можно записать в файл стандартными средствами php. А в чанке соответственно можно разместить шаблон xml. И да, это можно сделать в событии например msOnCreateOrder.

говорить о том, что я вам сейчас сайт перепишу, удалю jquery потому что она медленная (чем приведу 85 плагинов в негодность) — ну вообще не вариант.

Абсолютно согласен. В таком случае надо говорить «до свидания».
Ровно как и фирме, в которой ты работаешь. Тебе здесь пишут это уже не первый раз, стоит задуматься)

Или тебе интересно ковырять весь этот говнокод, покрытый пылью и плесенью?

ему сделали сайт 7 лет назад за 1000 рублей и платить за технические работы по нему он не собирается

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

все программные работы для заказчика бесплатны

Повторю еще раз: беги оттуда, да не оглядывайся назад.

где сотни сайтов созданных черте когда и черте на чем, тоже нуждаются в поддержке, переделке и внедрению новых фич

Говорят, что за это нужно платить. Это же нужно заказчику и его бизнесу, а не конкретно тебе. Значит заказчик должен заплатить за свою хотелку. Если его сайт старый и не подлежит адекватной поддержке, значит нужно заплатить за новый сайт. Если не хочет — до свидания.

Уважать себя нужно.

Верно, Артем.
Видите мы с вами в процессе обсуждения пришли к такой неожиданной идее — в мире разработки, даже веб разработки, существуют совершенно разные миры. Эти миры живут по абсолютно разным законам и это нормально.
Вот вы пишите

Ради 1 строки вместо 3 тянуть jQuery?

Скажите, а что та фирма (или где вы работаете) занимается только разработкой с нуля проектов? Тогда конечно можно самим выбирать какие технологии использовать.
А мой мир выглядит так — директор находит на просторах интернета любые сайты, написанные на любых cms, движках и даже языках (пока не было только на C#), обещают им с СЕОшниками золотые горы и заключают договор. Сеошники сразу начинают говорить, ну мол ясно почему у вас все так плохо, у вас тут дескрипшены неверные, а тут нужно товары не так разместить, тут нужно сделать фильтр для товаров причем такой чтобы генерил урлы и позволял задавать тайтл свой для фильтрованных страниц и прочее в том же духе. И со всем этим приходят ко мне, мол — все делай. А это готовый сайт, сделанный 7 лет назад. К примеру вордпресс какой-то, у которого установлено 134 плагина, каждый плагин подключил свою версию jquery и так далее.
Согласитесь в такой ситуации, говорить о том, что я вам сейчас сайт перепишу, удалю jquery потому что она медленная (чем приведу 85 плагинов в негодность) — ну вообще не вариант. Причем это все нужно сделать на чистом энтузиазме, потому что лично заказчику совершенно все равно сколько и какие там библиотеки и плагины, ему сделали сайт 7 лет назад за 1000 рублей и платить за технические работы по нему он не собирается (тут особая странность нашей фирмы — мы типа только предлагаем услуги по СЕО, все программные работы для заказчика бесплатны и служат лишь для выполнения пожеланий СЕО).
Я это к чему, что есть и правда совсем разные миры в разработке и жизнь в них течет совсем разная, в каком то мире jquery это устаревшее и никому не нужное, сайты строит javascript собирает webpack, а есть миры (и их не мало) где сотни сайтов созданных черте когда и черте на чем, тоже нуждаются в поддержке, переделке и внедрению новых фич )

Нигде в этих сайтах не используется vue react или не дай Бог angular.

Правильно, потому что это совсем другой мир разработки.
Тут вопрос личных предпочтений — если тебе интересны CMS и нравится работать на условном битриксе, то естественно, что тебе не нужен ни React, ни Vue, ни Angular.
Но эти сайты никогда не смогут тебе предоставить такой же красивый, динамичный и приятный интерфейс, как условный Vue, например.

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

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

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

Правильные слова.
На данный момент я обслуживаю около 50 проектов в нашей компании. Но все это обычные сайты на разных cms (bitrix, modx, joomla, drupal, wordpress, opencart и еще более редкие). Плюс создаю новые, чаще всего на modx. Нигде в этих сайтах не используется vue react или не дай Бог angular. тут нигде (и в modx тоже даже нет нормального composer и поддержки psr-17). Поскольку мне ежедневно приходится работать именно с таким г… набором, то мне нет смысла (кроме собственного любопытства) изучать технологии (докер, vue и так далее). Но я их изучаю, но не использую (вернее только для своих тестов) и соответственно они напрочь вылетают из головы. Вот такая дилема)

вам же почему то не хочется писать .json() при работае с fetch хотя это всего7 символов

Потому что это далеко не единственное неудобство в fetch, если бы только это, то хрен с ним.

на это

[...document.querySelectorAll('div')].forEach((el) => {
  el.addEventListener('click', () => alert('hello world'));
});

Ради 1 строки вместо 3 тянуть jQuery?

я просто офигеваю от обилия технологий

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

Хотел написать, что вам же почему то не хочется писать .json() при работае с fetch хотя это всего7 символов, а почему кому-то должно хотеться переписывать

$('div').click(()=>{alert('hello world')})

на это

const divs = document.querySelectorAll('div');
if (divs) {
    divs.forEach((element)=>{
        element.addEventListener('click', ()=>{alert('hello world');});
    });
}

но наверное стоит уже заканчивать. Вы правы и молодец. Я не очень прав, но честно признаюсь — я просто офигеваю от обилия технологий и не успеваю их все вместить в свою голову. Я встаю утром до работы изучаю что то новое, работаю 9 часов, потом еще пару часов обучаюсь (и скажем так на пятом десятке это совсем не тоже самое что в 20 лет). И да, наверное все мои сомнения и мысли в первую очередь исходят из невысокого уровня знаний.

XMLHttpRequest признан устаревшим и от его использования нужно отказываться.

и

На сегодняшний день не обязательно использовать XMLHttpRequest, так как существует другой, более современный метод fetch.

Совершенно разные вещи. Здесь нет ни слова про «XMLHttpRequest признан устаревшим». Это не более чем рекомендация, потому что в каком-то светлом будущем у нас действительно будет современный и удобный fetch, но это уже совсем другая история.

XMLHttpRequest не может быть признан устаревшим, если для него нет полноценной замены.

что программист может сам решать что ему использовать, и если ему удобно работать с DOM через jquery то пусть работает.

Согласен, но это прямо говорит о том, что программист имеет довольно низкий уровень знаний или не хочет учиться. Повторюсь, что 95% оберток в jQuery запросто переписываются в 1-3 строки на чистом js, поэтому в jQuery нет смысла.
Помимо этого, это вешает на проект тяжелое jQuery-бремя и, вероятно, новый разработчик с более высоким уровнем знаний не захочет браться за старую jQuery лапшу.
Нужно думать не только о «мне так удобно и я так хочу», но и о проекте в целом. Если ты тянешь в проект jQuery, потому что «я так хочу», но на это нет веских оснований, то ты так себе программист.

в одном видео разработчик смешал vue и jquery.

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

Можно ссылочку на подобные учебники?

learn.javascript.ru/xmlhttprequest

На сегодняшний день не обязательно использовать XMLHttpRequest, так как существует другой, более современный метод fetch.

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

По историческим причинам: существует много кода, использующего XMLHttpRequest, который нужно поддерживать.
Необходимость поддерживать старые браузеры и нежелание использовать полифилы (например, чтобы уменьшить количество кода).
Потребность в функциональности, которую fetch пока что не может предоставить, к примеру, отслеживание прогресса отправки на сервер.

Учебник Кантора тоже как бы намекает, что использование XMLHttpRequest сходит на нет, но вы правы в том, что fetch пока не умеет следить за процентом загрузки.