Павел Гвоздь

Да этот код старый, как незнай что…
По идее правок в 3 первых событиях должно хватить.

Да.

Он в точности повторяет Radio, используйте его с шаблоном под select.

А проверить не вариант? Это старый метод. Лучше использовать вебхуки.

Нету.

Второй вопрос: Присутствует ли возможность редактировать шаблон множественного балуна?

Шаблоны балунов вообще не редактируются в компоненте.

Первый вопрос: Чем отличается параметр mode: default от mfilter2 помимо того что во втором используется платный компонент mSearch2?

Не понял вопроса.

Здесь.

Нигде.

Первая версия не моя, поэтому никаких обновлений и поддержки по ней от меня нет.

Как RSS. Остальные вопросы пишите в ТП на Modstore.

Там можно навесить плагин на каждую строку парсинга, вот так можно будет. Из коробки работа с msop не предусмотрена.

Каждый раз надеюсь на лучшее, но опять все зря

А на что именно надеешься и что именно получается? Потому что я лично вижу позитивный эффект на заметке про GraphQL с тех деталями.

Это ведь не Хабр

Разве не хорошо, что на modx.pro начали появляться публикации любой направленности? Помоему, это круто! Правда я считаю, что надо побольше технических деталей. Хотя мне ли говорить подобное, у самого есть такие посты…

Технических деталей не будет, они вроде никому не нужны

Ну конеш, нам лишь бы в майнкрафт игрануть))

это typescript?

Ага.

TS, как минимум, теперь приходится чаще использовать. Контекст не в том, что JS «типизированнее» PHP…

GraphQL реализация есть и на php.

В курсе, а ещё на куче других языков. Но в данном же случае обсуждается твой вариант реализации (на JS) и вариант Андрея (на PHP).

Тут вопрос спорный. Уже довольно много средств есть для генерации всего и вся, в том числе резолверов. К примеру, на той же призме, достаточно описать схему и запустить деплой, будет не только структура БД создана, но и сгенерированы CRUD-резолверы, включая условия поиска, сортировки и т.п.

То есть, на примере ИМ, можно просто описать схему запросов и мутаций для msCategory, msProduct, msOrder и т.п. и оно поедет?

рассчитывая, что ответ придет в соответствии с документацией

тогда-то и посыпались ошибки

примерно это я и здесь буду сейчас это проходить

Смею возразить, что не «это» и даже не «примерно». Ведь когда тебе разработчик с того конца даёт доку, то ты рассчитываешь, что в ней отражены все нюансы и тонкости, если нет — это плохой тон. В данном случае автор т.н. API, которое мы фактически парсим, ничего нам не должен и в любой момент может поменять любой тип данных от чего GraphQL начнёт ругаться.

К слову, я вообще по себе заметил, что работая с JS я стал более внимательным к типам данных и условиям

Вот это неоспоримый факт! Я порой офигеваю от того, что я делал раньше на PHP. Жжжуть…

7. modstore.pro и modx.pro судя по всему — это абсолютно разные сайты со своими отдельными базами данных.

Так и есть, Василий ни раз об этом говорил.

какой лучше

Это смотря для каких целей.
— Если тупо всю необходимую инфу получать и выводить о товарах, то RESTful подойдёт, он же проще ставится и работает только на PHP, на котором и сам MODX крутится.
— Если же нужна универсальность API, для какого-то мобильного приложения или SPA, то GraphQL будет предпочтительнее. Правда работы изначально придётся провести довольно много, чтобы прописать всё взаимодействие (запросы, мутации, подписки) в резолверы.

1. Вопрос: кто вообще что-то на замену phpThumb юзает?

github.com/Intervention/image

… github.com/lovell/sharp… библиотека в разы просто качественней ...

Согласен. Мне тоже нравится Sharp.