Andrey Grachov

В случае с уникальными данными (что бывает не очень часто) будет добавляться по одной записи в этой таблице, в то время как в варианте с сессиями набор свойств будет дублироваться в сессии каждого пользователя который зашел на страницу. То есть вариант с сессиями увеличивает размер базы быстрее, но, конечно, как вы правильно упомянули, там есть механизмы очистки.

Можно сохранять настройки вызова AjaxForm в таблицу такой структуры

CREATE TABLE `modx_ajax_form_properties` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `hash` varchar(32) NOT NULL,
  `properties` json NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `hash` (`hash`)
)

В коде AjaxForm меняем логику генерации хеша:

ksort($scriptProperties);
$hash = md5(http_build_query($scriptProperties));

и потом добавляем новую запись в базу если такого хеша еще нет. При обработке запроса AjaxForm берем данные по хешу из базы а не из сессии.

Если используется хук FormItSaveForm, то можно обойтись без лишнего сниппета:

{foreach $_pls['savedForm.values'] | json_decode as $label => $value}
    {$label}: {$value | e}
{/foreach}

joinSequence

Было бы неплохо добавить туда же tvsJoin или всегда включать их первыми, потому что сейчас, если в одном из видов join-а (или только в left join до этого обновления) понадобится значение TV, join для этого TV-параметра придется дублировать самостоятельно, то есть писать

&leftJoin=`[{"class": "modTemplateVarResource", "alias": "CountryTv", "on": "modResource.id = CountryTv.contentid AND CountryTv.tmplvarid = 15"}, {"class": "modResource", "alias": "CountryResource", "on": "CountryResource.id = CountryTv.value"}]`

вместо

&leftJoin=`[{"class": "modResource", "alias": "CountryResource", "on": "CountryResource.id = TVcountry.value"}]`

Могу предположить, что причина может быть в неправильном порядке вызова хуков. Вот демка с модифицированным сниппетом FormItSaveForm, пробуйте пока она жива:
s1509.h3.modhost.pro/manager/
s1509 / 721QTQutryPt

Если применить изменения, то можно будет использовать в шаблоне письма плейсхолдеры [[+savedForm.*]] с полями сохраненной формы (например, [[+savedForm.id]] для ID заявки).

Повторюсь еще раз — эти правки всего лишь заменяют фатальную ошибку нефатальной, всегда необходимо находить безошибочное решение :)

Осталось только удалить issue чтобы не шокировать разработчиков FormIt :)

Да, все верно.

Правки FormItSaveForm похоже были первоапрельской шуткой — хорошая попытка заменить Fatal error на Notice (Trying to get property of non-object). Чтобы все работало правильно, AjaxForm должен подменять $modx->resource, иначе не будут нормально (правильно) работать любые хуки FormIt, которые зависят от текущей страницы ($modx->resource), на которой находится форма.

Я это и подразумевал — если удалить связь с соцсетью, то это никак не повлияет на дальнейшую авторизацию. Поэтому если, допустим, добавить поле blocked в haUserService, то можно будет запретить авторизацию для конкретного аккаунта из соцсети, который ранее был авторизован. Но вопрос в том — нужен ли такой функционал? :)

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

Это JS методы, которые отвечают за установку/чтение значений из адресной строки: github.com/bezumkin/mSearch2/blob/master/assets/components/msearch2/js/web/default.js#L475
Поисковый запрос на сервер и так отправляется методом POST. Или что вы имеете в виду?

Копать надо в сторону модификации mSearch2.Hash.get/mSearch2.Hash.set.

Чтобы открыть окно, надо на ссылки авторизации повесить обработчик такого вида:

$('.ha-icon').on('click', function () {
    window.open(this.href, 'Auth', 'width=600,height=600');
    return false;
});

Единственный момент — после авторизации (или отказа от авторизации) произойдет редирект и целевая страница откроется в этом новом окне. Чтобы предотвратить это, необходимо в код компонента добавить второй режим работы (или воспользоваться другими способами), который будет выводить на странице код:

window.close();
window.opener.location.reload();

Этот код закроет попап и обновит страницу, на которой находился пользователь.

Да, там не настроены методы для оплаты online, по идее редирект будет отрабатывать как надо.

Набросал схематический вариант, посмотреть можно здесь: s5885.test.modx.pro/index.php?id=5 (доступ s5885/VPdm-g7Y6zKf), плагин QuickOrder.
Код плагина:

<?php
$context = $modx->context->get('key');
if ($context == 'mgr' || empty($_POST['quick_order']) || empty($_POST['id']) || empty($_POST['customer'])) {
	return;
}
/**
 * @var miniShop2 $miniShop2
 */
$miniShop2 = $modx->getService('minishop2');
$miniShop2->initialize($context, array(
	'json_response' => false,
));
if (!($miniShop2 instanceof miniShop2)) {
	return;
}
$_POST['customer'] = array_merge(array(
	'delivery' => 1,
	'payment' => 1,
), $_POST['customer']);
foreach (array('email', 'phone', 'delivery', 'payment') as $field) {
	$response = $miniShop2->order->add($field, $modx->getOption($field, $_POST['customer'], ''));
	if (empty($response['success'])) {
		return;
	}
}
$response = $miniShop2->cart->clean();
if (empty($response['success'])) {
	return;
}
$response = $miniShop2->cart->add($_POST['id'], $modx->getOption('count', $_POST, 1), $modx->getOption('options', $_POST, array()));
if (empty($response['success'])) {
	return;
}
$miniShop2->order->submit();
$modx->sendRedirect($modx->makeUrl($modx->resource->get('id')));

Теоретически это возможно, только для осуществления заказа обязательно нужен email, соответственно для неавторизированных пользователей необходимо придумать, чем его заменить :)

В родительском окне создать функцию, допустим showProduct. В iframe к ней можно будет получить доступ через window.parent.showProduct(), в функцию можно будет передать все нужные данные о товаре.

Скрипты называются CSS Inliner. Есть разные библиотеки, например такая.