Problems getting custom onAfterOrderCreate to work

I did install over the top (via Joomla Extension Manager) but it's not obvious if anything changed. But as I say, I did a binary compare of the package before your post and the one just downloaded and they were identical.

Just need to wait for some more orders...

Just had about a dozen orders come in and they all went through fine, compared to the vast majority prior to the update which did not. Many thanks.

Spoke too soon. It seems around 10% of orders are still not processing properly. I can't spot any pattern to those that work and those that don't.

I installed V2.2 dated 5th July yesterday, and today I note there is another V2.2 but dated 6th July. They do appear to be binary different but they have the same version number? I installed it anyway in the hope that whatever is fixed.

Still problems - about 1-3 in 10 transactions fail to process through HikaShop. It's very annoying as I'm losing sales through this - comments of "shambles" and "not ordering until these problems are fixed" do not fill me with joy. That then passes on to HikaShop as I'm now reluctant to purchase any pro editions of HikaShop. So I spend up to an hour each day going through the orders to see which HikaShop processed and which it didn't: I have to go through the PayPal data and update the HikaShop orders accordingly.

I'm also confused by your version numbering. I've downloaded about 5 versions of 2.2.0 and they do seem to be binary different. 1,573,271 bytes was reported for the version on July 6th; 1,575,046 bytes is reported for today's version (also labelled 2.2.0). Are these files actually different in terms of code and bugs fixed?

I downloaded the latest 2.2.0 a few days ago and am still having trouble - in fact it seems to be 100% of the orders are failing to go through. If I change the order status to "confirmed" then everything that's supposed to happen after that works (emails to customer, plugins get called, etc).

Can I roll back to a working version? If so, which version, and where can I find it?

The only things that changed on my website was adding one product and installing the latest versions of HikaShop. I don't understand what you're saying about non-public menus - access to the shop area is by a menu link, yes, but everything within is HikaShop software. All the orders have the Joomla user ID associated with them, so it's not as if somebody isn't logged in when they order. This is backed up by the fact that simply switching the order status from "created" to "confirmed" finishes the ordering process which enables the user to see that they have an order. There is nothing obvious in the PayPal configuration or the HikaShop configuration to prevent this working properly, nor has anything been changed by myself anyway. It's like suggesting "Ignore PayPal response" is switched on!

There is also the fact this was working fine previously, then suddenly stopped working, then you or your colleagues released a fix, and that upped the success rate to maybe 90%, but the latest fixes have dropped it back to zero. The only thing that's changing is installation of new versions of HikaShop. For reference we get 5-10 orders per day so we have reasonable figures with which to make these observations.

One thing that is annoying me is your version control. I have downloaded something like half a dozen versions of 2.2.0. The only way I can determine which version was installed was by looking at my download list to see which dated version of 2.2.0 was downloaded, but of course that is not indicative of what was actually installed. Using the component only shows 2.2.0 which is meaningless when there are so many editions of 2.2.0. Earlier somebody said I shouldn't have downloaded the latest released version, effectively saying because it might be buggy, yet this is the only version available to new users - and how should I know when to upgrade to a stable version - or even what IS a stable version?! Very confusing. But then I come from a software environment that requires unique version numbers for each release so perhaps I'm being a little harsh.

nicolas wrote: Then, PayPal tries to send the notification to that menu item and it is rejected by joomla because paypal's server is not logged on your website when doing the notification. So it would work fine for all users who would pay directly via the checkout and not for those paying via that menu. And in such case, the solution is to configure the "force a menu on checkout" option to a public menu so that all the customers go to paypal via that menu, ensuring that paypal can always send the notification to HikaShop.

That kind of makes sense except I'm not sure how some users might have success when others don't, when using the same menus. I don't think there is a hidden way into the shop.

I have found the setting you describe and set it to the home page menu item. Is that an appropriate selection? Not to a specific shop page or something?

nicolas wrote: Of course, it is always recommended to test an update ( for hikashop but also for other extensions and even for joomla) on a copy of your website and do a backup of the website before in case you encounter some unexpected issues after the update. That way, you can easily go back to what you had.

Indeed, but wouldn't have helped in this case where the success rate isn't exactly 0% or exactly 100%. My test order went through fine. It's only when real world customers started complaining that I realised something was up. That would never have appeared on a test website because it needed real world customers to interact with PayPal to expose the bug.

nicolas wrote: Regarding the version numbering, of course each new build we publish of HikaShop has a different build number. It is not displayed to the user as it is usually not necessary to know it.
If you look at the HTML code of the footer of HikaShop (if it is activated in the configuration) you will see the build number in the comments of the HTML code.

Ah, would that be the 2.2.0 [1308011801]? If so, may I suggest it is displayed in the back end? Users may not need to know but sysadmins often do without digging through reams of HTML code.

I have set the menu option and will wait to see the results of that before going on to the other suggestions. Thanks for the continuing help.

