Можно

Спасибо, буду обновляться сам. Насколько я понял на сегодняшний день актуальная версия 2.8.3. Еще один вопрос, могу я обновиться с 2.7.2 до 2.8.3 сразу, или мне надо сначала обновляться до промежуточных патчей 2.8.0.; 2.8.1 и т.д.

Каждую новую версию Modx — закрывают некоторые дыры в безопасности.

github.com/modxcms/revolution/blob/2.x/core/docs/changelog.txt — дабы не быть голословным, вот «XSS issues reported by Solar Security (#15720)».

Как для вас не печально, но нужно обновлять до последней версии, как движок, так и плагины, так и окружение (менять версию php с 5 на 7). Иначе это превратиться со временем в рассадник вирусов и спама, и ваш сайт попадет в черные листы поисковиков.

Сложности при обновлении движка и возможные глюки сильно зависят от сайта, плагинов, как он собран, и есть ли там самописный код.

Если вы не хотите сами с этим разбираться, вы можете подать объявление о работе тут: modx.pro/work — и за вас сделают работы и решат все возникшие проблемы при обновлении.

Это от уровня понимания задачи зависит, кому то написать ИМ — кара небесная, кому то нет. Из того, что хорошо запомнилось: добавлял я новые поля в карточку заказа, можно было сделать это еще сложнее?

Приятно строить из себя капитана очевидность?

Думаю есть смысл почитать документацию

Ну вроде все события для работы есть. Есть возможность расширить класс корзины/заказа, и там сделать то, что нужно. Куда еще проще, не понятно. Что подразумевается, под словом «проще». Сам по себе ИМ это явно не к слову «проще»

Дополнение должно давать инструмент взаимодействия, а возможность этот инструмент создать.
Я не хочу изучать реализацию minishop2, я хочу его использовать.

Например сейчас, нужно сформировать заказ. Почему не сделать условный триггер-событие, по которому начнется валидация, а после, оформление? То же самое с добавлением товара, очисткой корзины. Честно, работаю с minishop2 три недели, задачи по работе. Основная задача разработчика — сделать жизнь других людей проще, а не наоборот.

Скорее всего из-за этого правила.

RewriteRule "/\.|^\.(?!well-known/)" — [F]

Вообще попробуйте поставить оригинальный .htaccess

Примерно так

<?php
$client = $modx->getService('rest', 'rest.modRest'); // подключаешь restful api
$params = array();
$response = json_decode(sendRequest($client,$params),1); // отправляешь запрос
// тут как-то его обрабатываешь

function sendRequest($client,$params){
    $data = array();
    $url = 'https://domain.ru/assets/reciever.php';
    if($client){    
        $response = $client->post($url, $params);
        $data = $response->process();  
    }
    return $data;
}

reciever.php

<?php
require_once '/home/d/doskazaym/doskazaymov.tech/public_html/config.core.php';
require_once MODX_CORE_PATH.'model/modx/modx.class.php';
$modx = new modX();
$modx->initialize('web');
$modx->getService('error','error.modError', '', '');
$params = $_POST;
$output = array();
// тут получаешь список событий и записываешь в $output
echo json_encode($output);

В reciever.php хорошо бы проверку какую-нибудь добавить, чтобы все подряд не могли запросы слать.

Непонятно. Календарь событий на одном сайте, а вывести ты его хочешь на другом? Что он из себя представляет? Таблица в БД? TV?
Если это разные сайты, то можно использовать встроенный RESTful API клиент для общения между сайтами.

Ошибку нашел. Файл:
core/components/tinycompressor/model/tinycompressor/tinycompressor.class.php

Строка 98.

$path = $this->modx->getOption('base_path') . $container . $file['name'];

$container уже содержит base_path.
Плюс, между $container и $file['name'] должен быть разделитель /.

После исправления, всё заработало. В личном кабинете TinyPNG появилась информация о количестве сжатых файлов.

Возможно такое, компонент не обновлялся несколько лет — там уже sdk сервисов обновились и api компонентов modx. Постараюсь в ближайший месяц переписать его.

Спасибо! Это в нужную сторону.

Посмотрите тут, что-то подобное уже обсуждалось.

Давайте рассуждать. Чтобы было легче идём сюда. Событие msOnBeforeSaveOrder как-то связано с сохранением заказа, учитывая задачу, пользователя надо бы оповестить о том, что выбрав доставку он теряет скидки и хорошо бы показать сколько он в итоге должен заплатить. На этапе сохранения заказа это сделать невозможно. Однако, если присмотреться к списку событий внимательно, то можно заметить, что порядок событий в нём точно такой же в каком они происходят при совершении покупки. И тогда становится очевидным, что перед сохранением заказа происходит ещё много событий. Какое же из них выбрать? Я думаю то, которое как-то связано со стоимостью заказа, ведь в конечном итоге меняется именно она. Я бы начал с msOnBeforeGetOrderCost, в него передается экземпляр класса корзина и экземпляр класса заказ. Из второго объекта получаем способ доставки, если это не самовывоз делаем так

if($order->get('delivery') != 1){
    $tmp = $cart->get();
    foreach($tmp as $k => $v){
        $product = $modx->getObject('modResource', array('class_key' => 'msProduct', 'id' => $v['id']));
        $tmp[$k][$v]['price'] = $product->get('price');
    }
 } else{
    // скидки надо возвращать, если выбран самовывоз
}
$cart->set($tmp);

Код выше это, конечно, не окончательное решение, а просто для направления мысли.

Не работает компонент почему-то с minishop2.
Проверил размер превью продукта «до» и «полсе» перегенерации превью из вкладки «галерея».
«До» было меньше (20кб), чем стало «после» (23кб). Если загрузить «после» вручную на сервис tinyPNG, то файл сжимается в 2 раза (49%).
В phpthumb.class.php нужная сточка присутствует. При перегенерации срабатывает только 1 событие из плагина: OnFileManagerFileCreate (наверное так и должно быть, но всё равно не сжимаются картинки)
Оригинал картинки был около 700 кб (т.е. меньше 5 мб).

В справочнике минишоп все очень кратко, упоминается событие msOnBeforeSaveOrder — но никакой информации более подробно нет.

А какая информация еще нужна например?

Создай свой класс обработки доставки и там убирай уже скидки у товара, если его выбрали

Я бы тоже в верстке скрывал уже. К вызову pdoMenu можно добавить &levelClass.

Класс уровня меню. Например если укажите «level», то будет «level1», «level2» и т.д.

А потом в стилях что-то вроде:

li.level3 {
    list-style: none;
}
li.level3>a {
    display: none;
}