Андрей Степаненко

Походу твое решение спустя 4 года все такие стало актуальным

github.com/modxcms/revolution/pull/16571#pullrequestreview-2061133420

Только для linux (не mac)
На linux два вариант работы)))
— Либо работаешь под root
— Либо настраиваешь www-data пользователя и под ним работаешь

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

@Александр Мельник думаю что папка modx не под root, это на хост машина так файлы и папки выглядит))) Они на самом деле под пользователем id которого, отсутствует на хост-машине

нужно зайти в контейнер с php-fpm и посмотреть id пользователя внутри контенер, и создать такого же пользователя у себя

id

Еще вариант
Как еще можно указать под каким пользователем будет работать контейнер
github.com/webnitros/facade-app/blob/bcc07c7a823afb70d129fd246471472a698b2ebf/docker-compose.yml#L22

services:
  app:
    image: 'webnitros/modx-app:latest'
    env_file:
      - ./.env # variables from the env file are exported when the container starts
    user: '82:82'

Но опять же это не поможет сильно)) Есть nginx, который все равно будет под www-data создавать файлы)))
В общем беда на linux по работе с docker)))

Отправил коммит, пока что для улучшения контейнеризации
github.com/modxcms/revolution/pull/16569

Дальше уже можно будет чем то другим обвешивать

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

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

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

app()->getOption('site_name')

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

Контейнеризация есть
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 в обе версии интегрировать эти фасады, можно было бы добиться какого-то моста между версиями для совместимости других дополнений.

К примеру вызов того же pdotools в версии modx 2 сделать по максимум чтобы все вызывалось через Facade
Тогда при установке на modx 3 этого компонента, была бы обратная совместимость. Опять же не прям всех классов и функций, но таких которые являются базовыми (наивное предположение конечно же))).

Нашел альтернативное решение для написания комментариев к функциям, чтобы можно было в два клика добраться до неё.

Для modx @see \modX::getOption

<?php
namespace FacadeApp\Facades;
use Illuminate\Support\Facades\Facade;
/**
 * @method static mixed getOption($key, $options = null, $default = null, $skipEmpty = false)
 * @see \modX::getOption
 * @see modX
 */
class ModX extends Facade
{
    protected static function getFacadeAccessor(): string
    {
        return 'modx';
    }
}

Для pdoTools @see \pdoTools::getChunk

<?php
namespace FacadeApp\Facades;

use Illuminate\Support\Facades\Facade;

/**
 * @method static string getChunk($name = '', array $properties = array(), $fastMode = false)
 * @see \pdoTools::getChunk
 * @see modX
 */
class Pdo extends Facade
{
    protected static function getFacadeAccessor(): string
    {
        return 'modx';
    }
}

Cобрал пакеn по старинке через modExtra
Github: github.com/webnitros/facade-app

На модерацию уже отправил в modstore

Кому интересно, disk.yandex.ru/d/EtmO2tOPCYC6xA

Работает как в Modx 2 так и в 3 версии
Проверил на обоих версиях, одинаково отрабатывает код

# modx 2 и 3 запуск одинаковый
$site = \FacadeApp\Facades\ModX::getOption('site_name');

echo '<pre>';
print_r($site);
die;

С composer все еще могут возникать проблемы совместимости.

Еще событие добавил FacadeAppAddSingleton чтобы свои фасады можно было добавить github.com/webnitros/facade-app/blob/master/FACADE.md

Проблема, вероятно, связана с тем, что вы используете неправильные переменные для формирования путей к CSS и JS файлам. В вашем коде вы обращаетесь к переменным `jsUrl` и `cssUrl` в свойстве `config` вашего объекта `xmlReader`. По умолчанию, эти переменные должны содержать относительные пути к JS и CSS файлам относительно корня сайта.

Однако, поскольку пути формируются неправильно и указывают на абсолютные пути на сервере, вам нужно убедиться, что переменные `jsUrl` и `cssUrl` в вашем объекте `xmlReader` правильно сконфигурированы. Возможно, они вам неправильно заданы в конфигурационном файле или в другом месте, откуда вы получаете этот объект.

Если переменные `jsUrl` и `cssUrl` должны содержать абсолютные пути, вы можете изменить их в вашем объекте `xmlReader` таким образом, чтобы они содержали правильные абсолютные пути к вашим JS и CSS файлам.

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

спасибо за ответ, сначала поверить не смог что modx 3 это сделано.

Проблема в том что в статье, я еще пару файлов подключал, что лишним было
Как раз про это писал что в modx 3 плохо разобрался.

Вспомнил про контракты.
Кто то все такие реализовал полноценную контейнеризацию ))
github.com/modxcms/revolution/commits/3.x/core/src/Revolution/Services/Container.php

Респект))))

@Василий Наумкин подскажи плиз, Facades из коробки получается работают в modx 3?

core/src/Facades/Fenom.php

<?php
namespace MODX\Facades;

use Illuminate\Support\Facades\Facade;
use MMX\Fenom\App;

