Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

PHP script downloads instead of executes

Status
Not open for further replies.

rpg121

Programmer
Mar 14, 2001
89
US
I wrote a PHP script utilizing PEAR, and one if its modules specific for exporting to an Excel file. Everything PEAR and module related works flawlessly and is set up correctly.
The script itself is approximately 7-8000 lines long.

Basically my issue is this: it seems that as soon as I get to some magic amount of code in my script, the browser stops executing the script as it is supposed to, and rather, attempts to download the .php file instead.

I've realized that it doesn't matter what modules of my script that I comment out. I can comment out the first and third module, the third and fourth module, the tenth module, etc, it seems that once I pass some arbitary amount of code, the script won't run anymore.

I've already tried increasing memory_limit in the php.ini file from 8M to 16M and 24M with no visible difference. I've tried using ini_set("memory_limit", "16M"); at the beginning of my script, and this also seems to result in no visible difference.

Does anyone have any ideas as to what my problem might be? Anything anyone can suggest is greatly appreciated. Thanks in advance.

Josh Bart
MCP, A+, Network+
 
usually the script downloads because php has crashed out in the load process (i.e. when the script is called if php is a cgi or when the web server is started if php is a sapi).

this can happen if an extension is supposed to load at startup but php cannot find the files necessary for it to do so. A common culprit is mysql.

does a simple call to php work?

Code:
phpinfo();
 
Well, I wasn't totally sure in what circumstance you wanted me to run that piece of code, so I did the following:
- I ran simply that piece of code between <?php ?> and nothing else, and yes, this call to php works.
- I put the function call at the beginning of my script when I had enough code commented out to make it run, and yes, this call to php works. I recieved a page with the current information about the state of PHP.

If the script causes a crash out of the load process, what can I do to prevent that? I imagine there are plenty of scripts out there that are larger than mine, but if the memory_limit is not the issue, I can't think of what else could be. It might be helpful to add that I cannot make the code anymore efficient than it already is.

Thanks for anything you can tell me.


Josh Bart
MCP, A+, Network+
 
i had meant the first context, but either will do.

i would not have thought a script of only 7-8k lines would cause a problem with memory. and if it did, i would expect php to bung something in its logs for you to check. have you checked the logs?

can you provide some details about:

1. your platform (OS/WS/PHPvx etc)
2. what PEAR classes you are trying to use other than the spreadsheet class?
3. do you really need to use the spreadsheet class? or can you achieve the same goal another way (maybe a brief description of your goal would be helpful)?
4. if you are using the spreadsheet class, is it possible that the file that you think is the script being downloaded is, in fact, the completed spreadsheet? if no file name is provided for a download, your browser implies that the file it is receiving is called the same thing as the page it is looking at. the way to tell this is to download the file, change the extension to xls and see whether it opens up nicely.
 
I did think of checking the error log, and it seems the log is approximately a gigabyte large. I do not have root access to this server, and I am doing this as contract work for another organization, so unfortunately the state of the error log is not something I can really do anything about.

1) Mac OSX Darwin professorx 6.8/Apache 1.3.26/PHP Version 4.3.3
2) I am only using this single class from PEAR, it was for a specific purpose.
3) I am exporting information from their database to an excel report. Unfortunately, after discussion with them, pdf and other methods were deemed unfeasible and I've been through hell getting PEAR installed to perform this. I'm actually completely done the script too, it took me a month to do it and now that I'm done, I just need to find a way around this problem.
4) Unfortunately this isn't the issue I don't think. I name the file at the beginning of the script and it comes out as AnnualReport - Employee.xls, and my script is excel-test.php. I attempted seeing if when it downloads the excel-test.php file its actually an xls file with the wrong extension, and it isn't.

Do you think perhaps its an overload on mySQL? I overwrite the same query variable every time with the next query when I'm done with it.

Josh Bart
MCP, A+, Network+
 
have you tried installing the script and tables on another computer (with perhaps a more up to date installation of php/mysql/apache) to see whether the same behaviour is exhibited?
 
