В плагине после строки

case 'OnWebPagePrerender':

добавить строку

if($modx->resource->id == 8) return;

где 8 — id нужного ресурса, меняем на нужный.

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

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

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

Хорошая статья.
От себя могу добавить, сниппет genPassword можно не писать. У класса modUser есть метод generatePassword. В который тоже можно передать длину пароля

у меня контекст один. Идея была такая же, только проблема в реализации — я свой первый сниппет буквально два 3 назад написал)

Изменить стили хочу на странице категории товаров.
Отображаю при помощи pdoPage:

[[!pdoPage? 
        &element=`msProducts`
        &tpl=`products_row`
        &includeTVs=`prod-img`
        &limit=`400`
]]

Содержимое products_row:

<tr>
	<td class="prod-name">{$pagetitle}</td>
	<td class="prod-size">[[!msOptions? &options=`size` &tpl=`tpl.msOptions-sizes` &product=`[[+id]]`]]</td>
	<td class="prod-sost">[[!msOptions? &options=`sost` &tpl=`tpl.msOptions-sizes` &product=`[[+id]]`]]</td>
	<td class="prod-nalichie">{$weight} кг</td>
	<td class="prod-price">{$price | replace:" ":""} руб.</td>
	<td class="prod-primechanie">[[!msOptions? &options=`prim` &tpl=`tpl.msOptions-sizes` &product=`[[+id]]`]]</td>
	<td>[[+prod-img]]</td>
</tr>

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

представьте насколько проще было бы вам помочь, если бы вы показали, куда и что вставляете.
Начнем с того, где вы хотите «изменить стили»? На странице категории товаров (где идет вывод списка товаров) или на посадочной конечной странице товара?
Если в категории товаров, то как вы их отображаете, при помощи сниппета msProducts?
Если да, то вы в нем указываете имя tpl чанка, который отвечает за отображение одного товара в списке, ведь так? В этом чанке будет работать код, указанный Евгением — тоесть проверка на то что в переменной $favorite лежит что-то что может быть приведено к true. Ставите у товара галочку — особый и в эту переменную попадает 1.

Если вы хотите иметь доступ к переменной $favorite на странице товара, то используйте такой вызов
{ if $_modx->resource.favorite}my_class_for_favorite{/if}

Тут человек AjaxForm путает с AjaxSnippet, поэтому твой совет не поможет (но комментарий привлёк меня, так что косвенно ты тоже помогаешь :))
Там нет никакой формы и вообще ничто никуда не отправится.

При этом сниппет addfavorites ведёт себя как хук для FormIt (хотя вполне себе можно без него, просто оперируя POST данными).

Следовательно вызов в таблице должен быть таким:
(чтобы не мешать синтаксис, ведь люди старались сделать всё изначально на Fenom)

{$_modx->runSnippet('!AjaxForm', [
    'snippet' => 'FormIt',
    'form' => 'tpl.Favorite',
    'hooks' =>  'addfavorite',
    'fi.name' => $service.name,
    'fi.id_service' => $service.id_service,
    'fi.cost' => $service.cost,
    'fi.address' => $service.address
])}

Параметры fi.name и т.д. нужны, чтобы прокинуть данные в форму. См. modx.pro/components/3342

А чанк tpl.Favorite переделать хотя бы так:

<form action="" method="post" class="ajax_form">
    <input type="hidden" name="name" value="[[+fi.name]]">
    <input type="hidden" name="id_service" value="[[+fi.id_service]]">
    <input type="hidden" name="cost" value="[[+fi.cost]]">
    <input type="hidden" name="address" value="[[+fi.address]]">
    <button type="submit" class="center">В избранное</button>
</form>

Это, конечно, не отменяет множество проблем в коде автора.
Например строка $id_user = $modx->user->get('id'); будет работать только для авторизованных пользователей (для админа когда он проверяет). А на пользователях-гостях вполне себе будет падать.

Ну и какой-то странный формат HTML вёрстки с запятой и разными кавычками)

<td class='service' id="cost", value="{$service.price}">Стоимость: {$service.price} ₽</td>

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

я, похоже, как обычно куда-то не туда вставляю, потому что у меня ничего не получается(

Отлавливайте клик средствами JS. Передайте куда нибудь в data атрибут идентификатор товара.
После того как поймаете клик по нужному товару — сформируйте ajax запрос на сайт.
Ловите запрос через плагин на событие onHandleRequest и далее уже средствами php как-нибудь запоминайте этот товар как избранный

Помню, несколько лет назад реализовывал функционал избранного, но не через сессии, а через куки.

То есть, при добавлении в избранное, идет проверка, авторизован ли пользователь на фронтенде. Если да, то id товара пишется в extended пользователя, если нет, то сажаем ему куку в браузер. Список айдишников просто через запятую, при добавлении, есесно, проверяем наличие этого айдишника в избранном, если есть, то удаляем из избранного и наоборот.

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

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

Суть будет примерно такая.

1. Нужно создать таблицу в базе данных. Поля user_id — число, session_id — строка, product_id — число
2. Создать модель для этой таблицы, чтобы modx знал о ее существовании.
3. Создать класс управления таблицей. Основные методы add(), remove(), getList(), может быть getCount()
4. В каждом методе написать обращение к таблице и ее чтение, добавление записи, удаление записи.
5. При записи в таблицу если пользователь авторизован — записывать его Id как идентификатор, если нет — то записывать session_id
6. Подготовить js файл который по клику будет определять чего хочет пользователь и слать запрос на корневой адрес сайта
7. Подготовить плагин на событие OnHandleRequest который будет слушать обращения JS файла и вызывать класс компонента и соответствующий метод.

Подскажите, пожалуйста

Евгений, да, вы правы. А я об этом не подумала XD

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

Николай, спасибо. Я посмотрю, может что-нибудь и получится)

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

Добрый день.
В минишоп нет такой возможности из коробки.
Данный вопрос уже всплывал недавно, он добавлен в список «Хотелок» и в «ближайшем» будущем будет реализован.
Пока что ваш вопрос можно решить следующим образом.
Согласно документации создать и подключить свой класс оформления заказа, устранив оттуда логику создания заказа. Честно говоря не проверял — нужно пробежаться по коду — но из за отсутствия юзера в заказе проблемы могут возникнуть в самых неожиданных местах. Например где-нибудь в таблице заказов.

This page contains the following errors:
error on line 47 at column 113: EntityRef: expecting ';'
Below is a rendering of the page up to the first error.

Ну честно говоря, автоматическое создание аккаунта при заказе иногда приносит проблемы.
Не раз сталкивался со следующим поведением
— человек делает заказ указав email test@test.com и свои контактные данные
— ему автоматически создается аккаунт
— через месяц он еще раз делает заказ на сайте, указав тот же email, но другие контактные данные, например у него сменился телефон или адрес
— в такой ситуации в заказ могут попасть некорректные данные, подтянутся «старый»
телефон к примеру. Так же некорректные данные могут прийти в письме менеджеру о новом заказе.