How can I "do something" after a successful PPE order?

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.

lat9:

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_shipping.
2. It's not a page that is "easy" to refresh, since it's never visible in the customer's browser.

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.

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...

mc12345678:

Could take from both or a combination. The "earlier" one to gather the session data that is then deleted later (and not otherwise retrievable),

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).

mc12345678:

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...

I think you are way over complicating things with this approach.

mc12345678:

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...

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.

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:

lat9:

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.

I thought you guys were continuing the discussion on a theoretical basis, but if there's still concern for my application (thank you) I had it working @ post 24 above.

s_mack:

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?

lat9:

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 to both of you, your suggestions have helped me to implement something similar on one of my local dev sites.

s_mack:

I thought you guys were continuing the discussion on a theoretical basis

I was/am.

Mainly to get ideas - whether they be sound, practical, efficient, best for purpose, or whatever. It's all good IMO.

I see as a result of this thread we already have one person (frank8) that has taken the idea(s) to do something on his own site(s) -
Something that may possibly never have eventuated otherwise.

The choice of *HEADER_START or *HEADER_END (or both) is certainly going to be dependent on what is needed and what data is available for that need, and with all that is currently known, I too would say that you have made the right choice for your purpose. I might even go as far to say that I may have made the wrong choice for the purpose of the ec_commerce module.

As a result of this discussion, Frank, and others that follow, have the benefit that neither you or I had when we started our projects - We've covered three possible notifiers (and a combination of them) that could be used for a purpose, and we've revealed the benefits and pitfalls for each, and the one instance that wasn't a good choice for the need (the NOTIFY_CHECKOUT_PROCESS_HANDLE_AFFILIATES).

It has been (and is) a good discussion even though the initial 'problem' has been solved.

Cheers
RodG

Agreed Rod. I just wanted to be clear that I wasn't still waiting for help :)