Простое переключение на 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.
Руки опускаются, интерес моментально пропадает. 😅

Не заработало((
MODX 2.8.8

Сорян. Не хотел обидеть. И нет у меня никакого негатива )

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

Всё, что ты написал, можно уместить в одну фразу — работа ради работы. «Мне задонатили, я так и быть, что-нибудь сделаю, а там уж дальше сами, я этим пользоваться не буду, и поддерживать не буду, я просто отработал деньги».
Не знаю, насколько это честно.

Мне тоже за доработку pdoTools обещали финансовую мотивацию. Я мог бы взять деньги, выкатить продукт и отвалить. Но я посчитал честным отказаться, хотя деньги предложили достойные. Я физически не вытяну доведение до ума новой версии. И не хочу, чтобы мне потом предъявили.

Возможно у тебя есть свои планы на минишоп3, но если нет, то это просто способ заработать денюжку с неясным результатом. Что-то мне подсказывает, что никто после тебя не полезет в него и не будет его развивать. Но это чисто моё видение ситуации. Буду раз, если ошибаюсь )

Старая песня заиграла новыми словами! Раньше — лет 7-8 назад было так — магазины теперь никому не нужны, т.к. есть Instagram, соц. сети Wix и Tilda!))). Теперь пугают маркетплейсами — все оказывается туда перемещаются! Я работаю с сайтами-магазинами строительной тематики, где формируются большие, сложные и сборные заказы. Они никак в логистику маркетплейсов не укладываются. Сколько заказчики не пересказывали сказки про то, как сосед добавил объявление на АВИТО и «телефон оборвали» — ни один из них сайт не сократил и рекламу не сиквестировал. Наоборот есть такие, которые говорят — нужен сайт и Директ, задрали бабки с маркетплейсов, сканирующие сотни объявлений в поисках самого дешевого товара.

Так что овчинка не стоит выделки

Смотря что считать овчинкой. Я взял на себя обязательства в свое время, и считаю делом чести их выполнить. Кроме того ребята поддержали дело донатами, и тем более должны увидеть результат. А уж использовать его, или нет — каждый сам для себя решит.

Как только ты спроектируешь и реализуешь минишоп с использованием современных паттернов и инструментов в виде Fast Route, Eloquent, Phinx и т.д., ты поймешь, что MODX тебе уже не нужен. Зачем? Ради древней админки? А для оплат есть куча опенсорсных модулей. Имея композер можно насобирать любую конфигурацию )
Но проблема в том, что минишоп нужен только в MODX. Отдельно он не взлетит. Уже есть готовые раскрученные решения и с ними конкуренцию выиграть невозможно. Плюс спрос на личные интернет магазины заметно упал, так как все перемещаются на торговые площадки (озон, вайлдберис, яндекс, сбермаркет и т.д.). Так что овчинка не стоит выделки ¯\_(ツ)_/¯

П.С.
Кстати, еще в прошлом году на хабре видел бенчмарки роутеров. И симфоневый был быстрее ;)