Николай Савин

В системную настройку mail_smtp_pass (SMTP пароль) вписываете пароль приложения, вместо пароля от почты и все. Никакой магии нет.

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

1. Неправильные права на директорию core/packages/
2. Файл zip загружен с неправильным владельцем

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

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

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

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

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

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

Дмитрий. первые две строки в вашем логе — это не ошибки. Это предупреждения о плохом коде. Они сами по себе ничего не ломают.
Настоящая проблема у вас только одна, та, что про article

Проверь наличие поля article в таблице ms2_products.
Это стандартное поле, оно всегда было в минишопе. Никаких манипуляций с ним никогда не производилось.

Здравствуйте. Стабильная версия PHP для minishop2 — это 7.4. До 8.1 тоже все работает, но могут быть проблемы с подключаемыми компонентами. Что касается СУБД — рекомендую использовать mariaDB 10.6 — она довольно современна, но при этом не вызывает проблем.
Оптимизацию под mysql 8 насколько я знаю специально никто не делал. Вернее закрывали ряд проблем, но не все.
Насчет возрастания нагрузки не знаю что сказать. Таких замечаний отдельно не встречал никогда.

Если вы хотите вы можете заказать оптимизацию минишоп2 под mysql8 — я думаю сделаем. Можете попробовать организовать сбор средств.

Ну и замечу что начинается эпоха MiniShop3 — он уже почти готов и к новому году я думаю увидит свет в магазине дополнений Modstore

pthumb последний раз обновлялся 11 лет назад. Там даже нет поддержки PHP8, Composer Namespace и т.п.
Конечно же не нужно его использовать, если есть современные альтернативы

Я прошу прощения. Конечно, нужно было зайти, посоветоваться. Не догадался.

Модерация будет пройдена, если компонент будет дороже на 30%

Особенно тревожит то, что даже активные разработчики вроде biz87 признаются в использовании нейросетей для базового кодирования — это говорит о недостатке «живых» разработчиков в экосистеме.

На отца руку поднял, негодяй. Удалить его что-ли?

mFilter3 планируется да. Концепта еще никакого нет, я не знаю где ты нашел подробности. Скорее всего это будет принципиально другой подход в работе.

YandexMarket2 — это маленький компонент, где для совместимости с MODX нужно было десяток строк подправить. Я уже сто раз отвечал на этот вопрос.
Minishop2 — огромный продукт с устаревшей архитектурой и кодовой базой — нам дали шанс сделать все с нуля как надо, по современнному, вместо того, чтобы тянуть и дальше старье.
То же самое mSearch2 — это очень большой и очень старый продукт. Для своего времени он был прорывным, но уже много лет как устарел, не отвечает современным требования ни в чем. Ни архитектурой, ни кодовой базой, ни зависимостями — его тоже нужно писать с нуля, сохранив бренд и общий смысл.

Хорошие новости — это будет сильно быстрее, чем история с минишопом.

Ну и пусть растут себе. Ветки MODX2 и miniShop2 (в том числе и прилагаемые компоненты) — почти заброшены. Обновления если и бывают — то крайне редко.

Просто исправь код у себя на проекте и живи счастливо. Обновления не ставь, там ничего критичного не потеряешь, я уверяю.

Если прям хочется сделать все правильно и красиво — то идешь на github, находишь там нужный компонент и делаешь Pull Request с исправлением. Пул Реквесты мы принимаем, и патчи выпускаем.

Ну это все на уровне кода фиксится же. Причем некоторые вещи довольно просто. Если нет желания возиться — всегда можно привлечь программиста.

@Евгений Webinmd обрати внимание. Некоторые вещи можно пофиксить и выкатить патч

Среди перечисленного кода нет ошибок. Это предупреждения. Они никак не ломают код, не прерывают работу проекта. Ворнинги можно отключить на уровне PHP, на уровне веб сервера (htaccess, nginx), на уровне PHP.ini

Простое переключение на php >8.0 приводит к многочисленным ошибкам и ворнингам (деприкейт-функции) в журнале ошибок.

Прям таки к многочисленным? А ну покажи что за ошибки? Доработкой под PHP8.0 занимались, известные немногочисленные проблемы закрывали.

Есть ли смысл тратить время на устранение всех этих ошибок?

Ну если тебе за это платят деньги — то наверное смысл есть. Между PHP 7 и PHP 8, серьезных проблем совместимости нет и никогда не было. Восьмерка поддерживает все из семерки, но чуть строже относится к синтаксису. То есть некоторое количество правок синтаксиса — и все заработает. Я думаю в течение дня с помощью нейронок можно успешно хоть на PHP8.4 перейти.

Тут еще смотря какой набор компонентов используется. Чем их больше — тем и кода больше нужно подгонять.

Василий, что-то ты мудришь сильно. Давай по порядку.
Для начала все это не движ от Symfony DB и Controllers. В MiniShop3 обычный классический PHP подход. Почитай про PSR-4, крайне рекомендую.

Во-вторых, про метод addPackage в MODX3 забудь. Это делается один раз автоматически при загрузке MODX. Далее MiniShop3, MODX, PHP уже знают про все классы, которые есть в каталоге /core/components/minishop3/src/

Если ты создаешь любой кастомный класс, например

/core/components/minishop3/src/Controllers/Cart/CartCustom.php

ты обязан использовать namespace. В твоем случае это будет

namespace MiniShop3\Controllers\Cart;

И полное имя подключаемого класса будет

MiniShop3\Controllers\Cart\CartCustom

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

Вот примерная заготовка для создания класса. расширяющего стандартную корзину

<?php

namespace MiniShop3\Controllers\Cart;  //  Обрати внимание это путь к каталогу Controllers\Cart\

use MiniShop3\Controllers\Cart\Cart;  //  Это мы подключили стандартный класс корзины, который будем переопределять

class CustomCart extents Cart
{
    //  Вот и все.  Класс подключен и расширен. Никаких addPackage
}

Ну и в системных настойках нужно указать имя расширенного класса (путь не нужен, он по namespace уже известен).

Я сделаю инструмент для подключения классов, без прописывания системных настроек
Будет отдельная инструкция.

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