Suddenly Front end blank. Admin fine.

[mc12345678]

By "replacing" (maintaining a backup of them) and changing the constant that lat9 suggested I think on or near post 10, to true, if the "other files" are an issue, then such an indication should be made available. That is if the test of forcing an error in a file (RodG's suggestion) still presents at least the phpinfo data...

BTW, RodG go to bed! Or sleep if you're already there.

[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



Checked. Did not exist. Index.php does exist

Thought there was a "summary" post of the current "status" but couldn't find one.

Normal ZC operation does not require an htaccess file in the root of the store (new directory) if the one from the extras folder is still there, please remove it. I should have stated that before when I pointed out that ultimately it was unnecessary because it was already shown that a php file (one that showed the phpinfo()) had already proven to function without an htaccess in the new directory.

[mc12345678]

By "replacing" (maintaining a backup of them) and changing the constant that lat9 suggested I think on or near post 10, to true, if the "other files" are an issue, then such an indication should be made available. That is if the test of forcing an error in a file (RodG's suggestion) still presents at least the phpinfo data...

BTW, RodG go to bed! Or sleep if you're already there.

The suggested change was actually in post 6

[RodG]

Observation (forgot to mention)
http://www.lightsforholidays.com/new/images/
Or any other folder that exists, or should exist, is producing the godaddy not found response rather than the expected permission denied response.

Godaddy is doing some weird sh1t

[mc12345678]

Observation (forgot to mention)
http://www.lightsforholidays.com/new/images/
Or any other folder that exists, or should exist, is producing the godaddy not found response rather than the expected permission denied response.

Godaddy is doing some weird sh1t

Agree to an extent, one directory that has an index.html will load the missing file notification now if just the directory is accessed, but load the index.html if included in the path. (blank page, but view source shows code.)

[Nepherael]

Apologies for the delay. I had to put a family member in the emergency room and, subsequently being admitted, yesterday. I've had a moment to review.

To start, I removed the htaccess put in the /new/ directory just now as directed.

Current changes that remain from start:

all redirects removed from the root htaccess.

This may be why you are getting page not found error instead of Zen access denied. Should I reinsert those redirects to where the site functioned prior?

[Nepherael]

By "replacing" (maintaining a backup of them) and changing the constant that lat9 suggested I think on or near post 10, to true, if the "other files" are an issue, then such an indication should be made available. That is if the test of forcing an error in a file (RodG's suggestion) still presents at least the phpinfo data...

BTW, RodG go to bed! Or sleep if you're already there.

This was the suggestion.

For some additional data-gathering, you can edit the file /includes/application_top.php, finding this line:

define('DEBUG_AUTOLOAD', false);

and changing that to read

define('DEBUG_AUTOLOAD', true);

That will cause the auto-load status to be displayed for each item processed. There might be a missing class-file or some other obscure issue and that display will aid in that determination.

Remember to turn that back to false (no quotes) when you're finished.

If this is a direction to go I can go back and mark it true and push forward with more of the file testing

[mc12345678]

Apologies for the delay. I had to put a family member in the emergency room and, subsequently being admitted, yesterday. I've had a moment to review.

To start, I removed the htaccess put in the /new/ directory just now as directed.

Current changes that remain from start:

all redirects removed from the root htaccess.

This may be why you are getting page not found error instead of Zen access denied. Should I reinsert those redirects to where the site functioned prior?

I would say no, that they aren't needed (yet) and as far as redirecting the main uri to the subdirectory, if redirects will end up being used, there is a far easier/better way, but as the includes/configure.php file stands right now, it's not necessary for the "testing".

[mc12345678]

This was the suggestion.



If this is a direction to go I can go back and mark it true and push forward with more of the file testing

There were two different things being addressed.
RodG's suggestion if I remember the destination correctly, was to replace the current index.php with one that has the echo phpinfo(); command and then to also then require a file that doesn't exist. Attempt to access the directory and or directory with index.php and see if the the phpinfo even appears...

The second thing with the code change is in order to see how far ZC processes files before execution stops.

Now all that said, and based on the summary of the current status, I had incorrectly provided a command that gave a 500 error. After that I provided the correct command name to use in the htaccess. Could you add:

DirectoryIndex index.php

Into your root htaccess that does not have the redirects in it.

[mc12345678]

The third suggestion after the test with the index.php was to replace index.php and includes/application_top.php with original versions of those files, then to modify the setting described by lat9...