а почему 'parents' => '{$id}',?
надо наверное 'parents' => $_modx->resource.id

Что-то показания путаные! То ошибка 404, то все то же самое…
Можно попробовать вообще строку 'parents' => $id, убрать на время и проверить. По умолчанию в parent подставляется $id текущего ресурса.

Повторюсь, навскидку все должно работать. Тут либо шаблон не тот, либо лыжи не те)))

И что за сниппет setlocale? Он не может как-то влиять?

Да эти ссылки ведут на контейнеры с шаблоном 7


Если я ставлю как вы говорите parents' => $id, то у меня уже попадает в этот список страница Ошибка 404 и т.д. не работает…

До этого был шаблон вот такой, может где то ошибка в нем!

[[$template.breadcrumb]]
			<div class="page-section">
				<div class="container">
					<h1>[[*longtitle:default=`[[*pagetitle]]`]]</h1>
					<nav class="categories-nav">
						<ul>
							<li[[*id:is=`4`:then=` class="active"`]]><a href="[[~4]]">Все</a></li>
                            [[pdoMenu?
                                &parents=`4`
                                &level=`1`
                                &firstClass=``
                                &lastClass=``
                                &tpl=`@INLINE <li[[+classes]]><a href="[[+link]]">[[+menutitle]]</a></li>`
                                &tplOuter=`@INLINE [[+wrapper]]`
                            ]]
						</ul>
					</nav>
					[[setlocale]]
					[[!pdoPage?
                        &parents=`[[*id]]`
                        &limit=`8`
                        &sortby=`{"publishedon": "DESC"}`
                        &useWeblinkUrl=`1`
                        &tpl=`news.item`
                        &includeTVs=`image`
                        &prepareTVs=`image`
                        &where=`{"template": 7}`
                        &tplPageWrapper=`@INLINE 

<div class="paginate-links js-paginate-links">
                        	<ul class="pagination justify-content-center js-pagination ajax-pagination">
                                [[+pages]]
                        	</ul>
                        </div>`
                        &tplPage=`@INLINE <li class="page-item"><a href="[[+href]]" class="page-link">[[+pageNo]]</a></li>`
                        &tplPageActive=`@INLINE <li class="page-item active"><span class="page-link">[[+pageNo]]</span></li>`
                        &tplPageSkip=`@INLINE <li class="page-item disabled"><span class="page-link">...</span></li>`
                        &toPlaceholder=`listing`
                    ]]
                    [[+listing:ne=``:then=`<div class="objects-archive by2-sm by4-lg row ajax-result">
                        [[+listing]]
                    </div>
                    [[!+page.nav]]
                    `:else=`<p>Пусто...</p>`]]
                    [[*content]]
				</div>
			</div>
		</div>

disk.yandex.ru/d/TZ1s71O-Q8cXEQ — эти ссылки ведут на отдельные ресурсы-контейнеры, у которых дочерними являются ресурсы с шаблоном 7, так? И у этих контейнеров шаблон как в описании, так?

Если да, то должно работать с 'parents' => $id, Если элементы хранятся в файлах, возможно, был кеш не сброшен после редактирования шаблона?

В сниппете rcv3_html достаточно отложить загрузку через setTimeout (хотя кто-то делает через onClick). Не думаю что мой вариант самый правильный и что вообще стоит принудительно таймаутить что-либо, но меня пока так устраивает + поможет улучшить показатель TBT в PageSpeed.

Меняем вот эту строку:

$modx->regClientStartupScript('<script src="https://www.google.com/recaptcha/api.js?onload=ReCaptchaCallbackV3&render=' . $public . '" async></script>');

на

$modx->regClientScript('
        <script>
            function loadCaptcha() {
              let script = document.createElement("script");
              script.src = "https://www.google.com/recaptcha/api.js?onload=ReCaptchaCallbackV3&render=' . $public . '";
              script.async = true;
              document.body.append(script);
            }
            setTimeout(loadCaptcha, 2500);
        </script>
    ', true);

В итоге получаем отложенную загруку скрипта на 2,5 секунды + он будет не в head, а в body за счёт замены regClientStartupScript, на regClientScript.

Пробовал, все тоже самое….
т.е. если я нажимаю «акция» он мне должен показать документы в категории «акция», а он показывает «все»

так попробуй:
'parents' => $id,

Решил свою проблему через имя пользователя, но хотелось бы через права пользователя «Неограниченные права»

<?php
  /**
  * Системное событие OnManagerPageBeforeRender
  *
  */

  // какой скрипт запущен
  $script = $scriptProperties['controller']->scriptProperties;
  $url = $script['a'];

  // пользователь
  $user = $modx->getUser();
  $username = $user->get('username');

  if ($username != 'admin' AND $url == 'system/settings' ) {
	exit('Доступ запрещен '. $context);
  }

Спасибо, тоже очень интерестное решение.

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

А так ничего готового из подобного функционала нет.

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

'where'  => [
    'Data.price:!='=>'0'
]

Предположим, что объявления это ресурсы. Тогда я бы создал отдельную таблицу для хранения данных об оплаченных услугах для конкретных ресурсов. Сами услуги и оплату сделал бы через minishop2. Ещё повесил бы на крон задачу, которая будет проверять когда заканчивается оплаченный период.

miniShop2.Order.add('extfld_delivery_price','100', function() {
		        miniShop2.Order.getcost();
    })

Это вот работает, но чтобы увидеть изменения нужно перезагрузить страницу. Посмотрю еще. Спасибо

То есть может получиться так, что мне придется вызывать свой action который будет добавлять поле с таким значением в сессию заказа?

Скорее всего дело в том, что за короткое время происходит изменение нескольких полей заказа и, поскольку данные записываются в сессию, она не успевает обновится. Тут либо переходить на хранение данных в БД, если версия minishop2 позволяет, или ставить задержку через setTimeout().

Благодарю за ответы.

Если суть поста: стоит или не стоит, то тут всё зависит от тебя. Хочешь копаться, разбираться — стоит. А иначе можешь и откатиться, но не факт что всё заработает…

Стоит ли копаться и решать проблему или лучше откатить Minishop2 до 2.5.0-pl?

Т.к. вводных данных крайне мало, можно только теоретизировать:

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

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

Имхо, лучше поправить ошибки, и остаться на актуальных версиях дополнений.