Артем

Никто не мешает занаследовать процессор и искать по чему хочется.

Дык нафиг он нужен, если там нет ни одного метода, который не нужно переопределять?
searchResources юзает getCollection, ровно как и остальные методы для поиска, тут можно передать привет оперативке.
process тоже переопределять нужно.
И что там в итоге остается, проверка прав?

Понял. а если сделать проверку типа

Тогда остается доступ к произвольным *.tpl, *.html и *.php файлам. В общем, это довольно скользкая штука и рано или поздно может аукнуться. Хорошей практикой будет просто указывать этот шаблон на сервере и не париться о всяких проверках.
Тем более, в твоем примере просто проверяется наличие '@FILE' в строке, а не на первой позиции. Это я к тому, что накосячить с этим гораздо проще, чем кажется.

А если $_REQUEST['minQuery'] будет равна 'три'

То она просто скастуется до 0 через (int), а затем будет взято 3. В общем, в этой переменной всегда будет число и ошибки не будет. Максимум — условие не пройдет, если передать отрицательный minQuery.

Почему?

Потому что value="@CODE {$modx->removeCollection('modResource')}"

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

Если у тебя будет 30к товаров, то getIterator сожрет всю оперативку даже не дойдя до половины.

$query = strip_tags($_POST['query']); // хватит?

Конечно, защищает от любых sql-инъекций.

Тогда уже так

достаточно просто

$minQuery = (int) $_REQUEST['minQuery'] ?: 3;

<input type="hidden" name="tpl" value="@FILE chunks/blocks/service-item.html">

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

$resources = $modx->getIterator('msProduct',$dbQuery);

Объекты тут вообще не нужны, гораздо правильнее заменить это на

$dbQuery->select(['id']);
if ($dbQuery->prepare() && $dbQuery->stmt->execute()) {
    $ids = $dbQuery->stmt->fetchAll(PDO::FETCH_COLUMN);
}

$query было бы неплохо хотя бы поверхностно обработать, т.к. он дальше напрямую передается в запрос.

$minQuery = $_POST['minQuery'] ?: 3;

Можно добавить (int).

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

{if $_modx->resource.parent in list [16, 17, 18]}
    УСЛОВИЕ ВЫПОЛНЕНО
{else}
    УСЛОВИЕ НЕ ВЫПОЛНЕНО
{/if}

Этот модификатор работает не так, как все от него ожидают. Он проверяет сразу несколько условий:

• $a in list $b
• $a in keys $b
• $a in string $b (если указана строка вместо массива)

Соответственно, в твоем случае in list возвращает false, но сразу после этого идет проверка на in keys, которая уже возвращает true. То есть проверяется, что parent текущего ресурса содержится в ключах массива, а это, разумеется, правда.

Из сорсов:

return in_array($value, $haystack) || array_key_exists($value, $haystack);

Не знаю, зачем был придуман этот модификатор, потому что в реальных кейсах никто не проверяет такой «микс» условий.
Рекомендую забыть об этом модификаторе и юзать его более конкретизированные версии, в частности in list.

{($_modx->resource.parent in list [16, 17, 18]) ? 'true' : 'false'}

Скорее всего нужно же ещё отредактировать файл /core/components/minishop2/model/schema/minishop2.mysql.schema.xml?

Не нужно так делать, есть куда более правильный подход.

А вообще, мне лично неясно, зачем здесь нужна вторая таблица. Достаточно создать 3 новых поля — discount, discount_after, discount_until, затем написать небольшой кусок логики, который будет проверять, что товар попадает в нужный временной отрезок и к нему можно применить акцию, ну и останется только рассчитать скидку согласно акции.
По инструкции, которую ты скинул, можно расширить админку и сделать вполне удобный интерфейс для заполнения этой инфы.

Как наиболее оптимально найти name?

const { name } = initialDataForSelects.countries.find(country => country.id === 16);

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

modx.pro/help/20349

После @ указывается набор параметров.
В админке тык по шестеренке -> Наборы параметров.

'class' => 'msProduct', за что отвечает и почему без этого параметра в корзине пишет что она пустая?

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

С рабочего проекта:

{'!Localizator' | snippet : [
    'snippet' => 'msCart',
    'class' => 'msProduct',
    'tpl' => '@FILE chunks/_checkout.cart.tpl',
]}

Соответственно, в чанке юзается просто {$product.pagetitle}.

Сделать адаптивной модальное окно с заказом в админке сайта.

Это, кстати, реальная проблема, клиенты часто на это жалуются.

$modx->removeCollection(msOrder::class);

танцы с бубнами — иначе не назовешь

Спасибо за твой огромный вклад в сообщество, за все твои труды, дополнения и заметки.
Восстанавливай нервы, отдыхай от этой суматохи и возвращайся с новыми силами!

И значит если какой-то прогер не знает о баге с pdoResources,

Земля пухом коннектором, что еще тут скажешь.

Вы плохо читаете или понимаете?

Ты решил поиграть в самого дерзкого или к чему ты мне это написал?

Если вы так уверены в этом, просто не ставьте pdoResources в разрешенные.

Я не собираюсь использовать твой компонент, который состоит из 30 так-себе-написанных строк, да и другим не советую этого делать.

Вообще кек, мои слова о поддержке на modx.pro забираю обратно.

Какие мы тут плохие, обидели бедняжку:(
Ну ты извини нас, мы дружно скачаем твой компонент и будем использовать на всех своих сайтах. Ведь это самый удобный и самый практичный способ работы с ajax.

в чем принципиальное отличие запроса в коннектор и просто в сниппет

Принципиальное отличие в том, что в коннекторе ты сам вызываешь нужный сниппет и сам передаешь ему параметры, поэтому сюрпризов там не будет, а в твоем случае ты просто запускаешь произвольный сниппет с произвольными параметрами.
Собственно, если в разрешенных сниппетах будет какой-нибудь pdoResources, то это будет аналогично этому коду:

$modx->exec($_REQUEST['snippet']);

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