News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Derick Rethans:
Xdebug 2.3 Improvements to Debugging
March 25, 2015 @ 09:13:34

In the latest in his series covering some of the improvements in the latest Xdebug release, Derick Rethans has posted this new article detailing some of the performance enhancements related to remote debugging that come with this new version.

This is the fourth article in a series about new features in Xdebug 2.3, which was first released on February 22nd. In this article we are looking at the improvements towards "remote" debugging.

The updates include showing the values of user-defined constants, being able to set an exception breakpoint on all exceptions and additional features around debugging the exceptions themselves. The output now includes the exception's error code and which exception the flow was broken on (though in his example of PHPStorm, the IDE won't report that information back). The last change he mentions is a change that reverts the output to a log if it can't write to a socket (usually SELinux related).

0 comments voice your opinion now!
xdebug performance improvement remote debugging version release

Link: http://derickrethans.nl/xdebug-2.3-debugging-improvements.html

Derick Rethans:
Xdebug 2.3 Munging errors
March 10, 2015 @ 09:15:47

Derick Rethans has posted a new part of his series looking at the improvements that came with the latest Xdebug release (v2.3). In this new article he talks about error handling and intercepting them to make debugging simpler.

One of the first features I added to Xdebug was the interception of error messages, so that it was possible for me to include a stack trace. Xdebug 2.3 has a few additional settings to control the behaviour of interception.

He covers the addition of three new settings: xdebug.halt_level, force_display_errors and force_error_reporting. Each of these is designed to provide you with customizable error reporting. Each setting comes with an example of its configuration and how it modifies the output of the resulting errors.

0 comments voice your opinion now!
xdebug error haltlevel force reporting display debugging tool

Link: http://derickrethans.nl/xdebug-2.3-error-munging.html

Derick Rethans:
Xdebug 2.3 Enhanced xdebug_debug_zval()
March 03, 2015 @ 10:50:41

Derick Rethans has posted another article about Xdebug and some of the changes made in the most recent release, version 2.3. In his previous post he talked about the improvements to var_dump and in this one he shares updates to the xdebug_debug_zval handling.

xdebug_debug_zval() has been around for quite some time, to provide correct information about how PHP internally stores a variable. Unlike PHP's built in debug_zval_dump() function, it does not modify the variable information that it tries to show. This is because instead of passing in a variable, you pass in its name. Passing a variable into a function, can modify the various parameters that are associated with this variable, such as the is_ref and refcount fields.

He includes a bit of background about what the function is used for and then shows the difference it has in 2.3: the ability to handle nested data structures including property dereference support. He includes a few code examples showing the use of the function and the output it would generate for both an array and an object.

0 comments voice your opinion now!
xdebug enhanced xdebugdebugzval array subarray object dereference

Link: http://derickrethans.nl/xdebug-2.3-xdebug-debug-zval.html

Derick Rethans:
Xdebug 2.3 Moar var_dump()
February 27, 2015 @ 09:58:40

Derick Rethans has a new post to his site starting a series of posts about the new features of Xdebug 2.3. In this new post he talks about an improvement that's been made to the output provided by var_dump with more information than before.

One of the new features relates to one of the first things that I added in the original Xdebug: making the var_dump() output "pretty". Xdebug replaces PHP's standard var_dump() function with its own version, as long as the xdebug.overload_var_dump setting is not set to 0. [...] Xdebug 2.3 enhances the overloading of var_dump() with the inclusion of the file name and line number where var_dump() is called at. This has been a long standing feature request.

He provides a few sample screenshots comparing the old and new output formats and mentions another handy setting, xdebug.file_link_format, that makes the resulting filename a link in a browser and lets you customize the format.

0 comments voice your opinion now!
xdebug vardump overload file path information output improvement release

Link: http://derickrethans.nl/xdebug-2.3-overload-vardump.html

Derick Rethans:
Code Coverage Finding Paths
January 07, 2015 @ 09:33:13

Derick Rethans has continued his series looking at the code coverage handling that XDebug and PHPUnit make available, allowing you to find the spots in your code not tested much easier. In this new post he talks about a new feature coming to the XDebug tool - branch and path coverage.

Picking up from where we left last time, in this second article we will look at some upcoming functionality in Xdebug. Sebastian has been pressuring me for years to add branch and path coverage to Xdebug, with issue #1034. In the post I will show you what "branch and path coverage" is, and how it helps.

How does this new type of coverage differ from the current functionality? Derick goes on to explain the difference via a simple example (and its resulting coverage). In the first example, using the XDebug available today, shows a fully tested function despite not all paths being testing correctly (a false coverage report). He gets into the "under the covers" changes he's made including how the opcodes are reported and changes he's made to the VLD to make it handle the branching smarter and make coverage more than just a "lines covered" metric. He shows an updated graph of the new coverage/branch flow and what a resulting coverage report might look like with the new "Paths" reporting.

0 comments voice your opinion now!
code coverage phpunit xdebug report paths vld lines

Link: http://derickrethans.nl/path-branch-coverage.html

Derick Rethans:
Code Coverage The Present
December 02, 2014 @ 11:54:01

Derick Rethans has posted the first in a series focusing on the Xdebug tool and the code coverage functionality it can provide via PHPUnit's testing. In this first post he catches the reader up on the current state of things and what all the Xdebug tool can do.

Since ages Xdebug has provided code coverage support for PHPUnit, a way to show which lines are covered by your test cases. But I never really wrote about how it works. A recently filed bug prompted me to write this post, as well as a follow up post on Code Coverage's future.

