Семён Кудрявцев

В данном видео мы посмотрим как можно избавить себя от использования ExtJS при разработке компонентов и начать применять современные реактивные фреймворки, такие как Vue, React, Svelte и другие.

В данном видео познакомимся с реал-тайм логгером buggregator и его интеграцией в MODX Revolution 2/3 версий

Всем привет!
Я тут работал над одним проектом, в котором очень много контентной и интерфейсной графики, десятки тысяч изображений и, конечно, возник вопрос оптимизации сайта, чтобы удовлетворить требования поисковых систем.
Энтузиазма добавили, появившиеся относительно недавно у гугла, так называемые Core Web Vitals.
Кто не в курсе это пачка технических показателей качества сайта, которые скоро будут включены в алгоритм ранжирования и все тормознутые сайты из-за них, типа, покатятся вниз.
Ну в общем, встала задача оптимизировать картинки, а также сделать так, чтобы не пришлось переписывать кучу html кода, чтобы эти картинки туда вставить.

Всем привет!
Возникла задача, сделать поле стоимости доставки у заказа в админке редактируемым вручную.
Я, честно говоря, до сих пор не понимаю почему это не сделано из коробки — просто нет никакой возможности поменять стоимость доставки уже сделанного заказа из админки. Я не говорю про авто-пересчет через все нужные классы доставки, понятно, что трудно повторить их логику в рамках админки, но просто сделать поле вручную редактируемым не такая уж сложная задача.
Проблема следующая: если клиент при согласовании заказа решил сменить способ доставки, например с «Курьером» на «Самовывоз», как выставить стоимость доставки в 0 и пересчитать стоимость заказа? Вот и начинаются танцы с бубном, менеджеру надо пойти сделать ещё один заказ через фронт сайта, ну в общем, думаю, знакомая тема многим.

Всем привет!
Так как в miniShop2, к сожалению по прежнему нет пересчета доставки в админке, приходится из раза в раз что-то придумывать.
Какие решения я пока нашел:

1. Полностью создать новый заказ через фронт — самый легкий способ, который всё пересчитает как надо, проблема только в том, что нужно заново набрать корзину с теми же параметрами, что у клиента, выбрать способ доставки с теми же параметрами, что у клиента и наконец выбрать способ оплаты
   Плюсы: охватываем даже сложные способы доставки с динамическим расчетом через всякие API
   Минусы: повторять весь процесс формирования заказа
   
2. Сделать плагин на событие обновления заказа, чтобы он пересчитывал стоимость доставки, тут проблема в том, что в плагине уже нет объекта корзины, но, что мешает его создать на основании заказа. Я нашел среди issues минишопа одно решение (Код ниже), которое по идее должно решить этот вопрос хотя бы для простых способов доставки, у которых фиксированы доп. стоимость и стоимость при которой доставка бесплатная. Но проблема в том, что плагин почему-то считает не корректно, возможно из-за того, что он написан в 2015, а минишоп недавно прилично так обновился и с этим могут быть связаны проблемы. Собственно нужна помощь сообщества, чтобы его поправить.
   
3. Ну и третий способ, правим исходники минишопа и делаем все поля заказа редактируемыми, таким образом решая все возможные проблемы с пост-обработкой заказа в админке. Да в таком случае менеджер может насчитать что и как угодно, но это уже проблема магазина и ответственности менеджера. Единственное, что при таком способе хорошо бы делать — это вносить все изменения в историю заказа, так можно будет произвести разбор полетов в случае чего.
   

Кто нибудь может объяснить смысл в методах xPDO — getObjectGraph и getCollectionGraph
В доках написано, что они позволяют за один заход подцепить другие таблицы, у которых определены отношения с запрашиваемым классом объекта.
Я подумал, что это, наверное, способ сократить количество sql запросов, но что то мои примеры показывают следующее — yadi.sk/i/cOzItZ8Z3Xvg4r

