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

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

[[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 пока не умеет следить за процентом загрузки.

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

Но согласитесь вы с таким высказыванием?, что программист может сам решать что ему использовать, и если ему удобно работать с DOM через jquery то пусть работает. Не все программисты рисуют интерфейсы через новомодные фреймворки, добрый старый html никуда не делся.

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

Ведь все началось с чего, Евгений (автор поста) написал что в одном видео разработчик смешал vue и jquery. Мне кажется — если у него все получилось, то он молодец.

Почему fetch не сможет отправить запрос и вернуть json?

Сможет, только тебе придется писать для него обертку, чтобы удобно работать с api. В реальном приложении ты постоянно обращаешься на разные эндпоинты, конвертишь json и обрабатываешь ошибки, fetch из коробки либо что-то из этого не умеет, либо делает это неудобно. У тебя здесь нет выхода, тебе нужна обертка, либо твое приложение превратится в ад.

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

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

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

Подскажи, как ты собираешься обойтись без axios, если ты хочешь работать с api в условном Vue?

не могу ничего ответить разумного, я не пользуюсь vue.
Ознакамливался с учебником 2 версии, сейчас вроде уже 3 вышла.
А в чем там проблема? Насколько я понимаю, принцип работы vue в том, что он умеет реактивно изменять dom (не хочу сейчас вдаваться в тонкости между dom в браузере и виртуальным dom с которым работает vue), отсылая запросы, получая json ответы и по этим данным опираясь на template изменять страницу. Почему fetch не сможет отправить запрос и вернуть json?

тут молчу, я об этом не знаю.

но потом приходит понимание, что не просто так же используются другие решения (иногда просто так :) )

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

мне кажется это странные аргументы

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

Да, над fetch есть обертки, которые тебе и исключение бросят, и .json() за тебя сделают, но процентную загрузку они тебе не дадут без XMLHttpRequest.
Поэтому еще раз повторю, что fetch — низкоуровневый инструмент и пока он не сможет в процентную загрузку, заменить XMLHttpRequest им невозможно.