Олег

Проблему помогли решить на Гитхабе данного компонента. Оказывается, переключение контекста в системе должно срабатывать РАНЬШЕ, чем событие, к которому привязан ClientConfig (OnMODXInit). У меня переключение контекста срабатывает самописным плагином для Бабела в событии OnHandleRequest, которое идёт после OnMODXInit. Соответственно, для нормальной работы компонента с контекстами, мне нужно было сделать переключение контекстов на событии OnMODXInit, а для плагина ClientConfig на этом же событии выставить приоритет 1, вместо 0. Надеюсь, никакие косяки после таких манипуляций не вылезут…

Спасибо. Я решил проблему немного иначе:
```
var comboData = JSON.parse(MODx.config[«mycomponent.combodata_array»]);
```
В настройке массив хранится в виде:
```
[[«val1», «Label 1»], [«val2», «Label 2»], [«val3», «Label 3»]]
```

Подскажите, пожалуйста, как сделать, чтобы массив data (значения для выпадающего списка) брался из системной настройки MODX?

Язык админки можно настроить индивидуально для каждого пользователя (менеджера) стандартными средствами MODX, переопределив системную настройку «manager_language» в разделе Пользователи -> Настройки. Тоже самое и для контекстов. Или с этим какието проблемы? А дизайн страницы входа в админку переопределяется в папке /manager/templates/TEMPLATE_NAME/security/login.tpl — там и логотип можно любой поставить, и свой дизайн сделать за 5 минут.

Тоесть, тех, кто думает не так как вы (кстати, «вы» — это кто? принимающие решения, или нанятые программеры?), вы просто «посылаете»? Это не профессионально, особенно внутри сообщества. Я не говорил о создании новой CMS, только указал очевидные недостатки текущей и предложил концепцию их исправления. И это, между прочим, не мои идеи, а многих, кто работает с MODX как инструментом создания конечного продукта (веб-сайта для клиента), а не дополнений для самого MODX, с целью их продажи в маркетплейсе. Не знаю, что там внутри происходит у вас, но MODX Evo пошёл уже по своему пути новой «Мега CMS», как ты говоришь (уже Twig там планируют и кучу других полезных и удобных для разработчиков вещей), потом наблюдаю дискуссии по поводу SLIM Framework, которая также к разделению приводит… Неумение принимать и понимать мнение большинства других людей, которое не совпадает с собственным, приводит, обычно, к расколу и прочим негативным последствиям. Я искренне не хочу, чтобы в будущем MODX стал тупиковой веткой в развитии PHP CMS систем. Я люблю MODX за многие идеи, которые в нём есть (отделение контента, отделение дизайна, свобода выбора архитектуры приложений итд), но есть моменты, которые меня огорчают. И когда команда, которая взялась за развитие этой некоммерческой системы и работающая за ресурсы общественности и спонсоров, говорит, что вещи, которые на самом деле важные, пока в приоритетах не стоят, то это печалька… Может разумнее было бы провести опрос в сообществе, по поводу ключевых моментов развития системы в дальнейшем? Чтобы потом не переписывать всё заново, или, не дай Бог, расколоть и так немногочисленное сообщество.

Дополнения напишутся новые, гораздо быстрее, если разработчикам не нужно будет изучать для их создания специфичные и практически нигде, кроме MODX, больше не используемые инструменты, вроде ExtJs и xPDO. И будут эти дополнения намного качественней и практичней тех, что есть сейчас для Revo, так как круг разработчиков расширится, уменьшив порог вхождения. Ну да, совместимости не будет со старыми дополнениями Рево, большинство из которых (по крайней мере в официальном репозитории) так и остались в стадии беты или RC и не обновляются по несколько лет. Почему? Да потому что это СЛОЖНО и невыгодно, а не как могут сейчас мне ответить «руки из ж*пы». Если стоит цель сделать Open Source CMS популярнее, то надо делать её доступнее и понятнее широкому кругу разработчиков, а не только поклонникам cms.
А по поводу пользовательского опыта — выглядеть всё может точно также, админам по сути по барабану, на чём там работает админка. И на чистом HTMl + CSS она бы работала намного шустрее, чем то убожество, что сейчас, которое отпугивает клиентов. Дошло уже до того, что сами разработчики Рево пишут для своих клиентов персональные админки, а всю работу с кодом переносят в IDE. Да, я считаю. мой план отличный. Когда MODX Revo создавался, никого не остановило это, и потеря совместимости, и клиентская база. Время и технологии не стоят на месте.

