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

[s_mack]

OOOHhh... OK, so the last bit of the constant, is that the page name? That makes sense. I was reading it more as a description of the event. So when we're talking about NOTIFY_HEADER_START_CHECKOUT_SUCCESS, is that saying "I'm notifying that the header for checkout_success has started"?

Perhaps not though, because what page would the one I chose relate to?

NOTIFY_CHECKOUT_PROCESS_HANDLE_AFFILIATES

I chose that one because I figured that any code relating to handling affiliates, which is normally determined on actual sales, that it would be least likely to be affected by reloads and such.

Thanks for help and suggestions folks.

[lat9]

The notifier constants are just that -- string constants. You can normally infer the page (or class) from which they're issued by the name ... but not always.

[RodG]

I'd lean more towards a notifier within the checkout_process path. The checkout_success page can be refreshed, resulting in your processing being re-run.

Good point. This potential problem is/was mitigated in the ec_analytics module via a test of one of the session variables (that gets unset after the 1st page load).

Cheers
RodG

[RodG]

So when we're talking about NOTIFY_HEADER_START_CHECKOUT_SUCCESS, is that saying "I'm notifying that the header for checkout_success has started"?.

Correct.

NOTIFY_CHECKOUT_PROCESS_HANDLE_AFFILIATES

I chose that one because I figured that any code relating to handling affiliates, which is normally determined on actual sales, that it would be least likely to be affected by reloads and such.

Thanks for help and suggestions folks.

OK, so I haven't done a complete analysis of the program flow through all the checkout variances, but having just taken a quick review of things, the notifier you chose is probably a better option than the one I chose for ec_analytics.

I suspect that I never even considered this option under the assumption it would only be triggered for affiliate related sales and not for *all* sales.

FWIW, you/we don't need to limit ourselves to using these pre-defined hooks, it is actually quite a trivial task to create and use our own in pretty much any place in the ZenCart code, for almost any purpose. Alas, for this to work does require a very minor change to the existing code to add the 'hook', and in my opinion this defeats the most significant reason for using the notifiers in the 1st place.

On a slightly different note:
Does anyone here know of any reason, circumstance or situation where the checkout success page *wouldn't* be loaded (after a successful checkout)? The reason I ask is because I've had the rare report that not all sales are being tracked by the ec module (I've not been able to confirm or replicate) - and about the only cause I can think of is if this success page is somehow being bypassed or skipped.

If this theoretically possible?

Cheers
RodG

[s_mack]

Over the years, with just the stock checkout, I've had a few extremely rare cases (maybe 3 in 10,000) where a payment went through but the order was never recorded. I don't know if that would coincide with what your users experienced but thought I'd mention it.

So adding hooks is really as simple as just placing a $zco_notifier->notify('WHATEVER'); where convenient for us? I figured each hook was actually registered somewhere but I never really looked.

I *try* to avoid core over-writes as much as possible. I really appreciate the idea behind the overrides, observers, etc... but the fact is no matter how hard I try I always end up extensively modding the core. In practice, the overrides system is limited. It would be greatly enhanced if "pages" could be overridden, and also functions (or, if functions were held to a stricter standard of not including any html output).

Of course, that's off topic.

This topic, we can consider closed from my perspective. They way I did it in post #5 is working just fine. I will change the initiation (or whatever its called) from 180 to "above 199" if that's considered good form. I don't think it makes a difference for my purposes.

Thanks for the assistance and tips, folks.

[lat9]

...
I *try* to avoid core over-writes as much as possible. I really appreciate the idea behind the overrides, observers, etc... but the fact is no matter how hard I try I always end up extensively modding the core. In practice, the overrides system is limited. It would be greatly enhanced if "pages" could be overridden, and also functions (or, if functions were held to a stricter standard of not including any html output).
...

Me too! Take RodG's advice, though: If you don't see a notifier that's placed where you need it or one that serves up the data you need, add that notifier (a 1-line change, plus comments) to the core file and then do your special processing in the observer-level code. It serves to compartmentalize the changes and makes upgrading a whole lot easier!

Never, ever modify the data payload of a built-in notifier, you'd be asking for a world of hurt when the next version of Zen Cart re-purposes that notifier with different data!

[s_mack]

Never, ever modify the data payload of a built-in notifier

Can you explain what that means so I can know exactly what not to do? :)

edit: actually, I think I do know what you're referring to... so a better question is how do I know what notifiers provide what data?

[lat9]

Sorry to be obtuse! If you look at the structure of a ->notify function call (Zen Cart v1.5.2 and later), that call takes a (required) string notifier and from 1 to 9 additional parameters. The first additional parameter is a read-only value while parameters 2-9 are read/write.

I'm calling those optional parameters the payload.

Let's say that you've looked at /includes/classes/order.php and determined that you'd like to hook the notification:

     $this->notify('NOTIFY_ORDER_CART_ADD_PRODUCT_LIST', array('index'=>$index, 'products'=>$products[$i]));

For whatever reason, you'd like the value of $rowClass to be included. What I'm suggesting is is that it's bad form to modify the order.php class to change that notifier to add the $rowClass value because the next version of Zen Cart might choose to update that data payload:

     $this->notify('NOTIFY_ORDER_CART_ADD_PRODUCT_LIST', array('index'=>$index, 'products'=>$products[$i]), $rowClass);

Instead, since you're editing the file anyway, add a totally new notifier for your use that you control:

     $this->notify('NOTIFY_ORDER_CART_ADD_PRODUCT_LIST_LAT9', array('index'=>$index, 'products'=>$products[$i]), $rowClass);

[s_mack]

Crystal clear, thank you.

[DrByte]

/includes/auto_loaders/config.myProcessor.php

<?php
  $autoLoadConfig[10][] = array('autoType'=>'class',
                                 'loadFile'=> 'observers/class.myProcessor.php');
  $autoLoadConfig[180][] = array('autoType'=>'classInstantiate',
                              'className'=>'myProcessor',
                              'objectName'=>'myProcessor');
?>

I'm especially unsure on the values I used for autloading (10 and 180). I went with 10 because the wiki used that for its example and I used 180 because PayPal uses up to 170 in paypal_ipn.core.php but really I don't understand it enough to say that was an informed guess.

Since the autoLoadConfig array is processed, and all its loads/requires/instantiations are executed during application_top, the actual "order" of loading your custom added observer classes is moot, save for the fact that yours should typically be above 200. The "order" is used only to ensure necessary prerequisites are handled, such as starting sessions before running init scripts that require the use of sessions, and starting the db before the db is needed, etc. That's all done below 200, and all your userland stuff should typically be done after 200. Additionally, you probably already grok this, but I'll state it to be clear: do your loadFile directive before your classInstantiate, and you're good. (And, yes, doing loadFile directives below 200 is fine, but equally fine to do above 200, as long as they're done before instantiating)