Closed VunderkindMedia closed 3 years ago
Думаю, будет достаточно - добавить вот здесь хук https://github.com/instantsoft/icms2/blob/090f8da0249263889da6989086759af25c14d95b/system/controllers/messages/frontend.php#L175
Хук должен принимать в себя $letter_name, $notice = array(), $notice_type, $to
Этого будет более чем достаточно.
Сперва решил что хук update_user_notification_types все решит
Почему обязательно формировать эти push-уведомления из хука уже на этапе отправки? Почему просто не отправлять уведомления по хуку их экшена, когда само действие происходит, о котором требуется уведомление?
Сперва решил что хук update_user_notification_types все решит
Почему обязательно формировать эти push-уведомления из хука уже на этапе отправки? Почему просто не отправлять уведомления по хуку их экшена, когда само действие происходит, о котором требуется уведомление?
Не во всех экшенах есть такие хуки. Например инвайты в друзья, отказы от дружбы. Там аналогичных хуков нет. Да и это получится велосипед. Обрабатывать кучу хуков или же один - есть ведь разница?
Тем более что вся логика уведомлений уже создана, нужно только добавить хук, принимающий в себя сырой нотис.
P.S. Изначально я иначе видел проблему - поэтому много воды написал про типы уведомлений и т д. Ничего этого не нужно.
Только добавить один хук в указанное мной место.
Только добавить один хук в указанное мной место.
Есть один нюанс. Указанное Вами место находится в цикле перебора массива. Может этот массив до перебора перехватить? Чтобы сто раз хук не вызывать.
Только добавить один хук в указанное мной место.
Есть один нюанс. Указанное Вами место находится в цикле перебора массива. Может этот массив до перебора перехватить? Чтобы сто раз хук не вызывать.
Можно и так, но тогда нужно передавать, вместо $to сырых $recipients. Только не вижу разницы, ибо в хуке все равно придётся циклом перебрать всех юзеров, кому адресованы уведомления.
Суть хука этого такая же, как и у before_send_email, который так же вызывается в цикле. Единственное отличие - новый хук должен просто принимать сам notice и его тип, а не готовый шаблон письма.
Можно получать все данные из ссылки в тексте при помощи регулярки.
Можно получать все данные из ссылки в тексте при помощи регулярки.
Можно, я об этом Вам писал на форуме. Но тут 2 проблемы. В некоторых письмах больше одной ссылки бывает. И структура ссылки может меняться на разных сайтах. Я ведь стараюсь сделать универсальное приложение. И данные с бэка должны приходить все-таки более менее стабильные.
Если не получу от разработчика обратную связь, то придётся идти таким путем. Но это, как мне кажется, очень дилетанский подход)
Итого, нужно просто добавить хук?
Совершено верно)
Прошу учесть моё мнение, что обращение к поиску дополнений в цикле замедляет работу сайта. Допустим, на сайте нет надоедливых пуш-уведомлений, а движок все равно будет искать хуки связанные с этой мерзостью. На мой взгляд, это приведет к тормозам. Если я неправ - переубедите.
Допустим, на сайте нет надоедливых пуш-уведомлений, а движок все равно будет искать хуки связанные с этой мерзостью. На мой взгляд, это приведет к тормозам.
Так если хуков обработчиков нет, то и тормозов не будет. Но в целом да, вызов хука надо один, перед foreach.
https://github.com/instantsoft/icms2/blob/090f8da0249263889da6989086759af25c14d95b/system/controllers/messages/frontend.php#L176 Тогда, полагаю и здесь нужны выносить функцию из цикла? Внутри sendEmail тоже есть хук - before_send_email, а сама sendEmail вызывается в цикле.
Просто не понимаю разницы. Что я внутри хука следаю луп по подписчикам, что сам хук запустится внутри цикла, но уже с целевым подписчиком - какая собственно разница-то?
Что я внутри хука следаю луп по подписчикам, что сам хук запустится внутри цикла, но уже с целевым подписчиком - какая собственно разница-то?
По сути никакой, но я уже сделал до foreach)
list($recipients, $letter_name, $notice, $notice_type, $letter_text) = cmsEventsManager::hook('messages_send_notice_email', [$recipients, $letter_name, $notice, $notice_type, $letter_text]);
Что я внутри хука следаю луп по подписчикам, что сам хук запустится внутри цикла, но уже с целевым подписчиком - какая собственно разница-то?
По сути никакой, но я уже сделал до foreach)
list($recipients, $letter_name, $notice, $notice_type, $letter_text) = cmsEventsManager::hook('messages_send_notice_email', [$recipients, $letter_name, $notice, $notice_type, $letter_text]);
Спасибо огромное)
Что я внутри хука следаю луп по подписчикам, что сам хук запустится внутри цикла, но уже с целевым подписчиком - какая собственно разница-то?
Этот луп будет только у вас. У остальных его не будет.
Что я внутри хука следаю луп по подписчикам, что сам хук запустится внутри цикла, но уже с целевым подписчиком - какая собственно разница-то?
Этот луп будет только у вас. У остальных его не будет.
А будучи внутри цикла, Вы полагаете, он будет всегда запускаться?) Если нет обработчика, то и запускаться будет нечему.
В целом вопрос уже решён и дальнейшая дискуссия, считаю, не уместна
А будучи внутри цикла, Вы полагаете, он будет всегда запускаться?) Всегда будет запускаться поиск хука.
Используемая версия InstantCMS: 2.13
Версия PHP: 5.6
Часть уведомлений в системе отправляются только по Эл.почте. Часть только на сайт. Часть по выбору и туда и туда. Вопрос в следующем. Добавят ли возможность для всех типов уведомлений выбирать оба типа отправки нотификации?
Сейчас работаю над мобильным приложением, а точнее над пуш уведомлениями. Хук отправки на емэйл не подходит для отправки пуш, т.к. в нем только текст, хук отправки уведомления на сайт подходит, но ограничен список уведомлений, отправляющихся на сайт. Сперва решил что хук update_user_notification_types все решит, но позднее увидел, что в некоторых экшенах отправка осуществляется только одним из методов и принудительное изменение типа уведомления в профиле естественно не сыграет роли.
Я понимаю, что это, скорее всего будет необходимо только мне, но без этого придется как то синхронизировать оба хука отправки, чтобы при выборе варианта - и туда и туда в мобильное приложение не прилетало 2 уведомления. Ума не приложу, что это получится за велосипед.
В конце концов я могу сам внести изменения и направить Вам. Если нужно - оплачу эти изменения.