Drupal, Eclipse, and PDT development workflow -- the big picture
Setting up my Drupal development environment based on Eclipse with PDT and the Zend debugger took me a huge amount of time. Searching on drupal.org yields a lot of configuration details for Eclipse, and Web-wide searches yield detailed setup instructions for various combinations of software versions and operating systems. But what finally helped me over my last, and most time-consuming, challenges was the workflow discussion at http://groups.drupal.org/node/2663.
So, in this article, I emphasize two main points that cost me huge amounts of time getting my development environment set up. I currently use Eclipse Ganymede 3.4.2 with PDT 2.0.0.
- Stable PHP projects must be created with "New->Project->PHP project" in Eclipse/PDT
This point was buried in the discussion referenced above, but I hope that emphasizing it here will save somebody a lot of time. My mistake was that I kept checking out Drupal, contributed modules, and my own custom modules from CVS repositories. These projects looked like PHP projects for awhile, but over time they would decay on me, and eventually forget the files they contained. To avoid this problem, I start each new PHP project with "New->Project->PHP Project" and then import the desired code from another location. When I do the import I do not overwrite the ".project" file that is already there. When downloading contrib modules, I establish them first in the main Eclipse workspace as discussed, and then I use Eclipse's "Refactor->Move" command to put put them in the correct subdirectory under my Drupal install.
- Breakpoints must be set in code as opened by PHP Explorer under the drupal directory you are debugging.
This was an important point for me once I had the previous point figured out and was making sure that I could debug my custom modules and step into Drupal code as well. Each project appears at the main level of the Eclipse workspace, as well as again under the main Drupal install if it is a module (and was put there with "Refactor->Move"). For example, my custom module for Composers' Village appears once at composers_village and again at drupal/sites/all/modules/composers_village. Breakpoints set in the main workspace one will never be hit, although they will look like they are set correctly. To have your breakpoints be hit, they must be set in the version of the file that appears under the Drupal being debugged. If your debug configuration points to drupal/index.php then your breakpoint must be set at drupal/sites/all/modules/composers_village, for example. This is my experience, anyway, and I hope it proves helpful. If this article helps you or if you have questions please contact me.
