Максим Кузнецов

{'!AjaxForm' | snippet : [
	...
	'emailFrom' => '{$_modx->config.emailsender}',
	...
]}

— нет нужды для повторного открытия {}, т.к. в самом сниппете они уже используются => вы уже внутри синтаксиса fenom. Так будет правильнее:

{var $emailto = 1 | resource : 'form.emailTo'}

{'!AjaxForm' | snippet : [
	'snippet' => 'FormIt',
	'form' => 'form_tpl.Callback_popup',
	'hooks' => 'spam,email',
	'emailTpl' => 'form_tpl_report.Callback_popup',
	'emailTo' => $emailto,
	'emailFrom' => $_modx->config.emailsender,
	'emailFromName' => $_modx->config.site_name,
	'emailSubject' => 'Заказ звонка с ' ~ $_modx->config.site_url,
	'validate' => 'workemail:blank,phone:required',
	'validationErrorMessage' => 'В форме содержаться ошибки!',
	'successMessage' => 'Спасибо! Ваше сообщение успешно отправлено',
]}

1. Копируете файл mfgost.tmweb.ru/assets/components/ajaxform/js/default.js в произвольное место.
2. В параметр сниппета добавляете &frontend_js=`/путь_до_нового_файла`

Сам jGrowl в файле подключается буквально в первых строчках:

if (!jQuery().jGrowl) {
	document.write('<script src="' + afConfig['assetsUrl'] + 'js/lib/jquery.jgrowl.min.js"><\/script>');
}

— можно в свежесозданном файле удалить эти строчки и подключить jGrowl вручную.

Почему у вас меняется jgrow.min.js на jgrowl.js — вопрос хороший, но без дополнительных данных/доступов сказать без хрустального шара особо не получится. Можно попробовать решить «общими» методами:
— переустановить ajaxForm
— почистить кэш

Вообще, таких проблем «из коробки» нет, так что причин может быть много, начиная от самописных плагинов и заканчивая хостингом.

А getComments без параметра threads корректно выводит комментарии?

Если да — можно попробовать ограничить результаты при помощи параметра &where:

&where=`{
	"Ticket.id": айди
}`

Попробуйте вызвать сниппет без параметра includeThumbs, а превьюшку отобразить в чанке через плейсхолдер [[+thumb]]

Как вы сейчас вызываете миниатюру в SimpleSearch?

msGallery автоматически закрашивает в белый, как оставить прозрачный фон в изображении?

Это баг текущей версии phpThumb, установленной в MODX. Лечится вот так.

Смотрите журнал ошибок MODX'a.

А какой вопрос у вас возникает?

mfgost.tmweb.ru/assets/components/ajaxform/js/lib/jquery.jgrowl.js — этого файла у вас нет, зато есть вот такой:
mfgost.tmweb.ru/assets/components/ajaxform/js/lib/jquery.jgrowl.min.js

Вы можете отредактировать его пути в подключаемом файле ajaxform (и попутно вынести его в другое место через параметр &frontend_css, чтобы ваше изменение не затерлось при обновлении) — и ошибка пропадет.

Да, только у тебя.

На будущее — в правой части сайта есть форма поиска.

Шаблон то у вас формируется, но в процессе работы очищается.
Скорее всего, где-то здесь:

/assets/themekalisto-design/js/scripts.min.js

Попробуйте ограничить выборку getComments через параметр &parents.

Есть 2 относительно безболезненных решения задачи:

1. Создать 2 страницы — одну с простой формой (form), и другую с вызовом msOrder. По заполнению первой, передавать все данные при помощи get/post и переадресовывать на вторую. Если какие-то поля, заполненные с первой страницы, нужно запретить к редактированию, то добавляете в чанк msOrder disabled.

2. Создать страницу с вызовом msOrder и дополнительный статус заказа, например «ожидает подтверждения» (для него отключить отправку писем). По оформлению заказа отображать дефолтную страницу «ваш заказ оформлен» с подредактированным оформлением + самописным сниппетом/процессором, который при отправке будет менять статус заказа на «новый» + опционально редактировать доступные поля заказа.

1. pdoMenu быстее
2. в нем точно реализована поддержка параметра &where. Насчет wayfinder — не уверен.

Кэш.

Конструкцию вида [[~[[+id]]]] в чанке лучше переписать на [[+uri]] — это избавит от выполнения лишних операций да и ошибка в логе пропадет.

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

Вариант 1 — дописать условие для ограничения выборки:

&where=`"parent:NOT IN": array(айди_родителя_1, айди_родителя_2)`

Вариант 2 — спрятать пункты визуально в чанке:

