-
Notifications
You must be signed in to change notification settings - Fork 62
Template Migration
GravityView 2.x introduces new template, data and state structures. If you're using one of these hooks in your code under GravityView 2.x then it's time to switch ;) While they all will still be back-compatible but GravityView will log deprecation notices and these will stop working in the future. You've been warned.
Fires of before anything View-related is output. Provides a $view_id as the first and only argument.
This hook has been switched for gravityview/template/before. It provides a $context argument that is a \GV\Template_Context instance containing everything you need to know about what's being output.
The same applies for the above. Moved to gravityview/template/header, gravityview/template/footer, gravityview/template/after. A $view_id is provided to the old hooks, while the nicer $context instance is provided to the new hooks.
When calling the wrapper functions in your own templates, please supply theses with the $gravityview global as the first parameter. Example: gravityview_before() -> gravityview_before( $gravityview )
Old templates will continue to supply just the $view_id to you. So stop using them.
These two get the old GravityView_View global. No, no, no. Use gravityview/template/table/tr/before and gravityview/template/table/tr/after which gives you the $context instead ;)
This is moved to the gravityview/template/table/entry/class filter and receives the $class string and the $context. Nice stuff, eh? The $context will contain the ->entry in question.
This has been deprecated in favor of gravityview/template/text/no_entries which has an additional third parameter with the $context. This way you can check which view this is being out put for without resorting to legacy evil. gv_no_results() accepts a \GV\Template_Context parameter now, and GravityView_API::no_results() does too.
Become gravityview/template/table/cells/before and gravityview/template/table/cells/after. The first parameter will the \GV\Template_Context instance. Easy.
Becomes a gravityview/template/table/fields filter, with... you guessed it, the context instance as the second parameter and the \GV\Field_Collection as the first. The context will contain the entry.
These become gravityview/template/table/cells/after and gravityview/template/table/cells/before. Obviously.
See the pattern? It's easy. If you're not getting the context in an action or filter you're using, then you're either using an old hook, or we missed it, so let us know!
These three filters have been deprecated in favor of gravityview/template/links/back/url, gravityview/template/links/back/label, gravityview/view/links/directory. All these come with the $context object now.
gravityview_back_link(), gv_directory_link() and GravityView_API::directory_link() should all be called with a $context.
Both the function and the filter now take a context instance.
These are split out into gravityview/template/(table|list)/body/(before|after) with the context instance as the first parameter.
The context-aware versions of these are gravityview/template/list/entry/before and after.
These 6 actions moved to context-aware gravityview/template/list/entry/(title|content|footer)/(after|before) counterparts. Context-aware for the win. Whew!
Remained with the same name. Just gets a \GV\Template_Context as an additional parameter.
Both are deprecated in favor of gravityview/template/field/label, which gives you the $context. Use it.
This function now accepts a second $context parameter. As do the following filters: gravityview/field_output/pre_html, gravityview/field_output/open_tag, gravityview/field_output/close_tag, gravityview/field_output/context/$tag, gravityview_field_outputandgravityview/field_output/html`. All of these have the context passed. Use it instead of the legacy globals.
The gravityview/field_output/args filter is deprecated. You can still supply override values for entry, field and form parameters in the legacy array format. Do, however, use the newer gravityview/template/field_output/context filter that gives you the $context instance, which can be altered to your needs (field, view and view->form, entry). It is, however, possible to override the label and the value by supplying value and label in the old filter. The $context is passed in there for your convenience as well.
Accepts an context instance now, too.
This filter is now deprecated. We will not be giving it the context. We will, however, supply the context instance via the new gravityview/field/value/empty filter.
These filters will not give you the new context instance. You are therefore discouraged from using them. They've been marked as deprecated. Use the new gravityview/field/output or gravityview/field/{$field->type}/output filter with a priority of 8 or lower for the pre_link filters.
Same here. But use gravityview/template/field/output or gravityview/template/field/{$field->type}/output filters with a priority of 10 and up.
This non-context aware filter has been deprecated in favor of gravityview/template/field/entry_link
Here's a list of all the field template hooks migrations that have been done in 2.0. Keep in mind that we aim to keep all old filters back-compatible, however, the legacy context constructs (pretty much everything with ::getInstance()) are all deprecated and not supported.
This is used in the checkbox and radio field outputs. This filter now receives the magical $context parameter as one of its arguments.
gravityview/fields/custom/content_before, gravityview/fields/custom/decode_shortcodes, gravityview/fields/custom/content_after
Same here, the context is not passed from the new parameters. Feel free to keep using these filters for your custom content field needs.
Gets the context treatment, too.
The entry, edit and delete link fields use this filter. It remains as is for now, apart, of course, from getting the context as the last parameter.
Context as the last parameter for this e-mail field filter. All good.
This method accepts a new $base_id parameter, which is passed onto the ::entry_link call. This allows the method to be decoupled from the legacy context. Pass a the post or view ID as this parameter.
The context-aware branch is switched to if the third optional argument is set to a \GV\Template_Context instance.
This filter now has a $context instance, containing everything you need to identify when and where it's being called.
Both upload filters remain named the same, but acquire a 2nd parameter - the $context.
gravityview/fields/fileupload/link_atts, gravityview/fields/fileupload/disable_link, gravityview/fields/fileupload/link_content, gravityview/fields/fileupload/files_array
These will continue getting the legacy "field" context, but are also gaining the context instance, like most of the other filters.
Context is passed as the second parameter to this filter.
Context is passed as the second parameter to this filter.
Context is passed as the fourth parameter to this filter.
Context is passed as part of this filter. The name has not changed.
gravityview/entry-list/item, gravityview/entry-list/after-link, gravityview/widget/recent-entries/output
These three filters from inside GravityView_Entry_List have remained unchanged. They all pass the instance of the list which will have the $template_context property set.
Context is passed as part of this filter.
The context is passed into there. This radio, checkbox filter name has no changed.
Context is passed as part of this filter. Second parameter.
Context is passed as the first argument on this action.
Will now require that a context instance is passed to it (3rd argument) in order to take the new context-aware branches.
This filter will receive the context now, too.
This shortcode callback will now receive the context as the second argument when called directly. Using it as a shortcode [gv_add_note] will trigger the legacy branches.
This method will now receive the context.