Рискну написать своё ИМХО, как веб-разработчик, а не специалист по MODX. Все вышеперечисленные изменения не тянут на смену ветки на «MODX 3» (или мажорный релиз, как там это называется). К чему спешка выпустить именно «новый продукт» этим летом? Ведь по сути, нового там толком ничего и нет. Внешний вид админки? Composer? Это может быть MODX 2.7. Настоящий MODX 3, лично в моём понимании — это:
1) MODX с админкой БЕЗ ExtJs (и вообще без всяких фреймворков и прочей джаваскрипт ереси) — на чистом PHP (REST) + HTML + CSS. Это даст разработчикам вздохнуть на полную грудь.
2) MODX без кастрированного парсера, который также уже надоел. Было бы круто, чтобы можно было подключать сторонние шаблонизаторы (по желанию) композером и писать PHP прямо в шаблонах. Концепция сниппетов отпадёт сама собой. Всё равно доступ к шаблонам можно ограничить для контент-менеджеров и других юзеров бекэнда.
3) MODX без xPDO — не надо рассказывать о его удобстве, все мы пользуемся pdoTools, огромное спасибо Василию за это прекрасное решение.
4) MODX с нормальной поддержкой мультиязычности, для ресурсов и дополнительных полей. То, что сейчас — это пародия на мультиязычность, которую приходится использовать, дополняя её Бабелом, Локализатором и др. дополнениями — спасибо авторам этих дополнений. Вообще — уже явно видно, что само ядро системы и некоторые её концепции неудобны, люди придумывают дополнения для решения обычных задач, которые должны быть из коробки в CMS в 2018 году.
Вот это была бы MODX 3. А вы тут про новый экран входа в админку говорите… Я понимаю, что на это всё надо много денег, времени и усилий, но ведь проблема в выборе пути движения, а не в скорости езды. Денег там, судя по данным с modx3.org уже немало собрано. Я даже не знаю, сколько разработчики там получают, но лучше заплатить программисту за переписание интерфейса менеджера без JS, чем дизайнеру за красивый UI, который всё равно потом переписывают конечные разработчики для своих клиентов. Если организовываются донаты, то хоть прислушивайтесь к мнению народа, который уже давно просит вынести хранимый код элементов в файлы на уровне ядра, отправки на покой ExtJs итд. Честно, я не понимаю, куда движется MODX.

