Алексей Карташов

> Есть много разных возможностей, и через связи (копии товаров) и через опции — в общем, от фантазии зависит.
Супер! Значит будем разбираться.

А на mamaboutique нашёл только несколько товаров (вроде этого) у которых можно поменять размер, но цена не меняется.

Корень проблемы нашёл — как обычно, ссзб.
В форме добавления нового тикета, кроме, собственно, полей тикета, так же есть поля для редактирования данных пользователя. И если пользователь залогинен, то данные автоматом подставляются в эти поля. Если не залогинен, то их надо вписать и юзер автоматом создастся и залогинится. Так вот при добавлении тикета поля пользователя обрабатываются отдельно — если надо — юзер создаётся, если что-то изменилось — юзер обновляется.
Так вот обновление юзера происходило вот так:

function userUpdate ($user, $data) {
	$result			= array();
	$userProfile	= $user->getOne('Profile');
	$userProfile	= $userProfile->toArray();
	// $changedData	= array_diff($data, array_intersect_key($userProfile, $data));
	$changedData	= array_intersect_key($data, $userProfile);
	if (count($changedData)) {
		/**
		 * Всё внимание на массивы, которые передаются в процессор:
		 */
		$response = $this->modx->runProcessor('web/user/update', array_merge(
			$userProfile,
			$user->toArray(),
			$changedData
		));
		if ($response->isError()) {
			$errors = $this->getResponseErrors($response);
			$result = array_merge($result, $errors);
		}
		$this->modx->error->reset();
	}
	return $result;
}

И фишка вышла такая — благодаря $user->toArray() в процессор передаётся так же поле текущего пароля. А точнее не сам пароль, а его хэш (в базе же пароли хешированные лежат). А процессор, получив заполненное поле пароля, делал из него новый хэш и его записывал. Соответственно, пароль-то фактически каждый раз менялся. Вот такой вот я балда :-)

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

function userUpdate ($user, $data) {
	$result			= array();
	$userProfile	= $user->getOne('Profile');
	$userProfile	= $userProfile->toArray();
	// $changedData	= array_diff($data, array_intersect_key($userProfile, $data));
	$changedData	= array_intersect_key($data, $userProfile);
	if (count($changedData)) {
		$response = $this->modx->runProcessor('web/user/update', array_merge(array(
			'id'		=> $user->id,
			'username'	=> $user->username,
			'email'		=> $userProfile['email']
		), $changedData));

		if ($response->isError()) {
			$errors = $this->getResponseErrors($response);
			$result = array_merge($result, $errors);
		}
		$this->modx->error->reset();
	}
	return $result;
}

Василий, я не зря отвечаю в этой ветке именно тебе, потому что в процессе копания выяснилась интересная особенность тикетов, возможно даже баг.
Помнишь, ты мне как-то помогал разобраться с изменением алиасов при создании тикетов? К алиасу добаляется id тикета в плагине на «OnDocFormSave» вот так:

$resource	= &$modx->event->params['resource'];
$alias		= $resource->get('alias');
$alias		= (strpos($alias, $id.'-') !== 0) ? $id.'-'.$alias : $alias;
$resource->set('alias', $alias);
$resource->save();

У меня в сниппете myTicketForm в самом конце, после всех шаманств и отработки всех процессоров, идёт редирект на этот тикет:

$redirectTo = $modx->makeUrl($result['id'],'','','full');
$modx->sendRedirect($redirectTo);

И вот в чём дело — редирект происходит на uri со старым алиасом, т.е. на тот, который был до моих изменений! Хотя все плагины отработали и всё должно было измениться. Но и это не самое интересное — у самого тикета алиас сохранился таким, каким я его и сделал, с id-шником! Т.е. makeUrl берёт uri документа из какого-нибудь alias_map, а там данные ещё старые. В итоге редирект происходит на не существующий адрес. Но и это ещё не всё — страница открывается! xD
Т.е., положим у тикета сформировался такой алиас — 'this-is-ticket-alias'. В плагине к нему подставляется id тикета: '123-this-is-ticket-alias'. И этот алиас фактически у ресурса и записан, но в кэше лежит 'this-is-ticket-alias', и при редиректе на этот адрес открывается только что созданный тикет (хотя адрес-то фактически не существующий)!
И вот только после того, как в админке что-нибудь изменю/сохраню или просто тыкну «обновить сайт» — кэш очищается и по адресу 'this-is-ticket-alias' как и положено вылезает 404, а сам документ становится доступен по '123-this-is-ticket-alias'.
Такие дела.

В процессе копания пришёл к вот этому.
Заменил код метода на:

$this->xpdo->cacheManager->refresh(array(
	'db' => array(),
	'auto_publish' => array('contexts' => array($this->context_key)),
	'context_settings' => array('contexts' => array($this->context_key)),
	'resource' => array('contexts' => array($this->context_key)),
));

Не помогло.
Потом заменил на одну строчку:

$this->xpdo->reloadContext($this->context_key);

И всё встало на свои места, всё заработало как надо. Только вот теперь чистится весь кэш сайта, а собственная система кэширования тикетов получается не при делах :-(

Выходит проблема именно в кэшировании тикетов. Точнее в очистке кэша.
Как-то так.

Не за что)
Вот туда же, в копилку на почитать и осмыслить =)
modx.pro/development/39/

Лично я эту проблему с денвером в своё время решить так и не смог. работать невозможно в принципе — тормозил не столько javascript (что естесственно, js же в браузере), а обработка php и время ответа от «сервера». Хотя может у меня и машинка php не потянула..)

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

rtfm.modx.com/display/revolution20/modX.parseChunk