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

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

@Наумов Алексей конечно же прав, нельзя передавать $_POST как есть, нужно его валидировать. Однако вопрос был не про безопасность, а про то как сохранить данные))) Безопасность это отдельная обширная тема.

А потом злющий хакер меняет в форме поле «id» на «1», а «content» на слово из 3-х букв…

Благодарю, почему-то сначала даже не думал в эту сторону

Большое спасибо, заработало. Но возник вопрос с alias, при создании записи генерируется alias, но он не появляется в поле псевдоним в админке. И еще вывожу страницы pdoPage

[[!pdoPage?
                            &element=`pdoResources`
                            &showHidden=`1`
                            &parents=`6`
                            &tpl=`myTplChunk`
                            &includeTVs=`img`
                            &limit=`12`
                            &tplPageFirstEmpty=``
                            &tplPageLastEmpty=``
                            &tplPagePrevEmpty=``
                            &tplPageNextEmpty=``
                            &tplPageFirst=``
                            &tplPageLast=``
                            &tplPagePrev=``
                            &tplPageNext=``
                        ]]

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

div class="article-item">
              <img src="[[+tv.img]]" alt="[[+pagetitle]]">
              <div class="article-descr">
                <h3>[[+pagetitle]]</h3>
                <div class="meta">
                  <p class="author">admin</p>
                  <p class="count-comments"><a href="[[~[[+id]]]]#comments">
                  <span class="icon-fa"><i class="fa fa-comment-o"></i></span>
                  <span class="count-comment">[[!ticketCommentCount:default=`0`? &id=`[[+id]]`]]</span>
                  </a>
                  </p>
                </div>
                <a href="[[~[[+id]]]]" class="btn btn-art">Подробнее</a>
                <div class="date">
                  <span>[[+publishedon:date=`%d`]] [[+publishedon:date=`%b`]]</span>
                </div>
             </div>
</div>

Делай так

oldUser = $modx->user;
$modx->user = $modx->getObject('modUser', 1);
$modx->runProcessor('resource/create', $_POST);
$modx->user = $oldUser;

Пока нет такого функционала, но постараюсь в ближайшее время добавить

Про код. Про «научиться писать код понятный и логичный». Не в тему поста выше, ситуация вчера/сегодня и смех и грех.
Вчера пришел запрос от Заказчика на сайте на Wordpress — сайт криптообменника. Там в настройках надо было добавить новый статус заказа. Добавили в админке, а на сайте у клиентов не отображается. Ну я типа ща минуту, легкотня.
В итоге провозился 2 дня. Пока разбирался в чужом коде. Вчера даже тестовый сайт лег после пробных правок кода, пришлось восстанавливать.
В итоге сегодня разобрался. Выставляю счет Заказчику за 7 часов работы анализа и правок и отладки кода (3 часа восстановления сайта не в счет, оказалось что сайт лог ошибок не пишет, а восстановить бэкап просто так нельзя и «вообще некогда нам» — кое как сам добавил логирование ошибок и восстановил сайт).
Заказчик в итоге спрашивает у меня — с какого так много запаришваешь? Типа поменять там всего то текст. А оказалось что в админке есть настройка, а в коде названия статусов выводит через дефолтные настройки в самом коде (рука лицо!). И вообще в админке указываемое название статуса нигде не используется. И 7 полей из 10 из таблицы статусов в БД не используется почти. И куча артефактов. И фильтров и функций непонятно каких. И вообще id статуса в таблице заказа не используется, а используется текстовое название статуса (аааа!). И вот сидишь разбираешься в этом г… не и не понятно кто будет платить за разбор. А казалось бы просто вывести название статуса в заказе клиента…
А до этого тоже делал подобное. И пока доделал — оказалось что задачка стала неактуальной. И код правки (по итогу 2 строчки кода) стал никому не нужен. Опять же 2 дня из-за непонятного чужого кода. Ладно хоть заплатили…

Теперь Заказчику приходится искать специалиста и по MODX и по VUE.

