Александр Мельник

Примерно такого поведения я и ожидал, как вы описали.
Не понимаю почему, но у меня получилось все в точности наоборот. Во-первых, применение группы ресурсов к группе пользователей ровным счетом ничего не меняет (и да, я выбирал политики доступа разные, в том числе и Resource как на вашем скрине). Пользователь в этой группе продолжает видеть в дереве все ресурсы. А вот удаление группы ресурсов из группы пользователей вдруг вызывает странное поведение — в дереве ресурсов явно начинает работать ограничение (почему? я ведь удалил группу ресурсов из группы пользователей). И плюс в дереве ресурсов вдруг оказывается тот ресурс, который я наоборот хотел скрыть.

мне помогла деинсталяция и повторная установка minishop.
Возникло ощущение, что этой версии minishop (3.0.7) крайне важно, чтобы при инсталяции уже был установлен pdotools.

Обнаружил и у себя такую же ошибку.

[2024-02-23 10:44:55] (ERROR @ /home/somedir/public_html/core/xpdo/xpdo.class.php : 644) Could not load class: pdofetch from pdotools.pdofetch.
[2024-02-23 10:44:55] (ERROR @ /home/somedir/public_html/core/xpdo/xpdo.class.php : 1248) Problem getting service pdoFetch, instance of class pdotools.pdofetch, from path 
[2024-02-23 10:44:55] (ERROR @ /home/somedir/public_html/core/components/minishop2/model/minishop2/minishop2.class.php : 642) pdoTools not installed, metadata for miniShop2 objects not loaded

modx 2.8.6
minishop 3.0.7
pdotools 2.13.2
php 7.4
устанавливал из modstore.pro

ps. при этом fenom работает. Кстати еще при инсталяции minishop заметил, что в окне установки отображались красным ошибки, что не найден pdoTools, но я посчитал что это нормально, поскольку на тот момент еще не устанавливал pdoTools

нет слов, вы большой молодец.

Могу высказать свое, личное и не объективное мнение.
Считаю что даже в 2023 году ни node ни vuejs все еще не доросли до такого уровня, чтобы их использовать как основной стек для крупных, серьезных проектов. К самой ноде особых притензий нет, но поскольку она всегда идет в связке с каким то vuejs или react то и говорю о них как об едином целом.
Почему я так говорю. Ну во первых из последнего опыта. Долгие годы работали с классическим стеком технологий для веба, последние два проекта решили делать «модными». Тем более что это были закрытые crm системы и там не нужно было думать о сео и как следствие о ssr.
Наняли специально фронтендщиков, которые в грудь себя били что ничего лучше vuejs в мире не бывает и что они любую задачу там решат. И что в итоге — полный провал по всем срокам, все задачи выполняются в 4-10 раз дольше. Постоянные проблемы с тем, что никто не хочет писать ничего своего, все из готовых vue компонентов собирается и оказалось, что сложные вещи делать на vue очень сложно. Все привыкли какой-то туду лист по примерам сделать и считают что все — теперь на vuejs могу любой сложности проекты делать. А потом приходит заказчик, говорит, мол отличная таблица с данными, только встройте в нее такой то функционал и вот такой то, разработчики пытаются один готовый компонент впихнуть в другой, возникает кучу проблем. Короче говоря, то, что я могу сделать на чистом js/html/css за день (при условии что я бекендщик) на vue занимает недели. А учитывая, что заказчик очень переменчивый и может каждый день менять решения, то внести визуальные и логические изменения становится нашим фронтендищикам все сложнее и сложнее.
Можно и нужно конечно сказать, что это нам так не повезло, что мол есть фронтендщики которые делают любой сложности задачи и быстро. Может и есть, но у нас это уже третий опыт, третья попытка нанять опытных фронтедщиков и третий раз она заканчивается полным срывом сроков.
Но это мой опыт, но есть и другие звоночки, что сама идея современного фронтенда (рендеринг на клиенте) не была гениальной и может в скором времени быть признана неперспективной. Видели новый next.js? В нем разработчики делают шаг назад и постепепенно отказываются от рендеринга на фронте. видео
Мой вывод (очень субъективный) — на 2023 год vuejs все еще интересный, но не продакшен реди инструмент, на котором легко делать простые вещи (туду лист и прочее) но сложно и долго делать сложные вещи.

Не знаю почему у вас работает. Я отрыл в документации (и даже по той ссылке что вы дали на mdn это тоже написано), что включение mode no-cors позволяет использовать только простые запросы.
Кстати до сегоднешнего дня не знал, что запросы делятся на простые и сложные. Но как оказалось, если запрос содержит content-type — aplication/json он уже считается сложным.

Простой запрос – это запрос, удовлетворяющий следующим условиям:

Простой метод: GET, POST или HEAD
Простые заголовки – разрешены только:
Accept,
Accept-Language,
Content-Language,
Content-Type со значением application/x-www-form-urlencoded, multipart/form-data или text/plain.

Любой другой запрос считается «непростым». Например, запрос с методом PUT или с HTTP-заголовком API-Key не соответствует условиям.

If mimeType’s essence is not «application/x-www-form-urlencoded», «multipart/form-data», or «text/plain», then return false.

