Specific notifier question - experts please!

In terms of the IPN application top, yes it is something we have discussed in terms of bringing it into the init_system structure rather than using custom code.

It should be noted as well, than even Paypal EC still has a dependeancy on the IPN handler for things like echecks :(

Ok, I think I have an idea... feel free to shoot it down :)

Here's the logic... in a "regular" (non-paypal) order, at some point the function "create" within the order.php class is called and (I think) it generates the order number. That same function is called from the ipn_main_handler.php file!

So can't we put a notifier inside that function? right after an id is generated?

• Steven

since you're doing stock mgmt, you'd be better advised to intercept the $order->create_add_products() call.

In this case, you already have access to these notifier points:
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_END');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_CREDIT_ACCOUNT_UPDATE_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_ATTRIBUTES_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_ONE_TIME_CHARGES_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_AFTER_ORDER_CREATE_ADD_PRODUCTS');

The problem is that the ipn_application_top doesn't have any of the functionality in it to load the custom notifier classes. Thus, even though the notifier points may exist and be fully functional via normal order-creation activities, the IPN subsystem doesn't have all the additional support present, and as such has no knowledge of any extra work it should do to follow actions in the defined notifier points.

DrByte:

since you're doing stock mgmt, you'd be better advised to intercept the $order->create_add_products() call.

In this case, you already have access to these notifier points:
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_STOCK_DECREMENT_END');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_CREDIT_ACCOUNT_UPDATE_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_ATTRIBUTES_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_PROCESSING_ONE_TIME_CHARGES_BEGIN');
$zco_notifier->notify('NOTIFY_ORDER_AFTER_ORDER_CREATE_ADD_PRODUCTS');

Yeah... I started with that and ran into a problem. Can't recall right now what that was though... hmm.

This part of the code isn't really doing any stock management per se though. Here, I'll tell you what it does do:

A customer previously came on and found an item that was out of stock, so instead of a "Add to Cart" or "Sold Out", they see "Request Item". That adds an entry to the DB so I know that item is wanted. When the item comes in, I add it to stock like normal, but one of them is made invisible to normal customers and is "on hold" for that particular customer. Its quite slick really. Everything works well right up until the customer who has it on hold purchases the on-hold item... at this point, I want the on-hold status to be removed. In order to do that though, I need to know what they bought...

so here we are. What my observer does (or rather... is trying to do) right now is listen for when the order_id is generated so that I can look up what was purchased and match that against the HOLDS table.

Now to mess with this even further, my stockManger also allows complete use of attributes too... and that could be why STOCK_DECREMENT doesn't do me any good... I can't remember exactly what was wrong there - it was a couple months ago. Since the core code only handles stock without attributes, its quite likely that was the reason I can't use that notifier. I would still need to know the order_id to look up the products AND attributes in order to remove the HOLD.

Does that make any sense at all?

My store has a large contingent of "special order" items... items I want to offer for sale, but that I don't (and won't) keep in stock. It was becoming unmanageable handling all the manual "can you bring this in for me" requests by email so I allowed people to order out-of-stock items... but then that really commits me to bring the item in, and depending on the number of requests and/or who the supplier is and their current situation that may not always be possible so that didn't work. Also, I didn't like taking people's money 60 to 90 days before the product arrived.

To solve this, I devised this Request/Hold system. And it works very well... save for this little quirk where I can't automatically remove the hold from the system after a PayPal order.

• Steven

DrByte:

The problem is that the ipn_application_top doesn't have any of the functionality in it to load the custom notifier classes. Thus, even though the notifier points may exist and be fully functional via normal order-creation activities, the IPN subsystem doesn't have all the additional support present, and as such has no knowledge of any extra work it should do to follow actions in the defined notifier points.

Ok, I think I get that now... but then how would I use those notifiers you mention above? Aren't they still under the same umbrella? The system still wouldn't be aware of those either with a PP order if I understand correctly.

• Steven

s_mack:

Ok, I think I get that now... but then how would I use those notifiers you mention above? Aren't they still under the same umbrella? The system still wouldn't be aware of those either with a PP order if I understand correctly.

• Steven

As things exist today, that is correct :lookaroun

Thanks for the explanation. Given the fact that you wish to manage the stock status "after" the order has been "fully" created, I would suggest not using the create_add_products notifiers anyway, as those notifiers are triggered on each line-item insert into the database.

