havenswift-hosting

Are either or both of you using PHP mail() or are you using the better Authenticated SMTP method (PHP mail provides unreliable delivery as it isnt authenticated plus many hosting companies disable the use of it completely). Which hosting companies are you both with ? Have you both recently done an upgrade and are you 100% sure that you did it properly - so many "unusual" problems like this are due to failed or partial upgrades. Ian

Hi Tony The file manager table holding the image references could be in a real mess after all of that - how many entries are there in that table. Having duplicates with differing suffixes is not right nor is having entries at zero bytes Also if the Admin File manager option is slow it probably indicates that you have far too many images all at the one level (I have seen tens of thousands all in one directory many times !) - so many people keep uploading product images into the one top level directory and CubeCart takes forever to read that listing. Ideally I suggest never more than a few hundred per directory - split them up into sub and sub-sub directories and the structure will depend on your products. It could be by category and sub-category, some do it by manufacturer etc Ian

This is likely a redirect that has been setup in cPanel (Domains | Redirects) although why you would want to add back in the index.php to the url is a mystery - most people would want to remove /index.php from any url to protect against any possible duplicate content issues. Check in that area and remove the redirect that is setup

Frank This has been covered in at least six different threads on here - do a search for "time_zone" and you will get answers - it is a problem at the server level that only somebody with root level access can fix although it is literally a 10 second job to fix it Ian

MyISAM by default (and the way that CubeCart is written) locks the whole table so a far worse situation - imagine a situation on a busy site taking lots of orders with 2, 4 or 8 admin users updating orders and stock and you can imagine what would happen. InnoDB by default locks at row level so a much better situation but still locked by the database connection making that transaction as you say. New CubeCart stores are created with most tables as InnoDB now (the reason that some were left as MyISAM was that full text searches wouldnt work on InnoDB but that was fixed all the way back in MySQL 5.6.4 so to my mind every table should now be InnoDB. Older sites (not even that long ago) were created with all tables using MyISAM and upgrades unfortunately do not change this

I give up ! As I have explained multiple times there are other "possible" problems such as database locking that are completely separate and to which I was referring - this was on the assumption which I CLEARLY stated that they should always be using different admin logins

The whole point of my last answer is that I never said that !! Read it again - I very clearly said that two admins should always be using two DIFFERENT logins - so really not sure why you keep saying that what I said was wrong. As the OP didnt go into any detail, I initially said that as long as they are doing that (using two different logins), then there should be no problems - it was only when he mentioned the database that I then replied with a little detail about database locking

No, I am not wrong as you are just repeating what I originally said !! It is very clear that I said they should be using different logins ! @Lots Moore then asked about possible database issues, so I answered that as well

It is actually slightly more complicated than a simple yes or no but for all practical purposes, you shouldnt have problems. CubeCart is not written to use row level locking although if the table uses InnoDB (rather than MYISAM) then row level locking is used automatically.

Yes that should be OK - two admins should always be using different logins though

If you clear cache does that process complete OK or do you get a white screen / error and if nothing obvious are you able to validate that the cache directory is then empty ?

250,000 is a reasonable number and should be fine for most users so you must have a very large number of files somewhere in your hosting account - is your hosting company not able to help and tell you where these are or are they saying that the cache directory is holding all of these ? Have you asked them if memcached is available ? If there really is (probably) more than 200,000 files in the cache directory, then there is a major problem somewhere

And the error message is ??

There are huge numbers of people using this great shipping plugin and while no one can ever say there are no bugs in any software, a much more likely explanation for this is that the order that you are putting through doesnt fall within any of the shipping bands that you have configured. Without knowing how your products are configured, what is in the order and what shipping bands you have setup in AIOS, it isnt possible to give any more advice

Sounds like a pretty cheap hosting plan that is restricting the number of inodes (effectively number of files) to a low number and if they are doing that, they are probably restricting a good number of other things (all while probably claiming it is "unlimited" hosting !). Worth checking but VERY unlikely that a hosting company like that will have memcached and certainly not REDIS installed and available but both of those would certainly solve the problem (and speed the website up !)