Dirty Butter

Just saw this - sorry I hadn't found it sooner: https://www.semperfiwebservices.com/easter-2017.html

I use an old v5 mod that creates sequential order numbers, and I have to edit this section of order.class.php with each upgrade: /** * Validate order ID PROBLEM WITH SEQUENTIAL ORDER NUMBER - solved by commenting out this new 6.0.8 section and not using tests in cubecart.class.php * * @param string $order_id * @return bool NOTHING GOES HERE public static function validOrderId($order_id) { if(preg_match('#^[0-9]{6}-[0-9]{6}-[0-9]{4}$#i', $order_id)) { return true; } return false; } END OF DELETED SECTION TO MAKE SEQUENTIAL ORDER NUMBERS WORK */ There's also several tweaks in cubecart.class.php that have to do with validating the order number: /* 6.1.7 version before Sequential Order tweak if (isset($_GET['cart_order_id']) && Order::validOrderId(trim($_GET['cart_order_id']))) { */ //Sequential Order Number tweak for Lookup Order if (isset($_GET['cart_order_id'])){ //end Sequential Order Number tweak for Lookup Order Maybe you can do something similar to keep your longer id's from being chopped.

Have you manually changed to 30 and still have the issue with a test order? If so, that means there is a place in CC code that is creating the order_id to that size. Oh how we miss Bsmither!! What version are you on?

See my suggestion on your email post.

Maybe there is still an issue with extra admin file/folder combinations at the root of your store. Double check the naming in includes/global.inc.php and be sure ONLY THOSE are the names in use at the root. Any others need to be deleted - just be sure you are deleting ONLY from the same directory level that has the includes folder in it.

I just subscribed with an obviously fake registration without any problems. My browser has the newest javascript versions in use, as I have two sites on 6.1.7.

I'm certainly not knowledgeable, but IF there is no upgrade script in the upgrade scripts of all intervening versions of your next upgrade that deals with cart_order_id, it seems like your varchar change would not be messed up on upgrade. I only found 3 tables with cart_order_id in it, not counting email_log and email_content_backup. Maybe you have more because of mods/plugins? Otherwise it would be fairly easy to edit the tables and change the varchar on each one.

CubeCart_email_content is what you want from the database. It's not encrypted or obfuscated in any way. You should be able to copy to the Source code of each template.

Any edits you had were over written on update. You will need a file compare program to help locate your edits from your backup of the old version and merge them into 6.1.7.

Please refresh our memory. What version are you on? Have you cleared all cache except images and control/F5 your browser?

It's in Catalogue>title_popular. Whenever I can't find which dropdown to use I goto the definitions.xml in the language folder and search for the term. Then I scroll up to see which section it's in. It's best NOT to make the change in the file, as your changes in admin Language are databased and not lost on upgrade.

You can certainly rename it in Languages>click on your flag, if that works for you. Yes, that section has not changed in 6.1.7, so you should be able to comment out any section you do not want. Again, if you comment all of them out, the sidebar space will still be there, unless you make grid changes as well.

That's what I thought you were talking about. It gets huge in a hurry now that so much more is being logged. Sadly, it IS normal for now. I've requested on GitHub that a choice to see all or just the warnings be added to make it less intimidating and more useful to the ordinary user (kind of like the Customers Online vs Bots and Customers). If you're on the support plan that makes good sense. But please, if you can, let us know what was wrong and how Al fixes it.

Well, it sure seems to me that it's logging EVERYTHING! LOL

Welcome to the forums, @Steve llea! Most of the time when you want something to load on every page from the storefront, it needs to be added to main.php in your skin templates. I don't understand when it's needed and when it's not, but I always seem to end up enclosing the javascript in {literal} {/literal} tags. Sometimes it needs to be in the header, others near the end. Hopefully Piwik makes that clear - of course there's always trial and error. Just be sure, whatever you try, to be sure all cache in CC (except images) and browser are cleared after each change. Temporarily disabling cache would help while testing. As for being lost on upgrade - yes, if you keep the Foundation name for your skin. If you copy the Foundation and rename it, making appropriate naming changes in the skin config file - your copy will not be overwritten on upgrade. That means you have to manually make any skin changes an upgrade might have in it (but they are relatively rare). According to Piwik's directions - https://piwik.org/docs/installation/#getting-started

Frankly, it was customer service with a CC related issue that caused me to change to hosting with Havenswift.

I used to use Hostgator for our CC installs. I'm assuming you have hosting through them as well? They have different packages that might make a difference in how well CC runs.

Perhaps this will be helpful: https://support.cubecart.com/Knowledgebase/Article/View/227/41/how-can-i-install-cubecart-v6

If you mean the new system error log that logs EVERYTHING - the only ones of any concern are the Warnings, not the Notices. Now the 404's ARE cause for concern. What did you upgrade from?

Sorry, I was hoping that was it. Did you clear all Maintenance CC cache except images AND clear out your browser? Try Control/F5 for your browser. There are javascript changes that may already be cached with the old version, and it can sometimes be stubborn to get out of cache.

There are several new files in 6.1.7. It sounds like you have not added them to your install, since you would have done this upgrade manually.

I am so afraid of causing a disaster that I commented out the section in Maintenance that has the warning about clearing SEO URLs. Something like that should work. How about comment out the Sales Report and Statistics in the dashboard navigation. Then bookmark the two pages in your browser. As long as you're logged in, they should load. There might be CSRF complaints, but if you refresh pages before you use them it should work. admin/source/element.navigation.inc.php storeurl/admin_XXX.php?_g=reports storeurl/admin_XXX.php?_g=statistics In admin/skins/default/templates/dashboard.index.php you can easily comment out the total sales graph.

I rolled back our plushcatalog store to a GitHub commit from early March (basically back to 6.1.5). I then took an order all the way to payment and, unlike my usual testing, I actually paid for it with a different account debit card. I used a different domain email address. And all the payment process worked properly. And the refund from PP processed correctly on CC as well. I DID see the part I've quoted from your comment, @foz1234 But by the time I checked in admin, it had Processed. All the CSRF changes are what I don't have in my live code. I DO still have captcha turned off, thanks to all the changes in that coding that my plugins and edits don't have yet.

As a Super User you see everything. Uncheck that for sure for those who should have limited access to info in admin. I'm not the one to tell you how, but there should be a way to edit code to modify what information is available on stats and reports, based on not being a super user.

I think you're right, foz1234, but I wasn't sure.