Два дня проковырялся, пытаясь сделать по этому конфигу.
Один сайт сразу завелся, остальные вместо перехода на страницу редиректят на главную — чудо не иначе)

FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream или
FastCGI sent in stderr: "Access to the script '/var/www/os/data/www/os.org/4720-psi.html' has been denied (see security.limit_extensions)" while reading response header from upstream, upstream: "fastcgi://unix:/var/run/os.sock:"

да да, могу пообедать?

Хорошо бы до понедельника уже сделать… так что имей ввиду. Не планируй ничего на выходные

Обратил внимание, с радостью волью новый PR

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

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

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

Николай, отлично, спасибо большое. А правда, что планируется mSearch3? Интересно, будет ли mFilter3 с возможностью загрузки через AJAX при загрузке страницы? Уверен, это значительно ускорит загрузку страниц и повысит удобство работы в связке с seoFilter.

Вот удивительно, а почему например в YandexMarket2 поддерживается сразу MODX2 и MODX3, также как и cityFields, и другие модули… Ведь куда логичнее было бы сделать также с minishop2 и mSearch2.

Ну и пусть растут себе. Ветки 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