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

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

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

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

За поддержку 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 сделать! и да, если еще вопросы будут — давай переедем в соседнюю тему, чтобы Володю не дергать)

Да, в свои js скрипты добавить данный код, внутри функции разместить код от яндекс.метрики. Ну а для отслеживания конкретной формы нужно выяснить, к примеру, её id, который должен присутствовать где-то в response. Я предпочитаю к форме добавлять data атрибут, наподобие:

<form data-goal="feedback">

Пожалуй отвечу:
добавить обработчик на событие «fetchit:success»
docs.modx.pro/components/fetchit/frontend/events

document.addEventListener('fetchit:success', (e) => {
    const { response } = e.detail;

    // Посмотреть данные response
    // console.log(response);
})

Как бы я поступил:

создал компонент (на базе modExtra), чтобы быстро, где будет по сути 1 объект Услуга (header, alias, description, seo_title/seo_description, а также полем parent_id для вложенности).
Свой интерфейс для управления ими будет поудобнее, чем MIGX. Чуть подумать, чтобы интерфейс выглядел симпатично и понятно (больше всего вопросов по отображению услуга/подуслуга).

Да, можно конечно поставить fastRoute или VirtualPages, но т.к. уровень вложенности не большой, то в целом все решается не самым сложным плагином на OnPageNotFound.
Чуть сложнее, если нужно ряд услуг скрыть для определенных моделей авто…

Кстати, VirtualPages у меня трудится на одном проекте уже много лет стабильно:)

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

0. на фронте добавляем поле для выбора ширины или ввода его вручную

1. Создадим плагин на событие msopOnAfterGetCost

if ($modx->event->name == 'msopOnAfterGetCost') {
    $isGetModificationAction = (isset($_REQUEST['action']) && $_REQUEST['action'] == "modification/get");
    $isCartAddAction = (isset($_REQUEST['ms2_action']) && $_REQUEST['ms2_action'] == "cart/add");
    
    // Обрабатываем только ajax запросы, в которых компонент msOptionsPrice2 отдает цену
    // Есть альтарнативный способ: проверять $_REQUEST['ms2_action'] !== cart/add
    if($isGetModificationAction || $isCartAddAction) {
    // здесь наш основной код
    // доступна переменная $modification
    // если пользователь выбрал определенную модификацию и у нее есть цена, то берем данные из нее
    if($modification['id']) {
    } else {
        // нет модификации, соответствующей переданным параметрам...
        // нужно высчитать цену, исходя из ширины вашего товара
        // ...
        // а вот тут мы вернем цену
        $modx->event->returnedValues['cost'] = ???;
    }
    
    
    }
}

2.

Временный фикс:

Cниппет ms_CDEK2

1. Одну строку комментируем, новую добавляем:

//$modx->regClientScript('https://www.cdek.ru/website/edostavka/template/js/widjet.js');
$modx->regClientScript('https://cdn.jsdelivr.net/gh/cdek-it/widget@2.5.5/widget/widjet.js');

2. Еще одну строку ниже комментируем, а новую добавляем:

//path: "https://www.cdek.ru/website/edostavka/template/scripts/",
path: "https://cdn.jsdelivr.net/gh/cdek-it/widget@2.5.5/widget/scripts/",

Нужно отлаживать… добавьте debugger перед этим if, и нужно посмотреть что приходит в responseData? Есть там row? Есть в этом row id? Может различия в версиях miniShop2…

например, не так давно я работал с каким-то сайтом на хостинге, и хоть сайт был под php 7.4, но если я просто в консоли (из под ssh, или через веб-интерфейс хостинга) вызывал этот самый php, то запускался php 5.3.

Есть ли какие-то ограничения со стороны хостинга для запуска composer из php?
Я к тому, что пакет это делает… но не будет ли на некоторых хостингах это запрещено?

Привет! Молодец, как всегда)
mmxDatabase понравился! Прям чешутся руки применить и попробовать, осталось найти где. По нему небольшой вопрос, сторонние модели возможно добавлять в список поддерживаемых разработчику? Например для miniShop3 (когда-то в будущем)?

И вопрос по mmxForms, верно понял, что использование компонента на фронте выливается примерно в 1,5 мб дополнительного css и js? Много, конечно, если речь про формы типа «Перезвоните мне»

до сих пор придерживаются транспортных пакетов?

Устоявшаяся экосистема, привычные механизмы, куча реализованных пакетов (а переписать все это нужно много времени)? Типа работает — не трогай))