bsmither

Welcome z80CPU! Glad to see you made it to the forums. The "remember this login" is a feature/function of Firefox, and it is really annoying. Find the Options panels for Firefox and view the Security panel. There should be a checkbox that will enable storing passwords for sites. Uncheck that. Some have reported that there is some kind of "invisible captcha" that is causing problems. In admin, Store Settings, Features tab, if the "Bot Prevention" is currently at "Invisible reCaptcha", choose something else.

The captcha code can be copied to serve the purposes of the splash screen. You might want to give this plug-in a look: https://www.cubecart.com/extensions/plugins/age-verification-splash-screen

By "never again", just how "never" is "never"? CubeCart has a "Welcome Tour" for new admins. A flag is set when the tour is taken or when a checkbox is checked in the admin's Profile Details screen. This thing is not based on a session. I have a plugin that will have customers newly registering to be 'disabled'. They cannot actually login until an admin "approves" them, then they can log in. This plugin can be modified to throw up a custom splash page, and once read, the customer's status can change to 'enabled'. Once enabled, no more splash page. But a session-based test is exactly similar to the Captcha situation. Once a customer has solved a captcha, the "session" remembers and no more captcha regardless how many product reviews, Contact Us, orders, etc forms are submitted. Until the customer logs out and the session is destroyed.

It might. If the browser determines the SSL certificate does not match the domain, or if the "path" of the cookie does not match the path of the website (such as path=cube), then the browser will not allow a form to submit. But I see nothing wrong with the cookie.

That means the core code is not doing its job correctly. To review about the debug, for each item in $PRODUCTS, there is: product_options, options_array, options and optionally options_text. Of these four array elements, there may be references to choices from multiple choice options, but no references to text options. I think the next step will be easier if we take this to email. I will send you my diagnostic plugin and give instruction on how to use it. This will let us examine the values of variables the core code is working with. PM sent.

Good. Getting this narrowed down. To review: after upgrading to CC6112, in admin, for all orders(?), inventory that have text field option responses do not show? Or is it only orders placed after the upgrade do not show text option responses. That is to ask, an order placed three months ago does or does not show text option responses in admin? Using a programmer's text editor, open the admin skin template orders.index.php. At the end of the file, add {debug}. Save the file. In admin, view an order. Your browser will want to display a popup window. Let it do so. This is the template rendering engine's Debug Console. It lists all the variables and values. Scroll to near the bottom and find $PRODUCTS. This array will have several indications about the options for each of the order's inventory. Verify that the text option responses are listed. If they are, we will focus on the skin template. If not, we will focus on the core code that is supposed to find and provide this info to the skin.

Please observe whether or not you have the following situation: In CubeCart's main folder, you should have one file named admin_aBcDeF.php (where aBcDeF is some random sequence of letters). There should no other file that starts with 'admin'. Likewise, you should have one folder named /admin_fEdCbA/ (where fEdCbA is some random sequence of letters). There should no other folder that starts with or is simply 'admin'. There has been a consistent issue with upgrading that results in multiple admin files and folders.

No, if the text field entries (for orders after upgrading to CC6112) are databased, then we need to figure out why the admin side isn't displaying them.

If the text entries do not show up in the few places they get stored, then we can look at the Vector skin. However, if they do get collected from the form submission frontside and get databased, but aren't shown in the admin's screens, then we will focus on the admin code and skin. So, using an external database utility such as phpMyAdmin, directly access the database. Looking in CubeCart_saved_cart, scan through the basket column looking for inventory that has a text entry field value. You won't find the name of the text entry field, only the contents if any have been entered. This database table is used to hold shopping baskets until the customer checks out. Looking in CubeCart_order_inventory, find a target cart_order_id. Examine the product_options and options_array columns. This database table holds the inventory summary of orders in the process of checking out and afterward. If the text entry filed responses can be found for current orders, then the Vector skin is submitting the data and the CubeCart frontside code is getting it databased.

