bsmither

Having made the change to the request.class.php file, that should have made the request use https. I wonder if the UPS_Contract module does not use the Request class. We can force the Request class to log, even if the calling function sets it to not log. Near line 156, find: if (!$this->_log) return false; Change to: //if (!$this->_log) return false;

We can also implement a work-around regarding the URLs. In the Request Class, we can add a statement that tests for the existing (but obsolete) UPS URL and switch it to use the new URL. But we will need to determine what that existing URL is by looking at the Request Log (if the module uses CubeCart's Request functions).

Then that message should be in the Request Log (see previous reply).

No doubt they will. We can try to force the Request class to use SSL/TLS. In /classes/request.class.php: Near line 237, in the function send(), find: if($this->_request_hash === null) { $this->setData(); } On the blank line after that, add: $this->setSSL(); Save. I do not know if, by setting SSL, which just changes the port (443) and protocol (https), that TLS will somehow enter into the handshake with the remote server. Test. Watch for inadvertent problems caused by forcing all CURL comms (via using the Request class) to secure when not actually planned for it.

I added more info to my response above. Please refresh this page. Are you referring to: https://www.cubecart.com/extensions/shipping-methods/ups-advanced-shipping-module The gateway class file for this module is probably encoded, so there would be no easy way to check if it is setting/overriding the comms method for CURL to use.

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.