Alexey

>>>Были еще файлы, которые как я понял отправлял консольный запрос сервер
Что за файлы?

Привет! Компонент MinifyX есть на зараженных сайтах?

Список используемых на сайте компонентов:
Ace 1.9.3-pl
AjaxForm 1.1.9-pl
Comparison 1.2.14-pl
Console 2.2.2-pl
controlErrorLog 1.4.6-pl
FormIt 4.2.7-pl
gTranslit 1.1.5-pl
lmims 0.0.2-beta
MIGX 3.0.0-alpha5
MinifyX 2.0.3-pl
miniShop2 3.0.7-pl
mSearch2 1.14.9-pl
msFavorites 3.0.5-beta
msOptionsPrice2 2.5.22-beta
pdoTools 2.13.2-pl
pThumb 2.3.3-pl
Redirector 2.0.10-pl
Resizer 1.0.2-beta
seotext 1.0.6-beta
inyMCE Rich Text Editor 2.0.9-pl
translit 1.0.0-beta
-------------------------------

Всем привет! Присоединяюсь: хостинг timeweb, вредонос в .local/session/config/logs/php-fpm/model/observer/

MODX 2.8.5, php 7.4

Самое главное: нет конкретики…

Что за список товаров? Если в админке — он и так выводится в списке заказов, когда модалку открываешь. Если в публичной части сайта, к примеру, в ЛК, то зачем тащить процессор? Не проще ли составить нужный запрос в сниппете и в зависимости от id заказа цеплять товары? Ну, плюс ещё проверять принадлежность заказа к юзеру.

msOrdermsOrderProduct — опечатка?

Если минишоп выдает пустую таблицу, то — возможно — в логах админки есть что-нибудь?

>>>Посты за текущий и прошедший год (и комментарии к ним) оцениваются как есть. Коэффициент равен 1

Я верно понимаю, что имеется в виду отсчёт возраста поста или комментария дискретно по годам? То есть, если пост опубликован в декабре 2023, то в январе 2025 он будет считаться как двухлетний.

Блин, точно… нужно больше отдыхать)) Понимаю же, что должен быть текущий ресурс, а мозг клинит…

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

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

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

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

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

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

Привет! Тут посмотри: stackoverflow.com/questions/7689640/paypal-express-checkout-pay-without-account

В класс оплаты на сайте в методе send в массив $params нужно добавить параметр 'SOLUTIONTYPE' => 'Sole', — disk.yandex.ru/i/f59-EKcIiGXNOQ

Плюс в настройках пейпала разрешить оплату без авторизации.

Должно помочь.

Спасибо за труд!
skrinshoter.ru/s/160824/aSRanUBk — я правильно понимаю, что эта версия компонента поддерживает php 8+?

В системных настройках админки есть опция «enable_dragdrop», которая запрещает/разрешает перетаскивание в дереве меню админки. Если необходимо отключить перетаскивание для конкретной группы пользователей, то можно попробовать в плагине на событие OnMODXInit проверять группу текущего пользователя и — если группа подходит — как-то так:

$modx->setOption('enable_dragdrop', 0);

Возможно, для этой цели есть более «точные» события, внимательно не смотрел

github.com/modx-pro/miniShop2/issues/440 — иссушка давно уже есть

Мы немного уходим в сторону от темы топика)) Но все же рискну завершить оффтоп: мне кажется немного странной логика, в которой определяется привязка пользователя к заказу по неуникальному полю. Юзернейм и емайл — по умолчанию уникальные поля для пользователя в MODX, телефон — нет. То есть, в принципе есть вероятность прикрепления не к тому юзеру, разве нет?

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

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

Привет! В минишопе раньше была бага(или фича), связанная с привязкой юзера по НОМЕРУ ТЕЛЕФОНА, если его вводить в форму заказа. То есть, если вводишь новый email, а телефон использован у ранее зареганого юзера, то заказ прикрепится к этому юзеру, а не зарегает нового.

Сам нарывался на это, нужно было в файле минишопа закомментить пару строк, но в каком — сейчас не вспомню. Может, опытные товарищи подскажут?

Возможно, этот момент уже пофиксил в новых версиях минишопа, не знаю… но раньше точно была такая проблема

Спрячьте простыню кода под кат

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