Suddenly Front end blank. Admin fine.

May I suggest something a little along the same route, but different?

Could you copy the contents of the htaccess file from your extras folder into an htaccess (needs to be created) in the new directory?

Likely have to do even more to open operation up completely, but I have indication to suggest that it may help at least a little...

RodG:

There is also a possibility that the .htaccess with the go daddy rules and without the redirects could make the store work again but only if you point the browser to http://youdomain/new/ follow?
Scheers
RodG

Kind of. When you say with the godaddy rules but without redirects I get a little lost.

Nepherael:

File replaced. No redirects

That's interesting. If I load something like domain/new/index1123.php I still get the zen cart error that it wasn't uploaded

That's not a ZC message. That's from godaddy...

mc12345678:

May I suggest something a little along the same route, but different?

Could you copy the contents of the htaccess file from your extras folder into an htaccess (needs to be created) in the new directory?

Likely have to do even more to open operation up completely, but I have indication to suggest that it may help at least a little...

Done

RodG:

Another suggestion (should have thought of this ages ago). Check the files in the /new/ folder. If you see one called index.htm or index.html delete it.

Checked. Did not exist. Index.php does exist

mc12345678:

That's not a ZC message. That's from godaddy...

Oh I see. I had NO idea. Had I realized that was a Godaddy error that may have pushed me further along. I'm used to seeing Godaddy's Green orange and black colors on the parked pages and errors etc.

Summary of current changes.

Root htacces has all redirects removed but original code remains.
htacces copied from extras directory the new directory

Nepherael:

File replaced. No redirects

That's interesting. If I load something like domain/new/index1123.php I still get the zen cart error that it wasn't uploaded

Hmmm, I'm still getting the godaddy default page (website coming soon)... not the zencart file not found error.

The difference is important and significant. If it is the zencart page then we are back to square one.... if it is the goddady page, then it is a godaddy problem, but I do have one more thing I'd like you to do that im hoping will help godaddy sit up and take notice. .. remember how early in this thread mc1-8 gave you instructions about how to get the phpinfo? Well, this time, i want you to 1st make a backup of your /new/index.php file and then replace this file with the one with the phpinfo() command.
Now point your browser to yourdomain.com/new/ you should get the php info data. If not, try yourdoman.com/new/index.php

Im hoping that you dont get the results im expecting (a valid result).. cos that is going to put a spanner in the works. If you are lucky (unlucky?) you will be greeted with no results (blank page) or some other godaddy response. If this is the case, you will have elimated anything to do with zencart itself, and if they cant diagnose a problem with a site that essentially consists of a single php file with a single command... well.. say no more..

Cheers
RodG

tested.

Unfortunately, full valid result. I see the PHP version followed by all of the info.

Next thing. I will wait for your reply before I change back in case you would like to view it.

and finally, would either of you looking at it over an FTP program help? I can create a user and shoot you a message and you're welcome to do some checking as long as edits are kept track of and turned back if they don't work

pointing just to domain/new gives error page though. I have to navigate directly to new/index.php for it

mc12345678:

May I suggest something a little along the same route, but different?

Could you copy the contents of the htaccess file from your extras folder into an htaccess (needs to be created) in the new directory?

Likely have to do even more to open operation up completely, but I have indication to suggest that it may help at least a little...

Nepherael:

Done

Checked. Did not exist. Index.php does exist

Sorry, I should have realized that it wouldn't have helped do anything. A php file already was proven to execute from the folder with the phpinfo() test.

Nepherael:

tested.

Unfortunately, full valid result. I see the PHP version followed by all of the info.

Bummer. Not what i wanted.

I did still note one oddity though, a url with no filename (just ending with a /), is supposed to serve up a default file if one can be found. Typically these files are search for in the order of index.htm, index.html, index.php and a couple of others. You site isnt doing that. Whether this is relevent to the blank page problem ive no idea... I suspect not.

Thanks for the offer of ftp access, but I will pass on that .. its 2am, and I dont think im thinking straight any more.... this whole thing now has me bamboozled..... I seriously dont know what to suggest or where to go from here. It is clear that godaddy have something weird going on, especially in the way it is handling file not found errors, which it really shouldn't be doing, because that in itself is going to cause problems with zencart which needs to handle these for itself (or silently ignored). How this relates to your blank page when the zencart index.php file is found is still a mystery. There may not evrn be a connection. (Btw, have you checked the error logs recently? If any exist, they may still provide a clue).

I really am lost for ideas though...... for me to debug any further I'd be adding "echo" commands in various places in the zencart code (starting from the index.php file) and working through the program flow to see where the echos stop working. This isnt something that I could guide you through though.

Hopefully one of the other folk here can see something that I'm missing, or can at least make a better suggestion .... but at the end of the day, most of us know that godaddy are quite possibly the worst host on the planet and have a habit of doing things in their own unique way, and often making a mess of things (not being able to install a site in the root folder being a classic example). Generally speaking there are ways around their weirdness, but this one is totally new, at least to me.

Sorry, but ive done my best to help isolate the problem. I/we now know many things that isn't the cause, but we still dont know enough to determine whzt the cause is.... other than everything points straight back to goddaddy (its not the htaccess, its not the redirects, its not the php version, mysql is fine, the zenczrt code hasnt changed (?), theres no default .html file being loaded instead of the index.php. the index.php file isn't being loaded by default (as it should be), but can be accessed when specifically called, so in itself the failure to load by default is of no significance. Godaddy shouldn't be handling the file not found errors like it is, but appears fine when the files aee found, so probably not significant... or perhaps it is...

