Komodo Debugging Presentation From Tonight's Meet-up

Thanks Rob! I have downloaded and will look through your notes. I think I will try to figure out Eclipse before I buy a full Komodo package, but I'd really like to have an interactive debugger rather than relying on the Dev package tools or "printf".

--Darryl Richman
http://darryl.crafty-fox.com

I've got Xdebug working with Eclipse on my Ubuntu 10.04 server box. Life is wonderful!

It took me 1.5 days to get it to work. The problem I encountered was that, although I had no errors, Xdebug and Eclipse never communicated (and I couldn't get any output into the Xdebug log file). It seems that the Xdebug prebuilt package I got from the package manager was not compatible with Eclipse; when I finally got so frustrated that I downloaded the Xdebug 2.1.1 source and built it locally, everything just worked.

"Use the source, Luke."

--Darryl Richman
http://darryl.crafty-fox.com

Fun!

"In the land of the blind, the one eyed man is king."

Eclipse has a pretty confusing setup. There are projects, perspectives and workspaces. Projects seem to match up to Komodo projects in that they are a chunk of directory tree somewhere.

A perspective is a grouping of selected panels in a particular way: for example, there is a default PHP perspective and another one for debugging PHP. Eclipse allows you to create as many or as few panels as you like and you can dock them together or undock them as you like. You can organize tabs within the panels, and Eclipse provides a multitude of tabs to work with. These include things like editors (for source code or text), search results, code outlines, variables and breakpoints (while debugging), to do task lists and many more.

I'm not really sure what workspaces are, so we'll ignore those for the moment.

You can configure Eclipse default values and then modify them in any particular project. For most things, you'll probably want to set up the defaults correctly for how you work and you can be happy. But when it comes to setting up a debug environment for a project, you need to create individual values for the project.

You need to build some kind of a project with a web page in it to setup and test out your debugging environment. I actually used my test D7 tree, but nearly everything you find on the topic suggests creating some simple web page with some simple PHP code in it.

Debugging:
I'm assuming you have a LAMP stack already setup and working. My experience with this is limited to Ubuntu 10.04 (Lucid) Server and PHP 5.3.2.

As I mentioned above, I tried to use the package manager to install Xdebug. This seemed to be OK, but I could never make it work. Instead, visit xdebug.org and download the latest source code (it was 2.1.1 for me). Follow the directions they give you under the Documentation -> Installation tab on their website. Scroll down to Installing From Source. I found that the last line under Compiling, "make install", had to be performed as sudo make install. When the install completes, it will leave you with a summary display that includes the location where xdebug.so was installed on your system; don't lose this, you need it in the next step.

Now you have to configure your php.ini file. The Xdebug directions are so vague as to be useless. On my machine, the master php.ini file is located in /etc/php5/apache2/php.ini. BUT: there's also a subdirectory here called conf.d which has a file named xdebug.ini. You can make the following edits to either file, but it seemed logical to me to put them in the xdebug.ini file. If you put them in php.ini, you need the first line; if you put them in xdebug.ini, you don't need it.

Once you've made these changes, you need to restart Apache:

$ sudo service apache2 restart

This should make xdebug available. You can verify it with:

$ php -m

which will include xdebug in the list of modules loaded, if it worked. You can also see that it's present by loading up a webpage with:

On to Eclipse:
In the Navigator tab, you'll see your project listed at the head of the directory tree structure. Right click and select Properties and then PHP Debug on the left side of the window that pops up. There are a number of things to look at here:

You can get to the global version of this window from Windows->Preferences->PHP->Debug. (It doesn't include the Default Base Path fieldset.)

Probably the Default PHP Debugger will be Zend. Change it to Xdebug. Click Configure... and be sure to that the Port is 9000 (or it corresponds to another port that you've chosen in the xdebug.remote_port line; if you change that, you have to restart Apache to have it take effect).

The Server will probably be empty, click PHP Servers and then the New button to set up a new one. On the Server tab, give your server a name (like D7, for example) and then give it the document root URL (http://localhost/). Click on the Path Mapping tab and click add. The Path on Server is the doc root on your server filesystem (/var/www for me). Then select Path in Filesystem and enter the equivalent path on your local machine (since the server and my local machine are the same, /var/www works here, too). Click OK and OK to get back to the Debug Properties window.

You can go with the default encoding settings.

Base path is how to get from the server domain name to where your Project starts. If it's the doc root, enter /. In my case, it's in a subdirectory d7, so I entered /d7. The auto generated base URL is auto generated, but if you don't like it, you can change it by hand.

Break at first line means that the whenever you load a page under the debugger, it will stop in the debugger on the first executable PHP line. This can be handy for your first debugging session (so be sure to check it to get started), if you want to learn how Drupal bootstraps, or if you're working on something much simpler than Drupal, but for general use in Drupal, unless you just can't get a breakpoint you've set to fire, this probably isn't that useful.

Now, one other config area: click Windows->Preferences->PHP Executables. If you know where your PHP interpreter is in the filesystem, click add (mine is at /usr/bin/php). If you don't, click Search and then select /usr to start from. In my case, there were a couple dozen of them under /usr/X11 (the windowing system in Linux) and only the /usr/bin/php otherwise. So I deleted all the others (there's a bug here, even if you are sure you multiselected everything but the one you wanted to delete, it deletes as many as you selected from the top of the list). Either click edit or add, as appropriate to your choice above and select Xdebug as the debugger, then click OK and OK.

Finally, you are ready to try it out. Click on the down arrow next to the bug icon in the toolbar at the top of the window. You should see your "server" name listed in the menu. Select it. If you were in the PHP perspective, it will change to the PHP Debug perspective. A copy of Firefox, if not already running, will launch with a new tab, in the background. The Debug tab will come to the front of the panel it is in and show you a trace of the execution. An editor tab will show your index file and you'll see a small blue arrow on the left margin showing the line of PHP about to be executed.

If you find the Variables tab, it will show you all of the global variables available, like $GET and $POST. You can poke around in them and see all of their fields. If you look at the Breakpoints tab, you'll see that it lists the first line of code with a checkbox.

If you want to step through the execution, you'll find that F5, F6 and F7 provide Step Into, Step Over and Return functions. Step Into will begin to execute the next line of code and, if there's a function call, you will stop at the first line in the first function called. If there are no function calls, then it is equivalent to Step Over, which completely executes the statement. Return continues execution until it leaves the current scope (usually the end of a function). F8 continues execution until the next breakpoint is encountered.

Good luck with this!

--Darryl Richman
http://darryl.crafty-fox.com

• kristen pol
• robknight
• gharmon
• yamboy

• Arabic
• Alappuzha
• Event Platform
• Western Ohio User Group
• Goa Drupal Community
• Liverpool
• Chandigarh Drupal Geeks (C.D.G.)
• API-First Working Group
• Compony opinionated developers
• 4SPOTS