Дима Сайт old см. профиль

@Prihod привет!

Осваиваю плагин, нравится очень, но накопился небольшой багрепорт:
• 2 набора системных настроек, и работает «не тот, что ожидалось» :)
• добавляет описание к создаваемым элементам, но т.к. оно ничего не означает, лучше бы не добавлял

Подробности на скриншоте:


И на словах ещё дополню: я раньше пользовался StaticSaver. И под него я создавал отдельные источники файлов для каждого вида элементов т.к. плагин позволяет указать их отдельно. По идее это более MODX-way, чем прямые пути в сис. настройки писать, т.к. в источнике можно настроить ещё и ограничения по форматам файлов, поддерживаются разные виды хранилищ (хоть всё это и не нужно сейчас). Но это так, ворчание, как сейчас — ок работает (но я наткнулся на то что сис. настройка для источника не та подцепилась и насоздавал десятки чанков с привязкой к Загрузкам т.к. стандартный источник с id=1 во избежание помойки сразу направляю в /assets/uploads/ )

Загребли руки, раз нет решения готового)

MODX::findResource() для проверки существования ресурса пришлось найти и заюзать, работает (однако есть мнение, не проверял, что не будет работать при отключенной карте alias-ов, но в моем проекте этой оптимизации не требуется)

Кто будет делать, не забудьте начальный / отрезать в REQUEST_URI, а то с ним не находит!

@Сергей Шлоков @Дмитрий @Александр Мельник спасибо за комментарии!

Добрый день! Тоже встретил такую хотелку… Руки не гребут делать это)
@Александр Мельник, не поделитесь копипаст-решением (с проверкой без лишнего редиректа)?

(можно в личку, но у вас она закрыта)

Промучился вчера с оформлением документации для демонстрации в паблике ;), и забыл на первый вопрос ответить…

Давайте по порядку:
1. Модуль сохраняет заявки в MODX чисто «как бекап» и на случай если портал Битрикс24 будет не доступен, а проверка дубликатов контактов или открытых сделок, куда нужно добавить новую заявку, происходит уже на стороне Битрикс24 (но сам код, алгоритм этой проверки, работает на стороне MODX-компонента)

2. По логике работы и проверкам написал в предыдущем посте. По стоимости, чтобы она потом не устарела в этих комментариях, готов озвучить в лс. У вас @yuri личные сообщения закрыты, если нужно, напишите мне сами, или откройте лс в настройках профиля на modx.pro

Извиняюсь что в таком виде, но документация у меня не публичная, а загружать файлы на modx.pro у меня почему-то не получается… В общем вот скриншот, не знаю сколько он проживёт.

Тут более менее полное описание функционала. Подробности по внедрению и стоимости давайте лучше в личку здесь на сайте (кнопка есть в моем профиле).



Компонент протестирован на нескольких проектах и каждый день отправляет пачки заявок на разные порталы. Горячие этапы поддержки уже позади.

P.S. Обновил картинку скрина, umgur жутко жмёт текст… а так вроде ок

Сергей, тут читатели почитатели — программисты в основном, а они (мы) довольно прагматичны.

В лично моих глазах и Василий и Вы достойны всяческих похвал и почетных мест в зале/аллее славы MODX!

Теперь по теме:
Наверное, чтобы.избежать разночтений, я только хочу посоветовать для прагматичной точности ваших слов использовать вместо «стандартный парсер» или «MODX парсер» понятную всем здесь формулировку: modParser либо pdoParser. Где то здесь видел что вы считаете что сайтов на MODX без pdoTools в принципе почти нет и потому стандартный для вас это pdoParser.

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

Я сам недавно писал где то тут в комментах что с появлением fenom возрасла скорость, за счёт отказа от сниппета if и костылей в виде динамической генерации имени сниппета, которые описал Василий в своем недавнем посте. Вы мне в том комменте ответили что я не врубаю как это работает, а я имел ввиду только отказ от рекурсии изнутри.

Признаться честно, я фанат смешанного синтаксиса, потому что синтаксис MODX-тегов считаю очень крутым, простым и понятным.
Мне как разработчику безусловно нужна скорость итоговая, но и удобство и красота кода для меня не последние слова ;) я уверен и смарти в зумИксе не парсит изнутри наружу рекурсивно, так что тут с феномом не будет разницы.

Пользуясь случаем хочу всем, кто просвещает тут людей вроде меня, не готовых лезть под капот парсеров в силу недостатка скиллов, ещё раз сказать спасибо. Ведь находить нужные слова, ничего не перепутать и подобрать формулировки, чтобы небыло разночтений бывает очень не просто!

@Николай Хохлунов, здравствуйте. Как можно записаться на бета-тест билдера?

Я сталкивался с поиском контакта по переданному в лиде телефону и почте, и созданием сделки с привязкой «старого» контакта без создания дубликата. Тут ещё стоит учесть, что автоматическое обновление контакта сулит большие проблемы, мы с клиентами в итоге оставляем старые контакты а в автоматически создаваемом комментарии к лиду/сделке добавляем новые, чтобы менеджер который обрабатывает заявки, уже сам принял решение о замене или добавлении дополнительных телефонов и почт для контакта.

Короче тут не только hook для formit, а ещё небольшое приложение для самого bitrix24, которое, используя его api делает нужные проверки и действия.

Если делаете сами, здесь в комментариях смогу что-то подсказать. Готовое решение, поймите правильно, на коммерческой основе т.к. в разработку, а главное, в тестирование вложена куча ресурсов…

Ну значит сайт все же будет работать быстрее, и сможет держать гораздо большую нагрузку, особенно на не-ssd хостинге (такие ещё остались, особенно там где облачные диски для VPS/VDS — они медленные и база на них тормозит).

