So I have a strange and quite ambiguous question, which I can't seem to find even a vague answer to anywhere on the internet.
I've written a bunch of classes which facilitate a checkout process. The entire process works perfectly fine on my development server, but when I upload it to my client's server the code dies about halfway through (I can tell because I know which actions were and were not performed).
Debugging the code on my development server yields no warnings or errors (and rightly so, since it WORKS locally).
When running the website on the remote server, the code dies with '?>' as the only output. There's just way too much code to post in here, and I can't narrow it down to a specific line or even file, since I don't get any error output (and as I mentioned above, debugging it is of no use because it runs fine in the location for which I have access to a debugger).
So tldr; my question is: Is there any generic reason for why this ?> might be echoed to the page? The nature of this text suggests that it's terminating and for some reason printing the PHP ending terminator tag?
I have no clue. I understand that this problem is very hard to diagnose with what I've given you (and it's all I have to go on, as well) but even the slightest idea or suggestion would be infinitely helpful.
Thanks!
Sounds to me that you've used short open tags (<? or <?=), and it's disabled in your production environment.
You can find out if this feature is disabled by checking the short_open_tag PHP configuration option.
When in doubt, you can use some echo statements to help see just how far the code is getting. Perhaps you've got a quote mark out of place somewhere, causing the page to actually just print that part of the code. Or maybe you've already terminated the PHP somewhere, and then you write ?> again without needing to.
In terms of that being an actual error message though, I doubt it. My money's on some erroneous character(s).
You're using the url path / and the web server fetches index.html or something similar and not index.php. Try to directly access it.
I don't know if you are using zend, but they recommend not having a closing php tag in php only files (like classes) http://framework.zend.com/manual/en/coding-standard.php-file-formatting.html
Maybe deleting the closing php tag will allow you an error message that will lead to the real problem.
Related
I have a strange problem about an additional line above my PHP output.
I'm using the Smarty template engine for formatting my output on a webpage. After I programmed a API connection, I get a newline above the output of the added subpage. Of course, I googled this problem. What I've tried so far:
deleting all newlines at the end of all files and saving them again as UTF-8 without BOM
auto_prepend_file in php.ini is set to nothing
deleting the Smarty cache, turn caching off
One other strange thing is that if I test the program on my local PC (using XAMPP), I get the newline on every page. But when I test the system on my customers live server, only the affected API-page gets this newline. PHP warnings (E_ALL) appear above the newline.
Anyone got a idea that I haven't tried yet?
Anyone got a idea that I haven't tried yet?
Well, as we cannot see the code, and while this is not an ideal or robust testing scenario, in your case this might be useful.
In the files where you think the error may be, starting with the first file which runs, add something like exit('Here');.
Then run the code and see if the new line is there before the exit message, if not the issue is after that exit().
Delete the exit() from that file (make sure you do this!), then add it to the next file in the run order.
Run the code again, if no issue, repeat through the files in load order until the issue presents itself.
When the issue is present, you know the issue is between the code/file from the last time you exited and the current exit.
Examine that code carefully, the issue will be there.
Again, this is a little tacky and not a great test or debug method, but it can be helpful and sometimes necessary without a testing environment in place.
Also adding, as #Fred-ii- suggested, removing the ?> tags at the end of PHP files can help, if you have them (in fact you shouldn't have them there, this used to be a requirement many moons ago but generally just causes issues/headaches).
I know a lot of you guys are going to get angry, because it seems like so many questions have been based on this alone!
But, I have checked my PHP tags, all of which are using <?php..., PHPMyAdmin is installed on my server.
I just don't understand what's causing this? T_T
ftp://ftp.wagermatches.net/public_html/arithia/referral/test/home.php
I've tried changing the URL from ftp:// to...
http://ftp.wagermatches.net...
http://www.wagermatches.net...
http://www.wagermatches.net/arithia/referal...
I tried adding a .htaccess file to my server...
I'll be getting into my server classes two months from not, but I have no clue what's wrong. If you've got any idea, could you please point me to tutorials on how to do something and not just what I need to do? I am still learning. :( Thank you guys for your help!
Accessing the file through FTP will not cause it to be interpreted. Instead, you will get the file literally as you are now.
If you wish the file to be interpreted, you must first access it through HTTP and then configure your server to interpret it. How to do that depends on the web server you are using. As is, you’re getting an internal server error, which means that something is wrong with your server’s configuration. A good first step to diagnosing the problem would be to check the error log, as the internal server error page says.
Your server is not recognizing the php tags, so I think you do not have PHP installed. Note: I am not talking about PHPMyAdmin !!!
I have a question regarding rendering php files without php tags. Is there away to ignore the tags?
On a clients hosted environment our php script ran fine without the the opening and closing tags, however it died on our server. Just curious if there is a setting in the php.ini for this.
Thanks
It's considered good practice to omit the ending PHP tag in files that contain only PHP code. The beginning PHP tag is always required, however, as it is the only indication the interpreter has about what it needs to parse.
There are likely several ways to "cheat" this, such as running the tag-less code inside of an eval() statement, but there is arguably little reason to ever do this.
Oh my goodness. I never thought that I will need to ask you this. But unfortunately yes, I need to!
I have a PHP written script of my own that uses ffmpeg-php. And ffmpeg-php is a bastard. For some input it works ok, but for some it crashes my whole PHP and server throws Internal Server Error 500. I've tried several times to update ffmpeg-php, ffmpeg itself and so on, but when for some input it works in version 0.5 in 0.6 it wont work. And what i need is be sure that rest of the script will be processed correctly. And now it does not, because when it comes to run toGDImage() on movie frame I have Internal Server Error 500 and no feedback why from any source.
So for peace of mind of my users I decided that I need to isolate this part of script that messes with ffmpeg-php. I need a way to assure that if something will go terribly wrong in this part, it rest will go on.
Try catch does not work because this is not a warning, nor a fatal error, it is a horrible server-disaster. So what are your suggestions?
I think about putting this script into another file called ffmpeg-php-process.php and call it via HTTP and read result, if it is Internal Server Error 500 - I will know that it was not ok.
Or are there any other, more neat ways to isolate disaster scripts in PHP?
Ps. Don't write that I need to diagnose or debug or find the source of the error. I'm not a damn beginner and I'm not a ffmpeg dev to mess in it's code, I need to make my users safe now, and it's everything that i care now.
If you're getting a 500 error, it's because an exception of some sort is being thrown at a level lower than that of PHP itself. Unless your code is spinning into some kind of infinite loop or hitting a recursion limit (and especially since it worked with version 0.5), there's a good chance that ffmpeg or ffmpeg-php is crashing and taking the instance of PHP that launched it down with it.
Frankly, there's nothing you can do from PHP.
Your best bet would be, since you've already got access to the server, to write the script in question using a language like Python. There's a ton of ffmpeg python plugins, so you shouldn't have a difficult time setting that up at all. Call your Python script from PHP and pull in the output from a file. What this will do is isolate PHP from your script failing. It'll also get you away from ffmpeg-php (which, at least to me, seems like an unholy combination).
If you're dead-set on using PHP (which I don't recommend), you can launch another PHP script using php-cli from your outward-facing PHP script and do the work from there (as you would with Python). Again, I highly recommend that you avoid this.
Hope this helps!
You could spawn a new process containing your php-ffmpeg script. There are some functions to do that: proc_open() as instance.
The documentation has a not bad example about it:
http://php.net/proc_open
I have something similar going with a convoluted, large, bulky legacy php-email system I support. When it got apparent that the email system was becoming it's own beast, we split it off as its own virtual server entirely. There's no separation like PHYSICAL separation. And hey, virtual servers are cheap....
On the plus side, you can start, restart, and generally destroy the separate server with little affect on the rest of your code. It may also have improved backup implications (isolate media and logic) Since going this route, we've not ever taken the main application server down.
However, it does create a connection challenge as now rather than working local you're going to have your server talking to another separated by at the very least a bit of wire in the same cabinet (hopefully)
I am calling a PHP-Script belonging to a MySQL/PHP web application using FF3. I run XAMPP on localhost. All I get is this:
Connection Interrupted
The connection to the server was reset while the page was loading.
The network link was interrupted while negotiating a connection. Please try again.
There are a number of possible solutions ... depends on the "why" ... so it ends up being a bit of trial and error. On a fresh install, that's tricky to determine. But, if you made a recent "major" change that's a place to start looking - like modifying virtual hosts or adding/enabling XDebug.
Here's a list of things I've used/done/tried in the past
check for infinite loops ... in particular looping through a SQL fetch result which works 99% of the time except the 1% it doesn't. In one case, I was using the results of two previous queries as the upper and lower bounds of a for loop ... and occasionally got a upper bound of a UINT max ... har har har (vomit)
copying the ./php/libmysql.dll to the windows/system32 directory (Particularly if you see Parent: child process exited with status 3221225477 -- Restarting in your log files ... check out: http://www.java-samples.com/showtutorial.php?tutorialid=1050)
if you modify PHP's error_reporting at runtime ... in certain circumstances this can cause PHP to degenerate into an unstable state if, say, in your PHP code you modify the superglobals or fiddle around with other deep and personal background system variables (Nah, who would ever do such evil hackery? ahem)
if you convert your MySQL to something other than MyISAM or mysqli
There is a known bug with MySQL related to MyISAM, the UTF8 character set and indexes (http://bugs.mysql.com/bug.php?id=4541)
Solution is to use InnoDB dialect (eg sql set GLOBAL storage_engine='InnoDb';)
Doing that changes how new tables are created ... which might slightly alter the way results are returned to a fetch statement ... leading to an infinite loop, a malformed dataset, etc. (although this change should not hang the database itself)
Other helpful items are to ramp up the debug reporting for PHP and apache in their config files and restart the servers. The log files sometimes give a clue as to at least where the problem might reside. If it happens after your page content was finished it's more likely in the php settings. If it's during page construction, check your PHP code. Etc. etc.
Hope the above laundry list helps somebody someday ... probably myself when I run into it again and come back here looking for "how the heck did I fix it last time?" ... :)
It's possible that your script could be caught in an infinite loop. If that doesn't apply, then I'd check the error logs like TimB suggested.
It sounds like the PHP script you're calling is failing without returning a valid response. Depending on the level of logging that you have set up, this should generate an error in the Apache logfile, which will give you some idea of the problem. I'm not familiar with XAMPP, but you should be able to find out where the logs are, and look for an error that occurred at the time you made your request to the PHP script.
copying libmysql.dll to apache\bin folder may help you overcome this strange error
I solved this problem Upgrading the xampp\php\ext\xdebug\php_xdebug.dll
(changed to php xdebug v.2.0.5-5.3-vc9 )
I had the same problem and this is what i did.
I issued the http get command through php cli script, and as it turns out I had declared one class twice somewhere.
By the way , i use AMPPS on an mac
Hope this helps some one!
Try doing the request with Firebug enabled and see what info you can get out of that; I always find that using wget is helpful for seeing the raw HTTP interaction without worrying about Firefox's UI elements interfering.
If you are using certificates for ssl in Windows 2008 Server(iis 7) from old selfssl tool(iis 6), that is the problem. Sometimes Microsoft releases patches which can destruct all these old certificates. The solution is to generate them again.
copying libmysql.dll to apache\bin folder may help you overcome this strange error
Indeed this helped me to solve this problem
The connection to the server was reset while the page was loading.
Incase the issue is not working this did the trick for me.
1. I got a new zip directory for PHP and connected it with apache
2. I searched for the libmysql in the new php and inserted this to the apache/bin
its this libmysql.dll that is needed there and not the one form mySQL/bin.
ok at least thats the one that worked.
I experienced a very similar issue - which doesn't apply to the person who asked this question - but may be of help to others who are reading this page...
I had an issue where in certain cases PHP 5.4 + eAccelerator = connection reset. There was no error output in any log files, and it only happened on certain URLs, which made it difficult to diagnose. Turns out it only happened for certain PHP code / certain PHP files, and was due to some incompatibilities with specific PHP code and eAccelerator. Easiest solution was to disable eAccelerator for that specific site, by adding the following to .htaccess file
php_flag eaccelerator.enable 0
php_flag eaccelerator.optimizer 0
(or equivalent lines in php.ini):
eaccelerator.enable="0"
eaccelerator.optimizer="0"