Николай Савин

Заказчика запарило для смены статуса лазать в полное редактирование заказа, попросил сделать что-то быстрое и простое. На скриншоте выше конечный результат. Чтобы получить такой же, файлы из этого репозитория закиньте себе в папку /assets/ и создайте плагин, который описан в конце статьи. Однако, я настоятельно рекомендую почитать статью, чтобы понимать принцип расширения всего этого дела.

Есть потребность разобраться в том, как создавать свои дополнения для modx. Я читал старые уроки @Василий Наумкин, но увы не смог это воспроизвести. План видео урока такой:
1. Настройка окружения на базе phpstorm или webstorn
2. Разбор структуры компонента с пояснениями что и для чего.
3. Возможности автоматизации процесса за счёт других компонентов с примерами и стоит ли пользоваться.
4. Сам процесс написания компонента ( создание таблиц, схемы объекта, элементов управления в админке, генерация системных событий, использование других библиотек и компонентов для работы собственного) Таблиц должно быть минимум 2 чтобы можно было продемонстрировать как создаются связи между ними в самом простом виде.
5. Рассказать про отладку, как искать ошибки.
6. Пара слов про оптимизацию и безопасность, если получится.
7. Упаковка в транспортный пакет и установка в систему.
Я понимаю что бесплатно никто этим заниматься не станет, поэтому хочу узнать кто готов и за сколько денег и времени?

Привет, друзья!

В связи с выходом альфа-версии MODX 3, я выкроил время и переписал pdoTools — теперь он использует пространства имён и полностью совместим с новыми классами системы.

Соотвественно, работать он может исключительно в MODX 3, со старой версией никак не совместим. Какое-то время мне придётся поддерживать 2 ветки дополнений. Новый pdoTools, как и сам MODX, пока что в виде сырой alpha1, только для тестов.

А теперь подробности.

Привет, друзья!

Наверное, вы уже обратили внимание, что я не был особо активен в этом году в сообществе. Причина в том, что я набрал кучу работы, с которой смог разобраться вот только что. И работа эта с MODX была никак не связана — я писал собственное решение для сложных проектов, с нуля.



И вот сейчас я готов с вами им поделиться. Но для начала пара важных предостережений:

Привет всем.

Во время выступления Steffan Blockx (Building a CMP without ExtJS) в этом году на митапе MODX AMSTERDAM я вдоволь насмеялся, потому, что для меня тема и содержание его выступления были не содержательными. Он 45 мин. говорил, что компонент для MODX можно написать и без ExtJS. Но как же я ошибался по поводу очевидности его слов. Для кого-то — да, а для некоторых оказывается, что не совсем.

Несколько причин очевидности:

• ExtJS всё еще JS и обходится без магии работая с процессорами
• На данный момент есть много компонентов (барабанная дробь) которые работают на чистом js или используя библиотеки. Shopkeeper3 (Angular), imgArea (частично jQuery), ModxMinify (jQuery)
• Об использовании vue писали и раньше

Самый смешной аргумент звучал так: «Wordpress хорош тем, что там можно использовать что угодно!». Читатель, тут нужно смеяться.

Это была первая причина, а вторая поинтереснее. Как же устаешь от нытья в чате телеграм по поводу ExtJS. Каждый клянется, что он точно не является некрофилом и ему противно вступать в половые отношения с «мертвым» MODX.

Третья причина банальная, несколько людей попросили показать.

Встроенный curl клиент для отправки запросов на сторонние сервисы (RESTful и другие).
Так как все чаще используются сторонние сервисы в повседневной разработке сайтов, для этих целей в modx есть встроенный клиент, с помощью которого можно отправлять запросы:

/* @var modRest $client */
$client = $modx->getService('rest', 'rest.modRest');
$response = $client->get('GET запрос');
или
$response = $client->post('POST запрос');

// Обработка полученных данных в json или xml формате и преобразование их в массив
$array = $response->process();

В заметке перечислены способы работы с клиентом

Недавно начал работу над очередным проектом, и захотелось сразу добавить поддержку webp (раз такая поддержка уже есть в MODX из коробки). Задача несложная, но хотелось сделать все красиво, да так чтобы менеджеру не нужно было дополнительно эти изображения конвертировать.

С некоторых пор я плотно переехал на Webpack, так что решил обновить и свою заготовку для создания сайтов App.

Точкой входа во frontend приложение служит _build/assets/js/index.js, там вот такой код:

import 'jquery'
import 'bootstrap'
import '../scss/index.scss'

console.log('App is loaded!');

Если у вас есть дополнение, которое вы делали ещё на первой версии modExtra, то при его установке сейчас вы будете видеть такое сообщение об ошибке:

modAction support is deprecated since version 2.3.0.
Support for modAction has been replaced with routing based
on a namespace and action name. Please update the extra
with the namespace simpleupdater to the routing based system.

Исправить её не сложно, но раньше всё не доходили руки.

Привет, друзья!

Вы задумывались, как работают сессии в MODX? Каждый раз, когда кто-то заходит на сайт, PHP генерирует ему уникальный id и сохраняет его в куку PHPSESSID. При этом в базе данных создаётся запись modSession с этим id и содержимым текущей сессии.

При каждом запросе на сайт передаётся кука с id, MODX делает запрос в БД, загружает сессию, а потом сохраняет в неё изменения. Минимум 2 запроса в БД каждый раз.

Что же нам предлагает JWT? Отказаться от всех этих действий на сервере, и выдавать всё нужное сразу в одном токене. Он может храниться в кукисах или в локальном хранилище браузера. Ну а дальше, при запросе, из него будет создана сессия пользователя. Соответственно, мы выкидываем работу с БД и не храним пользовательские сессии на сервере вовсе.

Конечно, сразу же встаёт вопрос — а что будет, если пользователь такую сессию подделает? Стандарт JWT ему этого не позволит. Токены можно прочитать, но не изменить, потому что они все подписаны надёжным алгоритмом с ключом на сервере, который пользователь не знает. Это теория, а теперь переходим к практике в MODX.