Николай Савин

Слушай я по рабочему процессу решил отдельную ветку написать. Интересно стало.
Получается у тебя нода крутится на сервере, код ты пишешь локально?
Я так понял — при написании кода у тебя срабатывает автодеплой, нода на сервере подхватывает изменения и сразу же их показывает с перезагрузкой страницы? Это прямо в админке происходит? или ты отдельную страничку завел для тестов?

Уф. Вроде осилил. Не зря заказывал — спасибо порадовал.

С заголовком modAuth проблем нет, но куки приходится прокидывать в кастомном заголовке modCookie (предварительно разрешив его политикой Access-Control-Allow-Headers), который уже на сервере обрабатывается и добавляется в PHP массив $_COOKIE. После чего запрос успешно авторизовывается и возвращает данные из процессоров.

Интересный подход — нужно попробовать. Я в последнее время много локально со VUE и Реактом работаю и как то чаще велосипед с какими-нибудь токенами изобретаю. Ну и плюс CORS на сервере настраиваю.

MODSESSID, PHPSESSID. Может кто глубоко погружался, зачем нам два разных ID сессии?)

Это все чтобы кто-попало в MODX не приходил. Только истинные любители садо-мазо программирования.
Если не ошибаюсь MODSESSID для аутентификации в коннекторах админки да?

/usr/bin/php7.4 ~/www/core/components/yandexmarket2/cron/generate.php

Зачем усложняешь?

php7.4 ~/www/core/components/yandexmarket2/cron/generate.php

Напомню, что для сгенерированных MODX-классов (которые от xPDOSimpleObject) сделал свои proxy-классы Pricelist, Field и т.д, наследуемые от базового абстрактного.

А для чего такое решение? Чем не устроило то что есть в xPDOSimpleObject например?

Возможно, этот механизм нужно будет внедрить в miniShop2 (там рефлексия не нужна, а просто хватит проверки, все ли поля были получены для этих объектов из базы и засеттить их в соответствующие свойства).

Ох Женя это нехилый такой мажорный апдейт получится. Только не скоро у нас уже miniShop v3.0 запланирован с гораздо более простыми изменениями, которые нужны в первую очередь. Но вообще интересно. Я бы почитал исходники на предмет внедрения. А еще всегда можно прислать PR

MODX а не miniShop

Отлавливайте клик средствами JS. Передайте куда нибудь в data атрибут идентификатор товара.
После того как поймаете клик по нужному товару — сформируйте ajax запрос на сайт.
Ловите запрос через плагин на событие onHandleRequest и далее уже средствами php как-нибудь запоминайте этот товар как избранный

Вообще если честно судя по списку ваших вопросов я вам вряд ли смогу помочь подобными алгоритмами.
Больно уж много знать нужно о MODX

Суть будет примерно такая.

1. Нужно создать таблицу в базе данных. Поля user_id — число, session_id — строка, product_id — число
2. Создать модель для этой таблицы, чтобы modx знал о ее существовании.
3. Создать класс управления таблицей. Основные методы add(), remove(), getList(), может быть getCount()
4. В каждом методе написать обращение к таблице и ее чтение, добавление записи, удаление записи.
5. При записи в таблицу если пользователь авторизован — записывать его Id как идентификатор, если нет — то записывать session_id
6. Подготовить js файл который по клику будет определять чего хочет пользователь и слать запрос на корневой адрес сайта
7. Подготовить плагин на событие OnHandleRequest который будет слушать обращения JS файла и вызывать класс компонента и соответствующий метод.

Это очень простая задача — и отлично подходит для практики написания собственного компонента.
Всего одна табличка в базе данных плюс взаимодействие с ней.
Если хочешь могу подсказать логику реализации.

Добрый день.
В минишоп нет такой возможности из коробки.
Данный вопрос уже всплывал недавно, он добавлен в список «Хотелок» и в «ближайшем» будущем будет реализован.
Пока что ваш вопрос можно решить следующим образом.
Согласно документации создать и подключить свой класс оформления заказа, устранив оттуда логику создания заказа. Честно говоря не проверял — нужно пробежаться по коду — но из за отсутствия юзера в заказе проблемы могут возникнуть в самых неожиданных местах. Например где-нибудь в таблице заказов.

У ajaxForm нет системных настроек. Стили и скрипты передаются как параметры сниппета.

Близко к правде но есть нюансы. В вызове сниппета нужно создать переменную и с ней работать.

{var $clients = '!hookbackclient' | snippet}
			    		{foreach $clients as $user}
 								<tr class="title">
				    			<td class="table">{$user['name']}</td>
				    			<td class="table">{$user['surname']}</td>
				    			<td class="table">{$user['phone']}</td>
				    			<td class="table">{$user['email']}</td>
				    			<td class="table">{$user['recorders']}</td>
				    			<td class="table">{$user['paid']}</td>
				    		</tr>
							{/foreach}

А еще с данными массива можно работать через точку. Так чуть быстрее писать

<td class="table">{$user.paid}</td>

Правильнее всего сделать просто

return $users

А в шаблоне (или чанке) использовать шаблонизатор fenom и его метод foreach для вывода результатов.

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

Не нужно использовать такое. Эта дрянь никогда нормально не работала.
Пользуйтесь шаблонизатором fenom вообще, в том числе и для подобного. Материала на форуме для этого предостаточно.

Конкретно ваш вопрос решается вот так

{if '' | isloggedin : 'web'} 
    <li><a class="top_menu" href="{19 | url}">Личный кабинет</a></li>
{else}
    <li><a class="top_menu" href="{19 | url}">Вход</a></li>
    <li><a class="top_menu" href="{17 | url}">Регистрация</a></li>
{/if}

Еще проблема с изменением общей итоговой стоимости, при условии что мы меняет количество товаров или добавляем

Компонент же не про логику, а про дополнительные поля. К расчету стоимости он отношения не имеет.

вместо extjs windows накинуть treepanel или tabpanel.

Ну вас понесло. Как будет выглядеть интерфейс miniShop2, и используемый стек решает его владелец @Иван Бочкарев и команда разработчиков. Да и в целом не нужно в подобном компоненте подобную кашу возможностей разводить. Один компонент — одна решаемая задача. В данном случае удобное добавление дополнительных полей.
Вот работа с другими таблицами минишопа здесь была бы логичным продолжением. Можно добавлять поля в свойства товара, в производителя и т.д.

Интересно, а скрипт ноды для генерации изображений все время активен на сервере или запускается по расписанию?
Там какой то потоковый сборщик запущен с нужным пайпом или чисто JS скрипт с библиотекой?

Не, не обязательно. У многих платежек есть рекомендации слушать не только обращение к коннектору но и чекать IP. Все по делу написано.

Печально (

Познавательно!

Добрый день. В нашей версии Paypal проверка по IP адресам не используется вообще

Ну чтобы ошибки не было нужно написать вот так

$price = 0;
if($mod) {
$price = $mod->get('price');
}

У вас почему то запрос к модификации не происходит. Ошибки не будет, но и цену не получите.
Скорее всего неверно $option['modification_id'] написал.
Навскидку не помню как номер модификации в заказе хранится.
Распечатайте посмотрите — и скорректируйте этот момент.