Posted by jrearick on November 21, 2012 at 9:36pm
Start:
2012-11-26 19:00 - 21:00 America/Chicago Event type:
User group meeting
After getting stuffed with turkey and shopping 'til you drop, come by the November DrupalCorn meeting Monday, November 26 at 7pm. John VanDyk will show us all about Views' exposed filters to give your users the power to quickly and easily find the node (or entity) they are looking for.
LOCATION
We'll be meeting in Room 8, Curtiss Hall at Iowa State University Google Map. Please excuse the mess in the hallways as parts of the building are being remodeled.
As always, the first hour of the meeting is open discussion/question time. If you have a question, or would like to bounce ideas around with others, please come and share!
Please do sign up so we get a good count.
See you there!
Comments
Can't Be There...But
I do have a question you can all ponder if you'd like...
Following last month's discussion (John briefly commented on the virtues of NetBeans vs. Eclipse...and I made the switch back to NetBeans) about remote debugging I'm wondering...
Now that I have NetBeans configured I can remotely debug Drupal/PHP code. So is there a slick way to find a bit of code that's not working properly, but is also not producing any kind of error message or similar output?
Specifically, I have a handful of closely-related, contributed modules (not my creation). One of the features they support (a filtering capability) is not working properly and I would like to find the responsible code so I can see exactly what it is doing.
The only way I know to find this is to set a breakpoint in index.php, launch the debugger, and painstakingly walk step-by-step through the script until I get to the point I'm looking for. Anybody know of a better way?
Thanks in advance. Have a great meeting tonight, without me. 8^(
Mark
Breakpoints
With a little knowledge of what is happening in the code, your breakpoint does not have to be set at index.php. Or you could set additional breakpoints.
If I suspect a module is messing something up, and I can vaguely identify which hook it might be in, I'll set a breakpoint in the module's hook implementation and just look around. Maybe variables that you expect to be one value are another. As you get closer to the culprit you can set breakpoints closer and closer to the problem (and eliminate the breakpoints that aren't helping).
The above process is incredibly helpful. You can also throw in a hook_form_alter() (I usually put this in the ubiquitous site-specific module) and just inspect various forms as they get built if it's a form-related thing.
We'll miss you tonight.