Not really an issue per se, but more of a helpful recommendation to anyone using this module. (No handbook page to add a comment to, so I'm putting it here for now...)

If you're trying to do complex things with this module, don't add your code within the view filter itself.
Instead, put it in a function in a custom module, and then add just a call to your custom function to the view, as in:

return mycustomfunction(&$this);

This will save you loads of time and effort if you need to modify or tweak your code, as you won't have to constantly run back and forth to edit the view after every change. The code can be easily edited, committed to your versioning system, debugged, etc. Sweet.

Pretty simple, but it took my several days of devl before I thought of this. Hope this is helpful to someone. Thanks again for developing this awesome module!

Comments

brycesenz’s picture

brycesenz commented

My approach isn't quite as helpful as the one above, but I've found using the function "drupal_set_message()" to be incredibly helpful in debugging PHP code with this module. I pass variables or whatever I need into that function, and you can then check out the results in the views preview area. A bit hacky, but simple.

bdimofte’s picture

bdimofte commented

instead of drupal_set_message, try the functions provided by module devel, like dpm, you'll get addicted

gnassar’s picture

gnassar commented
Category: task » support
Status: Active » Closed (fixed)

A good point.

Changing to "support request," as most of the docs/best practices seem to be marked, and closing.

(Might be a good thing to throw in the Views PHP Filter handbook section, too, if you're interested...)