All of a sudden out of nowhere today we are seeing the following error message on multiple pages of our site (Version 2.1.3 Proffesional) :
Warning: Division by zero in /public_html/core/fn.images.php on line 52
This is a new one on me and have no idea why this would start to appear outta the blue as no file changes have been made on our end to cause this! 
Can someone please give me an idea how to quickly fix this as site is now non-functional?
Thanks!
What do you have in config.local.php?
// Maximum number of files, stored in directory. You may change this parameter straight after a store was installed. And you must not change it when the store has been populated with products already.
define('MAX_FILES_IN_DIR', [COLOR="Red"]1000[/COLOR]);
Thanks for the reply Tool!
// Maximum number of files, stored in directory. You may change this parameter straight after a store was installed. And you must not change it when the store has been populated with products already.define('MAX_FILES_IN_DIR', 1000);$config['vendor_index'] = 'vendor.php';?>
This is the most confusing error to solve that I have ever experienced, so far the hostgator support people are even struggling with this one considering not a single file was changed on my end and site was working flawlessly until this AM!
Probably the first time in over 10 years that our site has been outta commission for more than an hour…xkhfathklsdjfhsthrlg !! 
Is that how the code is formatted? If so, it’s commented.
Edit: I think you need to edit your sig.? 
Thanks Tool, you pointed me to the heart of the “Mystery Problem from Hell” !
Our config.local.php file was corrupted in a few different lines so after going through each line & making corrections our site is back up & running!
The mystery is that this file hasn’t been touched for several weeks, and I am the only person that has any authorized or ftp access to these files outside of the host, (Hostgator VPS) and this I do know.
Our site has worked flawlessly for months, and we truly are logged in from morning until late at night, then all of a sudden this morning the error popped up.
So, although our site is back to normal, we lost an entire day of orders & processing…
Probably not the only file.? That’s what happens with the excellent upgrade script that is used. I used Beyond Compare and fixed many files and also removed about 20MB worth of useless files from previous versions.
[quote name=‘The Tool’]Probably not the only file.? That’s what happens with the excellent upgrade script that is used. I used Beyond Compare and fixed many files and also removed about 20MB worth of useless files from previous versions.[/QUOTE]
I hear what you are saying, and I quite often do a combination of built-in upgrade script along with manually comparing files when I have a doubt!
However, that doesnt explain why our site has worked flawlessly for weeks after the upgrade to 2.1.3 and then mysteriously goes haywire, you know what I am saying!?
I fully believe “something” happened on the Hostgator vps side to cause this, just have never experienced anything quite like this before, the only positive note is that it is screaming along again. 
Who knows? Glad I could help.
We received the error you have listed when we changed “file” to “sqlite” on the config.local.php as was suggested elsewhere in the forum. I am guessing we do not have “sqlite” installed on our server. Good thing we had a back up of the file.
Thanks Clips,
Although, as I mentioned above:
[QUOTE]Our config.local.php file was corrupted in a few different lines so after going through each line & making corrections our site is back up & running[/QUOTE]
This was exactly the reason for our problem.
In your case, always remember to go back & clear your cache immediately after changing the cache “method” so that you don’t end up with conflicting cached files.
Nothing serious, you just need to clean house after making the change.
I cleared the cache, but still got the strange “division by zero…” and most of the images no longer showed on my site, even after a restart of the browser, tried IE instead of FF and tried it on my wife’s computer it did not work properly. So I took the ‘sqlite’ code out and had to fix the config.local.php
We’re good to go now…but without the sqlite.
Thanks,
Jim
[QUOTE]We’re good to go now…but without the sqlite.[/QUOTE]
Well, for starters did you ever actually verify if you had the sqlite3 module installed on your server?
Guess you will never really know what you are missing & will be running at less than optimal until eternity!
[quote name=‘Struck’]Thanks for the reply Tool!
// Maximum number of files, stored in directory. You may change this parameter straight after a store was installed. And you must not change it when the store has been populated with products already.define('MAX_FILES_IN_DIR', 1000);$config['vendor_index'] = 'vendor.php';?>
:([/QUOTE]
Hi Struck.
On Ver 2.1.4 pro, I had the exact same corrupted line tonight when I enabled sqlite.
After fixing the line the cart functioned normally.
The change was from:
…with products already.define(‘MAX_FILES_IN_DIR’, 1000);$config[‘vendor_index’] = ‘vendor.php’;?>
To:
…with products already.
define(‘MAX_FILES_IN_DIR’, 1000);
$config[‘vendor_index’] = ‘vendor.php’;
(I moved this line up to // Names of index files for administrative and customer areas)
?>
Must be a bug.
Thanks for pointing me in the right directions gents.
Cheers
To change the backend caching method requires editing the file. The caching method does nothing with config.local.php. Hence as unlikely as it may be, it is probably either the editor you are using or a fat-finger problem that caused the issue.
[quote name=‘tbirnseth’]THence as unlikely as it may be, it is probably either the editor you are using or a fat-finger problem that caused the issue.[/QUOTE]
Nope, it’s an upgrade bug. The file is/was corrupt from the upgrade. I noticed this right off the bat because I compared each and every file/folder to a fresh install and that is why I was able to help Struck with the situation.
Edit: I would highly advise anyone that upgraded to 2.1.4 to check their config.local.php file.
Was referring to Raeandy when he stated the problem started when he changed to sqlite.
I do not see an issue on my site that was upgraded to 2.1.4 from 2.0.15 (and the ones in between). However, if they are inserting that line into to config.local.php file, it is highly possible they have a problem with type of end-of-line. I.e. a unix style line ending being inserted into a file that has MS style could confuse an editor that tries to convert the end-of-line type from one to another (like opening in an FTP editor via notepad).
[quote name=‘tbirnseth’] (like opening in an FTP editor via notepad).[/QUOTE]
Gents, this is what I did.
I used FlashFXP and edited via notepad.
So tbirnseth, is it my editing method, or a away the server reads my file, or the way in which the cart in configured from a development side ?
I ask this as I am definately not in your (or the others) league when it comes to servers etc.
Perhaps clips could revisit this thread to sort out his sqlite issue.
Cheers to everyone for their help.
I do not know the reason why the file was corrupt (and don’t really care) but all I can say is that a good portion of the file was corrupt, not just the line in question above.
hi,
I changed config.local.php: define('MAX_FILES_IN_DIR', 1000); to define('MAX_FILES_IN_DIR', 5000);
but does not work.
regards,
hi,
I took same error,how can get rid of this situation on v401?
any idea? I read other posts,but there is no clue/hint.
regards,