Specific notifier question - experts please!

[DrByte]

I defer to the expert ... oh wilt ...

[swguy]

-> accesses a member (data or function) of an object.
An object is an instance of a class.
$this-> means "using the object that is running this function,
access the specified data or function member."

Scott

[wilt]

Hi,

My fault. You are right, that the call from the order class should use $zco_notifier.

the confusion arises because generally we want to attach to an event fired by an object, and where possible use the native object (in this case the order class) to do that,

Unfortunately the order class will never be available to observer classes (due to it only being instantiated on a few pages, and even then only after observer classes have been instantiated) so in this case we have to rely on the global $zco_notifier class to do our work for us.

The pattern used to build the observer/notifier system is really better suited to PHP5 than PHP4, hence the reason for shoehorning things using the extra $zco_notifier class.

HTH

[s_mack]

Great, thanks for that Wilt!

Amazingly, I still haven't tested it with PayPal :) So I still don't know if this fixed my original problem. I always do the changes on my local site first before commiting it to my live site... and I haven't yet figured out a good way to test PP from my local site.

Someone (I think it was Dr.B) gave me some very helpful suggestions about making my local site available to the outside world... but I tried it and it just didn't work Not sure why. Got the router set up, the firewall, and the no-ip.org address all done. I can ping the address from another computer and I can even connect on port 80 but I don't see my site (I'm using triad2apache) so I'm waiting for some help from their support forum.

In the meantime, I think we can consider this done! Thanks a lot for your help!

- Steven

[wilt]

Unfortuantely, I still think you are going to have problems with Paypal IPN. The problem now is that the IPN handler code uses a custom application_top and not the standard init_system based application_top code.

This means that no observer classes will ever get instantiated

I'll try and think of an easy workaround that does not involve hacking core code, if I can

[s_mack]

Oh great

I just ran into another problem too... when I was relying on NOTIFY_CHECKOUT_PROCESS_AFTER_ORDER_CREATE_ADD_PRODUCTS, I had the luxury of knowing the order_id because it is passes as a session variable in the checkout process ($_SESSION['order_number_created']) but the order class doesn't do that. I need the order_id for my function.

Basically, all I need is the order id and a trigger. Thanks again for continuing to help.

- Steven

[s_mack]

So hey! I wonder...

Can I just tap into the the header file for the checkout_success page? The user goes there whether they use paypal or otherwise, so would that work? That page also "knows" the order_id value since it is reported to the user

Your Order Number is: 645

Are there any circumstances where the order would be generated in the system but where that page would not be loaded? Because that would be very bad. Or any other pitfalls you could imagine?

- Steven

[DrByte]

In the case of PayPal IPN, that order number is not reliable on the checkout_success page ... it's only correct if PayPal "instantly" posts the results back and they are successfully processed before the page is drawn.

PayPal Express Checkout would be correct though.


I suppose you could look at loading the whole notifier infrastructure via the ipn_application_top ...

[wilt]

Just to expand on Drbytes post. when a customer uses paypal IPN they are taken to the paypal website. In a perfect world, as soon as they click on the PAY button an IPN callback will be generated and if the correct options are set they will be returned to the Zen cart site and checkout success will be invoked.

However its never a perfect world. Load on the paypal servers can mean the IPN call back might happen immediately, or not for minutes, even hours. Settings and other network problems mean that u can not guarantee that an IPN user will even be returned to checkout success,

As drbyte suggests, at the moment it probably means u will need to hack the ipn application_top to load and instantiate your observer class if you ever want your code to work with IPN,

[s_mack]

Right. As well, I guess there's a good chance the customer never clicks the "return to merchant" link... duh :)

So that won't work.

About your last statement... is that something *you* would be willing to do? I don't mean for me... I'm sure I can figure it out... but I mean for future releases. I'm really trying to not mess with core code here. I wish I discovered this problem 5 months ago when I started my stockManager contrib... it works so well except for this PayPal problem that I didn't forsee.

Oh well, what's past is past.

Maybe I'll look at the PP EC option. As it is, I don't like it for my store at all... I like what it is supposed to do, but with my layout it becomes confusing. So I'll have to customize that and then we're back at messing with core code again


Isn't there anywhere common to all payments in the checkout system that is post-DB?

- Steven