An apparent conflict with my Apache configuration

[cyberbaffled]

I've posted the following in quotes on several Apache forums and a Plesk forum, and haven't gotten any useful suggestions. One return post suggested that the problem isn't with Apache or Centos but the Zen Cart application. I can't imagine how an application could influence a server in such a fundamental way, but I thought I'd give this forum's participants a shot at solving the problem.

"Some Apache directive (or, alternatively, Centos 6.5 directive) automatically adds a copy of root directory and immediate subdirectory to my physical path. I create a physical path such as " /var/www/vhosts/my_domain.us/zencart" in which my index.php file is in the "zencart" directory. I then attempt to open the zencart application with the url "httpds://www.my_domain.us" and I get a 404 Not Found error with an associated error_log message:

[Thu Apr 02 23:09:21 2015] [error] [client 67.190.xx.xx] File does not exist: /var/www/vhosts/my_domain.us/my_domain.us/zencart/zencart.

Two new folders have been added to the physical path. There is also an associated problem. The above error_log message is sometimes generated without ftp displaying an adjusted physical path; i.e., with an unchanged, correct physical path displayed.

Any insight into this conundrum would be greatly appreciated. "

[lhungil]

CentOS version? Apache version? VirtualHost configuration? Contents of .htaccess files (including those in parent directories)?

Using mod_php? fastcgi? suEXEC? suPHP? Configuration of aforementioned?

Output from phpinfo (create file in webroot to output to a browser)?

URL to site exhibiting the behavior? Does behavior appear BEFORE or AFTER installing Zen Cart? If after was either /includes/configure.php file altered by hand?

[RodG]

There is also an associated problem. The above error_log message is sometimes generated without ftp displaying an adjusted physical path; i.e., with an unchanged, correct physical path displayed.

Any insight into this conundrum would be greatly appreciated. "

Although I've no idea what you are trying to say here (what is meant by 'adjusted physical path'?),
assuming a common cause for both the HTTP and FTP problem I'd be looking at DNS is being the cause.

Probably one of more of the CNAME entries are missing a trailing ".".

If you'd supplied more info, such as the name of the store I/we would be in a better position to run a few tests and checks and give a more definitive answer.

Cheers
RodG

[DrByte]

The only part Zen Cart would play in this situation is what URL and paths you've put into your configure.php files ... which you haven't shared here, so we can't help much with that.

Everything else is in your vhost/apache configuration settings, including DocumentRoot etc ... which you also haven't shared.

[cyberbaffled]

You, RodG, and DrByte have expressed the same exasperation regarding absence of specific information. Therefore, my reply to DrByte subsumes my reply to yourself.

[cyberbaffled]

You, Ihungil, and DrByte have expressed the same exasperation regarding absence of specific information. Therefore, my reply to DrByte subsumes my reply to yourself.

[cyberbaffled]

I will accumulate the information that Ihungil, RodG, and yourself have requested. However, since my post a more fundamental problem has afflicted my Plesk container, yielding an "Internal Server Error". I'm currently working with Odin (Parallels) to solve that. When I've restored Plesk I'll return to the issue the three of you have kindly responded to.

[cyberbaffled]

RESOLVED BUT NOT EXPLAINED. Returning to this double physical path log error issue, it occurred to me that the domain's physical path occurs in three individual places: Zen Cart config files, PHP ini, and Plesk webspace control panel. The three paths are identically stated, but the fact that there are three got me thinking in terms of some kind of mirroring. So I deactivated the Zen Cart configure files and sure enough, linking to the domain I no longer got the 404 (or 403; I forget which) but instead the very first Zen Cart page which begins an installation process. I proceeded through that process and installed a correctly functioning site. I installed using the database with the hundred or so products that were correctly displayed on the previous "hosted" site and I updated the files using the old files from that site (which I abandoned because of inadequate PHP memory). However, nothing I've been able to do makes the voluminous categorization and product descriptions recorded in the database available to the new install. I've synopsized this problem with a new post: "virtual server install catch-22".

[RodG]

RESOLVED BUT NOT EXPLAINED. Returning to this double physical path log error issue, it occurred to me that the domain's physical path occurs in three individual places: Zen Cart config files, PHP ini, and Plesk webspace control panel. The three paths are identically stated, but the fact that there are three got me thinking in terms of some kind of mirroring. So I deactivated the Zen Cart configure files and sure enough, linking to the domain I no longer got the 404 (or 403; I forget which) but instead the very first Zen Cart page which begins an installation process. I proceeded through that process and installed a correctly functioning site. I installed using the database with the hundred or so products that were correctly displayed on the previous "hosted" site and I updated the files using the old files from that site (which I abandoned because of inadequate PHP memory). However, nothing I've been able to do makes the voluminous categorization and product descriptions recorded in the database available to the new install. I've synopsized this problem with a new post: "virtual server install catch-22".

You are effectively moving to a new server. Follow the instructions found here:
http://www.zen-cart.com/content.php?...fferent-server

Cheers
RodG

[cyberbaffled]

You are effectively moving to a new server. Follow the instructions found here:
http://www.zen-cart.com/content.php?...fferent-server

Cheers
RodG

RodG, thanks again for your attention to this problem.