bsmither

Look in box.basket.php. That template may {include} another file such as box.basket.content.php which has the actual button code and link to <a href="{$STORE_URL}/index.php?_a=checkout".

"When you follow it"? I don't understand that sentence. The URL given is correct, however, the page=6 may not actually be valid. If you have enough items on sale to fill five pages, then whatever is calculating the pagination is at fault for believing there are enough items to fill six pages. So, making a page request for the sixth page of items may return a valid page (header, footer, sideboxes, etc), but the message "No products exist." may be shown.

Ok, but still, the module is not coded to look past the first element being 1, 2, or 3. In the cases of this forum conversation, the result is 4 (without looking at the API docs, I will assume 4 is "Authorized" as opposed to 1 being "Approved"). So, I will say that the module has a setting for Authorize only, but there is no matching code on what to do when Authorize.net responds with that result. Therefore, set the module to Authorize and Capture until the next version comes out.

There is no "transferring over" CubeCart PHP code. An upgrade is "whole cloth". So, you now have a folder named /admin/ and a folder named /admin_hash/. I suggest you determine which folder has this latest update, rename the other one to something completely bogus, then rename the correct folder to the same name that is in the /includes/global.inc.php file. (Yes, I do understand that having implemented a derived name for the admin folder introduced a number of headaches.) Just to make sure, also force your browser to reload the admin page resources (javascript and css - new versions in CC6110 - and images.) This is usually done with CTRL-F5.

Also, please see: https://github.com/cubecart/v6/issues/1741

The Authorize.net module, when using the AIM method (as opposed to the SIM method), uses CubeCart's "Request" set of functions. As such, there should be logged entries in CubeCart's admin Request Log.

The "default" checkbox was added in CC616 (see Github). The quickest way to check is to look at the file /admin/skins/default/templates/products.index.php, near line 368: <td>{$LANG.common.status}</td> <td>{$LANG.catalogue.title_product_options_matrix}</td> <td>{$LANG.common.name}</td> <td>{$LANG.catalogue.title_option_set}</td> <td>{$LANG.common.default}</td> <td>{$LANG.common.negative}</td> <td>{$LANG.common.price}</td> <td>{$LANG.catalogue.absolute_price}</td> <td>{$LANG.common.weight}</td> <td width="20">&nbsp;</td> The fifth line is new. If that line is not present, then one or more files, and possibly a database schema change, did not make it through the upgrade process.

When you say "They seem to push the Buttons," do you mean that the company, PayPal Mexico, is strongly suggesting that the "PayPal Button" is the best way for a Mexican customer to make payment via PayPal? If so, then the PayPal "Plugin" (as opposed to the "Gateway" module) is where one gets the "Button" to use. However, there have been several conversations lately that complain of anomalous behaviors from PayPal using that module. (I have no knowledge of PayPal, and so can offer little to no help in resolving those complaints.)

I think, generally, one should start with a common lowest package size. Then either one of two approaches: * use the options to adjust for size and enter a price differential, or * use the Quantity Discount feature. You would start with the product's initial price "Starting at $5.00" then the first option could be "Full Pound bag - $9.00", the second option could be "Two Pound bag - $15.00". The latest versions of CC6 allow for an absolute price on options instead of price differentials. This seems to be the most versatile with respect to quantity versus size. Also, CubeCart responds to the skin's coding (if present) where an ajax request is sent to obtain a price to be displayed depending on the options chosen. Or, do not do options at all, but rather Quantity Discounts with a disclaimer saying shipments will be in the largest sizes available. So, a quantity of ten (half-pound bags) will have a discounted price of $38.00 and be shipped as two 2# and one 1# bags (and not as 10 small bags).

CanadaPost uses CubeCart's 'Request' set of functions, so the actual request and the response should be logged in CubeCart's admin, Request Log screen.

I have not heard of 'Souse'. Google Translate recognizes it as a Haitian Creole word meaning 'suck' or 'sucking'. Does the store you've inherited sell vacuum cleaners? Not knowing what data would eventually become available from CC6.1.*, I would imagine the compatibility went only to the latest version of the CC6.0 family. I will assert that a CC6.0 skin is fully backward compatible with the CC6.1 family. (As well as will be backward compatible for all of CC6. Even CC5 skins work with the latest version of CC6 - they just do not show the latest data that is made available, and there is an issue with product options.) Anyway, we can make available a summary of the differences between what data is made available to the skin by the latest version of CC6.1 versus what data was made available by the latest version of CC6.0.

