Илья Уткин

Обновление компонента не требуется, так как оплата проходит на серверах самого Сбера.

Есть вот такое платное решение modstore.pro/packages/utilities/easycomm

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

Я отвечал на этот вопрос -Какие-то запросы текущему автору по исправлению были? Он отказал или что?

Давай, объясню банальности.

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

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

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

Я уже исправил пару мелких недочётов (но вообще компонент давно в стабильном состоянии, часто проблемы покупателей решаются правильной настройкой у них на сайте). Так же добавил пару фич по запросу (например, новое событие mse2OnGetWorkFields). Так же я работаю над совместимостью с MODX3 — иначе компонент просто перестанут покупать.

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

Если кто-то хочет и чувствует в себе силы исправить эти проблемы, переписать заново или что-то переделать — вы можете обратиться с предложением к администрации магазина. Прям так и пишите — Илья Уткин не справляется со своими задачами, не развивает компонент, вы из-за этого теряете деньги. Я могу сделать то-то и то-то. Уже есть вот такие наработки. Профинансируйте создание mSearch3 и будете получать в 2 раза больше денег. Я думаю, Леонид с удовольствием согласится и отберёт у меня компонент, передав его более достойному автору.

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

Думаю, если сделать по-другому — начать с представления сервиса, тогда всем будет понятно и не будет недомолвок. То есть написать отдельную статью — «Представляю вашему вниманию сервис facetsearch.ru, который предоставляет мощности движка OpenSearch для использования на ваших сайтах.» и т.д. Тогда сам компонент будет просто модулем интеграции вашего сервиса. И вопросов к нему не будет. А будет чёткое понимание, кому он нужен.

А в дальнейшем вы сделаете подобные модули для Wordpress, Joomla, Битрикса и пр. — они будут использовать одно API, но уже никак не будут связаны с MODX.

Вашу статью тоже видел, но такие изменения кода довольно критичные, нужно очень внимательно всё изучить, чтобы у остальных пользователей ничего не сломалось. Ведь у каждого есть что-то своё — люди расширяют методы и ожидают, что они будут всегда работать одинаково. Добавил статью в избранное, попробую изучить после адаптации к MODX3 — как раз будет мажорная версия, возможно, в нее добавлю дополнительное кеширование.

Запросов не было, пару раз мне в личку писали, что есть какие-то предложения по доработкам, я просил автора предложений связаться, но так никто и не связался.

По поводу указанных проблем в топике — они все довольно узкие и дискуссионные. Например — поиск внутри alt изображений — а нужно ли искать? Проблемы совместимости с cityFields — а это точно в mSearch2 проблема?

У всех есть работа, когда-то я много времени уделял сообществу — и статьи писал, и дополнения разные. Сейчас у меня увеличилось количество ответственности, больше дел, которые нужно успеть сделать помимо работы. Так что внедрять такие нестандартные хотелки вряд ли буду.

А вот над совместимостью с MODX3 как раз я работаю и скоро будет новая версия, которую можно поставить на новый сайт.

Вот пример того, как можно кешировать — ilyaut.ru/cheats/caching-mfilter

Я посмотрю документацию, но насколько я знаю, CDEK не предоставляет такой возможности — он сам отправляет уведомления, не спрашивая отправителя)

Я не просто так придираюсь. HTML внутри PHP выглядит очень плохо, модифицируется в будущем ещё хуже и абсолютно не читается. Если как вариант «сделать и забыть» — ну ок. Но мой опыт подсказывает — вы сами еще столкнетесь с необходимостью что-то поменять, и будет неудобно.

Что ж вы HTML-то напрямую в сниппет суете? Есть же такой классный механизм чанков у MODX, и феном, благодаря pdoTools можно использовать… Эх…

Да, действительно. Спасибо, чуть подправил описание, надеюсь, теперь будет понятнее.

Создать накладную автоматически может, трек-номер в письме отправить нельзя, но CDEK сам отправляет пользователю уведомление — «Для вас создана новая посылка». И дальше все уведомления CDEK так же отправляет.

Данные клиента нельзя «украсть» — они передаются только в API CDEK-а

Я больше про сам сниппет chunk — он ведь всё равно на каждой странице вызывается, но единственное, что сниппет делает — проверяет, есть ли данные в кеше и, если есть, выводит их.

1. Если не указывать свой раздел, то твой кастомный кеш будет находиться в папке default и он будет очищаться каждый раз, когда очищается кеш сайта. То есть при сохранении любого ресурса, чанка, плагина в админке, а так же когда пользователь нажимает «Очистить кеш» в админке. Если указать любой другой раздел, нестандартный, тогда твой кеш не будет очищаться стандартными средствами MODX и он будет «вечным», либо конкретно до истечения указанного времени жизни.

2. В стандартном механизме MODX время жизни у кеша указывается в системной настройке cache_expires. По умолчанию там ноль, то есть кеш хранится до тех пор, пока его кто-то не очистит.

3. Сниппет на странице кеширует свой вывод только для конкретной страницы. То есть если сниппет вызывается в шаблоне кешированным (без восклицательного знака), то он все равно будет выполнятся по одному разу на каждой странице. Поэтому если внутри сниппета ты добавишь своё кеширование, то ты можешь это поведение исправить. Вот так — ilyaut.ru/tips-and-tricks/site-optimization-on-modx-revolution/

4. Хранить его так же в базе данных или написать своё кеширование внутри этого сниппета или «снаружи» — https://docs.modx.pro/komponentyi/pdotools/parser#Управление-кэшированием

Я думаю, вряд ли примут)

А зачем ссылка на Яндекс, если компонент и так бесплатный?)

Прошу прощения за оффтоп, но… Они что, все статьи Боба Рэя с 2013 года публикуют как свеженькие в 2022 году? modx.com/blog/ten-essential-extras-to-make-modx-yours — свеженькая статья, которая рассказывает о таком чудесном дополнении, как getResources =)))

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

Этим правилом решается проблема несправедливости. Всё мы понимаем, что сделать аналог какого-то дополнения будет проще, чем придумать его с нуля. И такие аналоги могут начать демпинговать — пострадает и автор, и магазин. Так что это правило защищает в первую очередь авторов. И вы как разработчик можете быть уверены, что после размещения компонента будете защищены от демпинга.

Ну на самом деле вы придумываете несуществующую ситуацию. Если дополнение включает в себя только 30% функционала «похожего» дополнения, а на 70% состоит из нового функционала, то это явно претендент на размещение и ни у кого не будет никаких претензий. У нас есть msDiscount и msPromoCode. И то, и другое — скидки, но всем абсолютно очевидно, что это разные дополнения и выполняют они разные функции разными способами.