It would be better to do something later on, either in the send-email routine or maybe yet a separate call altogether ... as you mention, you need to pass the order number to it anyway.

DrByte:

As things exist today, that is correct :lookaroun

Ok, thanks for confirming that.

DrByte:

Thanks for the explanation. Given the fact that you wish to manage the stock status "after" the order has been "fully" created, I would suggest not using the create_add_products notifiers anyway, as those notifiers are triggered on each line-item insert into the database.

It would be better to do something later on, either in the send-email routine or maybe yet a separate call altogether ... as you mention, you need to pass the order number to it anyway.

Sounds like a plan.

Now that I have a good local PP testing ground to work with (thanks for that too ;) ) I'm going to find a way to do this. If y'all are interested, I'll update with my solution when I find it. Maybe it'll give you something to work off of for a future release.

• Steven

s_mack:

Ok, I think I get that now... but then how would I use those notifiers you mention above? Aren't they still under the same umbrella? The system still wouldn't be aware of those either with a PP order if I understand correctly.

The extra support layer could be coded... it's essentially a matter of duplicating some of the functionality of the init_system infrastructure into ipn_application_top.
Sounds easy to "say" that ... but writing it ... hmmm ...

Well, this isn't as easy as I hoped it might be... I've not really been able to get anywhere.

The major problem is with testing! I get no errors... just nothing happens. I would have thought that when the IPN calls my php files that if there is a php error it would show up in the logs, but even when I deliberately create an error (put in an extra { or whatever) and do a PP transaction, I never see an error... just the order never completes. The payment does though.

Maybe if you guys are going to add init_system functionality to the IPN code in the future I won't worry about it... maybe I'll just hardcode my functions into the IPN function and deal with it every time theres an update.

• Steven

Ok, I found a "solution". As described above, I ditched the idea of doing it properly (integrating observer functionality into ipn_application_top.php) and just hardcoded it. I'm going to write my solution here in case it helps someone trying to do something similar, or perhaps helps someone tell me how I can do it better.

in my particular case, I was tapping into the notifier: NOTIFY_CHECKOUT_PROCESS_AFTER_ORDER_CREATE_ADD_PRODUCTS that occurs in checkout_process.php immediately after these lines```
$order->create_add_products($insert_id);
$_SESSION['order_number_created'] = $insert_id;

The first line also occurs in ipn_main_handler.php so I simply added these lines immediately after```
//begin: stockManger
	$_SESSION['order_number_created'] = $insert_id;
	require(DIR_WS_CLASSES . 'observers/class.stockManager.php');
	$stockManager = new stockManager();
	$stockManager->update($this, 'NOTIFY_CHECKOUT_PROCESS_AFTER_ORDER_CREATE_ADD_PRODUCTS');
//end: stockManager

which essentially does what the observer/auto loader functionality does... only simpler and with no flexibility (hardcoded). I put in the first line there because the stockManager observer class that I created relied on that session variable.

Obviously, it would just be better to have the notifier/observer functionality present in the IPN processing so that contribs don't have to worry about any of this... but until then, anyone trying to make an observer that occurs after an order is completed (and uses PayPal)... this may help you solve the PayPal problem.

• Steven

I have been reading this thread and others.
I haven't tried a solution similar to s_mack's last post yet, but I am starting to wonder if it is all a bit too hard for the paypal/zen cart system at this stage.
Question: If I wanted to deliver virtual products (eg, add credit to mobile phone account) ONLY after the payment has been cleared / completed, using Paypal IPN, is it possible and is it reliable?
Any ideas on how it could be done?

"yes" and "probably"... using the same method I did as your basis.

• Steven

Also, just a quick update on the success of the solution I came up with above.

It works great! I haven't had a single issue since! Whether the order is from PayPal or not, the notifier now works as expected and the code is executed. Yes, its a bit of a hack - but it works.

A bonus is... while my code will become obsolete when/if Zen adds notifier support to the IPN code... it should just be a matter of me deleting the code I introduced! Or rather... I can just upgrade the IPN file without worrying about destroying my functionality because it should work in the exact same way. Of course, any updates Zen puts out BEFORE the notifier system is extended WILL destroy my code :) so I have to be careful.

Cheers!

• Steven

Thanks for the update.
As sugested I just hacked the ipn_main_handler file to check for payment status completed.
Haven't had full testing but looks to work well.
This Zen Cart really is an excellent product.