A developer’s take on GravityView 2.0 Beta

Briefing

GravityView 2.0 strives to deal with some inherent issues in the older versions of GravityView, while extending functionality to bring in new features, stability and performance.

Disclaimer

This is a beta. While we have written a lot of automated tests and made pretty sure the plugin behaves correctly, there will be issues. If you are running important production systems, this beta is not for you. Doing development? Testing? Let us know how it goes :)

The rendering core has been rewritten

The frontend rendering of Views has been rewritten from the ground up. It has shed a lot of weight, became more flexible and stable. We’ve already added a new shortcode that allows you to output any field from any entry in any View pretty much anywhere.

Coming soon: powerful queries

We’re also working to introduce a much more flexible entry query system (think ORM) that would allow our developers and third-party developers to control the entries that make it into the View in much more granular way, with unlimited boolean combinations. What will this allow? Powerful searching and filtering, and more importantly multiple form joins and unions! Which would mean Views can source rows and columns from several forms.

We’ll be rewriting the whole codebase bit by bit. It’s a slow process in the right direction.

We’ve also introduces some magic wrappers, notably:

1. gravityview()->request knows a lot about the current request
2. gravityview()->views->get() retrieves a view by ID, slug, post, etc.
3. gravityview()->log provides a PSR-3 interface for logging, instead of the old do_action-based solution
4. others are a work in progress, like gravityview()->render()

This is the future of GravityView. Stateless, easy to work with, full-featured.

Any casualties?

Refactoring, rewriting code from scratch always comes with a set of deprecations and incompatibilities with old APIs. What won’t work in 2.0?

Updated minimum PHP requirements

The plugin will not be allowed to activate under PHP 5.2 and lower. PHP 5.3 is fine. PHP 7.1 compatbility is guaranteed.

Some core APIs

The so-called legacy global state. If your custom code contains references to – GravityView_View, GravityView_frontend, GravityView_Data these may no longer contain the necessary state. A lot of the functions have been deprecated and substituted internally for the new counterparts (refer to our GitHub wiki] for more in-depth information).

Specifically:

• GravityView_API::field_value() has been deprecated in favor of using \GV\Field_Renderer objects.
• GravityView_frontend::render_view() and GravityView_frontend::insert_view_in_content() have been deprecated in favor of \GV\View::content() and the more low-level \GV\View_Renderer, \GV\Entry_Renderer, \GV\Field_Renderer.

While a lot of the old code is still there, everything will be rewritten to a new standard. So be prepared. If you have a lot of custom code, we’d love to hear from you. Custom code means we have failed to provide some needed functionality and we’d love to find out about interesting use-cases that we’ve not considered.

Are you overriding templates? You’ll need to update.

If your theme has a “gravityview” directory in it this means that you’ve been using View template overrides. While these will work, there may be serious issues in some edge-cases. Moving over to the new template files should not be too difficult. New template files can be found in the “wp-content/plugins/GravityView/templates”. The override structure and contents should match the ones here.

The main difference is that there is no more global state. You get a $gravityview object that contains some context and work with that. For more information refer to our in-depth 2.0 documentation and code docblocks.

Internal classes updated

Some internal classes, like GravityView_oEmbed, GravityView_Shortcode, which nobody should really be using anyway, will no longer produce any output. Refer to the new \GV\oEmbed and \GV\Shortcodes\gravityview class documentation.

Extension Compatibility

We aim to provide backwards compatibility for all extensions. Over time, all GravityView extensions will be rewritten to take advantage of the new 2.0 codebase.