Are you able to administrate your (complete) inventory in CubeCart's admin? That is, do all of the items before the upgrade show in the Inventory Table? When I look at your site, and click on a SiteDoc, I get: Warning: mysqli::mysqli(): (42000/1044): Access denied for user 'redacted'@'localhost' to database 'redacted' in /home1/redacted/public_html/encoreautographs.com/classes/db/mysqli.class.php on line 33 Warning: mysqli_options(): Couldn't fetch mysqli in /home1/redacted/public_html/encoreautographs.com/classes/db/mysqli.class.php on line 35 Fatal error: Access denied for user 'redacted'@'localhost' to database 'redacted' in /home1/redacted/public_html/encoreautographs.com/classes/db/mysqli.class.php on line 38 This tells me that the upgrade changed something about how CubeCart communicates with the database server.

Emails sent by way of the Contact Us feature are not logged. The content of the Contact Us email is found in admin, Languages, (edit) Contact group, email_content key. However, depending on the version of CubeCart (fixed not too long ago), any edits to this phrase resulted in the part <%s> to be stripped out, resulting in misplaced values for these placeholders. (The actual content of this key is longer than the text field initially shows. Be sure to scroll the contents of this field to view the entirety of the phrase. A bug report has been made.) The %s placeholders are filled with these data items from the form: Name, email, admin or department, content

Quite possibly a 'bot' just found your "Contact Us" page and filled in the fields it recognized. I get them all time.

The Wayback capture suggests the skin is a somewhat modified CubeCart 4 skin called "Classic". Yet, the screen grab of the admin suggests you are running CubeCart 6. So, if you actually got a CC4 skin re-coded to run under CC6, good on you! (I am trying to re-code CC3's Killer.) Still, if the name of any existing skin folder is something other than "foundation" (and I see that the skin folder here is called "heyday"), it would not be over-written. And I have not seen any code where CubeCart 6 would intentionally delete a skin folder even if it wouldn't run on CC6. As far as the admin screen anomalies are concerned, you say you upgraded from CC6.1.8. Are you sure? The missing editors was a problem when upgrading from CC615 - maybe earlier than that - and was directly caused by a lot of new code in admin.js for the version upgraded to, where the web browser was using its internally cached copy of the older version. Forcing the web browser to reload admin.js and other page resources (CTRL-F5) solved that.

In the CC6110 code I have looked through, no, a newly registering customer will have the language being used set in their customer database record. That is to say, if you have en-GB and es-ES (Spanish) enabled, and the registrant is viewing the site in Spanish when the Submit button is clicked, then the customer's record is inserted into the database with Spanish as their language. (And no obvious way to change it later.) That does not answer the question (needs exploring) of, should the admin then disable es-ES, what will this registered customer see? Spanish, though disabled, it is still installed? It may be worth making the experiment of deleting all languages you do not want your store to have. Thus, what would happen if the Spanish customer logs in, but there is no Spanish language installed? What will that customer see? (I'll put that on my list of things to examine.)

After making a successful payment, the URL should be: /index.php?_a=complete And on this page is the icon to print a receipt. Do you get anything different if the customer view their Order History, chooses a recent order, and clicks the Print Invoice icon? The URL for that (and order complete) would be: /index.php?_a=receipt&cart_order_id=170831-123456-1234 So, since both events use the same template, if you get different results, we will start looking at the differences. If you get the same results, we will start looking at the common code. Have you edited the content.receipt.php template file?

(I do not have a copy of GalaxyX, but) The Smarty code in probably all skins will be nearly the same. So, let's look at Foundation. content.category.php <h2>{$category.cat_name}</h2> {if isset($category.image)} <div class="row"> <div class="small-12 columns"><img src="{$category.image}" alt="{$category.cat_name}" class="marg-bottom"></div> </div> {/if} {if !empty($category.cat_desc)} <div class="row"> <div class="small-12 columns">{$category.cat_desc}</div> </div> {/if} {if isset($SUBCATS) && $SUBCATS} There is the category name, followed by a test for the presence of the category image. If there is an image (regardless of size), then show include the HTML to show it. Otherwise, do not include this HTML to show the image. This is followed by a similar test for the presence of the category's descriptive text. Then followed by a similar test to show the subcats. To absolutely not show the category image regardless whether there is one or not: From: {if isset($category.image)} To: {if false && isset($category.image)} Since a template has been modified, be sure to have CubeCart clear its internal cache.