/**
 * @method static void addModifier(string $modifier, callable $callback)
 * @method static void fetch($template, array $vars = [])
 * @see App
 */
class Fenom extends Facade
{
    protected static function getFacadeAccessor(): string
    {
        return 'mmxFenom';
    }
}

Для запуска

<?php

use Illuminate\Support\Facades\Facade;
define('MODX_API_MODE', true);
require 'index.php';


Facade::clearResolvedInstances();
Facade::setFacadeApplication($modx->services);

echo \MODX\Facades\Fenom::fetch('file:chunks/test.tpl', ['name' => 'Hello']);

Отлично, у $modx->services еще контракты подходящие

$modx->services->add('fenom', function (use $modx) {
    return $modx->services->get('mmxFenom');
});
Facade::clearResolvedInstances();
Facade::setFacadeApplication($modx->services);

echo \MODX\Facades\Fenom::fetch('file:chunks/test.tpl', ['name' => 'Hello']);

Записал видео, 12 минутное
Разобрал более подробней работу Facade
Несколько вариантов представил для сравнения

Понимаю
Есть такое
По этому в конце комментариев See оставляется

use MMX\Fenom\App;

/**
 * @method static void addModifier(string $modifier, callable $callback)
 * @method static void fetch($template, array $vars = [])
 * @see \MMX\Fenom\App
 */

То же раздражала навигация.

Спустя какое-то время понял, как ориентироваться, привыкаешь к этому, после того как запомнишь, как функция вызывается и что она делает.

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

По тестировал, на modhost.pro
попробуй вот так сделать:

wget https://raw.githubusercontent.com/modxcms/revolution/v3.0.5-pl/composer.json
composer install
composer require mmx/fenom --update-no-dev

будет ругаться на зависимости

Удаление core/vendor и composer.lock обязателен получается.
И затем установка

wget https://raw.githubusercontent.com/modxcms/revolution/v3.0.5-pl/composer.json
composer require mmx/fenom --update-no-dev

Либо вариант, проблемы с зависимостями в ручную разруливать: modx.pro/development/24702#comment-143093

изначально делал так

wget raw.githubusercontent.com/modxcms/revolution/v3.0.4-pl/composer.json
composer install
composer require mmx/fenom

Получал ошибку modx.pro/development/24702#comment-143091

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

Удалил composer.lock и core/vendor

сразу выполнил команду

composer require mmx/fenom

все установилось

Update:
кроме самого пакета mmx/fenom (перепутал))) сначала подумал что он то же установился
при повторе, опять ошибка не совместимости
composer require mmx/fenom

php 7.4 не установился

пробывал с:
wget raw.githubusercontent.com/modxcms/revolution/v3.0.4-pl/composer.json
wget raw.githubusercontent.com/modxcms/revolution/v3.0.5-pl/composer.json

composer require mmx/fenom
./composer.json has been updated
Running composer update mmx/fenom
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - illuminate/container[v8.0.0, ..., 8.x-dev] require psr/container ^1.0 -> found psr/container[1.0.0, ..., 1.x-dev] but the package is fixed to 2.0.2 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - illuminate/events[v10.47.0, ..., 10.x-dev] require php ^8.1 -> your php version (7.4.33) does not satisfy that requirement.
    - mmx/database[1.1.0, ..., 1.2.0] require illuminate/events ^v8.83|^v10.47 -> satisfiable by illuminate/events[v8.83.0, ..., 8.x-dev, v10.47.0, ..., 10.x-dev].
    - mmx/fenom[dev-main, 1.0.0] require mmx/database ^1.1 -> satisfiable by mmx/database[1.1.0, 1.1.1, 1.2.0].
    - illuminate/events[v8.83.0, ..., 8.x-dev] require illuminate/container ^8.0 -> satisfiable by illuminate/container[v8.0.0, ..., 8.x-dev].
    - Root composer.json requires mmx/fenom * -> satisfiable by mmx/fenom[dev-main, 1.0.0, 9999999-dev].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
You can also try re-running composer require with an explicit version constraint, e.g. "composer require mmx/fenom:*" to figure out if any version is installable, or "composer require mmx/fenom:^2.1" if you know which you need.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.
bash-5.1$ php -v
PHP 7.4.33 (cli) (built: Nov 12 2022 05:16:49) ( NTS )
Copyright © The PHP Group
Zend Engine v3.4.0, Copyright © Zend Technologies

С расположение пакетов это одна из проблем которую на мой взгляд нормально не решишь, всегда на измене что то то можешь затереть
По этому и придумал схему с :ro который защищает файл в Extras
Хоть сколько раз переустанавливай свой пакет
Если нужен собранный пакет то он будет в target в сборке с docker

Последние попытки запуска как раз и были связаны с WSL, Docker завершался с ошибкой и все.

Для отключения WSL
C:\Users\\AppData\Roaming\Docker\settings.json
«wslEngineEnabled»: false

И после этого docker запуститься. Ура)