Hello, I'm new to WebDeveloper.com. Besides being my hobby, I'm the Webmaster for a church, and it with that site that I'm having problems.
We use the WebCalendar PHP application for our organization's calendar on our Web site, the only real use of PHP we have. The script has been working fine for years, although I did upgrade it to version 1.2.3 when we moved to a new server about a year ago.
Suddenly, some pages in the application are having problems. The known problematic pages are: edit_entry.php and admin.php The exact message varies on the Web browser: In Firefox, the browser will attempt to download a .php file. In Chrome, a Chrome error page loads that says "Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data.", in IE8 an IE error page loads with the message "Internet Explorer cannot display the webpage"
The problematic pages were working fine the last time they were accessed, several weeks ago, and no new packages or updated packages have been installed. According to phpinfo() the server has PHP Version 5.2.10, this is an Apache 2.2.3 server running on CentOS 5, with Plesk as the management tool given to us by GoDaddy with the hosting package. We have a virtual server so GoDaddy will not help us in any way, but I at least have root access.
At first I thought it was a problem with Apache, so I restarted httpd. That didn't do anything. I've tried creating a new database and pointing a fresh download of the latest version of the Web Calendar script to it. While it set itself properly, the same pages are having the same problems. There are no relevant messages in /var/log/httpd/httpd.
I thought that this sort of problem was due to a problem on the server rather than with the application, so I thought of posting here before trying on the applications's SourceForge forum.
The mention of Firefox trying to download the .php file makes me think that the Apache config is messed up somewhere -- possibly just that directory or its parent directory via a .htaccess file. A quick test would be to put a simple "hello world" type .php file in the same directory as the file that fails, and see if you can access it OK via the browser, something like:
echo "If you can read this, then PHP is running okay here.";
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
The mention of Firefox trying to download the .php file makes me think that the Apache config is messed up somewhere -- possibly just that directory or its parent directory via a .htaccess file. A quick test would be to put a simple "hello world" type .php file in the same directory as the file that fails, and see if you can access it OK via the browser
I just tried it, the new file displays the results of phpinfo() correctly. This isn't surprising, as the files that fail are in the same directory as most of the rest of, working, files.