[[+parent:is=`айди_1`:or:is=`айди_2`:then=``:else=`оформление`]]

Ну и на pdoMenu лучше переписать, конечно.

core/components/minishop2/model/minishop2/msorderhandler.class.php

//строка 221
$value = substr(preg_replace('/[^-+0-9]/iu', '', $value), 0, 15);

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

Подскажите, пожалуйста, текущая версия (1.6.3) — рабочая?

Создаю свой расширяющий класс:

<?php
	require_once dirname(dirname(dirname(dirname(__FILE__)))).'/xlsx/console.class.php';

	class modModimporterCustomImportMinishopConsoleProcessor extends modModimporterImportXlsxConsoleProcessor {
		public function initialize(){
			$this->setDefaultProperties(array(
				"category_root_id"  => 1,
				"category_template_id"  => (int) $this->modx->getOption('modimporter.category_template_id'),
				"good_template_id"  => (int) $this->modx->getOption('modimporter.product_template_id'),
			));
			
			return parent::initialize();
		}


		protected function StepWriteTmpCommercialInfo(){
			return $this->nextStep("modimporter_write_tmp_goods", "Тест", null, xPDO::LOG_LEVEL_WARN);
		}
	}

	return 'modModimporterCustomImportMinishopConsoleProcessor';

И на выходе получаю ошибку:

PHP warning: Declaration of modImporterReader::initialize(modProcessor &$processor) should be compatible with modProcessor::initialize()

Да с кастомизацией есть небольшой простой в дополнениях, согласен — отчасти, пожалуй, потому что для менеджеров все-таки лучше отдельную админку пилить.)

Если коротко, решений для кастомизации админки и готовых модулей, по-сути, три:

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

— Плагины, расширяющие/заменяющие те или иные элементы дополнения. Можно как «вклиниваться» в логику работы дополнения (если у него есть такая возможность и нужное событие), так и «скрывать» неугодные элементы через ext.js примерно так:

<?php
	switch ($modx->event->name) {
		case "OnDocFormPrerender":
			$modx->controller->addHtml("
				<script type='text/javascript'>
					//ищем нужную вкладку по айди.

					//Например свойства товаров minishop'a: 
					Ext.ComponentMgr.onAvailable('minishop2-product-tab', function() {					
						this.on('afterrender', function() {
							//При помощи методов ext.js ищем нужный элемент и работаем с ним

							//Например, найдем по лейблу поле "цена" и спрячем ее из отображения
							//В примере ищем по лейблу, т.к. легче найти контейнер-родитель (если искать по айди input'a - то главный контейнер-родитель может находиться на разном отдалении
							Ext.get(Ext.query('label[for=\"modx-resource-price\"]')[0]['parentElement']).setStyle('display', 'none');
						});
					});
				</script>
			");
			
			break;
	}

Таким способом можно прятать определенные поля для менеджеров, которые недоступны для редактирования из Настройки форм.
Нюансы этого способа: пусть и небольшая, но лишняя нагрузка. Также во многих модулях не получится полностью убрать элемент способом .remove(), т.к. на примере тех же «свойств» товаров, при перещелкивании табов, в таком случае формы будут отрисовываться заново.

— Подключить свой css-файл в админку и через него и !important дописывать нужные свойства к любому модулю. Плюс в том, что не придется лезть в ядро дополнения, если оно не поддерживает предыдущие методы.

<?php
	if ($modx->event->name != 'OnManagerPageInit') return;
	$modx->regClientCSS('/design/admin.css');

Про виджеты особо рассказывать нечего, разве только о взаимодействии с тем же ext.js..)

Оум, спасибо..)

Ну, контексты здесь больше не для визуального разграничения, а для того, чтобы менеджерам не мозолить глаза техническими страницами (контекст для них спрятан).
По виджетам тоже настройка довольно простая, вроде даже рассказывать нечего… Разве только дефолтный shopStats переписан.
Если есть какой-то конкретный вопрос по модулю — спрашивайте, расскажу.)

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

Надеюсь, как закрою большую часть проектов, доберусь написать какой-нибудь комплексный гайд по созданию сайта, с учетом fenom-a и относительно свежих решений..)

Понятно.)
В принципе, готов заняться, если сроки не «горят», как раз сейчас закрываю проект с тем же функционалом и схожей тематикой (товары в стадии заполнения, пример заполненной рубрики) — т.е. где-то можно будет сэкономить.

Бюджет: минимальный от 80 (если экономить вообще на всём), максимальный — до 150-170.

Вопрос: нужен ли алгоритм поиска по вин-коду? — с запчастями это довольно актуально.