The PHP options (perhaps you are viewing the PHP Info page in CubeCart's admin) can be misleading if your site is using SUPHP. On this page, there may be a separate table detailing the SUPHP settings that override PHP's core settings. How one gets to view any SUPHP error messages, I do not know. Please review all files in the /images/source/ directory. All files must be image-type files, and all files must not consume huge amounts of memory when opened for editing/resizing. Generally, that means the stored filesize be under 80K.

I've done all that I can think of doing - not having this skin myself. Hopefully the skin programmer will get in touch, or you find a backup and compare what you did earlier.

If a field is in a comment, then absolutely nothing is going to find/see it.

Well, the form checks out as valid - that is, when it has all fields filled in with valid data. So that just leaves why the button won't submit.

There are two aspects: javascript-powered 'required' validation, and CubeCart 'data-present' validation. Since the page is not submitting, the problem is with the rules found in the file 3.cubecart.validate.js. What I am not sure, but makes sense - sort of - is that if there is a rule that a field is required, but the field does not exist, then is the rule still enforced? For example, line 163: username: { required: true, email: true }, This field is hidden if the "Already Registered? Login" is not activated. So, if something is hidden, or not even present, the rule for it has to be ignored - that just makes sense (I hope). So, I'm reviewing the rules and matching them up with fields that may not be showing, but are not hidden either. I also see this near the HTML for the Checkout button: <input type="hidden" name="proceed" value="1"><input type="hidden" name="proceed" value="1"><input type="hidden" name="proceed" value="1"></form> I do not know if three of these inputs will confuse anything. That is added via javascript when the button is clicked. So it can't confuse anything.

Do you have CubeCart requiring a response to a Captcha? Do you have CubeCart requiring the customer to check a box for "Agree to Terms & Conditions" checkbox? Neither the captcha nor the T&C checkbox is shown. Which will block the checkout sequence if required.

View Basket: Using that particular product, I cannot make any changes (e.g., quantity), so updating the basket is pointless. But clicking that button does post the form and I get a new page returned. Checkout (_a=confirm): I get the form to fill in my name and address. Is this where the problem manifests itself? Do you have CubeCart requiring a response to a Captcha? Do have CubeCart requiring the customer to check a box for "Agree to a Terms & Conditions" checkbox? Neither the captcha nor the T&C checkbox is shown. Which will block the checkout sequence if required.

Yes. The Clone icon on any product will create a new product having the same aspects (but having a different database record product_id). You can specify what aspects of the original get cloned at admin, Store Settings, Extra tab.

Please remind us where we may able to view your situation.

I have no idea what the actual cause is, but (even though you attempted to obscure the links above) when I visit your main site, I get a Kurouto skin, followed by a standard Authentication Required lockout. Visiting the /cube/ sub-folder, I get nothing but the lockout. It seems the Homepage document has two images that are forced to be loaded from the /cube/ subdirectory. As an experiment, temporarily remove the basic authorization needed to access the /cube/ sub-folder.

In this case, a cat_id is not necessary. A 500-ISE suggests that PHP is crashing. The Warning you posted would not cause a 500-ISE. Allow me to suggest a closer look at the error_log. Or, make sure that the error_log is in fact getting new entries appended onto it. There is a remote chance that the crash is happening before PHP gets involved. If so, see if there is a web server error log. See if there may be something unusual in the .htaccess file. It is strange that you say both are 'group=2'. One of them should be 'group=1'. Even so, this strangeness won't cause a 500-ISE.

Yeah, the "Please try..." ended up being nothing more than adding a bit of sanity to the code structure. It's the "But the real problem is..." that dismissed the validity of the "Please try...". Since you will be editing a template, be sure to have CubeCart clear its cache (admin, Maintenance, Rebuild tab, Clear Cache).

I am an SEO atheist, but I would think Google cares not for SSL badges showing more than once. It certainly depends on what the javascript does, but, yes, I would say, unless the javascript tries to detect if it is already loaded, then it will be executed twice. Of the two solutions, which did you choose, if either?

I am not liking how the <script> is inside the <span> that is supposed to contain the badge. Please try: <span id="siteseal"></span> <script async type="text/javascript" src="https://seal.godaddy.com/getSeal?sealID=0lwpmB7U1ELUSpdGka8lmjf9eCvphf9xt56esxBvE7YRhLdmA"></script> But the real problem is that the skin template has two <div> blocks where the Copyright content is placed: one 'show-for-small-only' and one for 'show-for-medium-up'. The situation is that both instances of the fetched javascript code is getting executed. Hence, two badges. One solution is to edit the actual template (main.php and main.checkout.php). Place the <script> part along with all the other <script> tags at the bottom. Leave the <span> block in the Copyright content. Another solution is to create a code snippet that will then have the script URL loaded into the template for any skin you may want to use.

It is data redundancy, true, but I think the 'cat_id' column is kept for legacy purposes. CubeCart does now use the CubeCart_category_index table as a many-to-many relationship: many products can be assigned to the same category, and many categories can be assigned to one product (where one of those categories is designated as the 'primary' category). This "glue" table (it 'glues' the inventory and category relationships) only needs the id numbers. With a minimally complicated SQL query, you can make it easy to identify the product and category you wish to affect.

Please verify that you are entering this code when the editor is in Source mode. Is the site publicly viewable? If so, may we have a web address?