Раз не даёте ссылок, может сами потестируете нагрузку через loadimpact/k6 или может @Сергей Шлоков или @Николай Савин уже таким увлекался, но нам не показал? ;-)

Просто в анонсах и статьях всё пишут что ZoomX решает проблему работы modx с двумя парсерами при использовании fenom, я понимаю эти слова, но практическая польза, итоговый выигрыш, который по идее должен там быть, продемонстрирован пока что слабо недостаточно.

После анонса pdoTools со сравнительными таблицами, прям захотелось брать и только на нём и делать, особенно из-за крутого прироста в скорости fenom за счет адекватной обработки условий с фильтрами вывода типа

[[*pagetitle:is=`condition`:then=`yes`:else=`no`]]

Пока такого сравнения нет, очень сложно мотивировать modx-программиста брать на вооружение нечто новое «не ясно/очевидно зачем»…

Стесняюсь предложить осветить тему практического применения ZoomX для обычного многостраничного сайта.

Идеально — сравнение скорости работы (время рендера на одинаковом хостинге) и удобства работы с кодом для сайтов на синтаксисе modx-парсера или fenom (совсем в мечтах: оба) с тем, как то же самое реализуется на ZoomX (с каким-нибудь, на ваш аргументированный вкус ;-), шаблонизаторе, им поддерживаемым )

Возвращайтесь, Николай, тут вон новый виток, а с вами было круто ;-)

Можно к стати в новом качестве: Вы же вроде обучением занимаетесь, может студентам подкинете в качестве заданий адаптацию ваших клёвых наработок под MODX3?

Кажется, что от этого могут выиграть вообще все!

Ещё к позволит, смысл прокси тот же самый, что и ваша «кластерная архитектура», только без vps и ещё дешевле.

Интересно, Александр, где вы встретили ограничение запросов по ip, ведь на сколькр мне известно, там наоборот нужно указать конкретный ip с которого будут запросы, а ограничение основано на XML-лимитах, которые выдает Яндекс щас подключенные сайты в сервисе я.вебмастер.

Существует даже «рынок» этих лимитов.

Сколько раз переносили наш сборщик на новы сервер, каждый раз приходилось руками указывать его новый ip в Яндекс.XML…

А для Гугла вам по-любому понадобятся прокси или VPS или ещё что-то для подмены ip (хоть vpn), для корректного снятия позиций в разных регионах, потому что гугл плевать хотел что вы задаёте регион явно, выдача все равно идёт с учётом ip. Поправьте меня если что!

Ошибка с кодом 500 обязательно будет расшифрована в логах вебсервера. Кидайте сюда текст этой ошибки, сможем дальше подсказать!

Попробуйте копать в сторону &pageVarKey и других параметров pdoPage в которых есть слово *var* (variable).

Кажется, то что вам нужно, есть там из коробки!

1. Класс
2. Лучше уж пусть дубликат создаёт чем по названию сверяет. Было бы неприятно потерять код в случае нестыковок.

Вот бы ещё решение для однократного сканирования.
У меня вот разработка всегда на тестовой копии, и там я включу автосканирование. Сделал изменения, залил в гит.

А вот уже потом на продакшене сделал pull и в админке нажал бы кнопочку (ну и привязал ресурсы к новым шаблонам, если надо)

Если компонент не создает пункт меню с кнопочкой «просканировать», то может подскажешь быстрый способ создать её руками? Нет ли коннектора который можно пнуть чтобы он там провернул шестеренки под капотом ?)))

P.S. возможно мне стоило бы использовать gitify и он такое умеет, но я не использую(

А вот если смотреть со стороны сервера, то XHR можно задетектить по заголовкам (типа is_ajax() в modhelpers, а Fetch-запрос вроде никак не спалить (и если он хочет, чтобы его узнали, то должен сам «представиться», передав ещё параметр например). Строго говоря, с точки зрения обработки запроса на стороне сервера, у XHR здесь преимущество перед Fetch.

Или я чего-то не знаю?

Привет! Отличная штука!
Вопрос: на какое событие срабатывает сканирование директорий, предполагаю что на загрузку страницы админки. Тогда вопрос, если я отключу настройку автосканирования, это снимет всю «создаваемую нагрузку» на файловую систему?

И ещё: бывает надо переместить статичный файл (чанк например) из одной директории в другую, предполагаю что плагин создаст дубликат в этом случае? Или эта ситуация как-то обрабатывается?

Ну если иначе не получается, сделайте 2 разных файловых чанка с нужными обертками (и дополнительным вызовом pdoMenu для подпунктов, тормозов не бойтесь, меню кэшируется)

Далее в общем чеке сделайте проверку id нужных пунктов и используйте frenom {include file: path/to/innerchunk1.tpl}, если боитесь хардкода id, используйте стандартное поле русскому link_attributes и в админке задайте например класс или другой признак чтобы его и проверять в чеке.

Вообще сложные меню в modx строить очень легко именно за счёт частичного кэширования.

Основные препятствия к тому что собрать из быстро не в инструментах типа pdoMenu, он имеет достаточно настроек, а в укладывании рекурсии при работе меню в голове разработчика, чтобы понять в какое место втыкать код с логикой.

Не сочтите за что то обидное, я несколько лет назад так бился с меню пока не обнаружил неточность в документации pdoMenu что пришлось осваивать механику гитхаба для создания pull request в эту самую доку. Я тогда попробовал с pdoMenu наверное вообще всё ))

Для тех, кто (как и я) не очень любит подписываться на всякие сомнительные аккаунты (@Андрей я не про вас), вот ссылка «из того последнего поста» на доступную из web документацию: telegra.ph/Crypto-Pay-API-11-25