Thanks for all your help jpadie...I appreciate it.

I spent the last day getting PHPmyAdmin and the whole php/apache/mysql/pear package installed on a local server I have here, to test it in a different environment. I migrated the database and got everything set to go. And of course, it generates the entire script flawlessly, and produces an excel file the way I've been trying to get it to generate the entire time.

So in other words, what parameters of my local installation should I be looking at playing with in order to figure out what's limiting my script on the original server?

Josh Bart
MCP, A+, Network+
 
first step is to upgrade your installations at the office end. in the php 4.x tree your installation should be at 4.4.7 at the moment.

i'd personally recommend moving to apache2 as well.

compare the outputs from phpinfo() on each computer to see whether there are any obvious deltas/gotchas between the two installations.

if you are running on mac there is a neat application that runs in userspace called MAMP that you could try out to see whether it is something at the OS level causing problems.

and, of course, run a ./pear upgrade-all on your pear libraries.
 
Well, my server has PHP 5.2.1, and Apache2. The client server has PHP 4.3.3 and Apache 1.3. I'm considering asking them to update to the same versions I have here on my own server because I know it generates the file properly, but I ran into some $_SESSION variable issues. I had simply copied over the html/php files from the web directory into the exact same relative locations, and it wouldn't process my PHP the same as the client server had.

I basically had to cut out the session variables that dealt with entirely. The connection between mySQL and PHP was fine, but it didn't seem to want to accept my session variables containing the ID and password that the user was logging into the system with. I basically had to hardcode the actual userid and password into the script to bypass that and get the Excel file generating properly. This is clearly unsafe in a production environnment, but I can get away with it temporarily on a local dev server to try and fix my Excel issues. I'm just concerned it'll pop up as an issue if I have my client updates the PHP version...

Does PHP 5.2.1 process SESSION variables differently than older versions such as 4.3.3 or something along those lines?

Josh Bart
MCP, A+, Network+
 
Also, would upgrading any of these packages create a risk of losing all the information they currently have stored in their database?

Josh Bart
MCP, A+, Network+
 
there was a change to password handling between mysql 4.1.1 and those previous (i think it was at this point). i do not think that this is your issue though.

if you just copied your php.ini across then likely as not sessions won't work as the session directory specified in the php.ini may either not exist or not have the right sessions.

there is no difference between later php version in session handling (that I am aware of)

upgrading php and apache (discretely) should have no impact on any data stored in a database. in any event a prperly managed system will have regular snapshots and backups of the database so you should not have to worry unduly about data loss. It goes without saying, I assume, that the taking of backups is only half the battle: a good backup strategy should involve a regular exercise of restoring data to a pseudo-live environment.
 
I didn't copy the php.ini across....simply the web front end (all the HTML/css/PHP files that you view as a user).

I'm going to have to talk to the administrator of the server and get him to update his installations, but barring this, I'm hoping to continue trying to find a solution in another manner. You suggested comparing the phpinfo() outputs to look for discrepancies. There are plenty of differences in certain areas, but I'm not really sure what I'm looking for.

I noticed the read_buffer_size value was approximately double on my server than on the client server. I've pasted the results of both phpinfo()'s into an HTML file, and put them on my webserver:

If you have a few minutes, can you take a look and tell me if anything jumps out at you as problematic?

Your continuing support is appreciated.



Josh Bart
MCP, A+, Network+
 
thanks, i have had a quick look.

a couple of thoughts (the code provided is in lieu of editing php.ini directly):

1. turn off output buffering on the client server
Code:
ob_end_flush();

2. for debugging, turn on error display and startup errors
Code:
ini_set("display_errors", "On");
error_reporting(E_ALL);
3. no value for memory limit appears to be set on the remote sever. i do not know what effect this will have.
4. i checked the referer in your remote php.ini and got redirected all over the place. is there some server module that could be getting in the way of your excel script?

remember that you need to restart the web-server every time that you edit the php.ini file.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top