Изменить стили хочу на странице категории товаров.
Отображаю при помощи 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, но другие контактные данные, например у него сменился телефон или адрес
— в такой ситуации в заказ могут попасть некорректные данные, подтянутся «старый»
телефон к примеру. Так же некорректные данные могут прийти в письме менеджеру о новом заказе.

ну база email собираются себе потихонечку, маркетологам на забаву

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

а чем мешают аккаунты?

Понятно, спасибо. Значит придется с JS мутить.

нет в минишопе такой возможности из коробки

тех. поддержку чего modx или minishop2? можете дать ссылку если Вам не трудно. Спасибо.