Also of interest might be lat9's Notifier Trace plugin: https://www.zen-cart.com/downloads.php?do=file&id=1114
Printable View
Also of interest might be lat9's Notifier Trace plugin: https://www.zen-cart.com/downloads.php?do=file&id=1114
That last bit of advice almost was perfect! I actually ran into an issue with my project. Obviously the notifier I'm using (NOTIFY_CHECKOUT_PROCESS_HANDLE_AFFILIATES) isn't appropriate afterall because it happens BEFORE PayPal updates the database. This is important because I want to change the status to something after PayPal changes it to "processing". if I do it before, then it gets clobbered.
I initially figured since they were getting recorded in the same second that perhaps it was just random chance which one appeared first, but I threw a 2 second sleep() in there to force my function to delay... and the PayPal still came after and still shows as the same second.
I installed lat9's Notifier Trace plugin as you suggested, so I could see the order. But NOTIFY_CHECKOUT_PROCESS_HANDLE_AFFILIATES doesn't show up in that log at all! How's that possible? I know it is firing because my code is being called properly.
I now see Lat9's contribution shows just a portion of the log file in the preview, so that text I was searching for wasn't showing. It is in the log itself though. I'm still unsure where I should be tapping in to achieve what I want.
After looking a little more carefully, I think I've settled on NOTIFY_HEADER_END_CHECKOUT_PROCESS
It gives me all the vars I need, it happens after function after_process() is called (which is what the payment modules uses to update the history), and I think it is tight enough to not have to worry about refreshes. I tried refreshing and there was no ill effect that I could see.
Does that sound right?
The notifier you chose (NOTIFY_HEADER_END_CHECKOUT_PROCESS) will do the trick for you:
1) It's at the absolute end of the checkout_process processing, just before the redirect to checkout_success.
2) It's not a page that is "easy" to refresh, since it's never visible in the customer's browser.
Thanks for that lat9.
A possible downside to using this notifier rather than NOTIFY_HEADER_START_CHECKOUT_PROCESS (both are in the same file) is that many of the session variables are cleared before the END_CHECKOUT is called - These variables could be useful/needed by whatever the new code is designed to do.Quote:
Originally Posted by lat9
BTW, nice discussion going on here. These notifiers can be *so* useful for so many different things I'm surprised that there haven't been more discussions about them. For what they can be used for they seem to be so under utilised, and I suspect that part of this is because although quite well documented there hasn't been enough talk about all the possibilities and options available.
I think it needs a discussion like this to pique the interest of more developers that are still doing things the 'old' way of hacking into core code when it's no longer really necessary.
Cheers
RodG
Could take from both or a combinatiion. The "earlier" one to gather the session data that is then deleted later (and not otherwise retrievable), the later one to use the previous session data if it is not already captured/transferred to something else useful. This way the information is gathered as necessary/when available and used when desired...
In a way, the worst thing that happens regarding the retriggering action is that the data is set again to what it already was... Meanwhile the "action" waits to observe the call to the notifier that is not "easy" to refresh...
Not really possible. Anything of use saved in the session data will always be available by other means at another time via other methods (generally a DB query).Quote:
Originally Posted by mc12345678
I think you are way over complicating things with this approach.Quote:
Originally Posted by mc12345678
The earlier notifier has all the session data needed for most purposes. What it doesn't have would need to be obtained via other means anyway.Quote:
Originally Posted by mc12345678
The later notifier will require a DB lookup for any data needed for the additional code (assuming all the sessions have been nullified).
The 1st notifier does run the risk of multiple triggering if/when the page is reloaded, but this will be a trivial task to mitigate (see the ec_commerce module).
Rather than trying to 'take from both' I reckon it would be better to ask the question "Is everything I need available from the session data, or do I need to perform a DB lookup.
If the former, then the 1st notifier and a test to page refreshes would (IMO) be the easiest to use, and the most efficient code wise.
If the latter, then since a DB query is going to be needed anyway, then use the last notifier and not have to worry about the page being refreshed.
I really don't see the point of 'taking from both'.
Perhaps I'm missing some important point you are trying to make here? (No offence, but even after all this time I still have a hard time trying to 'decode' many things that you write) <g> Seriously, more often than not, you're right on the money - it is just sometimes hard to see. I think this may be one of those times.
Cheers
RodG
The concept of "taking from both" is sound ... as in it's allowed. But it isn't always necessary.
One's observer class could certainly listen to multiple notifier hooks, and take action on each, including progressively building up a collection of data in a class variable which is used later in the workflow.
But for s_mack's current application I think using more than one is probably overkill. I agree with lat9's summary:
Quote:
Originally Posted by lat9