Всем привет!
Интересует вопрос про токены MODX.
У MODX есть REST API и он, довольно легко настраивается, вот я решил попробовать использовать его для одного front-end приложения, то есть связка такая: на фронте vue.js на бекенде — MODX.
При чём клиентская часть на совершенно другом домене.
Возник вопрос как можно реализовать авторизацию в таком случае?
В доках, вот тут — docs.modx.com/revolution/2.x/developing-in-modx/advanced-development/validating-requests-tokens-and-nonces
Написано, что токены авторизации запросов по-умолчанию работают в контексте mgr, то есть их, наверное, возможно задействовать и в других контекстах, если я правильно понял.
Но как получить такой токен по REST API, ведь клиентская часть, которая шлёт запрос находится на другом домене и вообще никак не связана с движком MODX, за исключением, что шлёт на него запросы?

Привет, сообщество!
Возник интересный вопрос по поводу минификации стилей в MODX проектах, конечно уже есть компоненты, которые пытаются решить этот вопрос, но у них это получается не очень, и судя по всему из-за использования кривых библиотек для сжатия css-кода.
И тут я подумал, ведь есть же на сегодня лучшее решение, правда, написанное на node — называется csso
По моим тестам этот компонент жмёт абсолютно всё и без ошибок, когда на тех же файлах php-библиотеки сразу же падают, поэтому такие компоненты как MinifyX и modx-minify от Sterc сегодня использовать не получается на полную катушку.
Я не программист и хотел бы услышать мнения опытных разработчиков, какие способы есть, чтобы задействовать библиотеку csso в MODX, ну, кроме как поднимать node сервер и там как в обычном фронтенде производить сборку. Может есть какое-то более интересное решение?

Всем привет, делаю сайт с региональными поддоменами (на контекстах), есть страницы типа «О компании»,
которые общие на все регионы, что бы не плодить копии в админке, есть специальный тип ресурса — Символическая ссылка, в которой можно указать id документа, чьё содержимое будет подтягиваться, но по текущему url. Обычно для таких страниц ещё указывается мета-тег canonical, чтобы не плодить дубли в поиске и обычно такой каноникал я делаю следующей конструкцией в коде

<link rel="canonical" href="{$_modx->makeUrl($_modx->resource.id, '', '', 'full')}">

Однако для ресурсов с типом «символическая ссылка» код должен быть другим, что-то типа

<link rel="canonical" href="{if $_modx->resource.class_key == 'modSymLink'}
                                    {$_modx->makeUrl($_modx->resource.content, '', '', 'full')}
                                {else}
                                    {$_modx->makeUrl($_modx->resource.id, '', '', 'full')}
                                {/if}">

Всем привет, на днях делал сайт с поддоменами и разными контекстами и заметил одну маленькую
неприятность — нигде в шаблоне нельзя получить такие поля контекста как имя и описание,
а key и rank выводятся без проблем.
Распечатал массив через {$_modx->context|print} и всегда получаю следующее:

Array
(
    [key] => web
    [name] => 
    [description] => 
    [rank] => 0
)

Все поля контекста заполнены, но отсутствуют при выводе.
Решил попробовать включить объект modx в настройках, думал может проблема в классе $_modx, но данный баг оказался более широким и — {$modx->context->name} или {$modx->context->description}
также не дали результатов.
Та же беда при вызове простейшего сниппета:

<?php
return $modx->context->key;//работает
return $modx->context->name;//не работает

Однако если воспользоваться xPDO и получить объект контекста то все поля как положено в наличии

<?php
$res = $modx->getObject('modContext',['key'=>'web']);
print_r($res->toArray());
Array
(
    [key] => web
    [name] => Москва
    [description] => Москва
    [rank] => 0
)

Собственно вопрос — где искать проблему в pdoTools или в самом MODX?
Просто весь сайт завязан на логике смены контекстов и везде использовать получение названия через xPDO как то не прикольно.