Jump to content

Geotex

Member
  • Posts

    36
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    The Woodlands, TX USA

Recent Profile Visitors

3,052 profile views

Geotex's Achievements

Newbie

Newbie (1/14)

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

Recent Badges

0

Reputation

  1. Sorry, the store was off line. Back on and WORKING thanks to your advice. You sent me in the right direction. I went to my demo store that was installed with a late edition. Did a file compare, added the code, Only had to remove RewriteBase directive as this cart is in web root. Thank you once again for the very valuable help you have provided me when I desperately needed an extra set of really smart eyes. Can you pm me an email address to deliver a big cup of coffee? Thanks again, George Snell
  2. Site had a phony .htaccess somehow inserted to redirect. I removed that, restored the original .htaccess, site came up but any front end generates 404 not found. admin pages working properly, cleared cache, did backups and manually upgraded from 6.42 -> 6.43 -> 6.44. Did not resolve issue. Before updates, checked all files that showed any changes for Aug 6, found nothing out of ordinary. We know the htaccess hack occurred around 4:30 PM CST, from email stamps. All email ceased until I cleared cash this morning, Aug 7 around 11 aM CST. Current status, admin reporting no issues, tested updates and changes in control panel work fine. All front end links seem show properly in address bar, but generate 404 not found (some other installations I have just show domain/cart/item.html == tried that here, but didn't work, same error) example menu link https://littledutchgirl.com/dutch-specialty-foods.html example featured product link https://littledutchgirl.com/dutch-specialty-foods/indonesian-conimex/conimex-sambal-badjak-6-oz-jar.html I searched and found another recent 404 error report seemed a different type of issue, followed the comments. did not resolve my issue. Any ideas or thoughts much appreciated
  3. Did changes and tested results. All works exactly as expected. Last question, what are the chances that classes/gui.class.php is updated or overwritten when an update is supplied? Thank you for seeing the issue and an excellent fix so quickly! George Snell
  4. Wow. Thank you. I will do the changes and get back. I had just blocked the call in skins/foundation/templates/box.sale_items.php to stop the display.
  5. I did not recall seeing any errors in this or any other log. Double checked again, shows --None-- here is a link to one of the pages in the cart https://littledutchgirl.com/dutch-specialty-foods/soup-mixes Any category with items listed, or subcategories with stock, will show the same. Categorie with only sub-directories do not show this error. I am looking now to find the call in templates to just not display the Specials block until we get the issue resolved. bsmither, Thank you for all your help. my efforts of late have been CMS oriented, using Concrete5 and of course WP, building primarily customer-maintained sites. Cube Cart is so basically stable, having several ecom sites using it for some time, this is only the 2nd major issue I have had to request help with.
  6. upgraded from 6.29. With this particular cart, the upgrade was difficult. Had to do a manual install of the files, first time I ran setup the update failed. Ran again, and update, though slow, did show successful update. (didn't mention before, but running on centos7, cpanel and PHP 7.3.x)
  7. This is a new development. Updated to version 6.42. All categories with products now show right side panels for featured produce, best sellers, and ALL items in the category as On Sale with 0.00 price. When clicking on the sale item, it does go in cart at regular price as there are NO items on sale. On Sale Anise Packages 12 per box $5.25 $0.00 Karvan Cassis Syrup 750ml/26.5 fl.oz $9.99 $0.00 Karvan Forest Fruit Syrup 750 ml/26.5 fl.oz $9.99 $0.00
  8. and, on the other hand, it is just my opinion that the overall system should never be "held hostage" to any plugin provided and submitted by outside sources. We need to be certain that whatever information submitted for gateway processing be at least validated as to correct format and completeness prior to submission. But, again, that is just me...
  9. re: what causes the form to be re displayed? Any error returned from the cc processor. re: SIM then, does not count as it goes directly to authorize.net for entering and checking the credit card information. What we are dealing with here is forms that are in the cart environment prior to submission. Where ever they are generated from, and it appears they are part of each gateway module, looking at the authorize.net module and the generic credit card module I use for testing, I will look at a couple of other gateway payment methods, but I suspect I will find the same. And yes, the form is populated with order. price and basic customer info. However, everything except the total and order number is fully editable, and with virtually no skill, the price can also be fixed before submission, all with no verification whatsoever of any input before submitting the information to the payment processor. We need at least validation of proper formation of credit card numbers, and at least verification that name, address parts of the form that need data are populated. This will go a very long way to increasing user satisfaction with the purchasing process, which is historically difficult when compared to swiping your phone near a payment device when checking out in a retail environment. The submit block should also be deactivated until a return from the gateway since it appears the order total is reset to zero at least until the auth codes are returned and the page is refreshed. This is in addition to the work you started to alter the response displayed to a customer, which from feedback I got from one user is still an issue. Not having the full fraud detection suite active at authorize.net seems to have cleared up a lot of issues, but that is something we cannot depend on. Our merchants need all the protection that can get.
  10. Running transactions on my test cart, which is a basic install, upgraded to latest version 6.1.12, shows there is no basic field verification of any data prior to submission from the form displayed at "index.php?_a=gateway." I feel really bad that I assumed this was taken care of only because nothing should ever be released for production without at least basic form validation. Depending on the plug-in module to do this verification is not an acceptable alternative. Basic PayPal is okay because you get an immediate redirect to PayPal with a transfer of only order number and amount, never taking you to the input screen at "index.php?_a=gateway" for any other payment module.
  11. I have run into 2 additional issues with the use of authorize.net, and I know it is because either the cart or the authorize.net module is not verifying the data prior to sending. Another issue is that if a response is delayed for whatever reason, more than one submit is permitted prior to getting a response. I found the following 2 errors (both repeated, but only shown once here for example) "3|1|5|A valid amount is required.||P|0||Payment for order #|0.00|CC|auth_capture||" (same time stamp, right after an approval, signifying multiple clicks to submit) " 3|2|33|Credit card number is required.||" (just hit submit without checking or filling out any info on payment screen) Both of these errors are allowed because there is no verification of input prior to submitting the order for payment to authorize.net (and probably any other payment, although not tested yet, that will follow today on my test cart). In other words, when you get to the screen to verity your cc, address, etc. you can just click on the green submit payment button, and off it goes.
  12. Thanks. I made a copy of the code. I have not heard back from my client. However, we both know the cause of the problem. I am working to get that resolved, but will go ahead and try the code out to see if that can resolve the repeated processing attempts.
  13. Interesting follow up. My client has talked to both authorize.net and her processor technical departments, and they both claim no responsibility, pushing the entire issue back on the "programmer" and yet we both know the issue is in the set up either in the authorize.net or the processor control panel. I know for certain this issue is in one of those control panels as I have 2 other accounts using cube cart and authorize.net with absolutely no issues. However, IMO, we still need C C programmers to deal with the response of 4|1|256 in a more acceptable face to the customer using the cart to place an order.
  14. I don't know right now just what the issue is, but best guess is you are correct about the fraud detect. However, having my own card hang is not an issue with my account. It may be due to actions my client has taken, or problems the client caused the processing company. My client talked to Authorize.net for some unknown reason and relayed that the issue was not theirs, but mine. So we are back at having the client talk to the horse's mouth. I will try to convey your comments to my client, but I suspect that will cause another 1/2 dozen or so emails telling me why I need to fix it. Thanks for all the time spent on this. I will update you with the outcome as soon as I can verify the changes.
  15. The account is definitely set for authorize and capture, and, as far as I know, was working properly set that way until this upgrade. Just to be certain, I did set to authorize and back to authorize and capture, but did not process another test order. The customer probably has the account set to approve but not bill until she goes in and marks as shipped. I have explained carefully and sent log copies and asked they contact there credit card processor, so we will see.. However, CC should be able to handle the notice without throwing up a red flag, causing the user to attempt to reprocess the card, thereby placing several orders. Being able to change the color to yellow, with a notice that the card was authorized but will not be billed until the order is shipped would be nice.
×
×
  • Create New...