I'm playing with a PHP weblog application using a shared hosting service, as a part of my PHP learning process. The service provider has a typical LAMP environment with remote ssh access.
Vim has been my best friend in exploring the PHP code. However, I found it sometimes hard to trace stuff in the code in case of error. For example, sometimes I visit a page and I got a blank response with no error messages whatsoever. How should I go about debugging this? Any tools that will be helpful?
My experience has been mainly in C/C++, Perl and some CGI programming. So PHP is a very refreshing experience with me :-)
In case it matters, the application I'm playing with is Lyceum, and I don't have much choice on the LAMP environment itself.
EDIT: Free software tools preferred :-)
I assume your hosting provider configured their PHP installation with display_errors turned off, which is a good thing. That's why you're seeing blank pages. So the most practical solution at the moment would be to have an .htaccess file which turns it on:
php_flag display_errors on
You'd also need error_reporting to an appropriate value:
php_flag error_reporting "E_ALL | E_STRICT"
Anyway, remember to turn this off before letting users access your web site.
For advance debugging I'd recommend Xdebug installed on the server with Eclipse PDT or NetBeans IDE with PHP support as your editor. They both are good clients for debugging, but I really doubt any provider would install Xdebug on their live servers. So you're pretty much left with logging functions if you don't have a development environment.
Getting access to your own local development environment (via XAMPP, for Example) would let you install XDebug.
PhpEd would let you debug it, but also Eclipse's PDT Environment.
Error Tracing and logging via editing php's ini config file is a good way as well, specially if you can manage it to log information. Also, consider adding trace statements and using FirePHP, for example.
Personally, I would recommend jEdit rather than vim. The SFTP plugin allows you to edit (well, load and save) the PHP documents directly on the server and the PHPParser plugin will give you some error recognition.
Also, if you get a blank page with no error messages, chances are hight that those messages are just hidden from you. Make sure that error reporting is enabled, either in your config or in your code like this:
// Report all PHP errors
error_reporting(E_ALL);
If error reporting is enabled and you still don't see any messages, either enable logging or enable output to the browser.
If you get a blank page, it's probably because of a fatal error, with display_errors turned off. By default, PHP will log errors to Apaches error-log, but you can also configure it to log errors to a separate log.
For debugging, you may also want to look into Xdebug. This extension can do a lot of things, including interactive debugging. You'll need a client to use the debugger, but there is a plugin for vim that does this.
Try NuSphere PhpED
Related
My php code is in the hostgator server and since I have to write a few scripts I don't have to install the wamp/lamp server.
I did a bit digging and found extensions namely PHP console. I added it and tested once, it showed me the line number of the errror.
But after a few hours when I tested the extension it is not working anymore for the same script and the same error.
I also tried another popular extension called Xdebug helper. But that also seems to be not working.
To test I have removed a semicolon in my working script and the link is : http://arqamahmad.com/music_app/getmusic.php
PS : I am using a shared hostgator server and I have done my research on the .htaccess and php.ini files. Nothing is helpful. The PHP console extension was the best but there seems to be some problem to that.
Answer : I had to add a php.ini file inside public_http making allowing the php debug mode on then only it the extensions work.
For Firefox, there is FirePHP (http://www.firephp.org/) in combination with Firebug. There is a similar extension for Chrome, but I haven’t tested that (https://github.com/itsgoingd/clockwork-chrome).
The general thing is that you need to somehow transfer your error messages from PHP back to the client. If you don’t want to use a browser extension for that, you can also use an approach chosen by many frameworks (e.g. Symfony): add an admin module in your page, where the error messages are displayed (you need to intercept errors on the servers for that, by registering a custom error handler).
Edit: This of course requires PHP to output error messages at all, which depends on (among others) the php.ini settings like error_reporting, which need to be set to a level that the errors you desire for reporting will trigger the error handler functions.
Concerning your remark about Xdebug: to use Xdebug helper, Xdebug (a PHP extension for debugging) needs to be available on the server, which it usually is not on production systems.
Since php is executed on the server side, no browser add-on will help you. You need to add a few lines of code to the php file to show the errors.
Here's a link for you: https://stackoverflow.com/a/21429652/6735510
I actually solved this problem eventually, but it took so long that I thought I would post the question I was going to post a few hours ago so others that might happen to run into it would not find themselves in the same boat of wasting 5 hours trying to solve a simple problem.
I was trying to get a version of Zend running under an installation of lighttpd with a scaled down php and Zend core framework running through fastcgi but the problem was that any time I confronted an error, it was not reporting in the browser and was not showing up in any of the log files. (the actual platform was android which added to the confusion, but the problem turned out to be a lighttpd/zend configuration issue non-specific to the platform)
Since I wasn't sure at which layer the logging was failing, I tried everything from modifying the error/logging settings in the lighttpd.conf, fastcgi values in both the lighttpd and php configuration files and setting various logging parameters in php.ini but none of them produced any error messages in the logs even though the zend page in question was saying 'Application Error' and little else.
What I ended up discovering was that all of the examples I had run across of setting up the lighttpd.conf showed good examples on how to set up the fastcgi, how to set the server parameters, how to configure php, etc. and even how to translate typical apache .htaccess files used for Zend including rewrite rules into something similar in the lighttpd.conf
What none of them did make obvious was the setting of any required Zend environment variables.
Under a default zend site configuration such as you might find on the Zend help pages, they generally set up some kind of bootstrap.php along with a corresponding application.ini file. In the examples I saw most often and therefore the ones I followed, they included the ability to configure multiple application environments such as production, testing, development, etc. This was controlled on the server in question by setting the environment variable APPLICATION_ENV to include the environment.
In my particular set up, the 'production' environment in the example I used was the default and turned 'off' all php, exception and other error logging for the production environment to avoid users seeing ugly errors in a production setting. Since this ran after Zend started, it over-rides anything previously configured in lighttp.conf or php.ini.
Even though this has been common in most of the exmaples I've seen on configuring a zend server, none of the examples I saw for lighttpd showed setting this variable and since I was focused on the 'layers' involved, it slipped my mind.
So setting the environment in the lighttpd.conf to include development environment made my errors visible again:
setenv.add-environment("APPLICATION_ENV"=>'development')
Now I have a functional zend LAMP server implementation running on my cell phone using bitweb for android! Thanks Andi!
I'm in a non-ideal situation where I have to debug a website a live website running PHP5.4 on a LAMP stack.
After enabling XDebug in php.ini and setting display_errors to true, I get nicely formatter HTML output for bugs.
However, I'd like to be the only person to be able to see these bugs.
I understand there is some sort of extension for IDEs that allow you do that, but I'm a bit confused about the whole thing.
I looked into xdebug.remote_host but couldn't get it to work.
Is there a way to make errors show up only to requests coming from my IP address?
Thanks!
The main thing you want to do has nothing to with XDebug... turn display_errors off. It sounds counter-intuitive but what display_errors actually does is configure whether or not the errors should be sent to STDOUT or STDERR from PHP.
If you turn off display_errors, you can then configure PHP to log them instead. Then, just SSH into your box and tail that log file while you track down the problem.
I have just done a fresh install of the latest stable PyroCMS version on my web server. I now can hardly use the site due to PHP errors pertaining to session data. "Cannot modify header data."
Why would the CMS run without error on MAMP but not on the live server?
I had the same problem. Looks like PyroCMS is having trouble with php 5.4 which is what MAMP is using by default. Try switching your php version to 5.3.
Thread with same issue
Both the server must be having different configurations with regards to displaying of errors.
Either place error_report('E_ALL'); at the initial page (most probably index.php) or find out how you can disable displaying errors in your CMS (there must be some configurations).
Or trying putting off the display_errors directive in your php.ini file.
You should have PHP set up so that you spot errors on your local machine before they make it to production. It seems like you currently have this the wrong way around!
To fix it, your dev install of MAMP should have error_reporting set to E_ALL in php.ini and display_errors set to 'on'. Your production webserver should have display_errors set to 'off' at the very least (check that they are sent to the log files instead - you don't want to lose them) and you may also wish to reduce error_reporting to E_ERROR.
Setting it to E_ERROR will keep the logs on the production server clean so that you can spot big problems when they happen. You may especially want to do this if you are using a library or CMS that produces PHP notices or warnings, which you can't do anything about. Alternatively, you may wish to keep everything going to the logs with E_ALL and systematically sort out all the stuff that shows up, however, you will need to be using code that you can modify without making it awkward to upgrade. This can be very useful because sometimes the environment on the production server differs from your local one and things can genuinely break for reasons you don't expect.
Incidentally, the 'cannot modify header data' error suggests that this is not a stable version of PyroCMS, whatever it says on the tin!
Thanks for the help guys. I eventually found the problem which was to do with sessions. I had session.autostart=on on the live server. Turning this off fixed the problem.
I am thinking along the lines of replicating a web hosts PHP setup environment for offline local development. The idea is to parse the output of phpinfo() and write any setup values it contains into a local php.ini. I would imagine everything ism included in phpinfo and that certain things would only be specific to the environment it is running on (paths).
You will probably get more usable results from ini_get_all()
http://us.php.net/manual/en/function.ini-get-all.php
You could then traverse the associated array to reconstruct an ini file without the hassle of interpreting the output of phpinfo()
It's quite likely to just be a stock install. Even then, I'd still want to make the local development environment subtly different to the live php.ini, to ensure that it showed all errors that were being produced (as opposed to hiding, or just logging them on the live site).