правда не работают дружественные url, конфигурации вроде верный, что ему не нравится

В логах по классике пусто, все страницы выбивают 404, локейшн вроде как прописал верно в NGINX, во всяком случае с isp это работало

решилось сменой владельца на www-data, от этого пользователя запускается php-fpm насколько это критично?

Я вообще не знаю, где класс Fenom находится

Ставлю бутылку))) Начинающему или среднем программисту до лампочи как там работает Fenom, там хрен разберешься (по себе знаю).
А вот вызов fenom, через чур усложнен, по этому хотя бы через Facade стоит прокинуть, как и многие другие сервисы.

Собственно Facade не требует ни какой дополнительно зависимости, mmxFenom уже устанавливает illuminate support где есть Facade

Короче)) пока modx не начнет вызываться вот так:

app()->getOption('site_name')

Ни какого прогресса не будет

Если есть хороший пример конфига — делись!

Конкретно в вашей конфигурации добиться того, чтобы файлы, генерируемые внутри контейнеров, редактировались на хост машине можно, понадобится всего 2 шага.
Первое.
в Dockerfile которые используется при создании образа для php-fpm добоавить строки,

RUN echo "root:root" | chpasswd
RUN useradd -m -p user -s /bin/bash user
USER user:user

Здесь мы задаем пароль root для пользователя root, а затем создаем пользователя с именем и группой user (можно любое). ОТ имени этого пользователя будут выполнятся все команды по умолчанию в контейнере, который будет запущен на основании этого образа. Это видно на скрине, что пользователь в контейнере user.

Но остается возможность, поскольку мы задади пароль для пользователя root переключиться и на него. Теперь когда будет выполнять код из вашего скрипта run-install файлы modx будут созданы уже не рутовым пользователем и смогут редактироваться снаружи.
Второе. Но есть еще проблема. В репозитории на гитхабе у вас изначально отсутствует директория modx, но она используется в docker-compose файле. Изза этого происходит следующее, при запуске docker compose up --build докер ищет директорию modx, не находит и создает ее. Но здесь очень важно, а где он ее создает. Так вот docker в таком случае создает диреторию modx ВНУТРИ контейнера и только потом прокидывает ее наружу. В таком случае директорию modx получается созданной пользователем root. Добавлю скриншот.

И получается, что наш пользователь user, который запустит команду установки modx не сможет ничего записать в директорию modx, которую он видит внутри своего контейнера. Но эту проблему легко решить, зная как именно работают неименованные volume в докере. Нужно чтобы пустая директория modx существовала в проекте перед тем, как будет выполнена команда docker compose up, в этом случае докер возьмет ее и примонтирует внутрь каждого контейнера и она (директория) не будет создана рутом. Наверное можно просто создать пустую диркторию, но я знаю что гит не позволяет помещать пустую директорию в отсеживаемую область, для чего используют пустой файл .gitkeep. Если modx умеет устанавливаться в НЕ пустую директорию то это будет решением. Если же не умеет (а скорее всего файл .gitkeep не позволит выполнить команду create project у composer) то директорию можно создавать во время выполнения run-rename, главное чтобы до запуска docker compose.

Все что написал, предварительно проерил и да, теперь у меня есть возможность редактировать код в директории modx и заработал админка. Не знаю по этой ли причине или нет, но это единственный вариант когда у меня открылась админка сайта на 8080 порту.

Так же напомню, что вам нужно еще подправить run-rename чтобы он делал копию env файла и переименовывал проект.
Обратил внимание, что при переименовнии проекта скриптом, нельзя использовать цифры. Причем сам скрипт об этом не предупредил и когда я в качестве имени указал alex-test2 то переименование произошло со сбоем. Что то стало называется alex-test2, а что то alex-test.

Контейнеризация есть
github.com/modxcms/revolution/commits/3.x/core/src/Revolution/Services/Container.php

Её и использовал для подключение Facade в 3 версии modx
github.com/webnitros/facade-app/blob/2fe0344f87806bead554ba8f91e1d3d1ad62bb7f/Extras/FacadeApp/core/components/FacadeApp/elements/plugins/FacadeApp.php#L47C52-L47C53

$modx->services # Все что в сервисах, это контейнеры modx 3

Проблема в другом

# Так буде работать
$modx->services->get('mmxFenom')->fetch($tpl, ['resources' => $resources]);

# Так нет
\MMX\Fenom\App::fetch($tpl, ['resources' => $resources]); 

# Если с Facade, это аналог: $modx->services->get('mmxFenom')->fetch($tpl, ['resources' => $resources])
\MMX\Fenom\Facade::fetch($tpl, ['resources' => $resources]);

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

Другой вариант контенеризации это сделать app() какой то, который будет обращаться к контенерам как будто
$modx->services->get('mmxFenom')

@Сергей Шлоков уже довольно давно, предлагал изменить getInstance,

// Здесь https://github.com/modxcms/revolution/blob/fe2df183eabfebfd66c2c6f2788f2b93c40d4d1b/core/src/Revolution/modX.php#L410
 // Это  
$class = __CLASS__; 
# заменяем на это
$class = class_exists($id) ? $id : __CLASS__;

и тогда можно обращаться вот так:

modX::getInstance('modX')->getOption('site_name');

