Andrew H

Orders aren't validating in my PS installation. The orders don't appear in the back office and the "customer" arrives at a blank page (or an order summary in the case of PayPal). Originally I thought the problem was specific to PayPal and then realised no orders were validating, even check/bank wire -I get a 500 error. It's on a 1.5.3 Prestashop store. I think the problem is related to the database in some way because the store is a copy of another store I operate (which works fine). I don't want to upgrade at the moment... thanks (I will only offer the work to someone who's been active for a while on the PS forum)

I have an online shop that has been upgraded through various versions through to version 1.5 Orders don't validate, so whether I use bank wire or check/cheque option the page hangs. If I use paypal, the order doesn't appear in the back office and PayPal IPN history registers a 500 error -although it does usually succeed in posting on the second attempt (but the order still doesn't appear). If it try and manually create an order from a cart, I get a 500 error. I've tried creating a fresh test product and I get the same trouble as I thought it might be some problem with a product from the old database Although I do plan to upgrade to 1.6, it's not something I want to go through right now so would prefer to getting it working in 1.5 rather than start again. I do remember some known problem like this related to upgraded shops although not sure of the cause or possible resolution. Any ideas? thanks

I'm not sure whether I needed to manually enable IPN for PayPal USA but I've set mine to: http://www.-------------.com/module/paypalusa/validation.php although I don't think this is making any difference. As I understand, the module tells PayPal where to post back (I may be wrong) but when viewing the IPN history in PayPal, there are error 500 codes although it does seem to be succeeding on second attempts, sometimes. If it does succeed on a second attempt the customer gets an "order received" email but not an order summary or invoice. No products appear in the back office, even if the IPN does succeed. Due to the initial 500 codes, I thought I'd check file permissions. I've got the PayPal module folder set to 755 and validation.php 644 which I think is correct (please correct me if I'm wrong). I've spoken to the host to see if they can help -they effectively said it's not their problem, that it's a PS problem... Any ideas? UPDATE: I've tried creating an order manually from the cart and this also creates an error 500. Just wondering if this helps identify the problem? SECOND UPDATE: I've realised my problem isn't specific to PayPal so I've posted an update here: https://www.prestashop.com/forums/topic/435282-orders-not-validating-in-back-office/

Thanks for putting this version of the module online: I'm using 1.5.3 and don't have the CSS issues you mentioned, layout is perfect. I'm trying to use this on a US store but have exactly the same setup working fine for a European site using the European module so I know the site is ok. Just a couple of things I wanted to say: Once you get to PayPal, there's no option to pay by card, only with a PayPal account -maybe that's a setting in PayPal, I don't know. The other problem, unfortunately it doesn't work for me. After entering PayPal details it hangs. If you refresh the page I get a pink Prestashop page about the errors. If I use the USA & Canada PayPal module I don't get the error message and it doesn't hang, but then I get the problem you describe with no order details appearing in the back office. If you have any suggestions how I can make this module work in my setup, that would be very much appreciated.

Thanks for your detailed reply. I certainly would be happy to roll back to the earlier version but as far as I know I can't due to the security problem with PayPal. The only reason I upgraded to the new version was due to the changes made by PayPal regards to the recent security alert.

I have this trouble too on 1.5.3 since upgrading to the new version of PayPal. We're in the UK and it's affecting international orders only related to the state error. It has so far affected all international orders and is now a real problem -affecting countries like the US and Canada that do already have the State drop down available. In this case I saw the customer attempted 5 times (far more than most would bother) and it actually worked fine on the 5th attempt without error so it very much seems like a bug. Another country (Italy) the customer was able to purchase but the shipping wasn't applied at all. I hope there's a solution as we're losing orders, particularly at this time of year, this isn't good at all.

Thanks for your reply. Basically I just want to remove the photos /files that have been uploaded by customers, nothing else... So I delete the files in the /upload/ directory and then clean those two database entries...? Will any of these changes cause issues with future uploads... What would happen if I removed the files but didn't change the database entries? Just interested to know the worst case scenario. As I mentioned, surely it would have been sensible to include a function in the backoffice to clean out such files...

Hi Please can someone tell me where the files are stored on the database for photos etc that customers upload, assuming it's safe to delete these without destroying other data. It doesn't take much for these files to get pretty huge on the database so I need to clean this from time to time. I'm surprised there's no option to delete such files older than a certain date... thanks

If that's the case, then Prestashop isn't considering the possiblity of more than one store (different versions) using the same PayPal account... (as far as I know, it's not possible to have more than one business account). However, with IPN disabled, the PayPal orders aren't appearing as "received" in the new version store and in old version store, the orders don't appear at all if disabled. To get around this issue, I've setup the IPN address to point to the old store with old PayPal version. So far it seems to be working for both stores (but it's too soon to tell because even before some orders were appearing in the back office and some weren't (the same for IPN -some were being sent, some failed) -I would have thought if this feature was redundant for Express it would either work or not work at all...

Thanks -it is PayPal express I'm using but it requires me to put a URL there anyway. I can't figure out why only about 50% of my IPN are getting rejected at PayPal... I've tried changing to the address you suggested and will see what happens.

hi Bellini -I'm using 3.5.8 -I assume that and 3.6 will be the same? I think it would make sense if the module specified the correct IPN to use for that version... Maybe it does, but I haven't seen it. The other problem, what if I have more than one store on different versions going to the same paypal account. Can I just set up the IPN based on one of the stores?

Hi Some but not all of my IPNs have been failing (possibly for an unrelated reason, I'm not 100% sure). I found info that said a specific address is no longer needed for latest PayPal version but to instead use this as PayPal requires something in the field (I don't know if this is true): http://www.***************.com/modules/paypal/ipn.php Is this correct? thanks

I've realised what causes my payment methods to stop working but not sure why. The other day, I was editing the PayPal settings, trying to get it to work with "force compile" enabled. I switched the shop back to "do not compile" -and realised moneybookers was working. It worked great for a few days without one failed order. PayPal still wasn't working. Yesterday I reset the PayPal module, trying to get that to work, (with force compile enabled again). I set it back to "do not compile" and then moneybookers and paypal stopped working. Through messing about with these settings I've got PayPal working again but not Moneybookers. It's driving me crazy. Does anyone have any idea why force compile could cause this issue (or maybe it's the disabling of force compile). I have noticed that this setting is also affecting something else in the shop so I wonder if it's somehow not working properly. *** UPDATE *** 16/10/2013 I've found part of the reason for the problem in the upgrade from the old version of Prestashop. Although the reason is partly my fault for using the wrong product code format, I certainly think the prestashop upgrade should have handled the issue better. Certain field lengths that were different in the old version but not acceptable in the new version and invalid code values in certain product codes (but were not rejected in old versions) meant that products from the original store were not processing properly (and when the cart contains these products) stops the order processing correctly. I realised today because 3 or 4 orders that didn't work contained the same product. When editing the product, without correcting the excessive characters or incorrect product codes meant an error page appeared. However, until I came to edit the page there was no indication of this problem. A good solution would have been the installation process to detect this issue and warn of the consequences or even better - for it not to slap tighter different rules on fields on new versions during an upgrade because this makes the upgrade process much more complicated and the months and months of issues and hassle I've had with this. Other than this, even better... PS should have automatically corrected the problems in the upgrade, I had no way of knowing except the hard way which isn't good enough to be honest. I can't be sure yet if this was 100% of the reason for the problems, but I know is certainly a contributory factor.

By the way, Conidig, did you add this to line 26 of validation.php for moneybookers module I assume? This is the exact same module causing me most issues (but gave me no issue in v1.4), although have similar problems with PayPal. The bug report did only refer to version 1.5.2 but I might give it a try in 1.5.3 anyway and see what happens.

Unfortunately there is no obvious constant. Due to the nature of the products, there aren't that many repeat customers. Since making the new website live, there have been no repeat customers from the old store. The odd few orders that have come through have not been repeat customers (except me, where it works fine every time with whatever product). However, there is one thing I have noticed. There are new products in the store that can be customised (old store didn't have this). I've been thinking it's "lucky" that each time I have an order where there is a personalised product -that the order comes through. I've just realised that EVERY time a customer places an order that contains one or more customised products, the order comes through ok. There have only been about 4 or 5 such orders, but considering about 70% of the small number of orders that have been ok have been customised orders, it could be more than a coincidence. I don't know if this is caused by the fact that the products are new or that the products have been added to the new (rather than old) site. Nearly all others do not come through or in some cases partially come through (so some of the products in the order appear) -but the full cart and order is always visible via the customer in the back office. I doubt it's relevant, but the only modification I made to the site with regards to customisation was the following: (I found this elsewhere in the forum -I'm only mentioning it on the offchance it's related -though I doubt it) Remove the line, or comment out, which says: require_once(dirname(__FILE__).'/init.php'); The file is in your admin directory and called displayimage.php and it's line 28 The reason for this modification was that the images uploaded with custom orders were not otherwise downloadable. thanks Andrew