So what am I missing? Anyone?

Cheers
RodG

Nepherael:

tested.

Unfortunately, full valid result. I see the PHP version followed by all of the info.

Next thing. I will wait for your reply before I change back in case you would like to view it.

and finally, would either of you looking at it over an FTP program help? I can create a user and shoot you a message and you're welcome to do some checking as long as edits are kept track of and turned back if they don't work

This is pointing to my next thought, which is/was how is index.php and/or includes/application_top.php modified from an original version of those files? (copies available from the main page of this forum site.)

I totally get it. As of now I will replace the index.php file to what it was and keep an eye on this thread. I will post as I am able if I come up with anything or want to bounce something off you guys.

Thanks for working with me to at least narrow it down further

mc12345678:

Sorry, I should have realized that it wouldn't have helped do anything. A php file already was proven to execute from the folder with the phpinfo() test.

True, and I knew that too. My suggestion here was twofold. First to see if it would load as a default (it didnt), but should gave done (a further clue?) and secondly, if it did give a blank page (remotely possible if godaddy were doing something "special" with an index.php file based on its name) it could have demonstrated the same blank page response which would have taken zen entirely out of the equation. Sadly this wasnt to be.

Ive just had another crazy idea though, what if, in the index.php file with the phpinfo (), another line were added to include a file known to not exist. Would it then produce a blank page due to the way godaddy appears to be taking contol over file not found errors? What do you think? Worth a try?

Cheers
RodG

mc12345678:

This is pointing to my next thought, which is/was how is index.php and/or includes/application_top.php modified from an original version of those files? (copies available from the main page of this forum site.)

You mean my version of the file is not the same as the one that comes in a fresh install? I'm not sure. They had someone build it and someone at Godaddy told me the weird redirect targets and some other things that are there pointed to this originally being installed on a windows server and then moved to Linux. I don't know how much water that holds or if it's even relevant.

Would replacing these two files with a fresh copy from a Zen 1.5.1 fileset be worth trying if index.php isn't loading in the first place?

Nepherael:

pointing just to domain/new gives error page though. I have to navigate directly to new/index.php for it

I used this post as a reference rather than RodG's because no editing required. :)

This indicates that perhaps the htaccess needs an IndexHome directive:

IndexHome index.php

But even in his dazed state, it does look like the issue is somewhere at least in those first two files...

Considering that you already changed the flag that lat9 suggested with no results, the problem lies between the start of index.php up to the require('includes/application_top.php'); into that file and up to the first set of loading somewhere before loading includes/configure.php...
I don't have a copy of the file open to compare/identify the line number, but after that flag was changed to true is a loading of several "groups" of files and within each of those are commands to output debug info. An error occurring before the first of those debug outputs would not be presented on screen by the ZC code.

I just tried that index home code line in the both htaccess in root and in new and it threw a 500 error on both with anything I typed in

RodG:

True, and I knew that too. My suggestion here was twofold. First to see if it would load as a default (it didnt), but should gave done (a further clue?) and secondly, if it did give a blank page (remotely possible if godaddy were doing something "special" with an index.php file based on its name) it could have demonstrated the same blank page response which would have taken zen entirely out of the equation. Sadly this wasnt to be.

Ive just had another crazy idea though, what if, in the index.php file with the phpinfo (), another line were added to include a file known to not exist. Would it then produce a blank page due to the way godaddy appears to be taking contol over file not found errors? What do you think? Worth a try?

Cheers
RodG

It certainly would be odd if that was something they were doing: process file, output nothing until processing is complete, if no error present total result, if error provide people trying to setup their first site. :P

Wouldn't hurt to try and discredit that possibility.

Could add a line like:

require('includes/tophat.php');

Nepherael:

I just tried that index home code line in the both htaccess in root and in new and it threw a 500 error on both with anything I typed in

Sorry, bad memory. DirectoryIndex instead of IndexHome...

Nepherael:

.
Would replacing these two files with a fresh copy from a Zen 1.5.1 fileset be worth trying if index.php isn't loading in the first place?

Whether they'll be worth replacing depends on where in the flow the error occurs.. it may be ine of those files, or it may be in another file that they are loading or trying to load.
You did ask a good question though, but even though the index.php file isnt being liaded by default, the problem still occurs when explicitly loaded, so the answer there is yes.... but again, it may not even be those specific files.

Im still thinking the godaddy file not found as being a factor, but if that is the case, there is still the issue of what file isnt being found, and will it cause a blank page?

Cheers
RodG (definitely calling it quits for the night this time)

Nepherael:

You mean my version of the file is not the same as the one that comes in a fresh install? I'm not sure. They had someone build it and someone at Godaddy told me the weird redirect targets and some other things that are there pointed to this originally being installed on a windows server and then moved to Linux. I don't know how much water that holds or if it's even relevant.

Would replacing these two files with a fresh copy from a Zen 1.5.1 fileset be worth trying if index.php isn't loading in the first place?

So, the content of the index.php file doesn't change whether GoDaddy will load it or not as a filename (considering the test offered by RodG of the file presenting the phpinfo() when directly loaded). But, the fact that no content is output when the file is referenced directly does mean that there is something about the file contents that are not right.

Typically the indication of where the file was edited is by line endings. PCs tend to add an additional "line" when the file is presented to a "linux" based system. (line ending of new line and carriage return versus just a new line). That type of additional text does not generally affect operation of the code (just an extra "character" per line throughout the file).