bsmither

Please verify: in admin, Documents, in the list of documents, make sure one of the documents has the Privacy radio button checked. If there is, then a replacement should happen - where %PRIVACY_URL% becomes an actual URL. <a href="%PRIVACY_URL%">privacy policy</a> If not, then the <a> and </a> tags are supposed to be deleted, leaving only the friendly text. Comparing what I see at csrocketry: Chris Rocket Supplies, LLC uses cookies. For more detailed information about these cookies please see our <a href="%PRIVACY_URL%">privacy policy.</a> Please accept to continue or block all non-essential cookies. Standard language phrase: %s uses cookies. For more detailed information about these cookies please see our <a href="%PRIVACY_URL%">privacy policy</a>. Please accept to continue or block all non-essential cookies. Note that there is a period as part of the friendly text for the phrase being used, where the stock phrase has the period after the closing </a> tag. I have no idea if the preg_replace() function (to strip the link tags) will malfunction with that period as part of the friendly text.

That looks like the "Accept Cookie Dialogue". But there is core code that is supposed to change %PRIVACY_URL% to the actual link (the Gui->_displayCookieDialogue() function). I see you are using Foundation, and the cookie dialog seems to be displaying correctly.

As of the moment I tested the site, the SSL certificate is not configured correctly. It is valid against: c6s.361.mywebsitetransfer.com The IP addtress loteriagringa resolves to is: 132.148.237.25 If this is not the correct IP address of the server you moved to (which may or may not matter at all), it could be the case that the world needs to wait until the "Internet Phone Book" update propagates across the world. Visiting just the FQDN (no subfolder, no index.html or index.php), I get: Future home of something quite cool. If you're the site owner, log in to launch this site If you are a visitor, check back soon.

