• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

XFCP overiding not working through deferred?

#1
Has anyone had trouble with their extended classes running under a deferred process?

I have extended the XenForo_Mail class in order to change transports based on the mail template, however the extended class seems to get ignored entirely when running through the deferred script, processing the mail queue.

Any ideas?
 

Xon

Well-known member
#2
Has anyone had trouble with their extended classes running under a deferred process?

I have extended the XenForo_Mail class in order to change transports based on the mail template, however the extended class seems to get ignored entirely when running through the deferred script, processing the mail queue.

Any ideas?
You need extend XenForo_MailQueue (to handle deferred items) not just XenForo_Mail (to handle directly sent items). There are then a couple other locations to hook to override to ensure your transport is picked up.

The best way todo what you are looking for, is you implement a wrapper transport, that when executed, loads the correct transport.

I have an MIT Licenced Email Queuing Enhancements addon as an example of this. It is available on github if you would like to fork it.
 
#3
Thank you Xon, yes I had started working with extending he XenForo_MailQueue. It occured to me that since many of the class calls in the deferred script are static, the XFCP_ method would not work.

I haven't got it working just yet, but thank you for your example, I will take a look! :)
 
#4
Just thought I should update this thread.. I did get the mail queue extended, the problem I had was in my listener. I was listening to the event load_class_mail rather then load_class. After making that change everything fell into place.
 

Xon

Well-known member
#5
Just thought I should update this thread.. I did get the mail queue extended, the problem I had was in my listener. I was listening to the event load_class_mail rather then load_class. After making that change everything fell into place.
load_class + hint is the preferred way to extend classes. The load_class_<type> is IMO a holdover from before the listener hint system was introduced.