Так и сделаю. Спасибо!

Привет Григорий.

Осадочек обоснованный — решение рабочее, но есть несколько моментов, которые стоит обдумать:

Что смущает в текущем фиксе

1. Изменение логики метода.
Оригинальный код при отсутствии сессии возвращал []. Теперь он создаёт сессию. Это может сломать логику в других местах SendIt, которые рассчитывают на пустой ответ как сигнал «сессии нет, нужно что-то сделать».

2. setcookie() без проверки заголовков
Если заголовки уже отправлены — будет ещё один warning.

Минимальный и безопасный фикс
Если цель — просто убрать warning без изменения логики:

$sessionId = $sessionId ?: ($_COOKIE['siSession'] ?? null);

if (!$sessionId || !$session = $modx->getObject('siSession', ['session_id' => $sessionId, 'class_name' => $className])) {
    return [];
}

Это сохраняет оригинальное поведение: нет куки → нет сессии → пустой массив. Создание сессии должно происходить там, где это предусмотрено архитектурой компонента.

Что бы я сделал

Посмотрел бы, где в SendIt сессия создаётся штатно. Скорее всего есть отдельный метод типа createSession() или это происходит при первой отправке формы. Вот там и должна быть логика создания + установки куки.

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

Понял, спасибо. попробую

[[*alias]] или [[*id]] выводит соответствующие поля текущего ресурса.
Если посетитель находится на главной — они от нее и выводятся.

Блоки в лендинге. должны выводиться аналогично меню.

[[pdoResources?
  &tpl=`section_tpl`
  &limit=`0`
]]

А в чанке section_tpl уже указывайте [[+id]], [[+alias]], [[+pagetitle]] и т. д. — они будут забираться от выводимых ресурсов

Написано — одна из доработок
Передача ссылки на оплату заказа или редирект на платежную систему

как это сделать — поясните кто нибудь!

тот же вопрос

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

Для MIGX нужно указать

"configs": {
    "startDay": 1
}

В Сбере поменяли работу с логином и паролем интернет-эквайринга. Теперь они без суфикса -api. И настраиваются в ЛК СберБизнес. (Логин ПШ и ПАроль ПШ).
Сейчас выдаётся ошибка доступа и вместо страницы оплаты идёт переадресация на страницу ошибки оплаты.
Будет ли обновление компонента?

У себя я вероятно нашел проблему.
Версия минишоп была 2.5 и обновления дальше 2.5 не видит. И установлена она была с modx.com, а не modstore. Сменил на modstore — предлагает обновления.
Обновлю, посмотрю модуль будет работать или нет

В моем случае смена на пхп 8.3, ошибку 500 не исправляет. Поэтому буду разбираться с нуля, где в оф заказа только этот модуль.

Да, я тоже нашел проблему с 500 ошибкой. Сначала она вызывалась иза отсутствия подключения к dadata.
Потом была проблема, что sendit меня опозновал как бота при тестах и просил перегрузить страницу. Видите ли слишком прямо я курсор вожу по экрану)

Недавно я опять нашел 500 ошибку, когда выбираешь населенный пункт, в котором нет пвз и выбираешь пвз доставку, то в консоли появляется 500 ошибка при аякс запросе.
И соответственно, если человек ушел со страницы оф. заказа в тот момент, когда у него появилась такая ошибка, то при след заходе в оф заказа падает сразу в 500. Очистка кеша/истории браузера помогает (не просто ctrl+f5).

Я пока склонялся к идее, что это чисто мои проблемы (в оф заказа много разных модулей добавлено...) и сейчас буду тестить максимально чистый вариант, без всего лишнего. Но первым делом проверю смену версии php, вдруг правда поможет.
И в демке на сайте такой проблемы нет, там при отсутствии пвз пишется текст, что его нет, всплывают сообщения сендит и в консоли 500 не наблюдается.

www.mail-tester.com/

Здесь можно потестить отправку — толковый сервис

проблема была в том, что тип всех таблиц был InnoDB, а таблиц minishop2 — MyISAM, после смены на InnoDB нагрузка спала.

С mail.ru вообще часто проблемы (как в плане отправки через них, так и им), стараюсь не связываться.

А вообще правила общие просты:
1. Отправляем через smtp
2. Убеждаемся, что домен, с которого отправляем, не в списках «спам» (см. сервисы разные в интернете)
3. Настраиваем DKIM и SPF записи для домена

Т.е. полный скрипт так выгладит, правильно я понял?:

<script>
$('#mse2_filters').change(function(){
    $('html,body').stop().animate({ scrollTop: $('#mse2_results').offset().top }, 10);
});
</script>

если так:

<script>
$('#mse2_filters').change(function(){
    $('html,body').stop().animate({ scrollTop: $('#mse2_results').offset().top }, 10);
    e.preventDefault();
});
</script>

то не срабатывает ползунок — слайдер

Так и что в итоге, компонент рабочий или как?

На данный момент не уверен, почему мне так показалось. Так или иначе новая версия компонента вызывает ошибку 500 на сайте, которую выдает сам MODX, так что даже не выяснить подробностей. Нигде в логах ничего не выводится, даже при debug=1

я обновлял и новая версия работает на 7.4.33. Обновил явно не в 1 клик, но это больше проблема нестандартного шаблона была.
А как вы поняли, что на 7.4 не работает? может я что-то не протестировал

По правильному нужно адаптировать проект под PHP8.1 — хуже от этого точно не станет, зато у вас появится возможность использовать более современные компоненты.
Из минусов — можно потерять возможность обновлять некоторые старые компоненты (правда они особо и не обновляются)
Ну и затратно может быть.