Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


KirkM last won the day on December 1 2021

KirkM had the most liked content!

Profile Information

  • Gender
  • Location
    Kapanaia Farms, Kapaau, HI

Recent Profile Visitors

7,128 profile views

KirkM's Achievements


Explorer (4/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later Rare

Recent Badges



  1. I don't tweak the look of the payment form very much. Just a little bit of stuff to make it blend with the store, but I don't mind the basic formatting that gets sent from Authorize.net. It would be nice to be able to easily blend it so it was visually seamless, but to be honest, I simply don't have the time to do any deep diving into it. Besides, I think you are probably right that it is part of the formatting coming within the iframe from Authorize.net. Have you tried using the developer tools in Chrome to look at the live css when the window is open? If you can identify the classes that are formatting things you want to change inside of the iframe, you might be able to do an override of those classes with your own values using those class names if they load AFTER the payment window.
  2. I believe frameborder html attribute is not valid HTML5 and is obsolete. If you try validating your css, you will get a message "The frameborder attribute is not supported in HTML5. Use CSS instead." Try using pure css: style="border:none;" That tells it to remove the border. Or you can make the border width 0: style="border:0;" And also try adding the !important marker if it doesn't work in case there is upstream CSS creating it: style="border: none !important;" style="border: 0 !important;" Don't know if this will work, but it is worth a try! Good luck.
  3. Back again to this extension. A new issue has popped up that isn't a problem with the extension per se, but some updates would help to mitigate the issue. Card testing is a recent problem where a bad actor gets tens of thousands of stolen card numbers and uses the accept hosted window in CC to test them. Once they get the window open, they can do over 10 submissions per second. All of them are on a single order with the same order number and amount. Technically, they are hammering on Authorize.net's site and not the server hosting the CC store. However, this results in both Authorize.net and the merchant processor shutting down the gateway. I use AFDS on authorize.net but we really need to try to stop the submissions in the first place. To help mitigate this, I have modified the hard-coded parameters sent in the Accept Hosted extension gateway.class.php file to this: { "settingName": "hostedPaymentPaymentOptions", "settingValue": "{\"cardCodeRequired\": true, \"showCreditCard\": true, \"showBankAccount\": '.$showBankAccount.'}" }, { "settingName": "hostedPaymentSecurityOptions", "settingValue": "{\"captcha\": true}" } Requiring the card code and ESPECIALLY showing captcha on the submission form seems to stop them in their tracks. Unfortunately, I have to go in and redo this mod every time there is a new version of this extension since they are hard coded and not part of the variables stored in the config table. I think it would be a really helpful mod to this extension to make these selectable in the extension admin, perhaps with a simple checkbox like with a couple of the other parameters there. Thanks for considering this.
  4. I upgraded my server to Alma Linux quite awhile ago and had absolutely no issue with CubeCart or anything else on any of my client's sites. I doubt you will notice any change at all. It is basically the same as CentOS, except it is being maintained. It reminds me of the switch from mysql to Mariadb back when Oracle took over and decided to be dicks about licensing mysql. No issues at all with Mariadb either.
  5. No, it's just one of the things I saw when I tested 6.4.7 with PHP 8.2. so I just mentioned it in case it hadn't been discovered in your testing.
  6. Thanks Brian. I would guess you already found this issue that was present in CC6.4.7 on PHP 8.2: Customer login technically works but just sits on the login page after submit so the user doesn't think they are logged in. Probably old news to you. So many little things that have been made much more strict on PHP 8.2 it is making me crazy doing testing / rewriting on my own systems. No more loosey-goosey coding and running functions like trim (and others) on foreach loops where there may not be data in some iterations. Lots of other things too. I tell you the #[\AllowDynamicProperties] trick is saving me right now because I can run 8.2 while I rewrite hundreds of class scripts to conform. I realize how lazy my OO coding has been over the years and am paying for it now. Tighter requirements make us tighter coders, I guess...
  7. I guess I wasn't too clear. I develop and host data management systems primarily but also have a few clients who are doing eCommerce using CubeCart on my server. I am finishing up re-coding and testing my systems with php 8.2 and will be switching the last data systems domains to 8.2 shortly. All of my other clients are moved to php 8.2 already. My CubeCart sites will be the only 8.1 users on my server. I would like to move them to 8.2 so I can remove all other php versions. Yes, that is why I posted in the CubeCart forum to see if someone like Brian had any additional info. It would be nice if php version compatibility was part of the documentation of each CC version update. I tested 6.4.7 and know that doesn't work so before I go to the trouble of doing a bunch of testing on 6.4.10, I wanted to post here to see if anyone like Brian knew if it would work or not. Mostly if they already knew it wouldn't work so I wouldn't waste a bunch of time testing something that was already known to not work.
  8. I have been updating my own data systems to be compatible with php 8.2 and also moving my clients sites that aren't using CC (non-eCommerce clients) to 8.2. I have my CC stores at 6.4.7 and tested one with php 8.2 and it had some significant issues that made it a no-go. I will be updating stores to 6.4.10 shortly and wanted to know if this latest version is php 8.2 compatible.
  9. No no. I have notes of what files have been changed in the skin. I will run DiffMerge on each of them and carefully update the code on the new CC version skin. I have very clear remarks on every change. I just need to carefully examine the code between the old and new to make sure I understand any changes in the new that may affect my modifications. It is slow and tedious. And, as I said, I have to think. Hate that.
  10. Thanks Brian. I have a filediff program. I was just wondering if I needed to go through it file by file. Just lazy but since things are pretty significantly re-arranged on my Foundation skin variant, I have to sit and transpose the differences instead of viewing the difference pages and approving the automatic code block updates left to right in the file diff edit window. I hate it when I have to actually do some work. Even worse when that work requires me to think. Thinking is hard.
  11. Just wanted to pop back in and thank Brian and Al (and whomever else worked on the update) for the php 8.1 compatibility. Finally got a rare minute to jump over and do some store upgrades and then switch them to php 8.1. As always, your work is very much appreciated. One question - Do you know if anything changed in the Foundation skin between 6.4.4 and 6.4.7? I have a skin that is based on Foundation but is significantly altered in its element arrangement so I would like to not rebuild it if there is no reason to. Thanks
  12. Thanks so much for finding that Brian. Definitely a silly oversight in the code. Your fix seems to have solved the issue. This is certainly a bug that needs to be fixed. Will you be reporting it or would you prefer I do it? As always, your thorough work and prompt solutions are greatly appreciated.
  13. Yes. The owner and I both have accounts on his store so we can simulate purchase and checkout. It did the same thing for both of us when we were logged in. Out of curiosity, would that make a difference? I thought that CC tracked customers by email address, whether they have an account and are signed in or not. I assume that would be relational to the coupon uses counting.
  14. No. In phpMyAdmin sorting by customer_id shows the lowest number to be 130. No zero values in that column. Not sure I understand this one. There are hundreds of rows with the same coupon code as he has had hundreds of customers use coupons over the years. Do you mean if the first test found a zero? If so, this test is moot, I suppose.
  • Create New...