When you say "it wasn't exactly what I was looking for," is it because the referenced conversation results in "it automatically reverts back to inches"? In admin, Store Settings, General tab, to change the choices for the length dimension unit, edit the admin source file "settings.index.inc.php": Near line 434, find: $select_options = array( About 25 lines later, find: 'product_size_unit' => array('cm' => 'Centimeters (cm)', 'in' => 'Inches (in)'), Change to: 'product_size_unit' => array('cm' => 'Centimeters (cm)', 'mm' => 'Millimeters (mm)', 'in' => 'Inches (in)'), The conversation referenced above affects the details specified on a per product basis.

If you are using a custom skin, or maybe one originally developed for CC5, several links are hard-coded to have .html suffixes. Please see this conversation: https://forums.cubecart.com/topic/57069-minimaliser-skin/

Please remind us of that other conversation. As best I know, this dimension (as well as weight) is used in shipping calculations where the size of the container affects the charges. However, I cannot locate any significant places in the code where this store setting is used. When adding/editing a product, the dimension unit can be specified for that product.

Using an external database utility, such as phpMyAdmin (a tool provided to you in your hosted account's control panel), view the table CubeCart_system_error_log. Hopefully, the error will have been logged there.

Again, those changes were implemented in CC650. So, the question remains, did your installation get completely upgraded to the the latest version?

The Catalogue class method `function getDefaultOptions()` was implemented in CC650. Please make sure the edits that appear here: https://github.com/cubecart/v6/commit/c25c5471b7b69688e6ce19dfb5e8ab5b60ea2145 have been implemented in your installation.

Please read the description for this: https://www.cubecart.com/extensions/shipping-methods/link-cubecart-products-to-specific-shipping-services-/-modules

According to the description of the third-party plugin mentioned earlier, each product can have its own shipping method.

Sorry, 'element.recaptcha.php' is new to CubeCart v6.5.2 (not yet released). So, I am thinking that, even though the script tag in the template has async defer, which allows the script to run without waiting for the HTML to finish, the script that gets fetched then constructs a new piece of the web page and loads another script - what seems to be that /recaptcha__en.js filename. The keywords async and defer do not need both to be used. Some say that async will be used, but if the browser is old enough to not support it, then the fallback is to use defer. In those files I mentioned, you can try to have only defer. (You may need to have CubeCart clear its internal cache if you make changes to the templates.) See: https://pagespeedchecklist.com/async-and-defer

Please examine the templates 'content.recaptcha.head.php', content.recaptcha.php', and element.recaptcha.php'. These templates call the recaptcha script, and the <script src=""> tag should have async defer in it. That should cause the browser to continue loading the HTML and rendering it without waiting for the script to finish loading. (Nor does the script wait for the HTML to finish loading.)

We can discuss regarding what you are asking for, but please know there are a number of blocks and other problems with submitting the data from a Subscribe form that is not under CubeCart control. Every CubeCart skin should have the box.newsletter.php template. You can start with that, but please know that the image you posted above is heavily formatted and styled using the Foundation platform - all defaults.

As an experiment, create a new category named FooBarCo. The category FooBarCo will have Status checked and Visible unchecked. On the Shipping tab, enter a Per Item shipping charge. Save. Choose a product and show its Edit screen. On the Categories tab, set as Primary FooBarCo and set as Additional the product's original category (so that it still shows up when viewing that category). Save. Have CubeCart clear its internal cache. On the storefront, place that product in the shopping cart and then View Basket or Checkout. You should see the shipping charge (By Category) in the Select your shipping method: drop-down.

The USPS module should log a Request/Response in admin, Request Log. The response from USPS should list all available shipping methods for the given postal codes and weight (and carton dimensions if entered in the settings panel). So, from that list of available methods, the USPS module will filter out methods that are not checked in the module's settings. What's left will be shown to the customer.

So, for any given item, there will be a manufacturer assigned to it. And for any specific manufacturer, each and every item associated with it will have the same shipping charge per item. There won't be a case where Item A needs to be shipped at 10.00 while Item B needs to be shipped at 15.00? Therefore, if a product manufacturer can be considered as a product category, then we can create hidden categories and use Shipping Per Category to tally a total cost. Per Category will calculate X 'per item' for each category, then sum those, then add the highest cost 'per shipment' from the various categories, for a total. (If the 'per shipment' needs to be distinct for each category, as would be the case for drop-shipments, that can be figured out.) See: https://www.cubecart.com/extensions/shipping-methods/per-category There is also: https://www.cubecart.com/extensions/shipping-methods/multi-level-shipping-by-quantity-product-category-level

Short answer: no. Better answer: Everyone involved could claim any piece of email as spam based on objective and/or subjective characteristics. The notice above is somewhat strange, as the email address hidden within the link looks like a legit address, but the friendly text that is the link does not look like an email address. (But that could be an artifact of pasting the message into the message editor as is - and not pasting the notice into the message editor's code editor (<>).) Your hosting provider should have (automatically) configured your hosted account's email MX record with all that is necessary to properly identify you as having permission to send email from or through the hosting server. But even if that has been configured (DKIM?), the recipient and recipient's email provider can still create rules that scores emails in ways you will never know about.

Interesting idea. An emailed Newsletter to (opted-in) subscribers might work. [And a mobile is never 'offline' (YMMV).]

The next version of CubeCart will have a drop-down selector on the Dashboard (and most everywhere else) offering to choose 25, 50, 100, 200, or 500 list items per page. That setting for that list will be saved in a 30-day cookie. It used to be that CubeCart was very annoying about having more than one browser tab open to admin. Not any more. So, my habit is to right-click on the Edit icon and select Open in New Tab. I work on the item's details, Save, then close that tab.

Regarding the calculated shipping cost being shown - but not included into the total - when viewing an order summary (and customer invoice?): Noted.

Please use an external database utility (such as phpMyAdmin - a tool found in many hosted accounts control panels) and examine the table CubeCart_system_error_log. If there is a reason for a failure to login, it might be there.

I don't see a "Flat Rate" amount that contributes to the cost for that range. So that wouldn't be the problem. On the General tab, is there an amount entered in the Packaging Weight field?

I see. I just now added an issue in the Github referencing the missing capability to assign a language to a customer that the admin creates. The database structure for the Cubecart_customer table states that the 'language' column has a default value, which, for your store, might be 'en-GB' (or just 'en', which was supposed to get corrected to 'en-GB' in CC511). Thus, customers you create will use the UK language - and so far, no convenient way to change it.

Could it be that the 'customer' that this email was sent to (if not actually you being a test customer) chose to view the store in the UK language? Do you have that feature enabled on your storefront (allowing a customer to choose their language)?