-
Notifications
You must be signed in to change notification settings - Fork 62
Debugging GravityView
Debugging GravityView Core and Extensions can be a little confusing at times. This document outlines some general debugging strategies and tricks to streamline issue identification and solving.
Almost all issues occur on a page that is either a View or a page with either an oEmbed or a shortcode.
For directory mode requests the first step is to obtain a var_dump of the GF_Query::_introspect() call once it's performed. This happens in the \GV\GF_Form::get_entries method (if move/gfquery branch is merged into a release, otherwise in the \GV\View::get_entries method in older releases.
The best place to setup the var_dump is right after the GF_Query::get() call almost at the very bottom of the \GV\GF_Form::get_entries method inside the add_fetch_callback callback, where entry arrays are transformed into \GV\GF_Entry objects and added to the Entry_Collection that is returned.
This _introspect() method, while marked as private/internal but provided by Gravity Forms for now, is a great way to find out the query's join, where, sort, limit and offset clauses. The same information is somewhat contained in the executed queries item of the array that the _introspect() method returned.
If in the future the method is removed falling back to using the WordPress query filter is also an option to get the generated SQL but it can be confusing to pinpoint the final query as one Gravity Forms query may actually be composed of several queries due to join and union generators in some cases.
Standard GravityView debug logging is also provided before the final ::get call. So the Debug Bar plugin can usually be of help in cases where var_dumping is not possible.
Once the conditions and the SQL query have been analyzed the immediate issue with the database request should be quite evident. Incorrectly generated, erroneous or missing auxiliary (joins, casts) SQL is almost always an bug in GF_Query itself, although we haven't had them for quite a while. Incorrect query clauses or parameters, values is usually the result of incorrectly passed search_criteria or generated GF_Query::where() call combinations in activated plugins (Advanced Filters, etc.).
Bubbling up through code to find out the source of the incorrect parameters and added WHERE conditionals is necessary to pinpoint the exact issue thereafter.
There are three hooks that have been used to alter entry set querying: gform_gf_query_sql, gravityview/view/query, gravityview/view/entries. Weird custom code might tap into the lower-level WordPress query filter, but this has not been observed in the wild.
This is a special case as most data is retrieved via the getData AJAX call with parameters. There are various nuances in the JavaScript and the backend but most issues boil down issues in the final SQL. Resolving by bubbling up though code is the best strategy as well.