Воеводский Михаил

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

С таким плагином произойдет большая печаль :)

Если серьезно, этот кусок кода для однократного запуска — он переносит значения из introtext в TV для всех ресурсов сразу.

Плагин надо повесить на событие OnDocFormSave. Его код:

switch ($modx->event->name) {
	case 'OnDocFormSave':
		if ($resource->template == 3) {
			$resource->setTVValue('tvtag', $resource->introtext);
			$resource->save();
		}
		break;
}

Тоже не проверял.

Кусок кода, перекидывающий значение introtext в TV:

$q = $modx->newQuery('modResource');
// Дальше несколько строк с критериями для выборки ресурсов. Например, ресурсы с шаблоном 2
$q->where('template' => 2);
$resources = $modx->getIterator('modResource', $q);
foreach ($resources as $resource) {
	$resource->setTVValue('tvtag', $resource->introtext);
	$resource->save();
}

Код не проверял, но должен быть рабочим.

Идея правильная. Такой плагин пишется за 5-10 минут.

Желательно поэтапно.
Хоть и не должно быть косяков при обновлении в рамках одной ветки (2.2), надежнее по порядку. Недавно столкнулся с косяками админки после обновления с 2.2.8 до 2.2.16.

Посмотрел — перепиливать основной сниппет нужно кардинально. Советом здесь не обойтись.

Вечером посмотрю исходники, скажу.

Верно, спасибо за замечание.

Необходимо смотреть, что удобнее для конкретной задачи.

<object class="chGuest" extends="modUser">
        <field key="class_key" dbtype="varchar" precision="45" phptype="string" null="false" default="chGuest"/>

        <composite alias="Data" class="chGuestData" local="id" foreign="id" cardinality="one" owner="local" />
</object>

<object class="chGuestData" table="ch_guests_data" extends="xPDOSimpleObject">
        <field key="surname" dbtype="varchar" precision="45" phptype="string" null="false" default=""/>
        <field key="name" dbtype="varchar" precision="45" phptype="string" null="false" default=""/>
        <field key="patronymic" dbtype="varchar" precision="45" phptype="string" null="false" default=""/>

        <composite alias="Guest" class="chGuest" local="id" foreign="id" cardinality="one" owner="foreign" />
</object>

Иной вариант — расширение пользователей с указанием нового класса.
Связь Data — по аналогии с msProduct, очень сильно упрощает работу с полями в дополнительной таблице.
Класс chGuestData — стандартный класс, расширяющий xPDOSimpleObject.
chGuest содержит методы прозрачного подтягивания полей из chGuestData: github.com/bezumkin/miniShop2/blob/master/core/components/minishop2/model/minishop2/msproduct.class.php

По всей видимости, без правки исходников не обойтись.

Сергей, отличная работа!
Компонент вырос многократно. Ура, для MODX теперь есть полноценный модуль работы с бронями!

И здесь не могу не согласиться. Но практика говорит об обратном.

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

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

Большое спасибо Василию за тот объем документации, который есть — это огромное количество материалов.

Стандартно — new или upd.
Если расширить процессоры собственными, то значения можно установить любые.

просто нужно документацию ясно написать.

Для написания документации объемом в лист A4, без учета скриншотов, может потребоваться несколько часов.
Кто будет это делать?

К сожалению, в мире Open source очень часто случается ситуация, когда продукт умеет в несколько раз больше, чем указано в документации. Основная причина этого явления — экономическая. Особенно для бесплатных продуктов.

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

Вся мощь MS2 заключается в тех возможностях, которые он дает как платформа. И на эту платформу Вы можете добавить:
— msOptionsPrice для управления характеристиками (уже не слишком актуально),
— msRevaluation для простого проведения переоценки,
— msPayAndSee для реализации закрытых платных разделов сайта
— и многое другое

К сожалению, в мире Open source очень часто случается ситуация, когда продукт умеет в несколько раз больше, чем указано в документации. Основная причина этого явления — экономическая. Особенно для бесплатных продуктов.

О новом функционале в курсе, но еще не добрался до него даже визуально посмотреть.

Можете это красиво оформить, чтобы не только программисты понимали? И Разработчик вам спасибо скажет.

Пока не до написания статей. Хотя идея правильная, спасибо.

Дальше речь _только_ о такой характеристике товара, как «Цена»:

Ссылку смотрел, этот компонент делает «Проведение переоценки товаров для MODX», о чем я и написал, что передавать с сайта нужно не только цену.

Ваша фраза «передавать с сайта нужно не только цену» мне совершенно непонятна. Особенно в свете отдельного вопроса об изменениях цен.
Если у Вас появилась необходимость изменить цену на 10% в связи с изменением курса валют, чем не подходит данный компонент?

Данный метод интересен тем, что позволяет программированием не заниматься. Здесь только чистая верстка + работа с админкой по созданию полей и добавлению потом записей словаря.

Теперь мне стал более понятен смысл ваших комментариев.