Поэтому насколько я понял, fetch принудительно меняет заголовок на text, если я указал mode no-cors.
Хотя у вас работает.
Я тоже грешил на сервер, потому что это мной построенные на docker целый кластер из контейнеров, с двойным проксирование запросов и напартачить там можно было во многих местах. Но запросы с postamn, curl — проходили правильно, с корректным content-type.
Пришлось более глубоко вникнуть в работу cors. Убрал из fetch no-cors и реализовал у себя в приложении обработку предзапроса по методу options. Полнейшее для меня открытие, но оказалось что как только мы хотим сделать «сложный» запрос на «не свой домен», перед основным запросом браузер отсылает предварительный запрос на тот же url но только методом options и просит разрешения на основной запрос.
Как только я организовал у себя обработку этих предзапросов и возврат корректных (по документации заголовков), у меня все заработало.

Прекрасно, что удалось открыть что то новое для себя и спасибо за подсказки.

я понял, это наверное изза

mode: 'no-cors',

Если делаю этот же запрос, но через postman, выбрав body->row-json
то запрос на сервер приходит с корретным Content-Type.

Так же проверил, что fetch автодектит тип данных и если совсем удалить заголовок и передать в запросе FormData, то он подставит заголовок корректный.
И я даже согласен с тем, что json по своей сути это текст, а значит можно сказать что fetch передал по умолчанию заголовок Content-Type:text/html, но почему он игнорирует заданный в парметрах заголовок, пока для меня загадка.

Действительно важные улучшения.
И превьюшки приходится перегенерировать часто. И импорт из коробки пригодится. (кстати только импорт? экспортировать нельзя?)
Спасибо.

Насколько я понимаю, должно произойти нечто подобное, что произошло с opencart.
Есть opencart, разрабатываемый американским разработчиком, есть отдельный (форк? не люблю я этот жаргон, скоро совсем уже нормальных слов не останется) — ocstore, который хоть и базируется на opencart но делается отдельными разработчиками, со своими модулями и дополнениями.

спасибо, Алексей.
нужная вещь и сделана с душой, код качественный.

сложно четко разграничить на «черное и белое», мол вот это костыль, а это нет, поэтому я так и написал — ощущение костыля. Но я не могу пока предложить решения лучше.

может. а смайлы чтобы хранить в базе данных, насколько я знаю, нужно еще и определенную кодировку устанавливать — utf8-mb4
а у вас на скрине другая. Это тоже может быть причиной.

Добавлю немного картинок, текст это всегда скучно)

только сейчас «догнал» что под строкой «536870911» вы имели ввиду длину данных в sql, а не строку, которую вы пытаетесь сохранить в это поле.

тоесть поведение изменилось? До этого вы вставляли длинную строку и говорили что она ОБРЕЗАЕТСЯ, а теперь вставляете короткую строку и пишите, что она НЕ СОХРАНЯЕТСЯ совсем?
Выглядит странно, по идее Денис все верно сказал, нужно изменить тип поля value. На самом деле максимальную длину хранимых данных данных можно и не указывать, будет выделено 65 килобайт под каждое значение.
По идее, вам и стандартного mediumtext должно было хватать, под него выделяет 16 миллионов символов, ну неужели ваш json был больше.
Проверяйте ошибки в логах, как в браузере в момент сохранение, так может и логи на сервере.
У меня родилась теория, что ваш json мог обрезаться не по причине длины строки, а по причине того что в его тексте встречался какой то запрещенный в sql символ, хотя это не поясняет ту ситуацию что вы описали в последнем коменте — не сохраняется даже простая строка «536870911»

плюс лично мне очень не нравится сама идея, когда ajaxForm (и fetchIt я думаю делает так же), хранит данные для форм в сессии.
Вся эта идея с генерацией уникального ключа для каждой формы, помещения по этому ключу данных в сессию, при отправке формы считываная этого с сессии… вызывает ощущение дикого костыля. Да, я вынуждем признать, что когда я писал свой аналог ajaxForm я тоже не придумал ничего лучшего и использовал этот же костыль.
Может быть, отчасти, именно поэтому я все реже и реже использую ajaxForm и его аналоги на сайтах и предпочитаю оставить форму в верстке, написаь свой js обработчик и свой php контроллер для отправки.

Вот видите как иногда полезно узнать чужое мнение. А то каждый «в своем мирке» и привыкает использовать инструменты только для каких то строго определенных целей. Я вот например использую ajaxForm (да я понимаю что речь идет о fetchIt, но задачи у них общие) только для примитивных форм в модалках, типа — заказать обратный звонок и так далее. И там необходимо, чтобы данные очищались. Если уже делать что то более серьезное, например личный кабинет о котором говорил Артур, то я предпочту писать все сам, благо сейчас на чистом js очень просто и подписаться на событие submit формы, и собрать данные через formData и отправить их на сервер через fetch и дождаться ответ через promise. Это приносит огромное ощущение удовлетворенности, что каждая строчка кода в личном кабинете написана тобой, что ты именно Разработчик, а не собиратель конструктора из чужих пакетов. Спасибо за ответы, я правда не мог подумать о таких способах применения этого пакета.

Прямо и восхищение и удивление у меня возникло.
Удивление вызвал Константин, вот прям интересно стало, зачем может понадобиться не очищать форму, после того как она отправлена? Это вроде бы такое странное поведение, все равно что пригнать машину на мойку, но попросить оставить грязным две двери) Ну тоесть теоретически там может быть, но зачем.
Расскажите пожалуйста, Константин, побалуйте пожалуйста мое любопытство, для каких целей форма должна оставаться с отправленными данными…
Ну а восхищение вызвал Баха, которые несмотря на нелогичность этого действия, даже добавил в сниппет параметр, за это отвечающий.

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