Василий, судя по тому, как быстро ты ответил, ты не стал читать (что и не удивительно). Но хотя у меня там не используется MODX (если говорить о modxclub.ru), это не означает, что это не применимо к MODX. К примере, у одного из моих клиентов на сайте корзина реализована на этих технологиях. То есть сам сайт на MODX (ажна на шопкипере сделан), а во фронте используется реакт (для корзины), на сервере крутится нода, дабы дать более качественное API. Сейчас еще и поиск будет сделан с применениями этих технологий. Весь сайт переделывать затратно, а вот какие-то плюшки можно вполне так частями докидывать.
Кто-то вод сторонние сервисы подключает типа Discuss. Ты же не против подключения Disqus? Тут вот есть заметки за него: modx.pro/search?query=disqus А это 99% сторонний сервис с хранением контента на стороне и написанном не ясно на чем. Вот и здесь вполне можно думать чтобы такое полезное сделать.
Виталий, не за что!
Да, я через гугл и вхожу. Но бывает, заходишь с другого устройства, и приходится еще в гугл лезть, чтобы получить этот быстрый доступ. Но это уже мелочи. По большей степени я даже не с этой стороны смотрю, а со стороны единства данных. Я же тоже в какой-то момент пробовал там чат на слэке сделать, какую-то синхронизацию, и ощутил на сколько это неповоротливо для конечного ресурса. Поэтому те наработки закрыл, а дальнейшее развитие пытаюсь сделать на единой платформе. Не так красиво получается как у вас, но на мои личные потребности вполне так. Когда-нибудь это еще дизайнерски оформится и вообще красота будет.
Я вообще это не со зла все. Просто высказал мнение. Может когда-нибудь и вы решите кардинально навести порядок, привести все к единой основе и сможете более оперативно внедрять новые фишки. Я вот уже видеочаты ввожу. Совсем скоро скринкасты обучающие будут. Догоняйте ;)
Ссылку не сразу посмотрел. Она ведет на сгенерированную структуру сайта. Это надо, чтобы понимать какие API-запросы можно в принципе выполнить. Вот интерфейс для API: api.modxclub.ru/
К примеру, здесь видно, что у пользователей есть ресурсы, голоса, настройки уведомлений и т.п.
Можно соответственно и запрос написать для получения этих данных.
Другая важная функция: смотреть какие запросы на изменения можно слать и какие параметры в них.
Это важно, так как API мощное, позволяющее обновлять вложенные сущности (к примеру «Создать отзыв, созданный создаваемым пользователем с кучей полей, включая sudo»). Вот чтобы не могли передавать лишнее, надо за схемой следить. Если знаешь, что пользователь не сможет ничего лишнего передать в запросе, то и на сервере меньше можно заморачиваться с проверками.
Зато база данных единая :) И на базе этого расширять функционал можно без требования дополнительно где-то зарегистрироваться/авторизоваться. За примером далеко ходить не надо: вот запустили вы чаты. И что? Практически мертвый он. И это при вашей посещаемости и активности? Ладно у меня там сейчас мало кто общается, но у вас-то народа много. А почему не общаются? Потому что надо переходить на отдельную страницу и проверять что интересное кто написал.
А потом вы решите еще пару полезных сервисов запустить. И что? Тоже надо отдельные аккаунты будет заводить? Ну неудобно же.
Леонид, не подумай, что я придираюсь, но все же меня всегда удивляло, зачем было разбивать на несколько отдельных баз? modx.pro — один профиль, modstore.pro — другой, modhost.pro — если я не ошибаюсь, тоже отдельно. Почему было не использовать единую базу с разделением по оформлению?.. Ну ведь не очень удобно редактировать свои данные в нескольких отдельных сервисах, которые по сути — одна площадка… Потом мучиться с синхронизацией данных и сбором единой статистики…
Ну да ладно, это лирика. Просто мой перфекционизм…
Леонид, я так понимаю, логика хромает. У меня показывает 10 дополнений (и аж 12-ое место, что слишком высоко для моего вклада). У меня практически все дополнения сняты с публикации. Вероятней всего, снятые не должны учитываться.
И фильтр «Принимает заказы» не корректно работает. Я не принимаю заказы, но все равно вывожусь с этим фильтром. И для чекбокса zIndex неверный, пробивается через хедер. joxi.ru/EA4KnbqcweBe02
Дмитрий, если еще есть интерес к webrtc, можете принять участие в тестировании нового функционала на сайте Клуба — видеозвонки. modxclub.ru/topics/modx-klub-2.12.1-pwa-i-videozvonki-v-chatakh.html
Сейчас это еще не законченное решение, но все равно довольно занятная штука. Код в открытом доступе и когда будет доведен до ума, каждый сможет у себя использовать.
P.S. принять участие в тестировании может любой желающий.
Я не знаю как правильней всего в феном, но можете там использовать объект $_modx. Вот изучите вот эти примеры: modxclub.ru/topics/eshhe-odin-primer-slozhnyix-sql-zaprosov-1922.html
Только там нативный объект $modx, в феноме вам надо использовать $_modx, вроде должно работать.
Потому что ценность гитхаба больше не в хранилище, а во взаимодействии с другими разработчиками. Я довольно активно там запросы пишу, иногда PR отправляю и ответы на вопросы ищу. И проще это все делать в одном месте.
Судя по всему бага в Jevix здесь. В УРЛы не запрещено вставлять символы @, и здесь ссылка распозналась как почтовая. В исходнике чисто. joxi.ru/Q2KeDqyh4x1Yjr
Да, я с тобой тут во всем согласен. В своем тексте я под объектами подразумевал любые передаваемые нескалярные переменные, конкретно в этом случае массив $items. Просто за два года работы с JS я перестал между ними делать особые отличия, потому что в JS массив — это производная от объекта, и по сути тоже объект.
Нет, я говорю именно про ссылки на объекты PHP.
modPlugin расширяет класс modElement. При выполнении там выполняется extract($scriptProperties, EXTR_SKIP); То есть все переданные параметры из общего массива экстрактятся в отдельные переменные. Это и позволяет в плагинах работать с переменными без объявления их, типа как в коде выше с переменной $items, которая нигде не объявлялась.
Но проблема в том, что при экспорте используется параметр EXTR_SKIP. При таком экспорте переменных создаются именно новые сущности, а не просто передается ссылки на существующие переменные. В этом и проблема.
Чтобы было понятней, вот пример:
MODX создал переменную $items=[$item1, $item2] и отправляет в ивент параметром. Ивент нашел 3 плагина и начинает по порядку их выполнять с передачей в них этой переменной.
В первый плагин переменная пришла с двумя элементами. Вы добавляете туда еще элемент $items[] = $item; и у вас тут 3 элемента. ОК, выполняется второй плагин. Как вы думаете, сколько там будет элементов в $items? Если думаете, что 3, то думаете неправильно. Для первого плагина $items — локальная переменная, никак не связанная с исходным элементов $itesm. То есть в первом плагине стало 3 элемента, а во втором (и далее) все те же 2.
Чтобы такого не произошло, надо или добавлять так: $scriptProperties['items'][] = $item; или создать свою связанную переменную $items = & $scriptProperties['items']; и работать уже с ней, как со ссылкой. Вот тогда можно выполнять несколько плагинов.
P.S. если бы они использовали EXTR_REFS вместо EXTR_SKIP, то экспортировались бы сразу ссылки и проблемы не было бы. Я даже где-то писал об этом давно (может даже тикет создавал или PR), но результата не было.
Я не могу сказать наверняка, так как давно уже в админке не лазил, но пара мыслей есть:
1. Вы делаете неправильно. Вот пример: forums.modx.com/thread/87107/adding-icon-to-the-resource-toolbar
Там возвращают через return $this->modx->error->success('',$items);
Посмотрите в эту сторону.
2. Не вижу у вас где именно вы объявляете переменную $items. Полагаю нигде. В этом тоже может быть засада. MODX не всегда корректно использует ссылки на объекты. В результате передается не объект, а его копия, и теряется связь с оригиналом.
Попробуйте вот так: $items = & $scriptProperties['items']; и добавляйте уже в него.
А exit в вашем случае для того, чтобы отдать контент. Плагины просто так контент не отдают, простые print и print_r в них просто записываются в логи MODX и все.
Да я сейчас не про плагин. В 2.7.0 я не работал еще, но как я понял из последних публикаций, появился новый механизм удаления ресурсов в замен старой кнопки. Вот я и говорю, что если и было желание новое сто-то сделать, то надо было старое не удалять. То есть я про ядро, а не сторонние решения.
Кто-то вод сторонние сервисы подключает типа Discuss. Ты же не против подключения Disqus? Тут вот есть заметки за него: modx.pro/search?query=disqus А это 99% сторонний сервис с хранением контента на стороне и написанном не ясно на чем. Вот и здесь вполне можно думать чтобы такое полезное сделать.
Да, я через гугл и вхожу. Но бывает, заходишь с другого устройства, и приходится еще в гугл лезть, чтобы получить этот быстрый доступ. Но это уже мелочи. По большей степени я даже не с этой стороны смотрю, а со стороны единства данных. Я же тоже в какой-то момент пробовал там чат на слэке сделать, какую-то синхронизацию, и ощутил на сколько это неповоротливо для конечного ресурса. Поэтому те наработки закрыл, а дальнейшее развитие пытаюсь сделать на единой платформе. Не так красиво получается как у вас, но на мои личные потребности вполне так. Когда-нибудь это еще дизайнерски оформится и вообще красота будет.
Я вообще это не со зла все. Просто высказал мнение. Может когда-нибудь и вы решите кардинально навести порядок, привести все к единой основе и сможете более оперативно внедрять новые фишки. Я вот уже видеочаты ввожу. Совсем скоро скринкасты обучающие будут. Догоняйте ;)
К примеру, здесь видно, что у пользователей есть ресурсы, голоса, настройки уведомлений и т.п.
Можно соответственно и запрос написать для получения этих данных.
Другая важная функция: смотреть какие запросы на изменения можно слать и какие параметры в них.
Это важно, так как API мощное, позволяющее обновлять вложенные сущности (к примеру «Создать отзыв, созданный создаваемым пользователем с кучей полей, включая sudo»). Вот чтобы не могли передавать лишнее, надо за схемой следить. Если знаешь, что пользователь не сможет ничего лишнего передать в запросе, то и на сервере меньше можно заморачиваться с проверками.
Я довольно часто этим функционалом пользуюсь.
А потом вы решите еще пару полезных сервисов запустить. И что? Тоже надо отдельные аккаунты будет заводить? Ну неудобно же.
Ну да ладно, это лирика. Просто мой перфекционизм…
P.S. галочку убрал.
И фильтр «Принимает заказы» не корректно работает. Я не принимаю заказы, но все равно вывожусь с этим фильтром. И для чекбокса zIndex неверный, пробивается через хедер. joxi.ru/EA4KnbqcweBe02
Сейчас это еще не законченное решение, но все равно довольно занятная штука. Код в открытом доступе и когда будет доведен до ума, каждый сможет у себя использовать.
P.S. принять участие в тестировании может любой желающий.
Только там нативный объект $modx, в феноме вам надо использовать $_modx, вроде должно работать.
А то неудобно прыгать с гитхаба на битбакет.
P.S. Спасибо за бдительность.
P.P.S. зашортил ссылку, сейчас ОК.
Поэтому для себя давно уже опускаю разделение одних на других. В данном случае мне правильней было говорить именно про массивы.
modPlugin расширяет класс modElement. При выполнении там выполняется extract($scriptProperties, EXTR_SKIP); То есть все переданные параметры из общего массива экстрактятся в отдельные переменные. Это и позволяет в плагинах работать с переменными без объявления их, типа как в коде выше с переменной $items, которая нигде не объявлялась.
Но проблема в том, что при экспорте используется параметр EXTR_SKIP. При таком экспорте переменных создаются именно новые сущности, а не просто передается ссылки на существующие переменные. В этом и проблема.
Чтобы было понятней, вот пример:
MODX создал переменную $items=[$item1, $item2] и отправляет в ивент параметром. Ивент нашел 3 плагина и начинает по порядку их выполнять с передачей в них этой переменной.
В первый плагин переменная пришла с двумя элементами. Вы добавляете туда еще элемент $items[] = $item; и у вас тут 3 элемента. ОК, выполняется второй плагин. Как вы думаете, сколько там будет элементов в $items? Если думаете, что 3, то думаете неправильно. Для первого плагина $items — локальная переменная, никак не связанная с исходным элементов $itesm. То есть в первом плагине стало 3 элемента, а во втором (и далее) все те же 2.
Чтобы такого не произошло, надо или добавлять так: $scriptProperties['items'][] = $item; или создать свою связанную переменную $items = & $scriptProperties['items']; и работать уже с ней, как со ссылкой. Вот тогда можно выполнять несколько плагинов.
P.S. если бы они использовали EXTR_REFS вместо EXTR_SKIP, то экспортировались бы сразу ссылки и проблемы не было бы. Я даже где-то писал об этом давно (может даже тикет создавал или PR), но результата не было.
1. Вы делаете неправильно. Вот пример: forums.modx.com/thread/87107/adding-icon-to-the-resource-toolbar
Там возвращают через return $this->modx->error->success('',$items);
Посмотрите в эту сторону.
2. Не вижу у вас где именно вы объявляете переменную $items. Полагаю нигде. В этом тоже может быть засада. MODX не всегда корректно использует ссылки на объекты. В результате передается не объект, а его копия, и теряется связь с оригиналом.
Попробуйте вот так: $items = & $scriptProperties['items']; и добавляйте уже в него.
А exit в вашем случае для того, чтобы отдать контент. Плагины просто так контент не отдают, простые print и print_r в них просто записываются в логи MODX и все.