bsmither

The UPS module (Contract? Other than the standard module?) uses CubeCart's "Request" functions. Therefore, there will be the Request and their Response in admin, Request Log. CubeCart does not ship with any TLS component. It relies on PHP to supply it, and/or the hosting server to make comms with TLS. In CubeCart admin, PHP Info, the top-most chart will have a row for "Registered Stream Socket Transports". See if 'tls' is listed here. Then, in the CURL table, see if TLS is mentioned in any way. Then, in the OPENSSL table, see if PHP has access to version 1.0.2m.

Nothing useful in here. 'Undefined index' notices will not cause PHP to crash (that is, if PHP is crashing - which has not been proven yet). More thoughts later.

Try this. In your foundation skin folder, css folder, cubecart.default.css file, add this rule: .top-bar-section .dropdown li a { line-height: 1.8125rem !important; } Normally this 2.8125rem (about 45 pixels), but we are overriding with not so much space between lines of text. This will affect all responsive layout widths - not just the large width layout. Because we changed a page's resource, you may need to force your browser to reload these files. This is usually done with CTRL-F5.

Unfortunately (but I haven't verified this against any very recent versions of CubeCart), the Query box only issues queries. There is no provision to display the results.

That may be from an instance of CubeCart delivering the Homepage (has Latest Products). In upgrading the database (which is what setup does), the upgrade step for 6.1.0 adds the 'latest' column (the 'key') in CubeCart_inventory. So, the CubeCart code uses 'latest' in a query, but the database is not ready to use that query as specified - which is why setup is being run. So, see if there is an error_log file in the /setup/ folder.

Let's see if the error_log can show us anything.

Nothing happens? There is no page refresh? Or there is a page refresh but the information shown is the same?

I have found in my personal experience that sometimes a browser will not 'auto-refresh'. Meaning that one would need to keep pressing the "Continue" button - giving about 5 seconds between each click for each step to finish. It has to do with the security settings I have implemented for my browser's behavior. Let us know if clicking Continue five seconds after getting each page still fails for you.

Sorry, my bad. "Force Order Completed Emails", when unchecked allows for CubeCart to skip that email when an order has only digital items. Allow Processing to be skipped should be checked if so desired and the order has only digital items. So, an order with any sort of tangible item will have all emails sent. In the Braintree module, we can customize it to suppress sending the "Received Payment" email.

We can try to suppress one email, at least: in admin, Store Settings, Features tab, near the bottom, find "Force Order Completed Emails" and set to an unchecked box. You can also try "Allow order 'Processing' to be skipped?" set to an unchecked box.

Please tell us what you see when you run www.yoursite.com/setup/index.php.

I think that's how the code is written (being intentional or otherwise). I see it as once the customer has taken the item "off the shelf", the internal "shopping basket" holds on to that price. The customer will always get the cheaper price of: normal retail price, quantity purchase price, group membership price, sale price, any plugin price, then with any options that affect the price. On the other hand, there is a lot of re-checking of the above prices that happen during every page load. I haven't tested what happens if the customer changes the quantity from one to ten (getting a quantity price), the base price changes, the customer then reduces the quantity to one (going back to the base price), the question is will the customer get the original base price or the new base price.

Welcome dw1973! Glad to see you made it to the forums. I think CC3 has a "Free Delivery" module. (I'll check later.) If that can be renamed, and it's "trigger value" be set to 1.00 (a really low amount), then maybe CC3 will offer this as a shipping choice - keeping all other shipping choices. I will experiment with that later today.

This is normal behavior. In the distant past, selecting Enable SSL would force SSL. In some instances, this caused some problems (not necessarily because of CubeCart). From admin, log out. On the admin login screen, be sure to first click the padlock (above the Username field) so that it is locked. Then login. (According to CubeCart's demo installation, once logged in under SSL, manually changing the link to non-SSL will get you a second login page - apparently a second session. Weird.)

I am also finding that once there is a 'finalized' PDF document, there is no (free?) way to make any changes to it.

We must assume that the PDF has a very standard layout. Your only task is to identify exactly where the change to the PDF is to take place (page number, x-offset, y-offset, x-width, y-height). There are a couple of PDF libraries for PHP that should be able to do this. CubeCart's structure would allow for easy implementation.

Never out of options. There are always options.

I think using $GLOBALS['tax']->priceConvertFX() isn't going to work, because at some point in the checkout process, the Tax class gets reloaded with the default currency, and has no provision for re-re-loading with the customer's currency after that.

Assuming you have the ability to make test payments with your PayPal account in a "sandbox" mode, let's try a few things. In the PayPal (standard) module folder, the file gateway.class.php: Near line 71, find: 'amount' => $this->_basket['total'], We need to exchange CubeCart's internally managed prices at the default currency rate with the customer's chosen currency rate. To do this, change the line to: 'amount' => $GLOBALS['tax']->priceConvertFX($this->_basket['total']), We also need to send the currency code that corresponds to the exchanged rate. In the same file: Near line 77, find: 'currency_code' => $default_currency, Change to: 'currency_code' => $current_currency_code, There isn't a function in the Tax class to get the currently used currency code. But if a customer changes the displayed currency, that currency code is stored in "Session" so that it will be used from page to page. Near line 66, find: $default_currency = $GLOBALS['config']->get('config', 'default_currency'); But what if the customer has NOT chosen a different currency. The currency code is not in "Session" as there is no need to remember the default currency. We need to make sure if we have the one, then use it, or use the other. On a blank line just after the above statement, add: $current_currency_code = ($GLOBALS['session']->has('currency', 'client')) ? $GLOBALS['session']->get('currency', 'client') : $GLOBALS['config']->get('config', 'default_currency'); Finally, for the currency that was used, we need to implement a way to log that in the transaction log. (Solution later.) As well as getting the exchanged currency in emails sent to the customer (and optionally admin emails). Keep in mind that reconciling external reports that show actual currencies transacted will not match what CubeCart reports, as the true prices, taxes, shipping charges, etc are always databased in CubeCart's default currency rate. Make copious experiments.

And as I said, you may also find the emails sent to the customer is expressed in Euros, even if the customer was viewing the store prices in Australian Dollars.

Ok, so what you are using is the PayPal standard gateway (as opposed to the PayPal Pro gateway)? If so, maybe making small but key edits to the gateway code would suffice. We also need to keep in mind CubeCart handles all pricings internally in its default currency. We can make changes to the gateway code to send off the "exchange-rate" value and the currency for it, but when CubeCart sends out emails and when the admin views the order summary, all prices will be in the default currency. I am certain that when the customer logs back in to review past orders, the prices will be in the store's default currency (until the customer re-selects the desired currency). I will need to make some experiments.

The characters that are part of admin.php is a new strategy implemented in the last few versions of CubeCart. The strategy is designed to apply "security by obscurity". That is, by making the admin folder and the admin script have un-guessable names, there will be far less likely chance of unauthorized access to CubeCart's admin pages. So, in CubeCart's main folder, make sure there is only one admin folder (/admin_hAsHeS/) and only one admin script (admin_mIxEdS). Then, in /includes/global.inc.php, make sure those very same names are the values for the related variables. The above situation should explain why you are getting a 404 page. But then, if the .htaccess file is being processed correctly, there is a directive there that says to send CubeCart's index.php page with the announcement that is a 404 message, and not the web server's plain message.

"It will put the payment through..." Are you saying that during the steps of going through checkout, the prices are still being displayed in the currency the customer chose? That is, the customer is not aware of the actual currency (and actual amount in that currency) with which to have the transaction conducted until they enter their credit card number? Or are you saying that the checkout screens - from the first - switch back to showing the store's actual working currency? There would need to be a determination what currency(s) your payment processor accepts. If several currencies, the module would need to be coded to send the desired currency and correct converted amount. Then someone would need to be informed who pays for the international exchange fee.

The code suggests that searching on the zip code happens first. All the zones are examined. For each zone, if it has anything entered in the zipcode box, the code ranges are parsed and compared to the first five digits of the delivery zip code of the order. If the delivery zip code does not fall within a range, then another comparison is made with the assumption the zone's zip codes are expressions (for example, 900* is for all of Los Angeles). If the zone has no postcodes specified for it, then the code tries matching any states that were chosen for this zone. (You can have postcodes or states or neither, not both.) If your test delivery address is not getting a match in a range or an expression of zip codes, we will need to verify that the range or expression is stated correctly.

I would imagine that if you have calculated postage, and have included it in the price of the item, then to make sure it does not affect weight-based shipping, set its weight to zero. If you have shipping based on anything else, we will need to explore some work-arounds.