1. I didn't have any orders unfortunately, despite half a dozen in each of the days prior. So I set up the menu option as you describe, "shop checkout" (I don't remember creating it - does HikaShop do this automatically), logged in, and did a test purchase. After paying with PayPal, it returned to my site with a blue "Thank you for your purchase" banner. The order still shows as "created" and no emails from HikaShop, nor any plugins called.

2. Thanks. Showing the build number will ultimately help you if somebody asks for advice and they say they have version 2.2.0... but which version of 2.2.0 do you have?

So, assuming I set up the menu option in the way you describe correctly, it doesn't look like that is the problem. Is there any debugging I can add, or option I can set (either in PayPal or HikaShop) that will allow us to see where it goes wrong?

Sorry, I missed that link (I find it hard to spot blue text within black).

Ok, debug was already running. Oddly the only contents are about a payment reversal (which did happen) and cancellation of the reversal (which also happened). I placed a new order but no new entries were made in the log file.

Next I looked at the Apache log. I couldn't find anything with even just "task=notif" in the search string. I did find a bunch of requests pertaining to the new order though:
108.x.x.x - - [09/Aug/2013:00:33:49 +0100] "GET /index.php?option=com%5fhikashop&ctrl=checkout&task=after%5fend&order_id=101103&Itemid=318 HTTP/1.1" 200 61907 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0"
108.x.x.x - - [09/Aug/2013:00:33:50 +0100] "POST /index.php?option=com%5fhikashop&ctrl=checkout&task=after%5fend&order_id=101103&Itemid=318 HTTP/1.1" 200 61907 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0"
108.x.x.x - - [09/Aug/2013:00:33:51 +0100] "GET /media/com_hikashop/css/frontend_default.css?v=220 HTTP/1.1" 304 - " www.xxxxxx.co.uk/index.php?option=com%5f...id=101103&Itemid=318 " "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0"
108.x.x.x - - [09/Aug/2013:00:33:51 +0100] "GET /media/com_hikashop/js/hikashop.js?v=220 HTTP/1.1" 304 - " www.xxxxxx.co.uk/index.php?option=com%5f...id=101103&Itemid=318 " "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0"
66.249.75.209 - - [09/Aug/2013:00:33:52 +0100] "GET /index.php?option=com_hikashop&ctrl=checkout&task=after_end&order_id=101103&Itemid=318 HTTP/1.1" 200 46565 "-" "Mediapartners-Google"
66.249.75.209 - - [09/Aug/2013:00:33:53 +0100] "GET /index.php?option=com_hikashop&ctrl=checkout&task=after_end&order_id=101103&Itemid=318 HTTP/1.1" 200 46565 "-" "Mediapartners-Google"

The 108.x.x.x address is mine. The 66 looks like Google, maybe to do with the Adwords advertising I have on my site. I found these entries by searching for the 101103 order ID.

The PayPayl plugin settings are:
Allow payment notifications: yes
Enable validation mode: no
Debug: yes
URLs: all 3 empty
IPs: 173.0.84.*,173.0.88.*,173.0.81.*,173.0.82.* (and no 173.0.8 in the Apache log) (if I click "refresh IPs" the box goes blank)
Return method: yes

As for PayPal, there are too many options. IPN is not enabled. The page you refer to says "Please make sure that the payment is accepted in your PayPal account. If the automatic validation of the payments is not turned on in your PayPal account, PayPal won't send the payment notification to HikaShop and your orders won't be confirmed !", however, I can't find this option.

Ok, here's the thing. When things started going wrong I did look into the IPN thing on the PayPal website. it was switched off and I don't recall ever setting it up (and indeed the fields were empty). So I did try putting a link in - and when I found this thread and copied the link from there - it was the same link I tried a few weeks ago. In the meantime PayPal sent me some warnings that IPN was failing and eventually it automatically switched it back off again.

Today when I put the link back in and do a test purchase, it went straight through correctly. Hopefully I'll have a customer or three today to see whether several orders go through correctly.

I apologise for not mentioning the IPN settings before - I honestly didn't think it was relevant because, to the best of my knowledge, it was never enabled when hundreds of previous orders had gone through okay in the six months prior to this.

Fingers crossed....

We released a new product yesterday so got a flood of new orders. Most went through but some still didn't. The HikaShop log file was empty (I emptied it a couple of days ago) so nothing useful there. Next I went to PayPal and look at the IPN log (now that it's enabled). That showed 403 errors. When I looked at the Apache raw access log, the IPs the notifications came from did not match the HikaShop settings. Upon Googling "HikaShop IPN IPs" I found a couple of threads where you (Nicolas) suggested just blanking the box but you didn't really elaborate. Is it safe? I mean, can a user work out their shopping cart order ID and then spoof-post the data into HikaShop so it thinks it came from PayPal? What's the point of having an IP white list if there's no need to use it?

Thanks.