He starts off with the early days of Xdebug, how it hooked into the Zend Engine (that powers a lot of PHP behind the scenes) and when it was triggered. This came with its own set of problems so Xdebug was updated to overload some opcodes. He talks about how it can calculate the unused lines and determines which lines can be covered in the code coverage results. He provides some example code showing the execution of the coverage report on a simple function and try/catch handler, complete with the HTML output of the results.

0 comments voice your opinion now!
xdebug codecoverage phpunit coverage history functionality opcode

Link: http://derickrethans.nl/code-coverage.html

SitePoint PHP Blog:
How to Install Xdebug with PHPStorm and Vagrant
July 08, 2014 @ 11:32:42

The SitePoint PHP blog has a recent post showing you how to get Xdebug installed and working with PHPStorm through a Vagrant installation. The Xdebug tool provides additional debug information on top of what PHP natively includes in its own error handling.

Xdebug is a PHP extension which allows you to debug and profile your code, view detailed and readable stack traces when errors happen, and much more. For a detailed walkthrough, see Shameer's post. If you're completely unfamiliar with it, you would do well to first install it following the procedures below, and then refer to the post linked above for a breakdown of everything Xdebug can do for you and your apps. In this tutorial, we'll set up Xdebug with PHPStorm for Vagrant hosted PHP apps.

His guide doesn't actually include the installation of Xdebug via Vagrant as the VM he's chosen (Vagrant Homestead) already has it installed. If you need instructions on that, check out this other tutorial. He shows you how to enable it in Homestead and configure the extension to connect back out to your waiting PHPStorm client. He then moves on to the client side and shows how to connect it to the server through PHPStorm's own debugger configuration. He includes a bit of sample code to test the connection (a Laravel route) and checking that the breakpoint handling works as well.

0 comments voice your opinion now!
xdebug phpstorm vagrant homestead install configure

Link: http://www.sitepoint.com/install-xdebug-phpstorm-vagrant/

Derick Rethans:
Dead Code
June 18, 2014 @ 10:49:56

In his latest post Derick Rethans talks about something that plagues every project, PHP or otherwise, after its grown to a large enough size: dead code. He's been asked why his Xdebug tool finds this code in places where people don't expect, so he figured he'd answer it once and for all.

The explanation for this is rather simple. Xdebug checks code coverage by adding hooks into certain opcodes. Opcodes are the building blocks of oparrays. PHP converts each element in your script - main body, method, function - to oparrays when it parses them. The PHP engine then executes those oparrays by running some code for each opcode. Opcodes are generated, but they are not optimised. Which means that it does not remove opcodes that can not be executed.

He gets down to the opcode level and shows some output from vld on how things are being executed (and what's not). Using a simple "foo" function example, he shows the execution flow and how the "branches" of executions work through the code. In his case, the "dead code" marker is coming from the line with a closing brace from an "if" statement. He points out that it entirely depends on the lines executed as to what is marked as "dead code".

0 comments voice your opinion now!
dead code xdebug path flow branch vld

Link: http://derickrethans.nl/dead-code.html

SitePoint PHP Blog:
Debugging with Xdebug and Sublime Text 3
February 28, 2014 @ 11:10:53

The latest post from the SitePoint PHP blog, a new tutorial by Peter Nijssen, shows you how to get started with Xdebug and Sublime Text 3 to debug your PHP applications.

Debugging - we all do it a lot. Writing code perfectly the first time around is hard and only a few (if any) succeed at it. More than a year ago, Shameer wrote an article on SitePoint about how you can debug your application using Xdebug and Netbeans. In this article, we are going to have a look at how we can debug using Xdebug in combination with Sublime Text.

He assumes you already have Xdebug installed (and links to the instructions for those that don't) and helps you configure it to find your listening editor. Back in Sublime, he shows you how to use the package manager to install the Xdebug client and configure the current project to use it. He shows how to set up breakpoints and view the stack/watch data when the point is hit.

0 comments voice your opinion now!
debug xdebug sublimetext remote tutorial package client

Link: http://www.sitepoint.com/debugging-xdebug-sublime-text-3/

Dutch Web Alliance:
The definitive remote debug and unittest with PHPStorm guide part 6
January 09, 2014 @ 11:20:28

The Dutch Web Alliance has posted the sixth part of their series helping you debug/unit test your applications with PHPStorm and Xdebug. In this new post they focus on working with command-line applications.

So there is already a lot covered: debugging web applications, testing your units, getting code coverage. But one thing that remains is trying to debug your command line applications. Even today more and more applications aren't built for primarily the web, but for other purposes or many web frameworks have some kind of "console" component which allows you to easily create command line tools that deals with asynchronous handling of data, or just mere as cronjobs.

They walk you through the steps you'll need to be sure everything it set up correctly for PHPStorm to catch the debug calls:

  • Ensuring Xdebug is active
  • Validating that PHPStorm is listening for incoming requests
  • Configuring Xdebug on where to connect
  • Setting up the mapping for paths inside PHPStorm
0 comments voice your opinion now!
xdebug phpstorm unittest debug tutorial series part6 commandline

Link: http://dutchweballiance.nl/techblog/the-definitive-remote-debug-and-unittest-with-phpstorm-guide-part-6/


Community Events

Don't see your event here?
Let us know!


example laravel5 introduction library php7 list community series extension opinion language release security interview framework podcast version voicesoftheelephpant api laravel

All content copyright, 2015 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework