jsalis

I have older versions of this contribution working on two different carts, but I am trying to get 1.5 working now on a third cart. Everything appears to work OK except adding addresses to the address book, and editing addresses in the address book. These two functions work, but they don't work OK. The edits take place on the server side (and the new addresses are inserted), however; despite the a 200 OK with a response of { "success": "true", } The following code block in the checkout.php file (around line 601) onePage.queueAjaxRequest({ url: onePage.pageLinks.checkout, beforeSendMsg: 'Updating Address', dataType: 'json', data: $(":input", this).serialize(), type: 'post', success: function (data){ onePage.loadAddressBook($this, addressType); }, errorMsg: 'There was an error saving your address, please inform <?php echo STORE_NAME; ?> about this error.' }); Is returning the errorMsg rather than completing the success function. I have gone through all the applicable code and cannot find any reason why this would happen. If I close the alert and close the dialog then click change address I can see that the changes were in fact saved despite the error message to the contrary. Furthermore once the new address has been added or edit made I can simply click the radio button of the address I want to change to and then click confirm and it changes it without any error message. Any help would be greatly appreciated.

I had time to look into the form field validation issues I was having and discovered the following: 1.) There apparently are validation scripts that do at least the minimum checks (ie. min. length) 2.) These functions are not being called and form data is going straight to the AJAX function. I put an alert in each of the three validation scripts I found (getFieldErrorCheck(), checkFieldForErrors(), fieldErrorCheck()) and none of the alerts came up. 3.) Apparently you should be able to force validation on a field by adding the class name "required" to an input, though I tried this and it did nothing. I imagine there would also have to be an entry in the getFieldErrorCheck() function which in my case there is. 4.)fieldErrorCheck() appears to be called on the various fields from the attachAddressFields() function, but in my case this call is not being made. Does anybody have any pointers here?

Duh! It might help some of you if I actually provide the link I spoke of. Here is the link to the fix for discount_coupons.php

I think I follow what you are saying, but that is not exactly what I am doing. Possibly we have different taxation requirements, I am in California, here we are not taxing shipping, the shipper taxes us we pass the entire cost of shipping along. The shipping company pays the tax to the state. Anyway I have a product store and a sandbox setup with completely different checkout systems right now. The production store has the default multi-page checkckout and the order total information on a test order I just created looks like this: That is a ten percent discount. The Priority processing is not taxable and specifically excluded from the discount. Note that the batteries are taxable and the tax rate is displayed, but not included in the line item total. The discount is displayed above the subtotal in this case, so I display the subtotal with the discount applied. Then shipping (calculated on the prediscount subtotal) and tax (calculated on the post discount subtotal of taxable items only) is added and a total provided. This meets local requirements. And unless my calculator has issues it is calculated correctly every time. Though I don't think this is exactly the arrangement you are speaking of. Next is a shipping discount. This is not as pretty, but definitely accurate. The order total module and discount module do not work together well enough to change the sort order of the discount line only when a shipping discount is applied. Since it is rare that we offer shipping discounts I went with above the subtotal. Technically in this case the discount is not applied to the subtotal, but applied between shipping and tax despite where it is displayed. the calculation appears to be off by a penny, because of the way the the line items and discount are rounded to the second decimal place. This seems to happen about 25% of the time. In the production environment I also moved the discount code entry from the checkout_payment.php page to the shopping_cart.php page and wrote an AJAX script to validate the code, tell the customer what the discount will be, and save the code in a session variable to be applied on the checkout_confirmation.php page. My cart is highly custom at this point and the code is not easy to integrate into another cart, but I will happily send you the code I used to integrate all or part of the solutions above if you think they will meet your local requirements. My sandbox is using the one page checkout and always displays the subtotal without the discount and displays/applies the discount right after the subtotal line. Otherwise all taxation is setup the same way in the sandbox version which should go to production later this week.

While doing further testing I have found the following Using KGT with One Page Checkout if the coupon is processed prior to selecting a different table rate shipping method the discount will also apply to the shipping as well as the subtotal. For a fix checkout this post I wrote regarding the includes/classes/discount_coupons.php and how I fixed the issue two post later. I also discovered that the Low Order Fee module apparently does not work in One Page Checkout. Does anybody have Low Order Fee working in One Page Checkout and if so how did you do it?.?.? Lastly I still haven't gotten back to the validation of the New Address and Edit Address functions yet. I hope to do that this afternoon.

