Наумов Алексей

Просто логически зачем внутрь Главной вложен Каталог? Это не имеет смысла, только приводит к ненужным сложностям.

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

Какое-то условие не срабатывает.
Вот тут значит данные получаются для дерева.

Стоит проверить такие вещи:
— Каталог находится внутри Главная;
— is_folder у ресурсов
— show_in_tree галочку
может еще что-то

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

а разве это зависит не от системной настройки, которая включает транслит названий файлов?
translit не грешит таким поведением?..

Да без проблем!

Сделайте некий сайт, назовите его api.ДОМЕН.ru, залейте туда базу данных своих авто и любой значит скрипт туда добавьте, чтобы он мог в json вывести данные по машинам, например:
/cars — список авто
/cars/123 — информация по машине с id 123
и т.д.

а на основных сайтах получайте данные уже… а чтобы это хорошо и быстро работало — данные в кеш modx сохраняйте, на сутки там к примеру. В этом случае не будет постоянных запросов к api, сайты будут работать быстро.

Ииии ни одного комментария на большую публикацию, и ни одного плюсика) а я поставлю!

С чего вы взяли то что он вышел?)))

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

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

Кстати, не разбирался, но заметил 2 нюанса с датами:
1. часовые пояса нужно как-то настроить… как?..
2. Теряется время! У unpub_date в базе 100% время прописано.

Вот пример данных, которые mmxDatabase мне выдал в модели:

"pub_date": "1969-12-31T21:00:00.000000Z",
"unpub_date": "2024-07-31T21:00:00.000000Z",

А вот то, что выдает $resource->toArray():

[pub_date] => 0
[unpub_date] => 2024-08-01 11:02:06

У дат видно смещение на 3 часа (московский часовой пояс в modx установлен), а у unpub_date время потерялось… осталась только дата.

Я тоже пересмотрел, не до конца понял профит (сокращение кол-ва подписей к объектам?).

Зато увидел усложнение, в виде накрутки над классом фасада, который еще сильнее усложнит жизнь).

А может у меня проекты такие, где это не нужно, не знаю)

За поддержку php 7.4 все ж спасибо! Как я писал в комментарии к прошлой заметке, я запустил mmxDatabase в связке с сайтом на modx 2.8.5, что оказалось очень удобно для одной из текущих задач (а именно выгрузка всего контента сайта в формате json для переноса данных на другую платформу). с mmxDatabase это решается очень быстро!

Кстати, если кому интересно, mmxDatabase вроде как можно запустить и на MODX 2.x.

Сначала в консоли делаем так:

composer require mmx/database

выполнять команду install не стоит, всё равно ж не получится.

а затем уже в php вот так:

require_once dirname(__FILE__) . '/vendor/autoload.php';
class_alias(\modX::class, 'MODX\\Revolution\\modX');
$mmxDatabase = new MMX\Database\App($modx);

и можно работать:

$resource = \MMX\Database\Models\Resource::find(1);
print_r($resource->toArray());

Слишком общий вопрос, нет волшебных решений.

Что значит у нас много опций, 20 штук? Как вы по ним хотите похожие товары искать?

Вот я к примеру делал так: мне в разделе «Стабилизатор напряжения» в карточке товара нужно вывести 12 похожих товаров, критерии такие:
1. Соответствуют количеству фаз
2. Близкая мощность, плюс минус 20%
3. Близкая цена, плюс минус 30%

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

Самое лучшее решение в данной ситуации — это сделать отдельный файл для работы с этим API, например:

/assets/components/mycomponent/api.php

ну или просто попроще

/api.php

внутри этого файла инициализируем MODX в API режиме, читаем, например:
modx.pro/development/3163

А далее просто получаем данные, как нам нужно и выводим в json:

$query = $modx->newQuery('modResource');
$query->where([
'parent' => 2,
]);

$resources = $modx->getIterator('modResource', $query);
$data = [];
foreach($resources as $resource) {
$data[] = [
'pagetitle' => $resource->get('pagetitle');
];
}

header("Content-Type: application/json");
echo json_encode($data);
exit();

да, если нужны TV поля, то запрос будет сложнее. Но эта информация тоже есть на форуме.
Если уж совсем лень писать запрос — то можно внутри скрипта вызвать сниппет pdoresources:

$data = $modx->runSnippet('pdoResources', [ПАРАМЕТРЫ]);

$_modx->resource['tv-name']

Или в чанках где-то внутри pdoResources

$_pls['tv-name']

но лучше избегать дефис в названиях TV. Дефис нельзя использовать в названиях переменных в php, из-за этого возникают трудности в Fenom. Замените на подчеркивание.

Я всегда делаю так:
В корневой директории сайта

/home/user/data/www/modx.test.ru/

создаю папкуgo

Extras/Scheduler/

и уже в нее кидаю содержимое репозитория.

Этот подход предлагает modExtra (см. readme) github.com/modx-pro/modExtra

Конечно и другие подходы есть к разработке, но я предпочитаю этот)

Когда идет разработка, то обычно исходники пакета лежат примерно по такому пути:

/Extras/ModxExtraName/

поэтому не совсем понимаю, зачем еще 1 уровень вложенности добавлять.

Перенесу и свой ответ тогда уж!:

пару месяцев назад я переписал это всё… сейчас по другому, в github код доступен. Можно даже PR сделать!

Интересная мысль насчет целесообразности создания сессий для ботов… в принципе может они и не нужны… как вариант можно добавить соответствующую настройку в компонент. В общем мысль сохранил.

так если про smartSessions вопрос — то я пару месяцев назад переписал это всё… сейчас по другому, в github код доступен. Можно даже PR сделать! и да, если еще вопросы будут — давай переедем в соседнюю тему, чтобы Володю не дергать)