Site Down, Storefront Pages Blank But Admin Fine

[carlwhat]

that information should be available on the admin (which the OP said was still up...)

admin -> tools -> server/version info...

[wndbne]

Many thanks for the help.. I ran the php info code and was the same as on admin: PHP Version 5.2.17 (ZenCart 1.3.8a)

I had run into a PHP version issue about a year ago, installed the php patches and has been up and running since.. but possibly something has changed recently..

I wasn't able to find any issues with files, and DB seems fine (admin working), so with the suggestions regarding php version, I'm hoping an upgrade to latest ZenCart Version may fix..

[carlwhat]

one of the first files to load is: includes/application/top

within that file you can add the following line:

die(__FILE__ . ':' . __LINE__);

then reload your home page and you can see whether you are making it to within that file. there should be a statement with the file and line number from that file.

if you are not getting to there, the problem may be within your .htaccess file.

good luck!

[wndbne]

one of the first files to load is: includes/application/top

within that file you can add the following line:

die(__FILE__ . ':' . __LINE__);

then reload your home page and you can see whether you are making it to within that file. there should be a statement with the file and line number from that file.

if you are not getting to there, the problem may be within your .htaccess file.

good luck!

Thanks, I inserted the code at various lines and was able to get a line number response down to line 87
"include(DIR_WS_INCLUDES . 'extra_configures/' . $zv_file);"

then blank screen if inputted below line 87

[carlwhat]

wndbne,
awesome.

so now we have established that zen-cart is loading; and there is a problem with a script within the includes/extra_configures directory.

the easy thing would be to see if you have access to your hosts apache error log. the error log should point you to the exact problem script. you can ask your host for that information.

barring that you can continue to add the die statement to the scripts contained within the aforementioned directory until you can further isolate the line that is failing.

good luck!

[mc12345678]

To possibly more conclusively identify which file(s) are a problem, you could try a portion of what was suggested in post #2 of this thread:

Advanced Developer Option. (THIS APPROACH IS *NOT* NEEDED FOR MOST SITUATIONS!!!!)

While the built-in myDebug-xxxxxx.log method above is far more reliable and secure (since messages are never shown in your customers' browser), another way to help identify *where* an error is happening is to show the errors on your browser. The drawback to this is that your customers can also see the errors, and search engines might catch them too ... which could be embarrassing, AND WILL CAUSE YOUR SITE TO FAIL PCI SECURITY SCANS.
To attempt to show PHP debug errors on-screen, create and upload a new file, like this:
Filename: /includes/local/configure.php

<?php  define('STRICT_ERROR_REPORTING', true);

Then try to access your site again. You may see many warning messages on the screen.

Be sure to delete the /includes/local/configure.php file once you've identified the problem, lest you leave yourself with a security problem on your site.

[wndbne]

fantastic, my site is back up --Thanks so much for all the help :)

I looked closer in the 'extra_configures' folder and found an odd file named "email_use_8bit_prexxx" ..appears to be a copy of "email_use_8bit" but had odd code inside.. not sure where it came from but missed it in my prior scan of files.. also had an older date on file so didn't trigger to look as a recent hack attempt as figured was a prior patch or add-on..

I deleted the file and all is back up and running --Many thanks again for all the help.. going to work on upgrading to latest Zen Cart version to eliminate the security vulnerabilities of my older version..