How do you debug PHP scripts?
I am aware of basic debugging such as using the Error Reporting. The breakpoint debugging in PHPEclipse is also quite useful.
What is the best (in terms of fast and easy) way to debug in phpStorm or any other IDE?
How do you debug PHP scripts?
I am aware of basic debugging such as using the Error Reporting. The breakpoint debugging in PHPEclipse is also quite useful.
What is the best (in terms of fast and easy) way to debug in phpStorm or any other IDE?
Manual debugging is generally quicker for me -
var_dump()
anddebug_print_backtrace()
are all the tools you need to arm your logic with.In a production environment, I log relevant data to the server's error log with error_log().
PHP DBG
The Interactive Stepthrough PHP Debugger implemented as a SAPI module which can give give you complete control over the environment without impacting the functionality or performance of your code. It aims to be a lightweight, powerful, easy to use debugging platform for PHP 5.4+ and it's shipped out-of-box with PHP 5.6.
Features includes:
See the screenshots:
Home page: http://phpdbg.com/
PHP Error - Better error reporting for PHP
This is very easy to use library (actually a file) to debug your PHP scripts.
The only thing that you need to do is to include one file as below (at the beginning on your code):
Then all errors will give you info such as backtrace, code context, function arguments, server variables, etc. For example:
Features include:
Home page: http://phperror.net/
GitHub: https://github.com/JosephLenton/PHP-Error
My fork (with extra fixes): https://github.com/kenorb-contrib/PHP-Error
DTrace
If your system supports DTrace dynamic tracing (installed by default on OS X) and your PHP is compiled with the DTrace probes enabled (
--enable-dtrace
) which should be by default, this command can help you to debug PHP script with no time:So given the following alias has been added into your rc files (e.g.
~/.bashrc
,~/.bash_aliases
):you may trace your script with easy to remember alias:
trace-php
.Here is more advanced dtrace script, just save it into
dtruss-php.d
, make it executable (chmod +x dtruss-php.d
) and run:Home page: dtruss-lamp at GitHub
Here is simple usage:
sudo dtruss-php.d
.php -r "phpinfo();"
.To test that, you can go to any docroot with
index.php
and run PHP builtin server by:After that you can access the site at http://localhost:8080/ (or choose whatever port is convenient for you). From there access some pages to see the trace output.
Note: Dtrace is available on OS X by default, on Linux you probably need dtrace4linux or check for some other alternatives.
See: Using PHP and DTrace at php.net
SystemTap
Alternatively check for SystemTap tracing by installing SystemTap SDT development package (e.g.
yum install systemtap-sdt-devel
).Here is example script (
all_probes.stp
) for tracing all core PHP static probe points throughout the duration of a running PHP script with SystemTap:Usage:
See: Using SystemTap with PHP DTrace Static Probes at php.net
Xdebug, by Derick Rethans, is very good. I used it some time ago and found it was not so easy to install. Once you're done, you won't understand how you managed without it :-)
There is a good article on Zend Developer Zone (installing on Linux doesn't seem any easier) and even a Firefox plugin, which I never used.
I use Netbeans with XDebug and the Easy XDebug FireFox Add-on
The add-on is essential when you debug MVC projects, because the normal way XDebug runs in Netbeans is to register the dbug session via the url. With the add-on installed in FireFox, you would set your Netbeans project properties -> Run Configuratuion -> Advanced and select "Do Not Open Web Browser" You can now set your break points and start the debugging session with Ctrl-F5 as usual. Open FireFox and right-click the Add-on icon in the right bottom corner to start monitoring for breakpoints. When the code reaches the breakpoint it will stop and you can inspect your variable states and call-stack.
Usually I find create a custom log function able to save on file, store debug info, and eventually re-print on a common footer.
You can also override common Exception class, so that this type of debugging is semi-automated.