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

{set $parent_id = $_modx->resource.parent} 
{set $grand_parent_id = $parent_id | resource : 'parent'} 
{$grand_parent_id | resource : 'pagetitle'}

чем ответ не устроил? Или чисто к словую smarty претензия?

Чтобы вызвать метод `getService` в наследуемом классе в MODX Revolution 2.8.3-pl, нужно использовать объект `$this->modx`. В вашем случае, чтобы воспользоваться функциями из другого компонента в обработчике корзины, можно сделать это следующим образом:

<?php
class msCartCustomHandler extends msCartHandler {
    public function __construct(modX & $modx, array $config = array()) {
        parent::__construct($modx, $config);
        // Ваш код инициализации здесь
    }

    public function someMethod() {
        // Пример вызова метода getService
        $myService = $this->modx->getService('myComponent', 'MyComponent', $this->modx->getOption('myComponent.core_path', null, $this->modx->getOption('core_path').'components/myComponent/').'model/myComponent/');
        
        if ($myService instanceof MyComponent) {
            // Использование методов компонента
            $myService->someComponentMethod();
        }
    }
}
?>

1. **Инициализация класса**: В конструкторе класса `msCartCustomHandler` вызывается конструктор родительского класса `msCartHandler`, чтобы корректно инициализировать объект.
2. **Вызов `getService`**: В методе `someMethod` происходит вызов `getService`, который загружает и инициализирует необходимый компонент (в данном примере `myComponent`).
3. **Проверка и использование**: Проверяется, что возвращаемое значение действительно является экземпляром необходимого класса компонента, после чего можно использовать методы этого компонента.

Этот подход позволяет вам гибко использовать функциональность различных компонентов MODX в вашем наследуемом классе.

Ваша проблема связана с неправильным переключением контекстов в MODX. Убедитесь, что ваш .htaccess и скрипт роутинга правильно настроены для работы с Babel. Давайте рассмотрим основные моменты.

### .htaccess

В файле .htaccess у вас всё верно настроено для переадресации запросов на index.php с соответствующим `cultureKey` и `q`. Однако, убедитесь, что у вас есть следующие строки в начале файла:

```apache
RewriteEngine On
RewriteBase /
```

### Роутинг

Ваш скрипт переключения контекстов выглядит правильно, но добавьте дополнительную обработку для других языков и `cultureKey`. Также убедитесь, что у вас есть все необходимые контексты в MODX.

### Пример улучшенного роутинга

```php
<?php
if ($modx->context->get('key') != «mgr») {
$allowedLanguages = ['en', 'ua', 'ru', 'fr', 'de'];
$cultureKey = isset($_REQUEST['cultureKey'])? $_REQUEST['cultureKey']: 'en';

if (in_array($cultureKey, $allowedLanguages)) {
$modx->switchContext($cultureKey);
} else {
$modx->switchContext('web');
}

unset($_GET['cultureKey']);
}
```

### Проверка контекстов и ресурсов

1. Убедитесь, что контексты `en`, `ua`, `ru`, `fr`, `de` существуют в системе.
2. Проверьте, что ресурс `franchiza` существует в каждом контексте и имеет одинаковый alias.
3. Перейдите в менеджер ресурсов и убедитесь, что все ресурсы переведены и имеют правильные alias.

### Дополнительные настройки Babel

Убедитесь, что Babel правильно настроен для всех контекстов:

1. Перейдите в «Системные настройки» -> Babel.
2. Проверьте значения настройки `babel.contextKeys` (ключи всех контекстов, разделенные запятыми).

### Пример настройки Babel

```plaintext
babel.contextKeys = en,ua,ru,fr,de
```

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

Для получения данных родителя на странице товара в шаблоне `product.tpl` с использованием Fenom, вы можете использовать следующий код:

{set $parent_id = $_modx->resource.parent} 
{set $grand_parent_id = $parent_id | resource : 'parent'} 
{$grand_parent_id | resource : 'pagetitle'}

Данный код выполняет следующие действия:
1. Получает ID родителя текущего ресурса.
2. Использует этот ID для получения ID «дедушки» (родителя родителя).
3. Выводит заголовок страницы «дедушки» по его ID.

Этот способ достаточно прост и позволяет получить необходимые данные без использования дополнительных сниппетов.

Если у вас есть вопросы или нужна дополнительная информация, пожалуйста, обращайтесь.

Походу твое решение спустя 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