Артур Шевченко

Вставлю свои 5 копеек. Кто не хочет интегрироваться с CRM, может создать отдельную группу пользователей, на bootsrap набросать несколько форм и таблиц, и вынести управление заказами на фронт. Все проблемы по пересчёту сумм, отправке писем, запрете на удаление заказов сразу же будут решены)))

Можно использовать AjaxForm + свой сниппет, в котором можно делать, всё что угодно.

Предполагалось что это будет сделано для людей без знаний html css, но потом мне подумалось, что слишком сложно, а если упрощать, то это уже конструктор, а их хватает. А вообще, может ещё запилю.

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

P.S. Настройки boostrap я выносил в clientConfig и при сохранении пересобирал sass. Хотел даже статью запилить, но подумал, что это никому не нужно)))

конечно, почти двухкратный прирост скорости отдачи станицы)))

Рендер на сервере.

Не знаю будет ли полезна эта информация, но я делал аналог для бедных на Migx. Так вот, чтобы кучу логики в шаблон не пихать, я рендерил страницу при сохранении ресурса и сохранял в поле контент или в отдельную TV, если нужен был визуальный редактор в контенте. Чтобы сниппеты, например AjaxForm, работали я заменял { на ## при написании шаблона, а в плагине менял обратно, таким образом вся статика парсилась на сервере, а вся динамика на форнте. Минус в том, что приходится использовать разный синтаксис в шаблоне.

Что я могу сказать, у меня тоже так было нужно проверять пути, название файлов и классов.

Я думал из контекста понятно, что речь идёт о пути к файла «компонента» codesender, вот про это [[++core_path]]components/codesender/model/

Про какие пути?

Возможно тебе подойдёт migx. Создаёшь под каждую таблицу отдельную конфигурацию, и создаешь конфигурацию, которая будет объединять эти конфигурации. Примерно как тут только вместо секций, таблицы.

В ТП писал?

Примерно так

<?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 клиент для общения между сайтами.

Давайте рассуждать. Чтобы было легче идём сюда. Событие 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);

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

А у вас каждый товар выводиться вручную по одному? Или есть какой-то шаблон, в который подставляются данные товара? Если есть шаблон, то что мешает в него микроразметку добавить?

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

Мне кажется, что нет. Вообще плохо представляю как он должен выглядеть и кому нужен, если можно нагуглить пример и подставить свои значения. Если говорить про Schema.org, то там вообще можно делать так

<script type="application/ld+json">
        {
            "@context": "http://schema.org",
            "@type": "Organization",
            "name": "{$_modx->config.site_name}",
            "logo": "{$_modx->config.site_url}{$_modx->config.logo}",
            "address": {
                "@type": "PostalAddress",
                "addressLocality": "Краснодар, Россия",
                "postalCode": "350000",
                "streetAddress": "Коммунаров, 269"
            },
            "email": "{$_modx->config.email}",
            "telephone": "{$phoneFormatted}",
            "url": "{$_modx->config.site_url}"
        }
    </script>

Берешь вот это событие и пишешь плагин, который будет проверять какие поля заполнены и, если нужные пустые, то переадресовываешь на форму редактирования данных. Ну а для проверки полей в ЛК можно написать сниппет или использовать встроенный функционал типа [[+modx.user.id:userinfo=`fullname`]]

В ресурсе класса msProduct на вкладке Свойства товара или Опции.

Судя по всему на сайте используется готовый компонент. Думаю стоит посмотреть документацию и убедиться, что всё сделано так, как там написано. По умолчанию данный компонент не перезагружает страницу и не очищает корзину.