bsmither

When uploading the new CubeCart package, you will be 'overwriting' all existing files. The existing file /includes/global.inc.php contains info specific to your installation - thus this file cannot exist in a CubeCart downloaded package. It won't have the right info, and you wouldn't want an empty file overwriting the existing file. Existing files not found in the downloaded package will not be overwritten (images, other skins, languages, plugins, etc). Look in the existing global.inc.php file and rename the extracted admin.php and admin folder from the downloaded package to those names. Then, the upload will correctly overwrite the existing admin file and folder with the accurately-named admin file and folder from the package. For most scenarios, you may ignore the file /includes/global.inc.php-dist. This is included for those who want to study what information is required should they wish to fool about with the installation. An upgrade (or same-version reload) uses the existing global.inc.php, and a fresh installation creates a new global.inc.php, renaming any existing global.inc.php to have a dated backup filename.

It's easy but the process requires direct access to the database. In CubeCart_sessions, find the record that has the IP address you want gone. Delete the row(s). Unless someone with that cookie value (session_id) is making page requests, it should disappear eventually anyway - maybe a week?

Some of the weird things involved mobiles in some fashion. (I don't do this, so I cannot say for sure) It may be the case that the browser on the mobile device had logged in, did some stuff, etc, while using the data plan. Then, later, the browser, still having the logged in cookie, but now using Wi-Fi, accessed your site. The IP would be different, but use the same cookie. (Again, just a wild guess.)

Are the Session Start times close together? Could it be that you first tried to access your admin using admin.php or /admin/index.php? Recent versions of CubeCart will cause a 404 response for that. But I have no answer for the different IP addresses. On the other hand, I have seen some weird stuff in error_logs I have examined.

Yes. The checkbox should appear when registering, but otherwise, at checkout. This depends on the skin being used. I am not aware of any skin that does not have the code to show this. In admin, Documents, the list o documents will have a column of radio buttons to indicate which document is to b used as the T&C document. There must be one selected.

Welcome Beagle Bytes! Glad to see you made it to the forums. Do the regulations say there must be a "specific" notice - visible and uniquely selectable at each and every sale? Or do you think that CubeCart's ability to require an unregistered customer to read the "Terms and Conditions" document in order to progress through the checkout process, or to read the "Terms and Conditions" document in order to complete the registration process, would suffice? Currently, the checkbox says "I agree to the Terms and Conditions," which is a link to that document. But if the regulations say that the checkbox must say something specific about waiving a right, we can change the phrase to include "and Waive Certain of My Rights." The Terms and Conditions document would have all that verbiage.

We may need to see your site to discern the cause of the problem. If possible, please let us have your site's web address.

At Authorize.net (account.authorize.net), view the AFDS settings. Here are some code changes that will make CubeCart's response more friendly. Keep in mind, however, Authorize.net, probably because of AFDS, has NOT put this transaction in the batch. The money will NOT transfer from the customer to the merchant unless and until the Merchant has 'approved' this transaction. In /modules/gateway/Authorize/gateway.class.php From: private $_result_message; To: private $_result_message; private $_result_status; From: } elseif($results[0] == 3) { $status = 'Error'; $order->orderStatus(Order::ORDER_PENDING, $cart_order_id); } if($results[0] != 1) { $this->_result_message = $results[3]; } To: } elseif($results[0] == 3) { $status = 'Error'; $order->orderStatus(Order::ORDER_PENDING, $cart_order_id); } elseif($results[0] == 4) { $status = 'To Review'; $order->orderStatus(Order::ORDER_PENDING, $cart_order_id); } if($results[0] != 1) { $this->_result_message = $results[3]; } $this->_result_status = $results[1]; From: // Display payment result message if (!empty($this->_result_message)) { $GLOBALS['gui']->setError($this->_result_message); } To: // Display payment result message if (!empty($this->_result_message)) { switch ($this->_result_status) { case 1: case 4: $GLOBALS['gui']->setInfo($this->_result_message); break; default: $GLOBALS['gui']->setError($this->_result_message); } } I strongly urge that Authorize.net's actual message that is returned with a "Hold for Review" status be changed in the Authorize.net Merchant Account interface (account.authorize.net).

I cannot reproduce it on CC6110, and if, as you say, this was happening with CC618, then I should be able to see something. PM sent.

This situation is quite probably the result of the Merchant having enabled Authorize.net's "Advanced Fraud Detection Suite" (AFDS). Here are some links that discuss it: https://support.authorize.net/authkb/index?page=content&id=A509&pmv=print&impressions=false https://community.developer.authorize.net/t5/Integration-and-Testing/Held-for-Review-Status-to-do/td-p/29840 https://community.developer.authorize.net/t5/Integration-and-Testing/Are-quot-held-for-review-quot-transactions-included-in-the-batch/td-p/48673

We can certainly modify the module's code. But as I said, the Authorize AIM Developer's Guide (Oct 2015) says the '4' is "Held for Review". I surmise there is some reason Authorize.net determined that this transaction needs further review. Someone will need to examine these "4|1|256" orders within the Merchant Account Settings Panel at Authorize.net to discover why Authorize.net flagged them as such.

The Authorize AIM Developer's Guide (Oct 2015) says the '4' is "Held for Review". Maybe in your Authorize.net Account Settings Panel, there are conditions of the transaction not being met that prompts this response. Still, CubeCart should not flag it as an error. On the other hand, maybe so - but the response is up to the merchant. The docs say that the Merchant can change the textual response (defaults to "Your order has been received. Thank you for your business!") in the Merchant Account Settings Panel.

If Authorize.net is returning "4|1|252", then, based on earlier conversation, it seems the module is sending an "Authorize Only" request. Please verify. Also, try switching to Authorize Only, Save, then immediately switch back to "Authorize and Capture", Save.

I tested this on CC6110, and I had the browser show me a "Print Preview". This (supposedly) will show what the actual printed document will look like. (And I have actually modified the template just a bit to not print an extra blank page.) If the order has notes to print, there will be that page containing the overall template (logo, store address) an also the Note - but no other data. All other pages do show the customer address block. Do you recall if this just started happening with CC6111? Please verify with your browser's Print Preview. The Customer Address block is in a floating div, and may get repositioned when the width of the document's outer-most boundaries are narrowed to the width of your printer's printable area.

In this case, no, it isn't anything to be overly concerned about. This error would indicate that the shipping was attempted to be calculated on an empty shopping basket.

Welcome 6502CPU! Glad to see you made it to the forums. Currently, no "common carrier" shipping module uses that carrier's COD product. For example, the United States Postal Service has a COD service product. But CubeCart's USPS module is not coded to calculate the costs and manage the paperwork required. As a tedious work-around, you can print the order's invoice and take it with you when you drop the box off at the post office. Thus, you will have some info at hand to fill out the COD paperwork. The common carrier (e.g., USPS) could have an online API to create a printable COD ticket. Even so, getting that coded into the module would be an effort.

I have this just about figured out. Does WA tax shipping? Not all states do, and some states only tax that amount of shipping charged in excess of the actual costs of shipping (which you will need to figure out after the fact). Some states don't have any argument against charging tax on shipping even if its not required - as long as you submit the taxes collected.

It is best to override CSS rules that may be difficult, if not impossible to find in the CSS that comes with the Foundation. So, in the file cubecart.default.css, add: a {color: #CB5B06;} a:hover, a:focus {color: #AB3B06;} button, .button {background-color: #CB5B06; border-color: #AB3B06;} button:hover, button:focus, .button:hover, .button:focus { background-color: #AB3B06;}

Depends. Later versions of CC6 give the frontside seven days of a session (PHP keeps a record of the cookie). Prior to that, frontside was one day (if I recall), and even earlier, one hour. However, the provider of your hosting platform may have an internal PHP setting of a more aggressive session management.

Wow! I really missed the mark. You ask about taxes and I give you shipping. We will need to develop a "tax by zipcode" capability.

Well, that sucks. Unless Washington State has an online API where, given the zipcode (and that is not at all a definitive special district boundary identifier), returns a list of who gets what pennies on the dollar. It seems the All in One Shipping module has the ability to create shipping zones based on postal codes. When creating a new Shipping Zone, you will be able to specify a collection of zip codes that are to be included in this zone.

Is this your understanding of Washington's tax rules, or is it your CPA's understanding. I know of only two states, and neither require complicated tax calculations. Just get the base rate for the state and the state will be happy with that. I also follow the "Amazon Tax" brouhaha that several states are arguing, and so far, I have only read about Amazon to collect the base state rate - not each and every dog catcher district.

Having followed my instruction to add a specific instance of the BXSlider into the Homepage document, you may have this: In admin, Documents, click the Edit icon for the document identified as the homepage document. On the Content tab, switch to Source mode. Find something similar to: <ul class="bxslider_homepage"> Change this by adding only the style="display:none;" part: <ul class="bxslider_homepage" style="display:none;"> Find something similar to: $(window).load(function(){ $('.bxslider_homepage').bxSlider({auto:true,captions:true}); }); Change this by adding only the .show() part: $(window).load(function(){ $('.bxslider_homepage').show().bxSlider({auto:true,captions:true}); }); We initially tell the browser to suppress showing the list of images. After the window loads, the BXSlider functionality is triggered, which converts the list to a slider. But, since the images for the slider are not shown, the added show() is used to make them visible then instantly converted to a slider.

Customers do not get an email when the order goes to Pending (exception: the POS gateway could send a reminder email). The config setting is for when the Administrators get an email. If the customer does not get an email when the order goes to Processing, that will be the issue to solve. Upgrading to 6.1.1, or 6.1.10?

The emails are in CubeCart's admin, Email Templates. Click the flag of the email translation you want to edit: probably Admin: Order Received. On the next screen, view the HTML Content and Plain Text Content tabs. You should see lines for Subtotal, Discount, Shipping, Taxes, and Order Total.