Николай

Небольшая пошаговая инструкция, как научиться сохранять любые интересующие данные о юзере в специальное поле 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();
	}
}

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

Кто чем обрезает картинки на сайте?
Нашел phpThumbOn, phpThumbsUp, phpThumbOf, Resizer, FriendlyThumbOf, pThumb, DirectResize, DirectResize2. Так собственно кто какой из них предпочитает?

Необходимо реализовать проверку данных в форме регистрации сниппета LogIn. А именно, во время регистрации проверять есть ли уже пользователь с такими логином и паролем. Это необходимо, что бы пользователь при регистрации мог указать только уникальные логин и e-mail. По умолчанию снниппет LogIn может проверять на уникальность только одно поле. Как проверить на уникальность 2 поля и больше?

Привет!
Коллеги, кто-нибудь сталкивался с выводом вот такой ошибки?

После недавней статьи про настройку сервера было много вопросов, касающихся всяких мелочей. Поэтому я поднапрягся, и переделал скрипты jkenters для автоматической установки MODx.

Как известно, при создании собственных таблиц в MODX принято наследовать или xPDOSimpleObject, или xPDOObject.

Отличие между ними ровно одно — в SimpleObject уже прописан первичный ключ id, а в Object — нет. То есть, если вы хотите, чтобы у вашей таблицы создавалось поле id с становилось primary key — нужно наследовать SimpleObject.

Я, однако, люблю простые таблицы ключ-значение, в которые добавляю первичным ключом два и более полей сразу. Например, в репозитории пакет может быть в нескольких категориях, значит нужно создать таблицу extraCategoryMember из двух полей category_id и package_id.

Ключ id мне здесь совершенно не нужен, ведь он будет расти при каждой операции добавления пакета в категорию, а таких операций может быть очень много. Конечно, вряд ли INT(10) скоро закончится, но зачем хранить лишнее?

Первым делом всегда-всегда-всегда нужно заботиться о резервной копии. Вариантов огромное множество, но лично я написал для себя простой и понятный скрипт для ежесуточного запаковывания данных с любого сервера, в том числе и shared-хостинга.

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

Проблемы, в общем то нет, вопрос изучен, но выплыл интересный глюк.
А именно: не работали процессоры для создания/обновления ресурсов.

То есть, процессор для логина — нормально, контекст mgr — нормально, а при попытке создать ресурс — просто пустая error.
Выложил вопрос на официальном форуме и никто мне не ответил. Пришлось разбираться самостоятельно, глубоко копая исходники.

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

Что же делать?
Все просто — нужно расширить сторонний класс своими методами. По сути, это очень похоже на «классные процессоры», только без процессоров и использовать можно везде — это стандартная возможность ООП.

Регулярно встречаю в сети разные велосипеды про то, как подключиться к MODX снаружи для работы с его Api. Даже на официальном сайте это описано сложновато.