Dirty Butter

Are you still on Galaxy X skin? I have no way to check, but I'm GUESSING you should find the image code in one of the skin/templates files - either content.checkout.confirm or one of the others that has checkout in the naming. Try content.checkout.medium.up and comment this out. <a href="{$item.link}" class="th" title="{$item.name}"><img src="{$item.image}" alt="{$item.name}"></a></td>

You will need to do a MANUAL UPGRADE. Do NOT try to upgrade from within Admin - even though you see a warning to upgrade and a link to do it with. Your images folder will not be over-written. https://support.cubecart.com/Knowledgebase/Article/View/228/43/how-do-i-upgrade-from-cubecart-v6-to-latest-v6 One of the security features that will be new for you is the renaming of admin file and folder to admin_XXX and admin_XXX.php. The XXX are random numbers. You should be warned at the end of your upgrade to keep a record of these new names. Assuming you have SSL, be sure to login with the https url with the admin_XXX.php link.

I had the link to the GitHub page, but it didn't stick! https://github.com/cubecart/v6

If you look on GitHub v6 Code page there is a list of which files have had changes. Look at the skin/foundation section, and you'll see that something was changed 15 days ago. You can find out what changes affected your skin and merge them into your version.

(Be sure you have the PayPal patch installed if you need it) There are skin changes and some new files in 6.1.7. Did you add those changes to your custom named skin?

If you still want to downgrade, these are the files I renamed with 617 suffixed and then uploaded the 6.1.5 versions temporarily: classes controllers includes js language admin_XXX your skin ini.inc.php admin_XXX.php (Basically everything LOL) I was on 6.1.5, so the database changes between 6.1.5 and 6.1.7 didn't seem to cause an issue, so I didn't try to revert those.

Sorry. I added this thread link to the GitHub post. In the meantime try commenting out this whole section and see what happens: {* Add "hide-for-small-up" to the class attribute to not display the more button *} <div class="hide-for-small-up" id="ccScrollCat">{$category.cat_id}</div> {if $page!=='all' && ($page < $total)} {$params[$var_name] = $page + 1} <a href="{$current}{http_build_query($params)}{$anchor}" data-next-page="{$params[$var_name]}" data-cat="{$category.cat_id}" class="button tiny expand ccScroll-next">{$LANG.common.more} <svg class="icon"><use xlink:href="#icon-angle-down"></use></svg></a> {/if} </div> <div class="hide-for-small-up" id="lang_loading">{$LANG.common.loading}</div>

Well this is a little different, but if clearing cache doesn't fix it - I'll add this thread link to the GitHub post.

Perhaps it's a cache issue?? Be sure to clear all CC cache except images AND your browser cache as well. PS Sergei - the <> in the post menu gives you a box to save code in - without it sometimes it doesn't appear properly - like it's trying to execute the code or something.

This is a known issue, possibly caused by a cache problem or customers changing their minds and using the back button. I'll try to find some of the threads so you can read what others have said. No one has yet, as far as I can remember, been able to reproduce it so it can be resolved. Here's the most recent one:

Sorry - saw the closed and posted to keat before I saw your GitHuib explanation about all Feature Requests being "closed" but still available for further consideration.

@keat This GitHub request has been closed without comment. Looks like you need a custom solution to solve it. Sorry.

I sure can't explain it. I had 2 out of 3 orders very quickly cause the issue when I upgraded to 6.1.7 before the patch was available.

Thank you for sharing, @sailing123 That may help someone else in the future.

6.1.5 doesn't have the issue. Your way of not using stock levels, etc. must have something to do with it.

Glad that did it for you.

I downgraded plushcatalog from 6.1.7 to 6.1.5 temporarily. I appended 617 to all the folders that had changed between 6.15 and 6.17 and uploaded the 6.15 versions. Be sure you change the version number in ini.inc.php. I'm not on my computer so it will be later tomorrow before I can tell you exactly which folders I uploaded.

Assuming you have not made any non-stock edits in sanitize.class.php - This is the link to the new raw sanitize.class.php file replacement. https://raw.githubusercontent.com/cubecart/v6/df12071a6e99bab5e87534557e02cc4740a1173c/classes/sanitize.class.php Open your sanitize.class.php file in the classes folder, and replace all the code in the file with this code. Then clear all CC cache except images in Maintenance. Also clear your browser cache - usually control/F5.

It did the same thing for me when I registered. I don't know how it could have any effect on this, but there was an edit in en-GB.xml that you should carry over to your Lithuanian xml file. Change your maxVersion to 6.*.* <code>en-GB</code> <character_set>utf-8</character_set> <version>1.0.0</version> <minVersion>5.0.0</minVersion> <maxVersion>6.*.*</maxVersion> <default_currency>GBP</default_currency> <text-direction>ltr</text-direction> When there are language file changes on CC upgrades - do you edit your Lithuanian files to keep up with the changes?

Mine has always been US in both, so I never had to deal with that. Like I said, I'm out of my depth. Sorry. You could try making another admin with Lithuanian language and see if that solves it on the front end. It might help someone with more knowledge know what needs fixing.

I really don't know, but I'm out of my depth at this point. How did you get admin in English and storefront in Lithuanian? I just tried an obviously fake registration and see it changes to lang="en-GB" What language is shown in your template main.php? It should be - <html xmlns="http://www.w3.org/1999/xhtml" dir="{$TEXT_DIRECTION}" lang="{$HTML_LANG}">

Well that appears to mean the database thinks you have British English as your default language. That would explain the default customer language being English. So, the question now becomes why does it think that. Be sure that you have Lithuanian set as the default language in Store Settings>General tab.

Did you do your current upgrade manually or via Admin? Do you have a backup of your previous CC and database version?

OK - I've picked up a piece of advice from Bsmither about a similar situation:

Sorry, but I'm a little confused. Is your site language working properly now, or is the customer still seeing English to begin with?