We would also like to know if: comparing the default language you have set in admin, Store Settings, and which of the languages you have enabled in admin, Languages, if the only enabled language is the same as the default language.

Please check the database table CubeCart_customer. You will need an external utility for this, such as phpMyAdmin. In the column 'language', it may contain a default value. When a customer first registers, or gets registered as a ghost when checking out as a guest, CubeCart uses the language currently in use (not necessarily the config default) to set the 'language' column. (I am not seeing any code on how the customer or admin can later change that.) Then, depending on certain conditions, a complete group of language strings could have been databased in CubeCart_lang_strings. These are loaded last, overwriting strings loaded from language files. (You mention making alterations to the language files. We recommend using CubeCart's admin Language editor.)

This error: [21-Sep-2017 09:46:32 UTC] PHP Fatal error: require_once(): Failed opening required '/home4/material/public_html/staging2/includes/lib/smarty/plugins/modifier.replace.php' (include_path='.:/opt/php56/lib/php') in /home4/material/public_html/cache/skin/0735e5b49cfaaa2c776820e2ae57a6b8fa455d99_0.string.php on line 18 Note how 'staging2' is part of the path being looked at, from code in a path that does not include 'staging2'. A Fatal Error is when PHP crashes. Depending how PHP is configured, PHP will either send the actual error message to the customer's web browser (not a good idea on a production machine), or tell the web server to send a 500ISE to the customer's browser. This suggests to me that you moved this CubeCart installation from the folder 'staging2' to its parent, including all of the files in the /cache/ folder. We recommend that all files in the /cache/ folder (except .htaccess) be deleted prior to the move. Please manually delete the contents (except .htaccess) of /cache/ now. These errors: [21-Sep-2017 10:02:27 UTC] PHP Warning: Invalid Security Token in /home4/material/public_html/classes/sanitize.class.php on line 143 are when more than one CubeCart page is open, one page has had a form submitted, and then a second page submits its form. Once a POSTing has been made, the security token changes, and pages already open will still have the now obsolete token. The browser's Back button will also cause this.

Would an HTTP Header suffice? That is, whatever your off-site caching application (CDN) looks for to determine if the page is to override standard caching mechanisms? The trick of adding a querystring to a URL works well to force the web browser to always fetch a fresh copy of a file (CSS, javascript) when making its GET requests. I have no experience with this method affecting the behavior of any intermediate system.

What needs to to be is for the source to be unambiguous about quotes and apostrophes. Note the value of the content is enclosed in quotes. Thus, any value for that having quotes itself would prematurely close the string. Such as: content="We have the "very best" stuff!" There are two ways to "somewhat" overcome this dilemma: use apostrophes when enclosed in quotes or use quotes when enclosed in apostrophes, and 'escaping' the quote or apostrophe (\"). Each method is used where appropriate. A third way is to change the problem characters to its 'HTML Entity'. In almost all cases, the browser will show the entity as its associated character. I have found that the browser title might away with having a quote or apostrophe as this value is enclosed in <title> tags, not actual quotes. Still, CubeCart converts the admin entered string to use the entity (makes it easy to database the value as well) and the browser will show the associated character in the title. (That wasn't always the case - reference Internet Explorer 6.) So, the question then becomes, will whatever that is out on the Internet that slurps your site's meta data know what to do with the entity? We must expect that it does. I think what got fixed may have been putting the actual characters in the content value and thus causing truncated results with what got truncated to be visible.

There is this: https://www.cubecart.com/extensions/plugins/registration-email-manager

To me, the ACP is the admin control panel. There is no method by which to suppress inventory that have a sale price from being administered. How would you then ever be able to edit it's description, for example? On the storefront, however, by administratively switching off "sale mode", that will cancel any and all discounts. Also, in admin, Store Settings, Features tab, "Number of sale items to display", setting this to zero will suppress the Sale Items sidebox. This will not, however, remove the "Sale Items" navigation link in the menu. To remove the nav link, an edit to the skin will be required.