Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn
Profile photo of support-octavio
Octavio Gonzalez
Web Developer spending each day wrangling front and back-end code - helping keep Genuitec on the web.

Introduction

If you code PHP and are tired of fighting logging messages, Eclipse PHP Development Tools (PDT) can end the fight! Using Eclipse PDT to debug PHP isn’t as hard as you might think. Read on to see how a few simple steps can make your coding life so much easier!
image00E

Background

Our portal uses WordPress, a powerful content management system (CMS), and we have written many custom plugins with specific requirements for our company. In the beginning, a debugger wasn’t necessary. But, as functionality got complex, we needed to find an easy way to debug PHP. This search lead us to a real time saver—Eclipse PDT along with Xdebug. Now we just use breakpoints and watchers to debug instead of the tedious task of printing out data and debugging the error log file.

Example

The following example demonstrates how to set up a PHP debugger for WordPress in just a couple of steps—making debugging PHP as simple as debugging JavaScript in your favorite browser or even better, in Webclipse.  We’ve also included information about profiling your app to help find bottlenecks.

Requirements

  • Apache server
  • PHP
  • Eclipse Luna

Setup

Before you start debugging, you will need to install Xdebug and configure your project in Eclipse.

Xdebug

To install XDebug in an Ubuntu-based distribution, run the following command in your CLI:
sudo apt-get install php5-xdebug

This installs the xdebug extension in the default php extensions directory, setting it enabled by default.

In Windows, I like to use Xampp. After installing it, Xdebug is pre-configured in the php.ini file.  To enable Xdebug, remove the semicolon ( ; ) to uncomment the line that manages the setup and settings.

Eclipse

Complete the following steps to configure a PHP project in Eclipse for debugging.
  1. Create a new project using the location of the current WordPress location.
  2. Click the Debug drop down arrow and select Debug Configurations.
    image08
  3. Select PHP Web Application and click New_configuration. The following window displays:
    image02
  4. On the Server tab click Configure to edit the default server or New to create a new server.  Enter the following information:
    Name—Type a name for the server.
    Debugger—Select XDebug.
    Base URL—Type the URL for your local domain test.
    Local Web Root—Set the path of your web root.

    Here are what my settings look like:
    image11
  5. Click OK and return to the Server tab on the Debug Configurations window.
  6. Select the PHP file to debug (the file from which the program starts).
  7. Configure the URL:
    image04Note: I configured my virtual domain ( ‘portal’ ) to load content in C:\Users\Octavio\git\wordpress, so I had to disable Auto Generate and remove ‘wordpress’ from the path.
  8. Click the Debugger tab and make sure XDebug is selected as the Server Debugger. Optionally, you can set a breakpoint at the first line of code.
    image10
  9. Click Apply to save your changes.

Debug

Now you have configured XDebug. To get started debugging, open the debug configuration profile you just set up and click Debug. The first time you run the debugger, you get an alert to confirm switching to the Debug Perspective. If you checked the Break at First Line option, your app suspends at the first instruction in the index.php file:
images00E1

Click the Stop button if you want to stop debugging:
image01

Now, follow these steps to debug something basic but useful.

  1. In a fresh installation of WordPress add the following code to the functions.php file of current theme:
  2. Set a breakpoint on the first line of the function and a second breakpoint on the last line (return $content;).
  3. Click Debug and notice that execution stops at the first breakpoint. Also note that we have access to the program variables, in this case the important one is $content.
    image05E
  4. Click Resume or press F8 to continue the program execution.  The program execution now stops on the second breakpoint.image06
    Notice the $content var has changed due to our function’s logic. In some cases, there are too many variables for the Variables tab to be helpful.  In these situations, use the Expressions tab and add only the variables you want to inspect:
    image03E

Bottlenecks

Sometimes we find a bottleneck in our application and don’t know which function is causing it, that’s when adding a profiler to our scripts comes in handy. Xdebug provides great data for profiling PHP and is easy to use.

Add a profile to a script

  1. Add the following to the php.ini file:

    Details
    xdebug.profiler_output_dir—The path where the profiles are saved.
    xdebug.profiler_append—If On, adds the data at the end of the file instead of replacing last profile.
    xdebug.profiler_output_name—Specifies the profiler’s name
    xdebug.trace_options—If 1, appends the traces instead of overwriting.
    xdebug.collect_params—Specifies if we want to consider the parameters in functions. We use 4 for a full variable contents and variable name. See more options
    xdebug.collect_return—If 1, XDebug writes the returning value of functions calls to the trace files.
    xdebug.profiler_enable—If On, enables profiler.

  2. Make sure Apache has read and write permissions to the profile’s directory.
  3. Webgrind is a web-app that shows the data saved with Xdebug. Download Webgrind and install under /
  4. Modify the config.php file with our profiler directory:
    $profilerDir ="/home/admin/traces/";
  5. Open Webgrind in a browser:
    image07

Conclusion

I hope you are able to put this information to good use.  Debugging this way has certainly saved us a lot of time (and also headaches!).  It may seem confusing at first, but once you have it configured properly you will find the time spent setting up was totally worth it.  

DEBUG-blog


Related Posts

Darkest Dark for Authentic Souls. If you are not fashion-challenged in the web development world and like to show your true colors, Darkest Dark theme is for you. Unlike the fake sense of self provided by Nordstrom’s mud-stained jeans, our theme appeals to your authentic developer’s identity, providing features that do make sense and allow you to work in a much more pleasant manner...
Darkest Dark Theme, Angular 4.0 Support, MyEclipse... We are excited! We have so much going on, and we wanted you to be the first to know all about our recent updates and new products. Introducing Darkest DarkLike many of you, we wanted Eclipse looking vibrant. We wanted our IDE to make us excited, and not feel like we are still coding in the early 2000s. That’s how it all started, and the “Darkest Da...
MyEclipse 2017 Stable 1.0 is out! Earlier this year we were really excited about being able to provide you with initial support for Angular 2. Well, now with this release you also get tooling support for Angular 4. Not only that, but we wanted to make sure you were able to update simply to Angular 4 -- with a one-click flow that does most of the steps for you. Once you are all set,...
SDC 2017 – Looks, Security & Neon. Get your installers ready (Java 1.8), because Neon is here! Our first release of the year is based on Eclipse Neon and with it, many other exciting updates.Totally new portal, we are updating the look and feel of the SDC portal, giving extra functionality that allows you to perform basic editing of packages without the need of the Admin Console. Yo...

Posted on Oct 1st 2015