А если вместо {include… писать {insert… — это увеличит производительность? Кто нибудь замерял?

Отключил Пушер в настройках компонента — всё заработало. Проблема, видимо, в реализации взаимодействия с Пушер, так как в самом Пушере все настройки совпадают с настройками компонента (кроме Кластера, настройка которого в компоненте отсутствует).
Теперь у меня другой вопрос: как с помощью данного компонента вывести последние, например, 5 сообщений из группы или канала, в котором Бот является участником (или даже админом)? Нигде не нашёл такой информации, ни в АПИ, ни не форумах. Мне удалось сделать что-то подобное, создав другого бота (без webhook), и при запуске компонента из сниппета я подменяю токен (параметр «modtelegram_api_key») на токен бота без вебхука. Таким образом получаю обновления через метод «telegramGetUpdates()». Но в таком случае бот выводит даже те сообщения, которые он получает от абсолютно любого пользователя Телеграмма, а нужно только сообщения от членов группы. Поставил фильтр по «chat_id», но тогда возникает проблема с количеством принимаемых обновлений. Например, если последние 5 сообщений были от «левых» пользователей (команды, вроде "/start" итд.), то выводить на сайт нечего, а Оффсет обновлений сдвигается. Вот такие дела… Кто может подсказать?

Чат мне удалось запустить (параметры, оказывается, нужно было давать созданному боту через Телеграм-клиент). Но теперь другая проблема: чат на сайте не обновляется без перезагрузки страницы. Сообщения в Телеграм-клиент приходят, но ответы на сайте в чате не отображаются (собственные сообщения тоже), без перезагрузки страницы и повторного нажатия кнопки чата. В пушере создавал разные вебхуки (webhook.php, pusherhook.php). Не помогло. Читал, что проблема может крытся где угодно — в настройках скрипта (параметр кластера), в самом коде JS итд. Что делать — не понятно.

Подскажите, пожалуйста, как начать работу с данным компонентом? Где прописывать эти команды "/login_user_password" итд? В инструкции, к сожалению, совсем мало информации, и для людей, плотно не знакомых с особенностями Телеграм достаточно сложно разобраться. У меня при нажатии кнопки чата выдаёт сообщение, что нет доступных менеджеров. Я так понял, что пользователя админки надо как-то залогинить с помощью скрипта webhook.php, верно? При обращении к этому файлу в браузере постоянно выдаёт Access Denied, какие бы GET параметры я не прописывал (action=login, /action/login итд). Где можно более подробно почитать, как всё пошагово настроить? Вебхук я поставил, пушер зарегил, все настройки прописал. Ничего не работает.

Спасибо! Я решил отказаться от компонента SimpleSearch (он, если честно, мне не сильно нравился) в пользу Вашего предложения с pdoPage — работает отлично. Единственное, не знаю как вывести «extract» (кусок текста до и после искомого слова), но это мелочи. К тому же, используя pdoResources можно в будущем расширить функционал поиска и подключить ТВ поля (SimpleSearch поиск по ТВ полям не поддерживает). Вообще, есть ещё много компонентов, которые пока ещё не поддерживают работу с Fenom. Возможно, есть какое-то универсальное решение для таких компонентов, вроде плагина, который бы проверял наличие pdoTools и подменял парсер?

Может кто знает, какие правки нужно внести в код сниппетов SimpleSearch и SimpleSearchForm, чтобы они начали понимать Fenom? Весь сайт на Феноме написан, не хочется запускать стандартный парсер.

Это весьма странный подход. Если говорить о полноценной мультивалютности (как в Opencart, например), то, судя по всему, Minishop2 её не поддерживает. Ведь цены в базе данных товаров могут храниться в разных валютах, а выводиться на фронтенд должны в той валюте, которую выберет покупатель селектором. И сменить валюту он может в любой момент и на любом этапе своего взаимодействия с сайтом, а не только при добавлении товара в корзину. Это обычная задача, у меня есть свой компонент для Yii2, который как раз по такому принципу и работает, но для MODX написать такой для минишопа будет ещё той заморочкой. Странно, что подобного функционала нет из коробки…

Я тоже не нашёл никакого конкретного решения реализации мультивалютности в магазине Minishop2. Тоже самое касается и мультиязычности (на контекстах через Babel с дублированием товаров — не вариант).

А как же тогда перевести систему на Fenom полностью? И чтобы вынести элементы в файлы (для редактирования через IDE)?

Тоесть, во всех этих сниппетах надо подменить объект $modx на $pdoTools? я правильно понимаю?

Может есть способ вместо имени чанка передать его уже обработанный парсером INLINE результат?

Данный вопрос касается не именно TaggerGetTags (он тут в качестве примера). Вопрос в том, как правильно передать в сниппет имя чанка, который является файлом на сервере и лежит в папке {core_path}/elements/chunks.
Например, как вызвать сниппет Formitб чтобы ему в качестве шаблона для отправки письма указать статический чанк? Сниппетов, которые используют мелкие чанки в качестве шаблонов для вывода данных — очень много разных. Но как им передавать такие чанки в параметрах, используя синтаксис Fenom?

«Используйте pdoResources + loadModels=tagger + class=TaggerTag» — это не относится к данному вопросу.

Вызов сниппета происходит через парсер pdoTools (синтаксис Fenom). Вопрос был по поводу передачи имени чанка в сниппет, в случае, когда чанк — это статический файл.