Thanks for the information I am using the 3.32 and used the auto installer, but have modified the contribution twice; once to accommodate a custom auto discount module I built to automatically generate and send coupons that can be used by this module when a customer makes a qualifying order and again to accommodate the One Page Checkout contribution. Could be why I saw no effect, but after looking at the code in question and how the function is called and used in the catalog/includes/classes/order.php order class cart() function I just don't see how it could possibly work. Apparently I would need to see how ver.3.34 is coded. Oh well it is working now and an alternative is posted. Seems like I had similar issues getting taxes working when I first implemented this contribution. My settings are: Enable discount coupon? true Sort Order 2 Display discount with minus (-) sign? true Display subtotal with applied discount? false Display tax in discount line? None Exclude product specials? true Random Code Length 6 Display discount total lines for each tax group? false Allow negative order total? false Use the language file to format display string? false Display Format for Order Total Line Discount Coupon applied Debug Mode false It works fine now, but I can't recall what the tax issue was exactly or how I fixed it.

Ok I figured this one out. Instead of this: if( MODULE_ORDER_TOTAL_DISCOUNT_COUPON_DISPLAY_SUBTOTAL == 'false' ) { //we don't want to display the subtotal with the discount applied, so apply the discount then set the applied_discount variable to zero so that it's not added into the order subtotal, but is still used to correctly calculate tax $actual_shown_price = ( $this->apply_tax( $product['final_price'], $product['tax'] ) * $product['qty'] ) - ( $discount['applied_discount'] + $discount['discount_tax'] ); $applied_discount = 0; $shown_price = $this->apply_tax( $product['final_price'], $product['tax'] ) * $product['qty']; } else { $shown_price = ( $this->apply_tax( $product['final_price'], $product['tax'] ) * $product['qty'] ) - ( $discount['applied_discount'] + $discount['discount_tax'] ); } It should be this: if( MODULE_ORDER_TOTAL_DISCOUNT_COUPON_DISPLAY_SUBTOTAL == 'false' ) { //we don't want to display the subtotal with the discount applied, so apply the discount then set the applied_discount variable to zero so that it's not added into the order subtotal, but is still used to correctly calculate tax $actual_shown_price = ( $this->apply_tax( $product['final_price'], $product['tax'] ) * $product['qty'] ); // - ( $discount['applied_discount'] + $discount['discount_tax'] ); Comment out this part $applied_discount = 0; $shown_price = $this->apply_tax( $product['final_price'], $product['tax'] ) * $product['qty']; } else { $shown_price = ( $this->apply_tax( $product['final_price'], $product['tax'] ) * $product['qty'] ) - ( $discount['applied_discount'] + $discount['discount_tax'] ); } The $actual_shown_price was in fact being used, but it was performing essentially the same calculation as $shown_price. After commenting the part of that calculation that subtracted the discount and added the tax not only do I see the subtotal without the discount applied it is also used for my table rate shipping, which was the entire reason I needed the subtotal to reflect the pre-discounted price. My table rates are based on price and the subtotal was being reduced by the discount prior to the shipping calculation being made which is a percentage of that subtotal. Of course none of this was an issue until I implemented one page checkout. The standard checkout forced shipping selection prior to discount validation. With one page checkout this can occur in any order. Something to be aware of if you are considering the One Page Checkout contribution with this discount coupon contribution.

Can anybody confirm this actually works. I have made this change to version 3.2, but still have the exact same result. I still have the discount displayed in the subtotal. Since I don't see any more comment on this I assume it works in at least one version of the contrib.

Anybody else notice that the add/edit address features of this contribution has inadequate validation to prevent people form entering screwy information in the address fields? For example I am able to add a completely blank address then use that for my shipping address. The end result to this little game is that the customer gets to checkout without paying for shipping, because there is no geo_zone and the shipping modules are assigned to the geo_zones. Validate, validate, validate. I am just about to head out for Christmas vacation, when I get back I will fix this and post a patch to the forum if nobody beats me to it. I don't have time at the moment to see where else the validation is lacking, but in this case it is not the end of the world simply charge the customer for shipping when you call to ask where they want the order shipped to. This is very basic level of validation however, which makes me wonder if this validated at all or if the user input is even escaped.

I figured out a much simpler, and more direct approach. I created a function in the includes/classes/shipping.php class as follows: function first() { if (is_array($this->modules)) { $rates = array(); reset($this->modules); while (list(, $value) = each($this->modules)) { $class = substr($value, 0, strrpos($value, '.')); if ($GLOBALS[$class]->enabled) { $quotes = $GLOBALS[$class]->quotes; for ($i=0, $n=sizeof($quotes['methods']); $i<$n; $i++) { if (isset($quotes['methods'][$i]['cost']) && tep_not_null($quotes['methods'][$i]['cost'])) { $rates[] = array('id' => $quotes['id'] . '_' . $quotes['methods'][$i]['id'], 'title' => $quotes['module'] . ' (' . $quotes['methods'][$i]['title'] . ')', 'cost' => $quotes['methods'][$i]['cost']); } } } } $first = $rates[0]; return $first; } } Then made this simple change to the includes/checkout/shipping_method.php file around line 42. // $shipping = $shipping_modules->cheapest(); $shipping = $shipping_modules->first(); Now all I have to do is start my sort orders in the admin panel at 1 and whatever I give sort order 1 is now the default regardless of how much the shipping method cost. This solves the international problem by simply defaulting to the module with the lowest sort order. If my Canadian or Alaska/Hawaii options come after my lower 48 options it doesn't matter because they don't quotes for those orders anyway. Just to keep it from looking confusing in the admin panel I made my lower 48 options sort 1-5 my Alaska/Hawaii options sort 1-2 and my Canadian option is sort one, so as we begin shipping to more and more geo_zones I will simply have similar sort groups for each new geo_zone. Hope this helps some of you.

I need to be able to set the default shipping method. This will not be the lowest, nor the highest priced shipping method, so changing the cheapest() function to look for the most expensive is not an option. I played with the idea of using the sort order by making the following edit in the includes/checkout/shipping_method.php file around line 41. if($free_shipping == false){ $ds_sql="SELECT configuration_key FROM configuration WHERE configuration_title = 'Sort Order' AND configuration_key LIKE '%MODULE_SHIPPING_%' AND configuration_value = 0"; $ds_query=tep_db_query($ds_sql); $ds=tep_db_fetch_array($ds_query); $ds_method = substr($ds['configuration_key'], 16, -11).'_'.substr($ds['configuration_key'], 16, -11); $shipping = array( 'id' => $ds_method, 'title' => 'Default Method', 'cost' => 'Default Cost' ); // $shipping = $shipping_modules->cheapest(); This does in fact work in that it sets the default shipping method to whatever shipping method is current in the sort order 0 (zero) position. The only problem is that we ship to US and Canada. Canadian shipments do not have this option available. So if a Canadian shipping address is provided there will be no default shipping address. I guess this is not a terrible thing as we do not ship to Canada all that often, but I was wondering if anyone had some ideas how I could set the default for multiple geo_zones. I thought of having the sort over start over at zero again for Canadian options, and starting the Alaska/Hawaii options at zero, so there would be three zeros, but I haven't quite figured out how to change the query to make sure I get the default for the correct geo_zone_name. I cannot find a db only solution and may have to use the $shipping_modules object in conjunction with the configuration table in the db. Any ideas?

I noticed the same thing, but for unrelated reasons I decided to show the shipping address by default and require login. No issue now, of course this requires customers to use the original create account script to create an account prior to using one page checkout. This is preferred for now in my case because we collect quite a bit of custom data from our customers during the account creation process. I also used similar if() statements to check the vertical or horizontal layout for the shipping/billing addresses to provide the same option for making the shipping options line up horizontally with the payment options, so selecting horizontal in the admin panel makes both the addresses and Payment and shipping options horizontal and minimizes the amount of scrolling to checkout. A nice trade off. You can see it here lwtest.49ercommunications.com I am wondering if you have Auto-show billing/shipping modules is set to false?.?.?

Steve, Thanks for the tip I am finished testing and at least in test mode everything appears to work as designed. I did remember however, why I wasn't using this particular Authorize.net payment module; this module has no way to turn off customer notifications from Authorize.net (we send HTML equivalents from osC directly) and this module stores the entire credit card number in the osC db. To make this arrangement PCI compliant I would have to change my server environment. Does anybody know if the Authorize.net notifications can be turned off from the merchant control panel at the Authorize.net website or a simple way to make this module request that no e-mail notification be sent to the customer directly from Authorize.net for each transaction the way that the authorizenet_aim.php module does? I am sure I can modify this module to x out the middle digits of the cc number, but I sure wish the other Authorize.net modules worked with OPC. The authoriznet.php module even has the ability to select which credit card types you want to accept and does echeck.net. Though I understand that particular module has some licensing issue that restricts how it can be distributed. Thanks, Jason

I found the payment module specified here http://addons.oscommerce.com/info/5662 and installed substituting the file as you suggested and the payment method now sets correctly. I will test with some transactions, if all is well I will not need to post again, so I would like to thank you now. Merry Christmas Steve and Thanks a mint, this was much quicker than figuring out why the other Authorize.net module didn't work. -Jason

Hmmm, I don't have that one. I will have to see if I can scrounge up a English language file to go with it.

How embarrassing, after plowing through the queries included with the contribution I verified that every query was successful. Then I looked at catalog/admin/includes/configure.php file and discovered that the change the db assigned there was the production db instead of the sandbox db that I ran the queries against. Anyway the admin panel does work fine and I no longer need to change the configuration from the MySQL db directly. My initial testing was with the cc payment module which works well enough.The Authorize.net AIM module (or Credit Card via Authorize.net module)on the other hand suffers the same fate as others have reported here in the forum. Basically if I select the Authorize.net module's radio button I get the "There was an error setting payment method, please inform [Company Name] about this error." message, then if I click continue I get the same message again in addition to the error that the first 4 digits of the card number indicates an unsupported card type message, only now the module is in fact actually loaded and can be used. I have tried making Authorize.net available with and without the cc module makes no difference nor does it make any difference which Authorize.net module I use.

Steve, Exactly! I looked at my configuration table after running all of the queries included with the contribution and that is exactly where I would expect it to be based on the records created. Admin>Configuration right in between Session Options (sort order 15) and Dynamic Mopics (sort order 17) , however; it is not there. I gathered from the two responses to my initial question that there is not a separate admin panel page for this contribution, but rather that the configuration is made using the configuration.php page with the appropriate gID specified in the url. When I check the configuration_group table I see that One Page Checkout is assigned configuration_group_id 7575. Despite the fact that there is no menu entry for One Page Checkout in my Configuration menu I tried this url catalog/admin/configuration.php?gID=7575 Which resulted in the following screen shot. As you can see not only is the Configuration menu entry missing the configuration.php page does nothing with the gID 7575. Strangely enough no error is generated either, just this blank configuration page. The next screenshot is of the relevant section of the configuration and configuraiton_group tables, perhaps one of the queries included with the contribution failed in some way without error and I am missing a record that somebody can point out. -Jason

Installed and works, sort of. I can actually check out, but I have absolutely no administration. The only way I can change any of the settings is to do it from the MySQL command line?.?.? I read in the forum several threads discussing various aspect of the administrations tools for this contribution, and how to change settings, but I have downloaded all version of the contribution and cannot find any admin files anywhere. I can see clearly that one of the sql queries added a sort order entry that would put the One Page Checkoutright between Session Options and Dynamic MoPics In the admin panel however there is nothing between these menu entries. Presumably because the package included nothing for me to install in the admin panel, but then how is it that many of you have administration tools for this contribution?.?.? :blink: I presume once I have this worked out I will be able to change the payment modules that are loaded. As it is the modules appear to work, but One Page Checkout ignores entirely the payment modules I set up with the usual payment modules tool in the admin panel. Any hints would be appreciated of course, but perhaps somebody can point out a duh! moment for me?.?.?

I had found a shortcoming in the contribution that I have since fixed, but was wondering if anyone has a better fix for this. The issue: I use multiple table rates (but the problem would apply to anyone using any combination of more than one shipping module. Basically if I offer a 100% off shipping discount the customer could select my UPS Ground Table rate or my UPS Overnight w/Saturday Table rate and it would still be 100% off. Obviously I don't want to give away, such an expensive delivery service. I solved the problem (code to follow) by putting a check in place right before the HTML is output to the checkout_confirmation.php page. The check first verifies if a code was entered then checks the code to see if it is shipping, if so it checks the the amount to see if it is 1.0 (100% or FREE) when this is the case it checks the shipping method, if the shipping method is not UPS Ground then it sends the user back to the checkout_shipping.php page with a message that the coupon code is only valid for UPS Ground. This gets the job done, but the code needs to be modified in two area for every site it is installed on. Not very many sites are using a Table rate called UPS Ground, so each site admin would have to adjust the shipping method to look for and also the site admin might not want limit only FREE shipping discounts to the least expensive shipping method, but perhaps any shipping discount over 40% or 75% or whatever. On the bright side the code that follows is very simple and easily edited to your taste, with minimal PHP skills. This code goes just above the HTML portion of the checkout_confirmation.php page. // if coupon code is for free shipping ensure user selected UPS Ground shipping service if (!(empty($coupon))){ //Only do this if a coupon code was entered // Get the coupon info from the db. $coupon_info_query = tep_db_query("SELECT * FROM discount_coupons WHERE coupons_id = '".$coupon."'"); if(mysql_num_rows($coupon_info_query) > 0){ $coupon_info = tep_db_fetch_array($coupon_info_query); if($coupon_info['coupons_discount_type'] == 'shipping' && (int)$coupon_info['coupons_discount_amount'] == 1 && $order->info['shipping_method'] !== 'UPS Ground (UPS Ground)'){ // Redirect only if the coupon is a FREE shipping and UPS Ground is not the selected shipping method tep_redirect(tep_href_link(FILENAME_CHECKOUT_SHIPPING.'?sc=1', '', 'SSL')); } } } This code goes just inside the body tag of the checkout_shipping.php page and generates the message to the customer. Alternatively the message stack could be used or you could place the notice somewhere else. <?php if($_GET['sc']==1) echo '<h3 style="background-color:red;color:white;width:100%;">That coupon code is only valid for UPS Ground</h3>'; ?> I would love to see someone universalize this so it could be added to the contribution. Perhaps the the threshold for the shipping discount and allowable shipping method should be stored in the db and controlled from the admin panel. It would certain simplify the administration for non coders, but would also add some unnecessary db queries. I look forward to your thoughts.

I think the refresh is taking you back to the store home page, because you have the main catalog directory specified as your base href in your head section. I did some experimenting when I realized that this is the default osC setup. I tried commenting out the base href line from the head section and presto it works. I still think it is better to get to the root of the problem, but hey there is a temporary fix. You will have to discover for yourself what osC components are justifying that base href. I cannot find any for this page in particular. Perhaps there are other pages that require this, and it was simply apply site wide. I have no idea on that one, but this is apparently why you are having trouble with the refresh issue.

This contribution has nothing to do with the catalog/admin/login.php page has nothing to do with this contribution. I suspect however that your catalog/admin/includes/configure.php file is not correct. Try to navigate directly to login url for your store http://yourstore.com/catalog/admin/login.php for example and see what happens. If you do not get a 404 take a look at your catalog/admin/includes/configure.php file and see if any thing is messed up in there as far as the directory constants are concerned. Another place to look is filenames.php file, as it is entirely possible that the FILENAME_LOGIN constant is not properly defined. If you do get a 404 however, then ftp in and see if the login.php files is even present on the server. From the message you provided I suspect that filenames.php and/or the configure.php file(s) have some constants not correctly defined and specifically the FILENAME_LOGIN constant simply isn't defined at all. Do tell what you find out. -Jason

I am working on some development for this contribution, but don't see where the number of times a specific customer has used a given coupon is stored. This feature allowed me to use a coupon 4 times that had a max use of 2 then on my fifth attempt is threw and error message stating that I had used the coupon 4 times and I am only allow 2 times, so I cannot use it again. I want to clean that up, before releasing my contribution to this module, but I don't see any db fields that would store such data. Can anyone point me in the right direction?

Did you give option 3 a go? Also option two must be called from an onload event. I forgot to mention that, sorry.

I have not been able to reproduce this problem. Believe me before I took this contribution with all of my modifications to the production server last night I tried to reproduce it to make certain I wasn't going to have a problem with it. I settled on version 3.32 as it had the fewest bugs and customizations for me to make, so I have no idea why you are having this problem. I would tripple check to make sure you didn't miss anything in the installation. After that if you still want to solve the issue by refreshing the page consider that there are about a dozen different ways to do this that I can think of off the top of my head, but they will get you stuck in a loop. You can set a delay so the user has time to move through the checkout process, but then they may continue on before the first refresh. I can only think of a few solutions that may solve your problem from a refresh approach that will not put your visitor in a refresh loop (think stock ticker that constantly refreshes with new data). JavaScript Solution 1 (probably the most cross-browser compatible, though I have tested much): if(window.location.search.indexOf('reload')<0) window.location.replace(window.location.href+'?reload'); JavaScript Solution 2 (works by storing a reloaded variable in the navigator DOM level and then checked on reload to see if another reload is necesarry. simply change the < 1 to however many times you want to reload.): function loaded(){ if (!navigator.reloaded){ navigator.reloaded=0 } if (navigator.reloaded < 1){ navigator.reloaded = ++; location.reload(); } } JavaScript Solution 3 (the simplest solution I know, but likely the least cross-browser compatible): if(name!='reload') { name = 'reload'; window.location.replace(window.location.href); } Test those out and let me know which seems the most cross-browser compatible. BTW the second solution can be called from an onLoad. -Jason

I am sure my boss will have me working on this one before long.