polyglot2 Posted January 29, 2008 Share Posted January 29, 2008 I recently tried out cart.php in WHMCS 3.5.1 because order.php in my installation has persistent issue with "Order failed" error message in step 6 for repeat customer (no error for new customer). When an order includes a domain, order total is always zero. And this prevents the order from being submitted. But when I only order hosting, the order value is correct. Anyone experiences this same issue? Any idea on what might have caused it? 0 Quote Link to comment Share on other sites More sharing options...
polyglot2 Posted January 30, 2008 Author Share Posted January 30, 2008 okay i tested with 3.6.0beta and it's now fixed. (now wondering what to do. 3.6.0beta is not recommended for production, but obviously i can't use 3.5.1 if people can't order using it guess i'll bite the bullet and use 3.6.0beta anyway...) 0 Quote Link to comment Share on other sites More sharing options...
WHMCS CEO Matt Posted January 30, 2008 WHMCS CEO Share Posted January 30, 2008 Are you sure you've got all your TLDs setup as ".com" and not just "com". The . at the start is important. V3.6 automates the adding of it if you leave it out which might be making it appear solved. Matt 0 Quote Link to comment Share on other sites More sharing options...
polyglot2 Posted January 30, 2008 Author Share Posted January 30, 2008 yup, it's all prefixed with dot ("."). when i peek into the session data file, the cart gets populated fine with the products. but as soon as a product with domain (like hosting+domain or just domain) gets added, whmcs shows the cart as empty. when i add yet another non-domain product, the product shows in the cart but the previous one(s) don't. anyway, glad that it's fixed anyway 0 Quote Link to comment Share on other sites More sharing options...
polyglot2 Posted January 31, 2008 Author Share Posted January 31, 2008 actually the problem still persists, and now i believe it has something to do with cookie domain. in our setup, per our security policy, whmcs and the database server run from an intranet site and not directly off a public server. then a filtering proxy retrieves the pages requested by clients from a public server. the filtering proxy, among other things, blocks "/admin" totally from the public so it can only be accessed from the intranet side. i will update this thread when i find something. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.