Кстати, где возможно, в свои проекты внедрил эту практику, работает отлично, без контейнеризации. Я не оценивал последствия, если это сделать стандартной сборке MODX 3 или 2, может там будут проблемы с процессорами. Но эта практика modX::getInstance('modX'), как и с Facade, упрощает написание кода.

Тогда можно будет сделать вот так

\MMX\Fenom\App::fetchNew($tpl, ['resources' => $resources]); 
Или вот так
\MMX\Fenom\App::instance()->fetch($tpl, ['resources' => $resources]);

Незнаю, может это не стоит считать проблемой, и вы и не планировали, что файлы в директории modx нуждаются в редактировании, но все же…

Именно так, да. Тем более, что настроить это сразу универсально никак не получится. Если есть хороший пример конфига — делись!

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

А я использую в production образы и хост одной и той же системы — Ubuntu (Debian), поэтому всё работает от одного юзера www-data. А на локальной MacOS проблемы с правами и вовсе нет.

Ну а кстати, зачем я вообще полез править файлы в modx. Админка тупо выдает белый экран. Главная страница сайта открывается, а никакие танцы с бубнами вокруг админки пока не помогли.

Скорее всего, MODX просто не может создать директорию с кэшем из-за прав, да.

Решил ознакомится поближе, вижу вы активно снимаете и выкладываете видео на канале, а это очень подкупает.

Спасибо на добром слове, планирую продолжать!

@Aleksandr Huz еще раз огромное спасибо, дополнение офигенное! Единственное, с чем столкнулся – у меня как-то криво работает сортировка drag-n-drop'ом при заполнении Таблиц контентом. Начинаешь перетаскивать – появляется зеленая галочка (1 selected row) — индикатор, что можно тащить. Но сортировка либо вообще не срабатывает, либо перетаскивается куда-то не туда (непредсказуемо, через раз).
Это какой-то known bug? Есть шанс что починишь или мне искать обходной путь?
В доке не нашел подробностей, как будто бы должно работать сразу из коробки.
MODX 2.8.6
pageblocks-1.0.0-pl

Не подскажете, есть ли способ переопределить эти методы minishop2.class? Про переопределение методов msorderhandler видел, а про minishop2.class не нашел

Привет из будущего! Ошибка все еще присутствует при удалении пользователя. Но пользователь все же удаляется.

[2024-05-10 00:22:10] (ERROR @ .../core/xpdo/xpdo.class.php : 1322) Could not get table class for class: modAccess
[2024-05-10 00:22:10] (ERROR @ .../core/xpdo/xpdo.class.php : 1291) Could not get table name for class: modAccess
[2024-05-10 00:22:10] (ERROR @ .../core/xpdo/om/xpdoobject.class.php : 240) Error 42000 executing statement: 
Array
(
    [0] => 42000
    [1] => 1064
    [2] => You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'AS `modAccess` WHERE `modAccess`.`principal` = 249' at line 1
)

Тоесть я так понял, что в modx3 так и не завезли никакого контейнера зависимостей и нормальной автоматической иньекции зависимостей? Я помню когда только шли обсуждения что выйдет modx3 говорили что будет применена какая то там библиотека для контейнера зависимостей. Я еще возмущался, почему не phpDi, а мне сказали что та библиотека даже более крутая.
А судя по вашему коду, сервисы все еще из $modx достаются? Печально.
Честно говоря, тоже не люблю фасады и не пользуюсь ими и в ларавель. Выглядит как сотый уровень абстракции над абстракцией, без которой вполне можно обойтись. Лучшее враг хорошего, хотя это лично мое мнение.

Решил ознакомится поближе, вижу вы активно снимаете и выкладываете видео на канале, а это очень подкупает.
Стало интересно, как вы решаете те проблемы, с которыми я сталкиваюсь при работе с докером и к сожалению сразу же споткнулся об эти же грабли.
Инсталирую mmx-app как вы указываете в видео. И при таком подходе весь код из директории modx недоступен для редактирования из хостовой машины. Проблема очевидная, ожидаемая и связанная с тем что инсталяция modx происходит внутри контейнера а там пользователь root. И соответственно все файлы которые мы видим в volume тоже может редактировать только root.


Незнаю, может это не стоит считать проблемой, и вы и не планировали, что файлы в директории modx нуждаются в редактировании, но все же…
Я для себя решил эту проблему тем, что описывая докерфайл создаю там сразу нерутового пользователя и запускаю контнейнер от его имени. В таком случае файлы, созданные от имени этого пользователя монтируются «наружу» с именем пользователя на хостовой системе, что очень удобно.
Ну а кстати, зачем я вообще полез править файлы в modx. Админка тупо выдает белый экран. Главная страница сайта открывается, а никакие танцы с бубнами вокруг админки пока не помогли.

extras.modx.com/package/pageblocks

Почему этот компонент перестал существовать?

Только считает стоимость.

Да, там был полный бардак с датами — сейчас привёл в порядок и написал тесты для проверки.

Обновляйся на версию 1.2.1

И еще не понятно — компонент только считает стоимость доставки или еще и отправляет заказы в ЛК СДЭКа?

Ты проверил все шаблоны и чанки?

Обычно при очистке кеша красным выводятся все дубли.