Yes, Debugging Templates and Core Code Works!

[Gazley]

Hi there,

The title just about says it all! I wondered whether anyone has been able to achieve this? I've been trying all day to configure PHPStorm but no luck far

Thanks

--Gary

[Adam Kiss]

Hey man, I can't help you (no-IDE guy here), I must say you seem to struggle with PW the most I've seen yet. Good luck.

[Gazley]

>I must say you seem to struggle with PW the most I've seen yet

That's comforting to know.

[Soma]

What do you want to debug? I have to say I have no clue about PHPStorm and XDebug. I think this has not much to do with PW rather than your IDE and PHP. DO you mean a local runtime environement? I think without having PW context there (not plain php) it doesn't really make sense, and something you do while coding templates -> testing in browser, if error go back and check, fix, continue.

There's also debug option you can enable in /site/config.php to see errors and warnings.

Edit: I think your struggle is also little selfmade, I've never needed autocomplete for something like PW, or debug, lint or anything, just for coding php websites, rarely really have the need as it's so simple. What I sometimes use is a phplint to spot errors in php code right away, but mostly it's just annoying and slows IDE's down.

[Gazley]

Hi Soma,

I'm pretty used to a live debugging environment in PHP. As far as debugging goes with PW, I would just like to be able to set a breakpoint in a template and be able to test the values being injected into the output. This is a fairly standard approach for me. The PW context is there when the code is being executed so, this isn't a design time requirement.

Thanks.

[Adam Kiss]

@Gazley: that was meant to sound sympathetic, sorry.

[Gazley]

@adamkiss No problem. I'm not really "struggling" with PW, I'm trying to see whether I can get it to fit into the workflow that I'm used to. If by spending some upfront time I'm able to do that, I'll be massively more productive going forward. If not, I'll just do things the PW way.

[Soma]

I don't think there's a "PW way". I think most limits as far as those techniques goes regarding PW is because the developer (Ryan) isn't using those workflows so it may not ready to do everything and it may not working/supporting all workflows and standards (which for myself also don't really use or care), not saying this can't be adapted to do so. I'm sure Ryan will be pleasant to help doing changes if there's any issues with it that PW gets in the way.

[Gazley]

I know that some of you wondered what the hell I was tring to achieve with this

After a lot of messing around, full debugging via XDebug works and I am now able to put break-points anyware in ProcessWire and even step into and through the templates and their nested PHP, when the site runs.

This means I can check variables, miscellaneous output as it is being written into the HTML, check program flow and step into and through the framework/CMS code.

Cool!

Edited August 8, 2012 by apeisa
Merged two xdebug topics together

[nik]

Hmm, this sounds interesting. I haven't been using a debugger recently, actually ever with PHP, but I think I would find it a very useful tool for some situations even in this context.

@Gazley: You might be in the minority with this kind of workflow, especially when it comes to everyday tasks, but I'm sure you're not alone.

Could you maybe give a little explanation on which steps you went through to set it up? I'm guessing there were some parts you got right with trial and error, so it could be useful for someone else (like myself maybe ) trying to get there to know where there may be some pitfalls along the way.

[Gazley]

Hi Nik,

I've successfully used PHPStorm and XDebug for quite some time. Before that, I used NetBeans and XDebug but there were issues between the latter pairing that eventually saw me move to PHPStorm after a year or so with PhpED and its own native debugger!

There is no real magic to the setup other than initially, I was coding against PW on an Ubuntu 12.04 server installation, in a VirtualBox, on my iMac. I used ExpanDrive on the Mac so PHPStorm just saw the Ubuntu server as another volume on the Mac. This worked fine until I decided to start debugging and I just couldn't get this to work at all.

Basically, PHPStorm + XDebug don't really like to debug against a "remote" server when the source code isn't in a "local" installation. So, as I was talking to Ubuntu in a virtual server, albeit local to my Mac, it was still "remote".

So, I installed MAMP on my Mac and setup PW in its htdocs folder. As far as PHPStorm + XDebug is concerned, it's "local". However, this still didn't work without error. I was stepping through the code and occasionally, it would just time out. This was using PHP 5.4.4 and XDebug V2.2.0, the latter known to be "buggy". In this case, maybe there was issues with PW running in PHP 5.4.4 or maybe it was XDebug.

To test, I backed of PHP back to the latest 5.2 release and an appropriate XDebug version. This works like a charm. It's too much hassle trying to build XDebug from source to its latest 2.2.1 release on my Mac. This would be easy in Linux but for various reasons, on the Mac, it's a real pain. When MAMP releases another version, it will likely have the XDebug 2.2.1 or later. At that time, I'll re-install it and see whether PW + debugging works with PHP 5.4.4 or later.

I was amazed that debugging seemed so alien to PW users. I really hate coding and hoping for the best so give me the ability to debug every time because when there's a problem, there's nothing easier than sticking a break-point in the code and seeing exactly what is going on.

