Андрей Степаненко

Всем привет.

На конец то придумал решения чтобы не лазить в админку для подключения плагинов и подписания их на события.

Это особо актуально, если работаешь через IDE, так как подписывать на события как не крути всегда приходиться через админку.

От проекта к проекту приходиться таскать и заново подключать разные плюшки через плагины, а это рутина)
Всегда удобнее скопировать готовый файлик и прописать строчку кода для подключения каких то плюшек.

Теперь свои плагины можно будет хранить в core/plugins/ModxPlugins/.

Всем привет.
Недавно занимался возможность интеграции PHPunit тестов со своим компонентом CrontabManager.

Сегодня удалось завершить эту разработку.
Теперь CronTabManager умеет запускать PHPunit тесты из коробки.

После установки CronTabManager как обычно создает директорию с котроллерами:

core/scheduler/Controllers/

Сейчас по дефолту добавлен контроллер demophpunit.php

core/scheduler/Controllers/demophpunit.php

Который как раз и показывает как запустить PHPunit тест.

UPD: 22.03.2020: Интеграция PHPUnit в PHPStrom с помощью компонента CronTabManager

Встроенный 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();

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

Порой клиенту приходит в голову навязчивая идея ни в коем случае никуда не перенаправлять со своего сайта. И даже чтобы оплатить заказ — ни на какую платёжку не уходить, оставаться на сайте. При этом, денег, чтобы заплатить за разработку интерфейса приёма карт прямо на сайте, у него нет:) Именно по этому поводу и был изобретён этот костыль.

Класс xPDOCacheManager реализует механизм кеширования в MODX. Кеш у нас хранится в файлах, а значит, этот класс может помочь нам в работе с файловой системой.

Чтобы иметь доступ к методам класса xPDOCacheManager, нужно получить экземпляр этого класса. Это делается одной строчкой:

$cache = $modx->getCacheManager();

xPDOCacheManager::writeFile

Первый метод поможет нам записывать данные в файл. Работает он очень просто:

$cache->writeFile(MODX_BASE_PATH . 'filename.txt', 'Текст');

Массовая выгрузка ресурсов, не такая уж простая задача, как может показаться на первый взгляд. Много подводных камней, касающихся улучшения производительности скрипта. Особенно неприятно, когда тормозит скорость работы из-за функционала ядра MODX.


Так, например, я столкнулся с куском кода в ядре, который увеличивает время выгрузки большого кол-ва товаров в ~3 раза, выполняя одно и то же ресурсоёмкое действие каждый раз, когда скрипт запускает обновление ресурса через процессор modResourceUpdateProcessor.

Сразу оговорю тот момент, что я не считаю этот кусок кода в ядре лишним или вредным, нет! Я полагаю, что этот код при обновлении большого кол-ва ресурсов можно выполнить самостоятельно по окончании работы скрипта выгрузки.

Я говорю вот об этой строчке кода. Давайте попробуем разобраться, что же с ней не так!

Своего писать я пока сомневаюсь, уровень не тот, а вот перевести полезную статью с официальной документации — это с удовольствием. Перевод местами может показаться несколько вольным, что касается формулировок, — иначе переводить скучно. Но в том, что касается технических деталей, старался быть дотошно точным. Так что, если найдёте технические неточности — ругайтесь в комментах. А на филологию прошу не жаловаться:) И тем более на идеологические расхождения с Вашим мировоззрением — тут все вопросы к авторам доков. Паранойи и почвы для громких споров среди «экспертов по безопасности» в статье предостаточно. Помни, о читатель, всё это касается в первую очередь важных и заметных проектов.
Добро пожаловать под кат.

Продолжая тему, начатую Василием, предлагаю решение для упрощения работы с TV. Оно поможет тем, у кого логика сайта завязана на TV — запросы, фильтры и т.п.
Решается эта задача созданием полей в таблице ресурсов и копированием в них значений TV.

DKIM — это цифровая подпись писем, отправляемых с вашего сервера. Она гарантирует, что письмо отправлено именно с него, и не было изменено.

Наличие DKIM на отправляемой корреспонденции крайне положительно сказывается на прохождении antispam тестов, поэтому лучше бы её настроить.

Краткий принцип работы заключается в том, что на сервере лежит закрытый ключ, которым подписываются исходящие письма. Удалённый почтовый сервер (Яндекс или Google) при получении письма видит в заголовках эту подпись и проверяет ее путем запроса открытого ключа из DNS домена.

Пример заголовка с DKIM:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=modx-test.com; s=mail;
	t=1378025116; bh=E27pqP5aWa/XXOeVzzjMW+iw0W7wbbCe2B4toIRxP9M=;
	h=To:Subject:Date:From:Reply-To:From;
	b=GqprdvEYgq/Ff95fCDNzV4k1JLaMA9Pz5p5PUyv2bI0UVZ/S1xl6IyAZK4j3FwMCW
	 5cLe4IGcmnd+dNzNhe2bSj/kCIJg7ZyLM3mXAzEirGXdiqCc/LAZQOGR7udbMmm5YP
	 42pkMa2lI9FqKxAKq5BrtXbrWE+n+Mxc5dpQcGMw=

Если подпись, сгенерированная сервисом, используя содержимое письма и открытой подписи совпадает с той, что указана в заголовке, значит — письмо настоящее и его не модифицировали после отправки с родного сервера.
Если нет — это подделка и, скорее всего, спам.

Под катом пошаговое how-to с картинками, для серверов, настроенных по этой инструкции, как научить Sendmail работать с DKIM.