R2m0x94 (Vasily)

Дорогие вы мои, подскажите пожалуйста, есть ли какое готовое решение чтобы запрещать отправку формы оформления заказа или ее вывод, если сформированный заказ не дотягивает до минимальной цены?

Hi, сделал новое дополнение CMPGenerator Pro на основе UiCMPGenerator.

Что может CMPGenerator Pro:

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

Что обычно люди делают в таких случаях? Верно, редактируют ядро или нужный компонент, и больше их не обновляют. Но ведь это неправильно, и можно решить вопрос иначе.

Пишем обычный плагин, выставляем для него событие OnMODXInit и меняем модель для нужных классов системы или дополнений. Например, я добавил id менеджера в заказ miniShop2:

$c = $modx->newQuery('Objekt');
    $c->command('update');
    $c->set(array(
        'name'  => $name
        ));
    $c->where(array(
        'id'    => $id,    
    ));
    $c->prepare();
    $c->stmt->execute();

$c->stmt->execute(); всегда возвращает true наверное потому что запрос выполнен

но как сделать проверку удачно ли прошел запрос или запрос прошел но неудачно так как условие where не нашло нужное значение
Спасибо

Итог, как сделал:

if($c->stmt->rowCount() > 0){
        echo "Ok";
    }else{
        echo"No";
    }

Давно использую MODX Revo, но в основном для небольших сайтов. А сейчас решил сделать на нём интернет-магазин. Захотелось сделать на сайте личный кабинет покупателя, где он сможет просматривать свои заказы. Начал искать и не нашёл ни одного решения этого вопроса (может плохо искал?!).
Странно. В итоге написал свой велосипед — сниппет и чанк в котором выводится содержимое.

[msListOrders] — Компонент реализует возможность вывода, сортировки заказов и вывода подробной информации о заказе [Minishop2].

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

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

В ходе одного исследования выяснил несколько интересных вещей про xPDO, о которых раньше не задумывался или некогда было проверить.

Решил немедленно поделиться.