Почему вы считаете, что плагин должен срабатывать? Вы ведь подключили его к хуку «order_action.pay», который соответствует действию с идентификатором «pay», а ожидаете, что сработает хук для действия с идентификатором «tipa-oplachen». Это же разные действия. Поведение у них совпадает, но действия всё-таки разные.
Ну, тут всё конечно крутится вокруг того, что считать "Поведением". Кто-то ожидает, что если при "Оплачен" чек регистрируется, то и про поведении "Оплачен" чек должен зарегистрироваться. Для меня было неочевидным, что поведение "Оплачен" - это просто заполнение полей даты оплаты.
Может, конечно, это я один такой, посчитавший, что действие в поведении должно производиться полноценно (кроме смены статуса).
Я исхожу из кейсов, которыми пользовались клиенты моих плагинов. И одним из вариантов, когда они подключают несколько маркетплейсов или разные транспортные компании, то создают дополнительные статусы, например, "Оплачено GOODS". И им важно, чтобы при этом просто заказ пошел по ветке альтернативных статусов, где заказ лежит до какого то события, потому что деньги приходят не сразу или если возврат, то он тоже придет не сразу и поэтому создают достаточное количество новых статусов и новых действий. И получается, что сейчас подключая "Поведение" они не могут полноценно пользоваться плагинами. Ладно, я заметил и по мере обращений в кассовые плагины добавлю отслеживание всех статусов и обработку.... Но многие даже и не заметят, что что-то работает не так.
Я не знаю, но например, https://www.webasyst.ru/store/... не хочу клеветать - не смотрел код, но скорее всего при использовании действий "типа оплачен" - вряд ли срабатывает kmEcommerce.payment, хотя я могу недооценивать коллегу и он учел, как работает ваше "Поведение".
Хотя, кому то может даже и нравится, что можно поставить "Оплачен" и не сработает хук и не зарегистрируется чек. И вот тут я подхожу к тому, что возможно нужно в поведении, чтобы было
- действие "......" без вызова хука - действие "......" с вызовов хука
Ну, или галочка "вызвать хук, соответствующий поведению".
Важно, чтобы было понимание, что "Поведение" сейчас неполноценное и не вызывает плагины, которые сработали при этом действии.
Согласен про "понимание", но хуки, имхо должны вызываться отдельно для каждого действия.
Либо должен быть инструмент, который в явном виде даст возможность вызвать один хук вместо другого. И тут тоже важно, чтобы у админа магазина было "понимание".
Категорически против вызова order_action.pay вместо order_action.tipa-oplachen как поведение по умолчанию.
P.S. Для себя взял за практику, что если плагин делает что-то по определённому действию, в настройки такого плагина выношу GROUPBOX с выбором нескольких действий.
Почему же против регистрации соответствующего идентификатору этого действия такого хука? Вроде бы нельзя создать два действия с одним id. А уже потом в плагине делать проверку - нужно ли, что бы сработал хук или нет.
Появилось предложение подписывать плагин на общее событие order_action.* и в обработчике события проверять, от какого класса унаследовано текущее действие. Если от класса действия pay, то выполнять основной код обработчика.
Сообщите, если такой способ подходит вам не подходит, и почему.
Реализовать регистрацию хука для действии сложнее? Проверка по строке "tipa-oplata" была бы проще, что бы не городить в плагинах дополнительные методы проверки.
11 комментариев
Почему вы считаете, что плагин должен срабатывать? Вы ведь подключили его к хуку «order_action.pay», который соответствует действию с идентификатором «pay», а ожидаете, что сработает хук для действия с идентификатором «tipa-oplachen». Это же разные действия. Поведение у них совпадает, но действия всё-таки разные.
Ну, тут всё конечно крутится вокруг того, что считать "Поведением". Кто-то ожидает, что если при "Оплачен" чек регистрируется, то и про поведении "Оплачен" чек должен зарегистрироваться. Для меня было неочевидным, что поведение "Оплачен" - это просто заполнение полей даты оплаты.
Может, конечно, это я один такой, посчитавший, что действие в поведении должно производиться полноценно (кроме смены статуса).
Я исхожу из кейсов, которыми пользовались клиенты моих плагинов. И одним из вариантов, когда они подключают несколько маркетплейсов или разные транспортные компании, то создают дополнительные статусы, например, "Оплачено GOODS". И им важно, чтобы при этом просто заказ пошел по ветке альтернативных статусов, где заказ лежит до какого то события, потому что деньги приходят не сразу или если возврат, то он тоже придет не сразу и поэтому создают достаточное количество новых статусов и новых действий. И получается, что сейчас подключая "Поведение" они не могут полноценно пользоваться плагинами. Ладно, я заметил и по мере обращений в кассовые плагины добавлю отслеживание всех статусов и обработку.... Но многие даже и не заметят, что что-то работает не так.
Я не знаю, но например, https://www.webasyst.ru/store/... не хочу клеветать - не смотрел код, но скорее всего при использовании действий "типа оплачен" - вряд ли срабатывает kmEcommerce.payment, хотя я могу недооценивать коллегу и он учел, как работает ваше "Поведение".
Хотя, кому то может даже и нравится, что можно поставить "Оплачен" и не сработает хук и не зарегистрируется чек. И вот тут я подхожу к тому, что возможно нужно в поведении, чтобы было
- действие "......" без вызова хука
- действие "......" с вызовов хука
Ну, или галочка "вызвать хук, соответствующий поведению".
Важно, чтобы было понимание, что "Поведение" сейчас неполноценное и не вызывает плагины, которые сработали при этом действии.
Согласен про "понимание", но хуки, имхо должны вызываться отдельно для каждого действия.
Либо должен быть инструмент, который в явном виде даст возможность вызвать один хук вместо другого. И тут тоже важно, чтобы у админа магазина было "понимание".
Категорически против вызова order_action.pay вместо order_action.tipa-oplachen как поведение по умолчанию.
P.S. Для себя взял за практику, что если плагин делает что-то по определённому действию, в настройки такого плагина выношу GROUPBOX с выбором нескольких действий.
Почему же против регистрации соответствующего идентификатору этого действия такого хука? Вроде бы нельзя создать два действия с одним id.
А уже потом в плагине делать проверку - нужно ли, что бы сработал хук или нет.
Сейчас и вызывается хук order_action.tipa-oplachen.
В своём плагине можно подписать как на конкретно это событие, так и на любое по маске.
Появилось предложение подписывать плагин на общее событие order_action.* и в обработчике события проверять, от какого класса унаследовано текущее действие. Если от класса действия pay, то выполнять основной код обработчика.
Сообщите, если такой способ подходит вам не подходит, и почему.
Реализовать регистрацию хука для действии сложнее? Проверка по строке "tipa-oplata" была бы проще, что бы не городить в плагинах дополнительные методы проверки.
Еще: У меня предложение переместить вызов хуков order_action.* перед отправкой письма с уведомлением.
(это к статусам заказов + уведомления относится)
Идея, хотя её следовало публиковать отдельным постом, не нова.
Как я понимаю, по историческим причинам такое уже вряд ли будет реализовано.
Однако добавили хуки notifications_send.before и notifications_send_one.before с передачей параметров по ссылке.