To be fair, in my day job, I use the MS stack (C#) so I use Visual Studio and that has always had great debugging/tooling. As you can imagine, I expect this to be available to me in PHP or Ruby too.

I hope this explanation helps.

--Gary

[Pete]

I was amazed that debugging seemed so alien to PW users. I really hate coding and hoping for the best so give me the ability to debug every time because when there's a problem, there's nothing easier than sticking a break-point in the code and seeing exactly what is going on.

To be fair, in my day job, I use the MS stack (C#) so I use Visual Studio and that has always had great debugging/tooling. As you can imagine, I expect this to be available to me in PHP or Ruby too.

You'll find debugging tools are generally used far less with web development unless you've used them elsewhere or are really into debugging.

Most web developers I know either use a text editor or Dreamweaver - those using IDEs are the exception rather than the rule I would say, and it tends to be people who are used to that way of working with other languages.

With PW I don't find there is any "hoping for the best" - it's pretty straightforward if you're used to PHP and have read some of the docs and tutorials. You'll always have a reasonable idea where something has gone wrong in the code and then be able to double-check it against the cheatsheet, so the time saved with an IDE for me doesn't seem that great.

I guess outside of the tutorials and the cheatsheet I don't think many people around here have really had the need to run a debugger

[Gazley]

Hi Pete - I used another PHP framework for circa 3yrs+ and the first two years, I never used a debugger because of conflicts with its encrypted source. So, I had to revert to the standard approaches used "back in the day".

I think it's down to personal preference and that's fair enough.

--Gary

[nik]

Thanks Gary, I'm sure your explanation will come in handy when trying to set things up!

But actually this caught my eye for another reason:

I was stepping through the code and occasionally, it would just time out. This was using PHP 5.4.4 and XDebug V2.2.0, the latter known to be "buggy". In this case, maybe there was issues with PW running in PHP 5.4.4 or maybe it was XDebug.

To test, I backed of PHP back to the latest 5.2 release and an appropriate XDebug version. This works like a charm.

I'm running ProcessWire locally on a Mac (OS X 10.6.8.) with PHP 5.3.8 and it seems to stall mysteriously every once in a while. It doesn't exactly time out, but loading a page just takes long, say 20 seconds or more. No errors or warnings can be found from error logs and everything else seems to be responding normally. I was just wondering could this be the same thing you were experiencing with the debugger? I've seen this behavior only on my local machine but with clean installations as well as with a bigger customer project. I think I'll have to look into this a bit deeper to find out what might be causing this. It does seem a bit odd though this hasn't come up before (or has it? anyone?), as there seems to be quite a few other PW users on a Mac as well.

I was amazed that debugging seemed so alien to PW users. I really hate coding and hoping for the best so give me the ability to debug every time because when there's a problem, there's nothing easier than sticking a break-point in the code and seeing exactly what is going on.

As Pete just said web developers tend to be using methods other than debuggers or even IDE's quite often. It's often just easier to try things out and add a few lines of echos to debug than run a debugger - especially if that means having to run a not-so-lightweight IDE as well. And when it comes to features with Javascript and/or strange CSS behavior we're out of PHP debugger's scope anyway.

But I'm not trying to say one way is any better than the other. I guess it all comes down to what you're accustomed to and what makes You more productive. And of course it's about choosing from a set of tools depending on the problem you're solving. For me being far more a programmer (or even a software architect if I may choose ) than a web designer it makes sense to use a debugger every once in a while. Having said that, there isn't a single web site I've ever built from scratch all by myself and that probably explains a lot . My cup of tea are the things under the surface: making things possible (been building a CMS for some years), integrations, imports/exports, (web) applications, and so on. And with these kinds of things using a debugger would most probably have saved me a few hours every now and then if I ever had learned to use one properly.

Anyway, my point must have been that it's great that ProcessWire doesn't make it impossible or even hard to use a debugger if needed. Being able to use the tools and processes you're familiar with may be crucial for anyone new to PW.

[ryan]

I think you guys are right on about this. I remember years ago (1990s?) I was using a full blown IDE, debugger and profiler. But I've rarely used such things in PHP. I suppose from-scratch debugging in PHP is a lot simpler than things I've used in the past, so it just hasn't come up as a need. I did experiment with XDebug years ago, but seemed like it was costing me more time than it was saving. Now I'm curious again, thinking I might benefit from a PHPStorm + XDebug setup in some situations (like mindplay.dk has mentioned as well).

[Gazley]

If anyone's interested, I've attached a screenshot of the debugging environment.

PW_debug.tiff

[SiNNuT]

Looks pretty cool Gazley.

[netcarver]

Just found this thread and it set me off exploring to see what debugging features were possible in Vim.

I've not used a proper debug environment/IDE with PHP though I used to with assembly/C/C++. I found an excellent plugin (joonty/vdebug) that, coupled with XDebug, works amazingly well and allows you to single-step, watch variables (global and local scopes), set breakpoints on lines/conditions and do evaluations - in short, all the usual suspects. I've been using it to single step through PW as it builds pages - neat!

[Gazley]

Hey netcarver, glad you you found this plugin. Despite what the hardcore guys think, having a debugger is really useful

I'm still using PhpStorm, more so than before given that I now use SASS and it has nice .scss support. All of these things just help you become very productive so more power to your elbow, I say!

Cheers.

[netcarver]

@Gazley

yeah, it's like having a microscope and being able to see inside the code again -- I had forgotten how useful it can be and it's certainly easier than having to instrument routines with all kinds of debug output. It's given me a much better insight into one of the other PHP codebases I look after so I'm really glad your thread prompted me to look for a Vim solution.

[ryan]

I didn't realize you were a VIM user too. That makes at least two of us here. I need to get setup with this debugger plugin too.

[netcarver]

I didn't realize you were a VIM user too. That makes at least two of us here. I need to get setup with this debugger plugin too.

We've touched on common use of Vim before unless;

1. you are forgetting or...
   
2. I'm delusional.
   

Of these, option 2 is probably more likely

Seriously though, XDebug + VDebug is a great combination. I've modded VDebug a little to compress the local variable context view which was a little sparse for my liking.

[ryan]

1. you are forgetting or...

This is the most likely case. My memory has never been great... I'm almost as old as VI itself, heh. But I'm looking forward to giving this debug combo a try.