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

В настройках модыкса, у поля «server_protocol» — стоит «https»?

Не вводите в заблуждение человека. Эта системная настройка не работает. Она вообще в MODX не используется нигде.
Протокол соединения формируется исключительно на основе порта подключения. Если порт 80 — то http, если 443 то — https

Да, вот уже люди поделились что давно наблюдают. А я впервые заметил.
Но также есть те, кто вчера потестировал не по подтвердил. В общем странное дело.
Я автора уведомил, теперь пусть у него голова болит.

А зачем? И главное зачем?

А чем тебе корсы мешают подключиться из локалхоста к серверу?
Вроде решается же несколькими правилами. По крайней мере я не замечал какой то особой проблемы. Могу поделиться своим CORS конфигом (тоже сейчас на VUE работаю, когда админка локально, сервер удаленно)

Нарекаю тебе ответственным за MODX + VUE. С тебя обучалки

Чет вы по-моему путаете минишоп и тикеты. Если речь идет о товарах нужно смотреть права на товары.

Для любой операции с добавлением\редактированием товаров нужно право msproduct_save
Все процедуру проверки прав происходят в соответствующем процессоре.
Например mgr/product/update
Там строку с проверкой прав можно при желании закомментировать.

А что тут заготавливать? Пишешь приложение VUE выполняющее нужный тебе функционал.
От modx там только запросы на соответствующий коннектор, плюс потом загрузка скрипта внутри админки.
Но это столь незначительно что даже твой Тезка тут об этом не пишет, рассказывая что ведет разработку локально без MODX потом просто вставляя скрипт в коннектор.
Ну а как вставить скрипт в админку MODX более подробно освещал Баха, вот тут вроде бы

Не знаю что там внутри — но на первый взгляд выглядит прям революционно!
Обязательно к изучению

Насколько я знаю, на данный момент в системе LiqPay нет отдельной ссылки для отмены или неуспешной оплаты.
Компонент старый — давно писался — отсюда фактически неиспользуемая системная настройка.

Если и есть нечто подобное — значит нужно компонент переделать.

Все что касается VUE понятно. А вот как скрестить админку MODX и VUE — уже сложнее.
Как вовремя поймать наложения скриптов и стилей админки и VUE? Как вовремя отловить все баги без постоянного деплоя.
Это наверное лучше локально на рабочей машине развернуть MODX и сразу на месте все вопросы решать.

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

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

С заголовком 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>