Jump to content

KirkM

Member
  • Posts

    201
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by KirkM

  1. Another thing I noticed is the skin is still caching. I FTP'd in with Fetch and deleted all the cache files, including the skin folder's files and the store is back caching them again. It isn't caching the general files. Is the skin caching detached from the overall caching feature?
  2. If you searched a product when the nav bar was whacked, it would be fine and the breadcrumb path was correct. In fact, everything worked fine for both SEO urls and the breadcrumbs other than the nav bar. If you used the menu and got the 404 error, I don't think it generated anything. Not completely sure about that, though. I can check it next time but I am hoping there isn't going to be a next time.
  3. I hand code and DW just is convenient for structure, organization and ftp uploading. It isn't anything like what it was that long ago. I have used it for decades and it is now quite good and very handy for app development and coding. I guarantee you the issue isn't with DW. When the nav bar goes sideways, NOTHING up there works. Not even the home page icon. It should simply be the base url of the domain, but this issue even manages to mess that up.
  4. I haven't seen that. I checked all of the links every time it happened and the ONLY rewrite issue was in the menu. Featured products, sale items, etc. always worked for me when the menu went sideways.
  5. Yes. Thanks. I looked right at that and didn't see it. So would the $glob['rootRel'] and $glob['storeURL'] additions fix this? It has been working since I added them so far, but every "fix" works temporarily and then it starts again.
  6. This popped up again. I added the two $glob values and cleared the cache and it came back up. This issue keeps returning. We should be able to alias alternate domain names in 301 redirect without it breaking the SEO rewrite or having to do a bunch of code gymnastics. Who doesn't have alternate domain names to capture alternate spellings or other user mistakes? That should be assumed in the store code architecture. I have dozens of other domains with multiple aliases plus SEO rewrites that aren't shopping carts and have never had any issue. What is really puzzling is that I have had multiple domains aliased to this CC store for YEARS and never had this menu problem. Did something change in the 6.5.x versions? Never got it all the way up through 6.4.7. Also, with all due respect, that caching system is not my favorite. Is there a way to turn it off? I'd rather lose speed than deal with the headaches it causes. Thanks
  7. That did it. Thanks as always Brian. Really appreciate the help.
  8. Updated to 6.5.6 from 6.5.3 and see just a pair of parentheses on the sort menu. Re-uploaded all the files and double-checked that the skin (based on Foundation) was also updated. Tried to attach a screen shot here but the forum server is throwing an error and won't upload it. Unknown error -200.
  9. Thanks Al. I had moved the domain 301 forwarding of two aliases to the registrar level recently from my Plesk server panel and that may have been the issue. I pointed them back to my own name servers and re-created the aliases, re-issued the SSL cert to cover everything and it is back working... for now. Hopefully, that is the problem and this will make a final fix on it. Appreciate the quick response.
  10. A strange issue has started to appear in the menu system of the store. It hadn't been touched for a while (6.5.3), and suddenly the menu system started throwing these long, convoluted urls that of course resulted in 404 errors. ALL of the other links on the page work fine with the proper SEO url rewrites. It is ONLY the menu system. Even the little home page button on the menu bar throws those bizarre urls, when it should just go to the base domain. I upgraded to 5.5.6, but that didn't help. I have tried all kinds of things and each time it has been temporarily "fixed" by a different solution. Once it was dumping and rebuilding the .htaccess file, another time it was turning off mod_security on my server, another it was changing the SEO settings in the store, clear the cache and set them back and clear the cache again. Another time it was manually going in and completely dumping the entire contents of the cache folder. Each of those worked exactly once. Now, nothing seems to work. It can be seen at https://anabolnaturals.com Any ideas would be greatly appreciated. Here is my .htaccess file: ##### START CubeCart .htaccess ##### ### GZIP Compression ### <ifmodule mod_deflate.c> AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript </ifmodule> ### Files Expiration ### <IfModule mod_expires.c> ExpiresActive On ExpiresByType text/html "access 0 seconds" ExpiresDefault "access 7 days" </IfModule> ### File Security ### <FilesMatch "\.(htaccess)$"> Order Allow,Deny Deny from all </FilesMatch> ### Apache directory listing rules ### DirectoryIndex index.php index.htm index.html IndexIgnore * <ifModule mod_headers.c> Header always append X-Frame-Options SAMEORIGIN </ifModule> ### Rewrite rules for SEO functionality ### <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / ##### START v4 SEO URL BACKWARD COMPATIBILITY ##### RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule cat_([0-9]+)(\.[a-z]{3,4})?(.*)$ index.php?_a=category&cat_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule prod_([0-9]+)(\.[a-z]{3,4})?$ index.php?_a=product&product_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule info_([0-9]+)(\.[a-z]{3,4})?$ index.php?_a=document&doc_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule tell_([0-9]+)(\.[a-z]{3,4})?$ index.php?_a=product&product_id=$1&%1 [NC] RewriteCond %{QUERY_STRING} (.*)$ RewriteCond %{REQUEST_FILENAME} !-f RewriteRule _saleItems(\.[a-z]+)?(\?.*)?$ index.php?_a=saleitems&%1 [NC,L] ##### END v4 SEO URL BACKWARD COMPATIBILITY ##### RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} !=/favicon.ico RewriteRule ^(.*)?$ index.php?seo_path=$1 [L,QSA] </IfModule> ### Default store 404 page ### ErrorDocument 404 /index.php ## Override default 404 error document for missing page resources ## <FilesMatch "\.(gif|jpe?g|png|ico|css|js|svg|webp)$"> ErrorDocument 404 "<html></html> </FilesMatch> ##### END CubeCart .htaccess #####
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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...
  17. 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.
  18. 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.
  19. 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
  20. 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.
  21. 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.
  22. 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.
  23. 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')).'\"}" }] } } }';
  24. 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.
×
×
  • Create New...