Suddenly Front end blank. Admin fine.

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...

Nepherael:

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

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

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

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.)

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?

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.

This was the suggestion.

lat9:

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', [B]true[/B]);

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

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?
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".

Nepherael:

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.

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...

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...
Another thing to try is to modify the /includes/application_top.php file, adding the following line right before the DEBUG_AUTOLOAD definition:

define ('STRICT_ERROR_REPORTING', true);

... just in case there's something else funky going on. Don't enclose that *true *in quotes, it's a boolean value.

Thank you very much for sticking with me here. I have a few more things to attend to but in the next few hours or slightly more I will report back and implement the suggestions in the last 3-4 posts and see where we can get.

You could also just edit the main index.php file, and add this anywhere after line 2 (ie: after the opening <?php tag):

 die('I got to index.php');
```At least that way you'd know whether your apache redirects are completely intercepting, or if it's something customized in your ZC that's causing another silent redirection.

For those following this thread. It appears that the problem is/was the result of a hack.

A new .php file had been recently added into the extra_configures folder. The contents of the file didn't give me any clues as to the nature of the hack, and I've no idea what method was used to place it there. The site is using zen151 and was installed in 2014.
I also found another php file with similar contents in one of the other folders. This was added in Jan 2016.

Both files had "prevv" As part of their filenames. If this seems familiar to anyone could you please PM me with any details that you may have.
My initial thought was that the OP may have created these as backups of some sort (previous = previous version?), but the OP knows nothing about them, so a hack is the only logical conclusion.

Cheers
RodG

RodG:

For those following this thread. It appears that the problem is/was the result of a hack.

A new .php file had been recently added into the extra_configures folder. The contents of the file didn't give me any clues as to the nature of the hack, and I've no idea what method was used to place it there. The site is using zen151 and was installed in 2014.
I also found another php file with similar contents in one of the other folders. This was added in Jan 2016.

Both files had "prevv" As part of their filenames. If this seems familiar to anyone could you please PM me with any details that you may have.
My initial thought was that the OP may have created these as backups of some sort (previous = previous version?), but the OP knows nothing about them, so a hack is the only logical conclusion.

Cheers
RodG

Good work RodG, at least you had/were able to make the time to help her out. I know not from prevv as far as I can recall. I didn't take good mental notes the last time I came across a hacked site to say that I've seen prevv used before.

Quite a resolution to this. There's no way I could have avoided a full rebuild without the help offered here. I don't know that I could have accomplished that in a timely manner especially on a platform I don't have much prior experience with.

The guys that own this site run a metal shop that serves a huge chunk of Indiana and serves their lighting decor nationwide. They are very appreciative also.

Thanks to all of you for offering your thoughts, comments, and suggestions. I'm so relieved to have this resolved.

@RodG, would you PM me a copy of the offending file so I've got that as a data-point?

lat9:

@RodG, would you PM me a copy of the offending file so I've got that as a data-point?

I can't seem to find the link to send an attachment via PM, so uploading it here. Two files (zipped).

The look pretty harmless - but as previously stated, I can't make any sense of what they were supposed to do.

Cheers
RodG