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.
Related
This question already has answers here:
How to fix "Headers already sent" error in PHP
(11 answers)
How do I get PHP errors to display?
(27 answers)
Closed 5 years ago.
I'm sorry if this question is considered as duplicate. I know what warning message come from but I want to know why in XAMPP (php 5.6) this error not showing but when I deploy in Ubuntu it show up. My development environment is in windows but I have to deploy web in linux. thanks
This is to do with your php.ini settings, and less to do with the environment's OS.
If you have display_errors on in your php.ini, then notices, warnings, errors etc will display on your page, the level of which depends on what error_reporting is set to.
For the best error logging experience, set error_reporting to -1, turn display_errors off, and set a custom error_log. Then in the terminal, type 'tail -f /path/to/error_log'. Your notices, warnings and errors will now scroll past in real time, without distorting your web page's display.
Your error happens because you are sending the request BODY before the HEADERS! Stopping the errors displaying will stop that.
Finally, look for whitespace at the start of your files, like a space before a <?php for example.
Xampp and similar software packs are bundled according to a developer's needs. If you are using a global web server, settings are high likely different to protect your server and sensitive data.
If you can download linux server's php.ini you can compare it with yours. For instance your local server's error_reporting is set to E_ALL then your linux server's ini could be different.
additionally you can check this link for best pratices
After some research, I found settings in php.ini output_buffering=4096 if I turn this off then in Xampp also showing error such session_start(): Cannot send session cache limiter.. like in linux, but I'm not really sure what is the use of output_buffering actually.
I am at an impasse, I am trying to turn on error reporting, which until recently was on.
This is a Development environment, completely separated from the Live Environment, The Set up is as follows.
Windows XP Home,
Apache 2.2,
MySQL 5.0 and PHP 5.2.6
It will run php no problem (Did a phpinfo to ensure that, even shows the mysql db connecting and both the local and master values for display_errors and display_startup_errors are showing as ON)
double checked the PHP.ini file and everything is on and the reporting level is set to E_ALL & E_STRICT
I even tried each of the two individually and rebooted inbetween each attempt.
I even tried setting error_reporting(-1) all to try and figure out where the php script is breaking..
I have looked at all the articles here about the display_errors either wont turn off or on and all point back at the PHP.ini file being the place to be for this. Given I have double checked the entire file for a possible reassignment of values, and there is none.
Is it possible the setting for error reporting is somewhere else as well?
This was resolved by looking beyond the usual scenarios and doing a scan of the affected drives, The Systems were firewalled and every security step was taken beforehand, Thankfully it was just the development environment and not the actual production server.
When all else seems to fail, check for viruses and malware in the end I do believe it was the babylon rootkit that was corrupting everything.
Thanks to Gordon, Lea and Sam_io for pointing out stuff that I did take but others may not think of, it was their pointing to the common causes that made me take the unusual steps of uninstalling the php and apache, neither were responsible for data in anyway so made it really easy to restore.
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'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
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).