Да, проблема возникает, если пользователи пропустили какую-то версию MiniShop2 и обновились сразу на последнюю. Я так понимаю, в версии 3.х содержимое этих файлов заменялось на include файлов из другой папки, а в 4.x уже вовсю используются новые файлы, имея ввиду, что если старые файлы и были, то они обновлены.
А если юзер обновил с версии 2.х сразу на 4.х — вот тогда и возникает проблема.
Было много запросов в техподдержку, что не всегда отправляются заказы в СДЕК. Мне нужно время, чтобы найти, в чём ошибка. Пока снял дополнение с публикации, чтобы покупатели не столкнулись неожиданно с ошибкой
Я отвечал на этот вопрос -Какие-то запросы текущему автору по исправлению были? Он отказал или что?
Давай, объясню банальности.
Василий написал mSearch2, какое-то время продавал его, отвечал на вопросы в техподдержке, исправлял, если что-то не работает, параллельно развивал компонент, выпускал новые фичи.
В какой-то момент Василий решил, что не хочет больше тратить на это время, хоть и получал за это какие-то деньги. Но так как от наличия поддержки зависит ещё и доход самого магазина, магазин решил нанять меня, чтобы выполнять обязательства перед покупателями.
Так вот, моя квалификация позволяет адекватно отвечать в техподдержке, помогать с настройкой, расширением, решать проблемы покупателей, выпускать небольшие исправления, если где-то что-то работает не так.
Я уже исправил пару мелких недочётов (но вообще компонент давно в стабильном состоянии, часто проблемы покупателей решаются правильной настройкой у них на сайте). Так же добавил пару фич по запросу (например, новое событие mse2OnGetWorkFields). Так же я работаю над совместимостью с MODX3 — иначе компонент просто перестанут покупать.
Но вот развивать компонент, переписывать JS, менять методику фильтрации, делать рефакторинг всего кода — это довольно большие задачи, которые особо на продажи не повлияют, да и, честно говоря, квалификации моей на эти задачи не хватит.
Если кто-то хочет и чувствует в себе силы исправить эти проблемы, переписать заново или что-то переделать — вы можете обратиться с предложением к администрации магазина. Прям так и пишите — Илья Уткин не справляется со своими задачами, не развивает компонент, вы из-за этого теряете деньги. Я могу сделать то-то и то-то. Уже есть вот такие наработки. Профинансируйте создание mSearch3 и будете получать в 2 раза больше денег. Я думаю, Леонид с удовольствием согласится и отберёт у меня компонент, передав его более достойному автору.
Я думаю, проблема в основном в позиционировании. Даже тут в статье опытные программисты не сразу сообразили, что компонент сам по себе работать не будет, а является интеграцией со сторонним сервисом.
Думаю, если сделать по-другому — начать с представления сервиса, тогда всем будет понятно и не будет недомолвок. То есть написать отдельную статью — «Представляю вашему вниманию сервис facetsearch.ru, который предоставляет мощности движка OpenSearch для использования на ваших сайтах.» и т.д. Тогда сам компонент будет просто модулем интеграции вашего сервиса. И вопросов к нему не будет. А будет чёткое понимание, кому он нужен.
А в дальнейшем вы сделаете подобные модули для Wordpress, Joomla, Битрикса и пр. — они будут использовать одно API, но уже никак не будут связаны с MODX.
Вашу статью тоже видел, но такие изменения кода довольно критичные, нужно очень внимательно всё изучить, чтобы у остальных пользователей ничего не сломалось. Ведь у каждого есть что-то своё — люди расширяют методы и ожидают, что они будут всегда работать одинаково. Добавил статью в избранное, попробую изучить после адаптации к MODX3 — как раз будет мажорная версия, возможно, в нее добавлю дополнительное кеширование.
Запросов не было, пару раз мне в личку писали, что есть какие-то предложения по доработкам, я просил автора предложений связаться, но так никто и не связался.
По поводу указанных проблем в топике — они все довольно узкие и дискуссионные. Например — поиск внутри alt изображений — а нужно ли искать? Проблемы совместимости с cityFields — а это точно в mSearch2 проблема?
У всех есть работа, когда-то я много времени уделял сообществу — и статьи писал, и дополнения разные. Сейчас у меня увеличилось количество ответственности, больше дел, которые нужно успеть сделать помимо работы. Так что внедрять такие нестандартные хотелки вряд ли буду.
А вот над совместимостью с MODX3 как раз я работаю и скоро будет новая версия, которую можно поставить на новый сайт.
Я не просто так придираюсь. HTML внутри PHP выглядит очень плохо, модифицируется в будущем ещё хуже и абсолютно не читается. Если как вариант «сделать и забыть» — ну ок. Но мой опыт подсказывает — вы сами еще столкнетесь с необходимостью что-то поменять, и будет неудобно.
Создать накладную автоматически может, трек-номер в письме отправить нельзя, но CDEK сам отправляет пользователю уведомление — «Для вас создана новая посылка». И дальше все уведомления CDEK так же отправляет.
Данные клиента нельзя «украсть» — они передаются только в API CDEK-а
Я больше про сам сниппет chunk — он ведь всё равно на каждой странице вызывается, но единственное, что сниппет делает — проверяет, есть ли данные в кеше и, если есть, выводит их.
1. Если не указывать свой раздел, то твой кастомный кеш будет находиться в папке default и он будет очищаться каждый раз, когда очищается кеш сайта. То есть при сохранении любого ресурса, чанка, плагина в админке, а так же когда пользователь нажимает «Очистить кеш» в админке. Если указать любой другой раздел, нестандартный, тогда твой кеш не будет очищаться стандартными средствами MODX и он будет «вечным», либо конкретно до истечения указанного времени жизни.
2. В стандартном механизме MODX время жизни у кеша указывается в системной настройке cache_expires. По умолчанию там ноль, то есть кеш хранится до тех пор, пока его кто-то не очистит.
3. Сниппет на странице кеширует свой вывод только для конкретной страницы. То есть если сниппет вызывается в шаблоне кешированным (без восклицательного знака), то он все равно будет выполнятся по одному разу на каждой странице. Поэтому если внутри сниппета ты добавишь своё кеширование, то ты можешь это поведение исправить. Вот так — ilyaut.ru/tips-and-tricks/site-optimization-on-modx-revolution/
А если юзер обновил с версии 2.х сразу на 4.х — вот тогда и возникает проблема.
Или можно попробовать написать свой плагин, который будет на каждого посетителя создавать юзера и авторизовывать его.
Давай, объясню банальности.
Василий написал mSearch2, какое-то время продавал его, отвечал на вопросы в техподдержке, исправлял, если что-то не работает, параллельно развивал компонент, выпускал новые фичи.
В какой-то момент Василий решил, что не хочет больше тратить на это время, хоть и получал за это какие-то деньги. Но так как от наличия поддержки зависит ещё и доход самого магазина, магазин решил нанять меня, чтобы выполнять обязательства перед покупателями.
Так вот, моя квалификация позволяет адекватно отвечать в техподдержке, помогать с настройкой, расширением, решать проблемы покупателей, выпускать небольшие исправления, если где-то что-то работает не так.
Я уже исправил пару мелких недочётов (но вообще компонент давно в стабильном состоянии, часто проблемы покупателей решаются правильной настройкой у них на сайте). Так же добавил пару фич по запросу (например, новое событие mse2OnGetWorkFields). Так же я работаю над совместимостью с MODX3 — иначе компонент просто перестанут покупать.
Но вот развивать компонент, переписывать JS, менять методику фильтрации, делать рефакторинг всего кода — это довольно большие задачи, которые особо на продажи не повлияют, да и, честно говоря, квалификации моей на эти задачи не хватит.
Если кто-то хочет и чувствует в себе силы исправить эти проблемы, переписать заново или что-то переделать — вы можете обратиться с предложением к администрации магазина. Прям так и пишите — Илья Уткин не справляется со своими задачами, не развивает компонент, вы из-за этого теряете деньги. Я могу сделать то-то и то-то. Уже есть вот такие наработки. Профинансируйте создание mSearch3 и будете получать в 2 раза больше денег. Я думаю, Леонид с удовольствием согласится и отберёт у меня компонент, передав его более достойному автору.
Думаю, если сделать по-другому — начать с представления сервиса, тогда всем будет понятно и не будет недомолвок. То есть написать отдельную статью — «Представляю вашему вниманию сервис facetsearch.ru, который предоставляет мощности движка OpenSearch для использования на ваших сайтах.» и т.д. Тогда сам компонент будет просто модулем интеграции вашего сервиса. И вопросов к нему не будет. А будет чёткое понимание, кому он нужен.
А в дальнейшем вы сделаете подобные модули для Wordpress, Joomla, Битрикса и пр. — они будут использовать одно API, но уже никак не будут связаны с MODX.
По поводу указанных проблем в топике — они все довольно узкие и дискуссионные. Например — поиск внутри alt изображений — а нужно ли искать? Проблемы совместимости с cityFields — а это точно в mSearch2 проблема?
У всех есть работа, когда-то я много времени уделял сообществу — и статьи писал, и дополнения разные. Сейчас у меня увеличилось количество ответственности, больше дел, которые нужно успеть сделать помимо работы. Так что внедрять такие нестандартные хотелки вряд ли буду.
А вот над совместимостью с MODX3 как раз я работаю и скоро будет новая версия, которую можно поставить на новый сайт.
Данные клиента нельзя «украсть» — они передаются только в API CDEK-а
2. В стандартном механизме MODX время жизни у кеша указывается в системной настройке cache_expires. По умолчанию там ноль, то есть кеш хранится до тех пор, пока его кто-то не очистит.
3. Сниппет на странице кеширует свой вывод только для конкретной страницы. То есть если сниппет вызывается в шаблоне кешированным (без восклицательного знака), то он все равно будет выполнятся по одному разу на каждой странице. Поэтому если внутри сниппета ты добавишь своё кеширование, то ты можешь это поведение исправить. Вот так — ilyaut.ru/tips-and-tricks/site-optimization-on-modx-revolution/
4. Хранить его так же в базе данных или написать своё кеширование внутри этого сниппета или «снаружи» — https://docs.modx.pro/komponentyi/pdotools/parser#Управление-кэшированием