Sphinx

Модель безопасности в MODX не самая очевидная. Хотя в MODX присутствуют примитивы, присущие, например, модели безопасности SQL, их предназначение в MODX несколько отличается.

При настройке безопасности конечной целью является дать каждому пользователю соответвующий набор привилегий – разрешить ему совершать определенные действия в системе. Действия могут совершаться над различными объектами: страницами (resource), контекстами (context), чанками (chunk), переменными шаблонов (TV) и т.д. Сами действия могут быть очень разными, в простейшем случае это создание, просмотр, редактирование и удаление. Таким образом, задача настройки безопасности сводится к заданию отношений между пользователями, объектами и привилегиями.

Мой прошлогодний курс по написанию компонентов теперь доступен для всех желающих.

Напоминаю, что на нём мы написали компонент Sendex, который лежит в репозитории, и кто-то им даже пользуется.

В целом, время потраченное на написание текстов, разработку дополнения и ответы на вопросы практически окупилось, и теперь можно выкладывать тексты для всех.

Единственное ограничение — в уроках нельзя писать комментарии, зато можно читать старые. У меня просто не будет времени отвечать всем новым читателям, поэтому так.

Надеюсь, что это поможет кому-то подружиться с MODX и разработкой для него. Напоминаю, что совсем рядом Simple Dream разыскивают новых разработчиков.

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

Так вот, вопрос к ним (и не только) — что не так с индексацией kino-govno.com, почему настолько большая разница в переходах с Google и Яндекс? Вопрос, понятно, не о MODX, но спросить больше негде.

Для сравнения, вот другие сайты по той же тематике: раз и два. Доля Яндекса или больше, чем у Google, или на уровне.

Рад представить вам на суд весьма полезное, по моему мнению, дополнение для MODX Revolution.

Всем известно, что для доступак файлам в MODX Revo используются так называемые медиа ресурсы, предоставляющие доступ к файлам размещенным как в файловой системе так и на других сторонних сервисах. Из коробки MODX умеет работать только с обычными файлами на диске и файлами в Amazon S3. Но ничего не мешает написать собственный провайдер, предоставляющий доступ к любому другому сервису.

Где-то год назад разработчик из Гонконга сделал подобный провайдер для работы с Dropbox, Марк Хамстра писал об этом. Именно тогда у меня появилась желание реализовать подобный провайдер для работы с Яндекс.Диском, но за год продвинуться сильно не удалось из-за особенностей работы с протоколом webdav и отсутствием нормальных библиотек на php для работы с этим протоколом. Но перед новым годом наткнулся на официальный SDK для работы с сервисами Яндекса от компании NIX Solutions из Харькова и решил возобновить работу над проектом.

И вот буквально вчера я закончил версию 0.5.0-alpha. В ней реализованы базовые функции для работы с файлами в Яндекс.Диске, а именно: создание, удаление, перемещение файлов и каталогов, создание и редактирование текстовых файлов из MODX. Генерация превью выполняется на стороне Яндекса, но для ускорения работы сгенерированные превью кешируются в самом MODX.

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

Ну и для скорейшего выпуска стабильной версии объявляется сбор денег (5000 рублей) для повышения мотивации меня, как разработчика.

Webmoney
Z203304231268
R140312479061

ЯД:
41001878021446

Уже собрано 1500

На этой неделе начну активно исправлять описанные баги.

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

На самом деле, это никакой не секрет. Во многих объектах MODX есть специальное поле типа JSON, которое хранится в БД как текст, например, properties у modResource и extended у modUserProfile.

При работе с объектами xPDO, JSON текст из этих полей превращается в массивы. То есть, общий принцип выглядит так:

// id нужного пользователя
$user_id = 15;
// Получаем объект modUser
if ($user = $modx->getObject('modUser', $user_id)) {
	// Получаем связанный с ним профиль пользователя
	if ($profile = $user->getOne('Profile')) {
		// Получаем специальное поле extended
		$extended = $profile->get('extended');
		// Добавляем новое значение
		$extended['mykey'] = 'mydata';
		// И сохраняем обратно в профиль
		$profile->set('extended', $extended);
		$profile->save();
	}
}

Самое приятное, что эти данные вы можете не только просмотреть на странице пользователя, но и изменить.

Увидел недавно вопрос на сообществе — человек хочет сгенерировать таблицу с расписанием занятий по дням.

Казалось бы, задача несложная, но это совсем не так. Стандартные сниппеты не предназначены для такой работы и их приходится запускать на каждый день недели. И даже если вас не волнует скорость работы, то в итоговой таблице будут пропущенные ячейки, что совсем не айс.

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

Поэтому предлагаю вам готовое решение, а заодно и демонстрацию работы с pdoTools. Конечно, можно было бы обойтись и родными методами MODX, но с ним быстрее.

Все нужные данные выбираются за один запрос, а дальше очень быстрая обработка и оформление на PHP.

Подскажите, как запустить два сниппета использующих pdoTools на одной странице?
Сейчас при запуске [[snippet1]] и [[snippet2]] в обоих местах результат работы [[snippet1]].

Не многие задумывались, что вместе с MODX Revolution поставляется и phpThumb. Это, фактически, единственная и самая крутая библиотека для работы с изображениями на PHP.

В MODX принято работать с ней через сниппет phpThumbOf, однако у него есть существенные недостатки, например серьёзные тормоза и странное кэширование. Поэтому, верным способом будет работа с библиотекой напрямую.

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

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

Долгое время я пользовался простыми и быстрыми редакторами для разработки, типа Geany и Notepad++. Просто не понимал, зачем мне тяжеловесная IDE, если и этих редакторов хватает с головой?

Я помню свой код, что откуда выходит и как работает, зачем мне подсказки от программы, которая грузится полторы минуты? Тем более, я люблю по-быстрому забежать на сервер, подправить пару опечаток и сохранить файл. Мне не нужно создавать проект, синхронизировать его с сервером и т.д.

Однако, всё поменялось, когда я написал miniShop. Компонент вышел большой, и со временем я понял, что просто запутываюсь в нём. Заодно я понял, что допустил много грубых ошибок, по незнанию — например доставучие уведомления о необъявленных переменных или ключах массива, те самые — E_NOTICE.

Поэтому, когда я засел за Tickets, сразу решил писать его в IDE phpStorm, чтобы таки разобраться в ней и упростить себе разработку. Поначалу было непросто, но я быстро втянулся.

Сразу говорю, всё освоено методом тыка, без чтения литературы или чьих-то инструкций. Подозреваю, что освоил я процентов 5 от общего функционала, однако и этот объем позволил мне работать радикально быстрее и выдавать в разы более качественный код.

Эта заметка назревала уже очень давно, полгода минимум. Вокруг замечательного MODX Revolution сломано много копий. Ходят слухи, что он «тормозной», «прожорливый» и «неповоротливый». И главным виновником всегда называют xPDO.

Конечно, это чушь и цель заметки — развенчание мифов. Закрыть, наконец, вопрос с «тормозами» и «прожорливостью». Показать, насколько Revolution удобен и гибок, что он позволяет работать как через ORM xPDO, так и без него — через обычный PDO.