Ну так они у тебя такие же будут если ты не будешь использовать дополнение

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

Мне кажется самое оптимальное это сделать просто tv поле с рейтингом у карточек.

Так ты сделай нормальное composer дополнение для MODX — и пусть его себе ставит кто хочет, вместе с остальными mmx-дополнениями. Древний транспортный пакет тут совсем ни к чему.

Есть же заготовка — просто используй.

@Prihod есть нюанс в путях… если сначала разрабатываешь на винде а потом нужно переносить на *nix сервера то слеши смотрят не в ту сторону… приходится сначала пробегаться по базе

UPDATE 
	modx_site_templates 
SET 
	static_file = REPLACE ( static_file, '\\', '\/' );

UPDATE 
	modx_site_htmlsnippets 
SET 
	static_file = REPLACE ( static_file, '\\', '\/' );

UPDATE 
	modx_site_snippets 
SET 
	static_file = REPLACE ( static_file, '\\', '\/' );

может сразу не обращать внимание на пути ОС?

привет, работает с MODX 3?

Я для себя нашел решение, такое как описал для Василия. Я не использую образу напрямую из dockerhub, а строю свои образы на их основании. Это позволяет добавить в контейнер своего пользователя, настроить его привелегии и избежать проблем с правами на файлы, генерируемые внутри контейнера.
А как например работает вы? Вот самый простой пример, нужно запутсить ларавель в контейнерах. По умолчанию считаем (и я всегда придерживаюсь этого правила и на своей локальной машине и на серверах), что раз я использую докер, то значит никаких локально установленных программ не должно быть. Тоесть на нашем компьютере нет своего php, нет своей node или nginx, нет redis и прочих mariadb. Мы запускаем php-fpm контейнер, в нутри которого проброшена директория с файлами laravel. Вам нужно выполнить команду в artisan. Напоминаю, что выполнить локально php artisan мы не можем, у нас просто нет php на машине. Значит нам нужно войти в php-fpm контейнер и там выполнить php artisan make model. Файл будет создан, появится у вас локально в редакторе кода, но редактировать вы его не сможете, потому что он создан пользователем root внутри php-fpm. При такой конфигурации, когда генерация файла происходит «изнутри наружу» и не продуманы заранее эти проблемы с правами, вы не сможете работать с кодом, генерируемым artisan, но если вы создадите файл модели в редакторе вручную, то он будет создан наоборот, «снаружи внутрь» и такой файл будет работать правильно.
В общем да, докер жутко неидеальный инструмент. И не простой. Его осознанное использование требует высоких навыков системного администрирования линукс серверов, глубоких знаних в работе компьютерных сетей (попробуйте ради интереса получить ip адрес пользователя внутри php запущенного внутри docker compose).
А лично моя проблема, которая доставляет массу неприятностей в работе, в том что я перфекционист в требованиях к себе. Я не могу пользоваться технологией, пока не разберусь в ней хотя бы на 4- из 5. Искренне завидую тем людям (без иронии), которые умеют просто пойти нагуглить функцию на стекоферфлов и даже не читая ее вставлять в свой код. Или же которые просят какой то там ИИ написать решение. Я не могу) Поэтому приходится дотошно ночами экспериментировать с технологиями, но мне нравится.