Мы такого не нашли :-). Я искал месяц, а потом перестал искать. Даже Василий Наумкин попробовал нам помочь с MODX и VUE, но у меня сейчас замороченный код и Василий сказал что не силен разбираться в тайнах чужого кода :-). Как бы научиться писать код понятный и логичный?? А то как обычно есть идея понятная логичная — пишешь код и начинается. То здесь фишку надо прикрутить, то там костыль прописал и в итоге хаос. Как пишешь первоничальный вариант, то делаешь одно, а как используешь в работе то вносишь уже совершенно другие правки. Пара лет правок и энтропия догоняет. Все становиться запутанным и малопонятным.

Уроки по синхронизации с Битрикс24 имеют весьма опосредованное отношение к Modx. Да и основная сложность при работе с Битрикс24 это структура хранения данных в самой CRM. Например банковские реквизиты компании это отдельная сущность, т.е. сначала нужно создать компанию, потом создать реквизит. А перед этим ещё найти контакт по лиду или создать его.

Спасибо за статью.
Я столкнулся с проектом где часть админки начали делать на VUE.js потому что так захотел/обосновал предыдущий программист. А после его ухода заказчик остался с недоделанным личным кабинетом. А по факту там надо было реализовать подгрузку документов пользователя. Ну может еще что реактивного, но я задался вопросом почему нельзя было стандартными средствами MODX реализовать и с Ajax-запросами.
Теперь Заказчику приходится искать специалиста и по MODX и по VUE.

Было бы классно если бы еще были уроки по синхронизации с Битрикс24.
Т.к. в коде выше я так понял нет примеров самой синхронизации.
На modstore есть 2 плагина платных, но по ним есть вопросы — в комментариях видно что не все позволяет синхронизировать (последние комментарии от 2024 года висят без ответов).
Т.к. Битрикс24 одна из самых популярных и функциональных CRM сегодня.

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

Читай мой коммент выше как исправить

Прочитав про комментарий выше о том что тема создает папку manager я вспомнил что уже писал об этом и сталкивался с проблемой в прошлом. https://modx.pro/components/25063#comment-144547
Повторю сюда решение проблемы при установке — т.к. после установки на сайт, у которого папка manager (папка админки) была переименована, — тема встает неправильно:

У меня админка размещена по другому адресу (не manager).
Страница входа выглядит не так как на картинке в теме выше. Посмотрел и увидел что в корне создалась папка manager/templates/eclipseui
При этом в папке админки в папке templates тоже появилась папка eclipseui. Но в ней папки частично пустые.
Просто перенес содержимое созданной папки manager в правильную папку админки и все нормально заработало.
Т.е. установщик ставит шаблон неправильно — где-то в коде указывает папку установки с прямым путем manager/templates/eclipseui, а надо брать путь к папке из конфигов.
Благо разобрался и все заработало.

После этого получил красоту.
Правда не понял в чем разница в настройке manager_theme с gihub на eclipseui — вроде одинаковые.
Еще было бы круто вынести в настройки выбор цветов.

Сначала сохрани ресурс потом устанавливай значение ТВ.

Я делал ровно такое через тегирование, компонентом tvSuperSelect.

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

@SELECT [[!pdoResources? //и тут выбор значений для чекбоксов ]]

То есть к врачу галочки ставишь, какие специальности, потому что специальностей список конечный, а врачей как будто нет. Услуги и цены создавал ресурсами, через настройку форм убирал лишние поля. Там где надо было схлопнуть дерево в админке, использовал компонент Collections.

Тут главное не забывать концепцию MODX, что ресурс — это не обязательно страница. Есть побочный эффект при таком подходе: на одинаковых услугах у тебя будет одинаковый alias, но это легко пофиксить пакетом customURLs, где настраиваются маски alias-ов по разным правилам.

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

Там все операции сводятся к перекладыванию JSON для MIGX и простейшим выборкам ресурсов, так что бояться такой кастомизации не стоит.

Успехов!

да

Типа каждый раз запрашивать код/звонк при авторизации?