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

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

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

Дело в том, что эти ворнинги, вроде, растут из контрибных пакетов. Может, есть где почитать, как в модх принято корректировать контрибный код? Что-то вроде патчей есть?

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

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

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

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

вот ошибки журнала (php 8.2):
[2025-10-30 14:37:11] (ERROR @ /home/xxx/public_html/core/components/minishop2/handlers/storage/session/cartsessionhandler.class.php: 15) PHP warning: Undefined array key «minishop2»
[2025-10-30 14:37:11] (ERROR @ /home/xxx/public_html/core/components/minishop2/handlers/storage/session/cartsessionhandler.class.php: 15) PHP warning: Trying to access array offset on value of type null
[2025-10-30 15:08:07] (ERROR @ /home/xxx/public_html/core/cache/includes/elements/modsnippet/43.include.cache.php: 74) PHP warning: Undefined array key «return»
[2025-10-30 15:08:07] (ERROR @ /home/xxx/public_html/core/cache/includes/elements/modsnippet/43.include.cache.php: 127) PHP warning: Undefined array key «return»
[2025-10-30 15:48:14] (ERROR @ /home/xxx/public_html/core/model/modx/modx.class.php: 1037) `` is not a valid integer and may not be passed to makeUrl()
[2025-10-30 15:48:14] (ERROR @ /home/xxx/public_html/core/model/modx/modresponse.class.php: 210) Attempted to redirect to an empty URL.
[2025-10-30 15:48:16] (ERROR @ /home/xxx/public_html/core/model/modx/modx.class.php: 1037) `` is not a valid integer and may not be passed to makeUrl()
[2025-10-30 15:48:16] (ERROR @ /home/xxx/public_html/core/model/modx/modresponse.class.php: 210) Attempted to redirect to an empty URL.

43 сниппет — это msGallery
насчет makeUrl() — пока не знаю, где искать эту лшибку. Куча шаблонов

Еще ворнинги на деприкейтид:
PHP deprecated: Creation of dynamic property modX::$pdoTools is deprecated
PHP deprecated: Function strftime() is deprecated

Магазин обновил до последней версии. Правктически все ошибки — со страницы товара
Если не сложно, заодно подскажите, как в модх принято корректировать контрибный код? Что-то вроде патчей есть?

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

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

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

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

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

Спасибо за ответ.
Не очень хорошие новости, но как есть.

1. работает с 7.4. с php 8.0, minishop2 — не работает.
2. вроде тут можно посмотреть, но не уверен в актуальности данных: sitedash.app/extras
3. стабильной версии — нет. есть альфа версия только для тестов, вот github: github.com/modx-pro/MiniShop3
4. Из альтернатив для modx я знаю только платный плагин commerce — modmore.com/commerce/

Василий, что-то ты мудришь сильно. Давай по порядку.
Для начала все это не движ от 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 уже известен).

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

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

Это то понятно, но надо именно расширение унаследовать, то есть стандартные методы add, remove, status и т.д. просто вопрос заключался конкретно в том, как это правильно сделать для MODX3, в MODX2 проблем нет, там всё привычно, а новый MODX3 ещё не совсем понял, тип там движ от Symfony DB и Controllers, а как унаследовать? При обновлении не потрётся файл если я его расположу в /core/components/minishop3/src/Controllers/Cart/CartCustom.php c использованием use

Можно пример с использованием namespace? Типа такой:

<?php
use MiniShop3\MiniShop3;
\MiniShop3\MiniShop3\Cart::getLoader()->addPsr4('MiniShop3\MiniShop3\CartCustom\, $namespace['path'] . 'src/').
$this->modx->addPackage('MiniShop3\MiniShop3\CartCustom', $namespace['path'] . 'src/', null, 'MiniShop3\MiniShop3\');

Разумеется сразу после addPackage

И ещё смотрю системные настройки там, где обработчик Класс обработчик корзины ms3_cart_handler_class
msCartHandler
надо же сменить обработчик например на msCustomCartHandler правильно?

Так и говори, что только с помощью хака. Ибо в MODX не заложена возможность легального механизма подмены библиотеки ExtJS. Есть только нативное управление формами, но опять же через ExtJs.

Я, имея опыт работы с разными CMS и фреймворками, могу более менее объективно оценить MODX. Это просто инструмент для небольших сайтов, блогов и интернет-магазинов. Даже при среднем всплеске посещаемости у нас в компании он падал. Пришлось сильно его оптимизировать, чтобы он вывозил 2 млн. посещений в месяц. Иногда костылить.
Но могу твердо сказать, что он лучше вордпресса и на 10 голов выше сраного битрикса. Но тем не менее, нахваливать его я не собираюсь. И это никакой не негатив. Просто здравая реальная оценка. Каждый инструмент хорош в чем-то одном.

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

П.С. Было бы круто, если бы переписали админку на Vue. Не уверен, что это остановило бы падение популярности MODX. Но стало бы более удобно кастомизировать админскую часть.
Хотя как вариант можно админскую часть своего пакета сделать отдельно. Например, для минишопа свою админку запилить. Современную.

Ага, правда до vue и т.д. я пока не дорос, поэтому обхожусь чистым js

про vue и тд?

Как будто бы от extJS можно оставить только оболочку ( в ресурсе вкладку, на отдельной странице — шапку и сайдбар), а остальное делай как душе угодно. Во всяком случае я именно так и поступаю 😉

Василий, Складывать классы в каталог custom не обязательно лет уже 7 как. Еще с тех времен как Василий изготовил подключение служб. Кладешь в любой удобный каталог и указываешь путь к классу.
То же самое по идее и в MS3. Только тут уже нужно использовать namespace и use. Я подготовлю документацию в скором времени. Кроме того будет визуальная утилита подключения служб, вместо того чтобы в консоли команды запускать.

Подскажите пожалуйста, а где папочка /custom/ не могу понять, как унаследовать msCustomCartHandler, и как это сделать правильно?

Ранее в modx 2.8.8 и ms2:
/core/components/minishop2/custom/cart/msсartcustomhandler.class.php
В ms3 вижу контроллер корзины:
/core/components/minishop3/src/Controllers/Cart/Cart.php

Ещё msPre потом надо будет обновить, и уйму всего переписать после обновления modx с 2.8.8 на 3.1.2

Сам себе отвечу: так как FormIt умеет только прикреплять файл к письму, для чего он файл грузит во временную директорию, надо отдельным хуком переносить файл на сервер в постоянную папку, копировать полный путь и записывать этот путь в гугл таблицу. Спасибо Артуру Шевченко за решение: modx.pro/solutions/24933 У Артура Formit работает через его плагин SendIt.

@Сергей Шлоков

Ради древней админки?

Админка реально древняя.
Начинаешь что-то писать — и сразу осознаёшь, какой адский путь предстоит пройти, чтобы сделать одну-единственную страницу со списком и управлением.
И всё это — как в старые добрые времена с процессорами и extJs.
Руки опускаются, интерес моментально пропадает. 😅