Вот кстати насчет того, что я не любитель магии в программировании. Василий в своих полезных видео рассказывает много интересного, но помоему сейчас его уводит в стороны рассказ о том как работать с eloquent и vesp, последние видео очень мало связаны с modx.
было бы очень позновательно, если бы вы Василий сделали отступление и рассказали, а как именно код нашего приложения интегрируется и попадает внутрь modx. Для меня например был неприятен момент, когда я редактирую PHP код компонента в директории для этого преднозначенной, это сразу отражается в работе сайта. Да это удобно и полезно, но это НЕЛОГИЧНО. Я ведь видел что проищошла инсталяция нашего приложения через composer а значит весь исходный код должен был переместиться в директорию vendor внутри modx а значит никакие изменения теперь не должны влиять. Ведь так? А влияют. Приятно, но НЕНАВИЖУ МАГИЮ. И приходится построчно изучать все инсталяционные скрипты, докер конфигурации, команды symfony console чтобы понять, откуда магия. И найти что вы так очень хитро манирулируете с симлинками. (кстати почти уверен что будут проблемы при переносе приложения из одной директорию в другую, поскольку симлинки в linux создаются с абсолютными путями). Или тот же фронтенд. Тоже небольшая магия, правишь код уже инсталированного composer приложения а он сразу меняется. Правда от этого гадостного современного фронтенда ты уже морально ожидаешь такого подвоха и ты уже удивляешься меньше чем с php. Но снова приходится искать в коде, что вы подменяете ссылки на подключение скриптов. Так же очень неочевиден роутинг. Я пока только мельком взгялнул и пришел к выводу, что теперь в системе есть аж 3 разных роутера. Прежде всего сам modx стороит свой роутинг на основании неймспейсов компонентов. Потом vue строит свой роутинг, для фронтенда. И потом vesp имеет свою роутинг, на основании slim и наверное fastroute. И есть очень много таких подводных камней. Я не говорю что они сделаны плохо или что я могу лучше, нет. Я просто считают что прежде всего нужно рассказать в видео именно о таких вещах, детально рассмотреть как именно встраивается ваше приложение внутрь modx. А то сейчас вы описываете в видео создание псевдо магазина и это инересно, но это совсем не про modx, а про vue, bootstarp-vue, vesp и так далее. И кстати. а как вам удалсь избежать проблем с несколькими реализациями psr-7? Мельком глянул код и увидел что modx использует реализацию от guzzle, а вы slim овскую. (кстати считаю что слимовская правильный выбор, это наиболее точная реализация стандарта). Ведь теперь в системе есть два класса реализующий один и тот же интерфейс и нельзя будет где то запрашивать иньекцю зависимости по интерфейсу. Хотя может в 3 modx и нет такой возможности.
В общем, буду благодарен если в одном из следующих видео Василй расскажет детально про магию. В том числе как планируется работать с миграциями, сейчас насколько я понимаю выполнить миграции можно только при установке компонента.

К сожалению документация не полная и купить полную версию не получится( Не могу разобраться, как ресайзить изображения, как использовать webp. Буду крайне признателен, если поможете. Я установил pthumb но не знаю как связать их.

Только для 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)))

Да, сортировка должна работать. Проверю и исправлю

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

Я в своё время его спросил, нафига добавлять контейнер Pimple, разработка и поддержка которого прекращена? Почему не взять развивающийся и более навороченный PHP-DI? Насколько я помню, он ответил какую-то чушь в стиле — зато легкая, а нам больше и не нужно. Даже Марк тогда присоединился к моему вопросу. Но Джейсон сказал, что переделывать он ничего не будет. Это было ещё до выпуска релиза MODX3, когда можно было хорошо почистить легаси.

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

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

server
{
	server_name 5.35.87.177 www.5.35.87.177;
	charset off;
	ssi on;
	index index.php index.html;
	disable_symlinks if_not_owner from=$root_path;
	access_log /var/www/httpd-logs/5.35.87.177.access.log;
	error_log /var/www/httpd-logs/5.35.87.177.error.log notice;
	set $root_path /var/www/5.35.87.177;
	root $root_path;
	gzip on;
    gzip_comp_level 5;
    gzip_disable "msie6";
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml;


	location @modx-rewrite {
        rewrite ^/(.*)$ /index.php?q=$1&$args last;
    }
	
	location / {
		location ~ [^/]\.ph(p\d*|tml)$ {
			try_files /does_not_exists @php;
		}
		location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf|webp|woff|woff2)$ {
			expires 24h;
		}
		try_files $uri $uri/ @modx-rewrite;
	}
	
	location @php
	{
		fastcgi_index index.php;
		fastcgi_ignore_client_abort on;
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
		fastcgi_split_path_info ^((?U).+\.ph(?:p\d*|tml))(/?.+)$;
		try_files $uri =404;
		include fastcgi_params;
	}
	listen 5.35.87.177:80;
}

так заработало, может кому полезно будет

правда не работают дружественные 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]);