Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by KirkM

  1. Thanks Brian. I should have gone and checked the bug tracker but am so busy I took the lazy way and posted here. Will monitor it over there.
  2. Upgraded store from 6.2.9 to 6.4.4. No error messages in the upgrade. However, now product options print in what looks like a hash of some sort instead of the color, size, etc. (See attachment) Everything seems correct in the admin and I even deleted and re-added the options but it still prints out this hash on the order. I went in to the tables to make sure it wasn't something getting written that way but the options are correct and in plain text there. Any help on where I should start looking for this would be greatly appreciated.
  3. Is this available somewhere? One of my clients wants this functionality and it appears it still isn't built into the latest version of CC. I don't see it in the Extensions Marketplace. Thanks
  4. I just did a test with the original code restored and the CCD enabled and it appears you are correct. Thanks for tracking that down. Seeing that the GDPR extends to any company who could possibly do business with anyone in Europe, I suppose it should just be enabled by default in CC since theoretically every store on the web is doing business "worldwide".
  5. Using DevTools in Chrome, I cleared all cookies from the site and then loaded a couple of pages. I see a lot of cookies being stored from the CC store, but none that appear to be any of the listed cookie names used by Smarty. I need to find out where the $smarty.cookies.accept_cookies variable is stored and how it is triggered to true. Perhaps this is a result of the "Cookie Compliance Dialog" not being active in the store?
  6. So it has something to do with the cookie acceptance. If I go to skins/foundation/templates/element.google_analytics.php and take out the smarty {if} statement, it works fine. Original code: {if isset($smarty.cookies.accept_cookies) && $smarty.cookies.accept_cookies=='true'} {literal}<script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', '{/literal}{$ANALYTICS}{literal}', 'auto'); ga('set', 'anonymizeIp', true); ga('send', 'pageview'); </script>{/literal} {/if} Removed the {if} statement and that works: {literal}<script> (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', '{/literal}{$ANALYTICS}{literal}', 'auto'); ga('set', 'anonymizeIp', true); ga('send', 'pageview'); </script>{/literal} I don't see where this cookie acceptance is unless it is in the GDPR settings. In this store, they are both off. Does the cookie compliance dialog have to be on for the GA code to work?
  7. My skin is basically the Foundation skin with a few css tweaks. It should be doing exactly what the Foundation skin does. I will have to hunt around and see if I can find what you are talking about. In the mean time, I see a LOT of this in the error logs: File: [controller.admin.pre_session.inc.php] Line: [26] "SET @@time_zone = 'America/Los_Angeles'" - Unknown or incorrect time zone: 'America/Los_Angeles' File: [controller.index.inc.php] Line: [27] "SET @@time_zone = 'America/Los_Angeles'" - Unknown or incorrect time zone: 'America/Los_Angeles' Don't understand how that can be since it is the correct formatting for a timezone and it is selected from the admin drop-down menu. Edit: It does it with all timezone choices. Edit #2: It appears it is not relevant to this situation per this thread - https://forums.cubecart.com/topic/55533-error-about-timezone/
  8. Strangest thing - I upgraded from 6.1.13 to 6.2.9 a little bit ago and my client just noticed that there is no GA feed to his GA account. The really strange part of it is that it isn't an instant drop off. It goes from Feb 2 to Feb 17 in a sharp decline to zero over days. I don't know if the upgrade has anything to do with it or not. If it did, you would think it would have dropped to zero instantly when the upgrade was done. I have diffmerged all of the files to make sure that everything is the same on my installation as the clean version of 6.2.9, including matching my custom skin to the foundation skin with only my css changes the difference. Everything seems to be there. Also, I noticed that Google Tag manager shows no Google Pixel on the site when I go to it in Chrome. I also checked to make sure the element.google_analytics.php file is there in the skin templates file. Not sure where to start looking for this.
  9. Al - Just noticed that the First Name and Last Name are inverted in versions 1.0.4 & 1.0.5 on lines 179 & 180 in gateway.class.php
  10. Here is what I have from tonight's test: - Order DOES go to "processing" even if the customer bails out after hitting the "Pay" button and doesn't go back to the store by clicking the "Confirm" button on the Auth.net results window. This is great. - Created a copy of the "Default emails" template, called it "Hard-coded emails", replaced the header image and signature macros with hard-coded urls and made it the default. - Under the "Email Contents" tab, I modified Cart: Order Confirmed and Admin: Order Received, replacing the macro {$DATA.link} with a hybrid hard-code / macro combination of https://mystore.com/index.php?_a=vieworder&amp;cart_order_id={$DATA.cart_order_id} (where mystore.com is the actual store domain and the order number is handled by the dynamic macro {$DATA.cart_order_id}). - Have NOT been able to solve the gigantic store title issue on the Auth.net transaction results page. Will have to keep looking or call their support and find out how to get this under control. It looks like all of the information is being sent correctly and the transaction was successful. (NOTE: I only tested auth only since my clients all capture funds when the item ships.). Generally, it works with a few workarounds and the need for a small formatting tweak. I much prefer the new embedded frame and the clean form look and operation to the old SIM. It works well enough for me to put it live in one of my client's stores. We will see how it goes over the next 24 hours of live use.
  11. Or maybe you are right. It happened when I first tested this extension but there were other things misfiring so that could have been it. I know the old SIM extension did that but we didn't employ the silent post URL with that. I will check v4 overnight (HST) and look at the status in admin before I click the CONFIRM button. Seems to be the standard M.O. with their API and documentation. Lots of blanks you have to fill in yourself. One other thing - Do you know if it is possible to format this? "settingName": "hostedPaymentOrderOptions", "settingValue": "{\"show\": true, \"merchantName\": \"'.addslashes($GLOBALS['config']->get('config', 'store_name')).'\"}" The store name is HUGE. I have searched around the Auth.net docs and I don't see it. If the store name is a moderately long word, it word-breaks and wraps. It looks pretty terrible.
  12. Yes, it went to processing and returned to the store correctly and displayed the receipt / summary CC page when the "confirm" button was clicked. Perhaps the customers aren't clicking the "confirm" button to complete the return to the store? I would love to get this extension to return without that extra step by the customer to return to the store. If they bail out without clicking the "confirm" button after the transaction is submitted, the order stays pending even though the transaction was completed on the authorize.net side. I wish I could get some quality time to work with this. I will try to get back to it as soon as I can. I am just hammered right now.
  13. Ahh, I was wondering about having to do a Silent Post URL in the Authorize.net admin. I am quite busy but really want to get this straightened out so I will try to get back to testing soon to try to figure this return issue out. Here is the request json code block that successfully processed the transaction with invoice number and description (this code insert feature blows out the formatting for some reason): $request_json = '{ "getHostedPaymentPageRequest": { "merchantAuthentication": { "name": "'.$this->_module['merchant_login_id'].'", "transactionKey": "'.$this->_module['merchant_transaction_key'].'" }, "refId": "'.bin2hex(openssl_random_pseudo_bytes(8)).'", "transactionRequest": { "transactionType": "'.$this->_module['payment_type'].'", "amount": "'.$GLOBALS['cart']->basket['total'].'", "profile": { "customerProfileId": "'.$customer_id.'" }, "order":{ "invoiceNumber": "'.$GLOBALS['cart']->basket['cart_order_id'].'", "description": "STORE NAME order # '.$GLOBALS['cart']->basket['cart_order_id'].'" }, "customer": { "email": "'.$GLOBALS['cart']->basket['billing_address']['email'].'" }, "billTo": { "firstName": "'.addslashes($GLOBALS['cart']->basket['billing_address']['last_name']).'", "lastName": "'.addslashes($GLOBALS['cart']->basket['billing_address']['first_name']).'", "company": "'.addslashes($GLOBALS['cart']->basket['billing_address']['company_name']).'", "address": "'.addslashes($GLOBALS['cart']->basket['billing_address']['line1'].' '.$GLOBALS['cart']->basket['billing_address']['line2']).'", "city": "'.addslashes($GLOBALS['cart']->basket['billing_address']['town']).'", "state": "'.addslashes($GLOBALS['cart']->basket['billing_address']['state']).'", "zip": "'.addslashes($GLOBALS['cart']->basket['billing_address']['postcode']).'", "country": "'.addslashes($GLOBALS['cart']->basket['billing_address']['country_iso']).'" }, "userFields": { "userField": [{ "name": "cart_order_id", "value": "'.$GLOBALS['cart']->basket['cart_order_id'].'" }] } }, "hostedPaymentSettings": { "setting": [{ "settingName": "hostedPaymentReturnOptions", "settingValue": "{\"showReceipt\": false, \"url\": \"'.$process_url.'\", \"urlText\": \"Confirm\", \"cancelUrl\": \"'.$cancel_url.'\", \"cancelUrlText\": \"Cancel\"}" }, { "settingName": "hostedPaymentButtonOptions", "settingValue": "{\"text\": \"Pay\"}" }, { "settingName": "hostedPaymentStyleOptions", "settingValue": "{\"bgColor\": \"blue\"}" }, { "settingName": "hostedPaymentPaymentOptions", "settingValue": "{\"cardCodeRequired\": false, \"showCreditCard\": true, \"showBankAccount\": '.$showBankAccount.'}" }, { "settingName": "hostedPaymentSecurityOptions", "settingValue": "{\"captcha\": false}" }, { "settingName": "hostedPaymentShippingAddressOptions", "settingValue": "{\"show\": false, \"required\": false}" }, { "settingName": "hostedPaymentBillingAddressOptions", "settingValue": "{\"show\": true, \"required\": false}" }, { "settingName": "hostedPaymentCustomerOptions", "settingValue": "{\"showEmail\": false, \"requiredEmail\": false, \"addPaymentProfile\": true}" }, { "settingName": "hostedPaymentOrderOptions", "settingValue": "{\"show\": true, \"merchantName\": \"'.addslashes($GLOBALS['config']->get('config', 'store_name')).'\"}" }] } } }';
  14. I got the order->invoiceNumber and description to work. All children of the transactionRequest that you decide to use MUST be in the exact order listed in the documentation or you will get a namespace error. For the "order" child and its children, it had to be after "profile" and before "customer". I tested and it worked fine. Now there are two outstanding issues I am having. Both the order confirmation and payment confirmation emails to the customer have the logo url and store url going to the authorize_accept_hosted directory instead of each of the appropriate urls. Other emails from the store work fine. Not sure where to go to look for this problem but those emails are a disaster.
  15. https://developer.authorize.net/api/reference/index.html click down the "REQUEST FIELD DESCRIPTION" accordion link under the code examples.
  16. According to the API documentation, I think the issue might be here - Instead of this block (or in addition to it if CC needs this echoed back): "userFields": { "userField": [{ "name": "cart_order_id", "value": "'.$GLOBALS['cart']->basket['cart_order_id'].'" }] } It looks like it needs: "order":{ "invoiceNumber": "'.$GLOBALS['cart']->basket['cart_order_id'].'" }, Actually, I have had clients that use multiple stores with a single Authorize.net account so I have always modified the old extension with the x_description along with the x_invoice_num so I would put in something like this in the new API: "order":{ "invoiceNumber": "'.$GLOBALS['cart']->basket['cart_order_id'].'", "description": "STORE NAME order # '.$GLOBALS['cart']->basket['cart_order_id'].'" }, Where STORE NAME is whatever the client wanted to use for a unique store identifier. Let me know if the "userFields" is needed for CC response or not and I will modify and test the code with these modifications.
  17. You can say that again! I have gone over it a couple of times in the last 6 months so that I could understand the new API and it was typically poor documentation from them. Clear, thorough explanation has never been their strong point. I will go back to it again and see if I can fish something out of that mud. I think that is the only little issue with the extension. Other than the invoice number, it looked like everything processed correctly and the silent post url worked too. The only other thing is I need to find out where the formatting is for the approved message. The store name at the top is HUGE. But that is just formatting. The mechanics of the CC API client seem solid. Thanks very much Al.
  18. I can verify that version 1.0.1 did have the live payments issue and 1.0.2 processes successfully. However, there is still a problem as the invoice number is not being passed to Authorize.net in 1.0.2. It was x_invoice_num in the old SIM extension but I am not familiar enough with the new API to see at first glance why it isn't being sent in the json string.
  19. I can not confirm at this time as I have so many projects going right now, I simply haven't had time to go back to continue testing the new accept hosted extension. I do know that I have NEVER been able to use test mode with Authorize.net to an actual account without failure. I would first confirm whether this error is occurring in test mode or live mode. I'm not sure, but it may be that test mode only works with their testing sandbox. Or, it could be that I just don't know what I am talking about. The only way I have ever been able to test any authorize.net gateway extension is by logging in as admin in the middle of the night, closing the store and then going out to the storefront and making a purchase (store set to authorize but don't capture). This way, I get a real customer experience and know exactly what is going to happen with actual customers. If there are no issues, then great. If there are, I hopefully can find the problem, fix it and then confirm with another test purchase. Then I just delete the purchases in CC and void the transactions in the Authorize.net gateway (I require that my customers give me full admin rights in their Authorize.net accounts) and re-open the store. I realize testing in the production environment is really not the best way to go about this but I have had so much trouble with the authorize.net testing environment that I just gave up and do this hack to test. I will try to carve out some time to do a midnight test and upgrade of one of my client's stores. I can report back the results.
  20. Found it on line 192 of gateway.class.php: "settingValue": "{\"showReceipt\": false, \"url\": \"'.$process_url.'\", \"urlText\": \"Confirm\", \"cancelUrl\": \"'.$cancel_url.'l\", \"cancelUrlText\": \"Cancel\"}" Looks like an "l" got inadvertently typed in front of the backslash. Needs to be corrected on the download package.
  21. Just trying this out and got this when testing the order cancel button: Not Found The requested URL /modules/gateway/authorize_accept_hosted/cancel.phpl was not found on this server. My first thought was there was a typo in the gateway.class.php file putting a stray character on the end of the php file name. But I don't see any problems with it when I look at the file. I also did a search over the entire store for "cancel.phpl" and there isn't anything. So, it must be getting generated somewhere by a piece of typo'd code but I haven't been able to find it.
  22. From my math (actually, my iPhone calculator's math), it looks right when I do some random shopping. Thanks very much, I am off to put this into the other two stores. I assume this will be included in the next dot release so I won't have to tag it in my customization notes for my stores.
  23. It is close, but still not completely accurate. It isn't cutting the tax in half anymore, but it is rounding it. The 8.25% rate is being calculated at 8% in the store when you use a coupon. Without a coupon, it is still correct. If you can kill the rounding of the tax percentage, I think you will have it. Thanks
  24. Al Brookbanks has verified the bug and is working on a fix at this time.
  25. Thanks for the info. I did file a support ticket and Al is going to take a look. The change in 5.2.13 must be it. I upgraded from 5.2.12 to 5.2.14 for all 3 stores and they started complaining this week when they noticed customers using coupons weren't being taxed enough.
  • Create New...