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

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

Итого у нас есть две утилиты
1. Добавление полей в базу данных и в карту модели.
2. Добавление полей на страницу админки.

Есть еще третья утилиты — вывод колонок в таблицах-гридах.

2) Нет с плагинами ничего не делал. Проблему я понял. Подумаю что можно сделать

Ну тогда уж и плюсик ставь к посту.

Того гляди и начнет народ MODX3 пользоваться.

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

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

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

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

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

Спасибо проверю. Подскажи как устанавливал? Скачал готовый транспортник из релизов или из git исходников собрал?

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

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

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

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 — хуже от этого точно не станет, зато у вас появится возможность использовать более современные компоненты.
Из минусов — можно потерять возможность обновлять некоторые старые компоненты (правда они особо и не обновляются)
Ну и затратно может быть.

Как всегда обновленный транспортный пакет ждет вас в релизах

У msCustomer есть поле user_id, которое связывает покупателя с modUser:

// В модели msCustomer
  'aggregates' => [
      'User' => [
          'class' => 'MODX\\Revolution\\modUser',
          'local' => 'user_id',
          'foreign' => 'id',
          'cardinality' => 'one',
      ],
  ],

Режимы работы

1. Автономный режим (по умолчанию)

• msCustomer работает независимо от modUser
• Покупатели авторизуются через свой email/пароль
• Подходит для магазинов без дополнительного функционала

2. Синхронизация с modUser

• Включается настройкой ms3_customer_sync_enabled
• При создании/обновлении modUser автоматически создаётся/обновляется msCustomer
• Синхронизируются: email, fullname → first_name, phone, активность
• При удалении modUser — покупатель НЕ удаляется (сохраняется история заказов), только отвязывается (user_id = 0)

3. Создание modUser при заказе

• Настройка ms3_order_register_user_on_submit
• При оформлении заказа создаётся системный пользователь
• Ему можно назначить права и группу пользователей

Для желающих протестировать — создал релиз в GitHub. Там можно скачать готовый транспортный пакет.

Дмитрий. первые две строки в вашем логе — это не ошибки. Это предупреждения о плохом коде. Они сами по себе ничего не ломают.
Настоящая проблема у вас только одна, та, что про 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%