There seems to be some kind of problem/bug when I send an order on my site. Every now and then the cart skips the order send and displays the empty-cart message, the order is not saved, even though all fields are evaluated properly. If I reload/refresh the page at this point, the order is sent and I get to the comfirmation page. At this point the "print order" function (link that opens new page with order details), often show an error message: Operation could not be completed!?!? If this page is clicked or refreshed several times the order details will eventually show...
Have any of you guys experienced this before!? The session and variables seem to be in place since a refresh (though after several tries), will give the information?
I've searched through the code (I'm using qc 1.4 loaded with all plugins enabled) and it seems the template calls are made in client-actions/orders.php:
fairbone - I think you messed up field validation in orders_delivery.tpl. Check again your orders_delivery.tpl against the original one.
fairbone
2006-11-15 15:41
Hi
Thanks for your reply... Yes I added some fields to the template, and I also added some code to the CheckFrom.js file to validate two of these new fields. To be on the safe side I also modified the php-field-check in core/orders.php and made it always return true.
I still get the same results, 70% of the time the orderplacement is exectuted as it should, the other 30% sends me to the empty cart page.
If it is the templates-file or field validation, where should I look for it in the code? just the templates file? In my opinion the problem seems more like a time-out related issue, since it works most of the time but not always. Could this be the issue in any way?
if it is related to some kind of time-out, is there any way get around that. I don't really know exactly how the sessions are handled in qc?
fairbone - check this http://opensolution.org/Quick.Cart/forum/?p=readTopic&nr=2884 (last few posts), describes an issue that may be the answer to your problem.
fairbone
2006-11-15 18:11
Thanks again
I have changed the wizzud code according to your post, first test order went well! I will keep testing from different computers/locations to see if that did the trick!
fairbone
2006-11-15 18:25
:( nope that didn't fix it! Still get the same problem with jump to empty cart and no order sent!
fairbone
2006-11-16 11:18
...OK
The problem still occurs randomly when:
1. viewing the cart (shows no products in basket even though I put some there), if i hit the refresh button in my browser the data is shown as it should, but if i click the link again - to view the cart, it still says that no products are in the basket.
2. proceeding from basket to checkout. Every now and again the cart says that no data could be found??? If I refresh once or twice the checkout with my products are shown.
3. When I hit the send button in checkout. The page will display "your cart is empty", if I reload the browser warns that data will be sent again, and if I hit OK I get to the confirmations pag.
4. When I try to print my order. The popup page that shows the order shows "Operation could not be completed". Here I usually need to refresh or klick link 3-5 times before I get my order shown.
To me this seems either like a read/write problem for the flatfiles db, or some kind of sessions missbehaviour. The site we have has about 100-150 visitors each day. a few weeks ago we got about 2 orders each day, now we haven't gotten any in 2 weeks. My main concern is that this is because of the problem I've described in this thread...
fairbone - i taked a look at page source in order - delivery and saw that you changed the code for hiding courier but it's incomplete, and as far as I know it's not working in QC14 (maybe I'm wrong!!). try putting back the code for iCourier select because my impression is that hiding it is messing up saving of your orders.
fairbone
2006-11-16 13:26
Hi Claps
Ok the courier code might be incomplete, but that ain't what's causing it... I've been in contact with our service provider and confronted them with the issue also, arguing that it might be a server related problem.
Now here's the interesting part. It seems that our service-provider uses a load-balancing 2-server solution that distributes all traffic evenly on these two servers. I managed to use a secure connection to our site that forced the traffic to only one server. Now I've tested about 20 orders and all went fine!!! So it seems that the load-balancing is causing the whole problem and would also explain why it works some of the times, but not all. Now the server people are looking in to this to see if they can override the balancing for our domain.
And as I earlier suspected the problem seems to be realted to the whole session-behaviour, you see all files are mirrored but the servers run on two separate php-engines, this is mainly why the data needs to be sent several times in some cases when the load-balancing occurs.
I'm trying to google for related issues to see if there's a way round this without forcing the site to one server, if anyone has any experience with sessions and load-balancing servers I would be greatful for the advice.
And again thank you Claps for helping me with this!
fairbone
2006-11-16 13:45
Hello again
I found a FAQ containing a similar problem:
"PHP, in its default configuration, stores session variables in small files on the file system. I wrote an application that is served by a group of web servers, so I needed each server in the farm to be able to recall the session variables set by any other server. Storing session variables in MySQL solved the problem."
@: http://www.tek-tips.com/faqs.cfm?fid=2037
This guy solved it by using a mySQL database, but surely this should be doable using an ff-technique also??? I'm surprised that I seem to be the only one with this problem?
fairbone
2006-11-16 18:21
Hi again
The problem seems solved now, the server people have forced all connections to our site to one server. I've tested about 10 orders and called everyone I know to put an order, and thus far the problem hasn't occured. I'm keeping my fingers crossed still, but it seems hopeful!