Blog

Field Guide to Pods 2.8

What’s new in Pods 2.8

Big ticket features

  • Field Groups! You can now add Field Groups to any Pod 🎉
  • Better Performance – Pods now loads more quickly, uses less memory, and can handle even more large complicated configurations you throw at it. Auto-loaded options have been reduced up to 95%!
  • New Pod Editor – The new Edit Pod screen has been completely rewritten in React and uses REST API saving separately for the Pod, Groups, and Fields.
  • New Field Types – We added two new layout-related field types — Heading and HTML.
  • New Pods Blocks – We are excited to introduce our new Pods Blocks which allow you to List Items, show a Single Item, display a Single Item Field, show a Public Form, or embed a View (any file) from your theme / child theme. We also included compatibility with the new WordPress 5.8 Query Loop blocks!
  • New Pods Blocks APIFor those creators out there looking to get ahead with some common custom block needs, our new Pods Blocks API allows you to register your own blocks.
  • New REST API – Our new REST API endpoints (11 endpoints total) allow for managing Pod configurations.
  • New WP-CLI commands – Our new WP-CLI commands (24 commands total) allow for managing Pod configurations.
  • New Editor option for WYSIWYG fields – The Quill Editor is now officially supported for WYSIWYG fields.
  • Now implementing a new core library – Pods 2.8 now uses the same core library that the fantastic plugins The Events Calendar and Event Tickets use. This gives us access to some great abstractions that we don’t have to build or maintain ourselves as part of Pods. We’ll be tapping into more of that magic as time goes on too.
  • Stability Improvements – We introduced 304 new automated tests with 11,131 new assertions to make sure new features and code structures are operating at their best.

Even more improvements

  • New field option – Now supporting the ability to turn on/off the trimming of whitespace (default: on) for text-based field types (text/wysiwyg/etc).
  • Pods::field() New Pods::field() / magic tag options for various new special notations including: Pod information, Field information, Item list information, and more. This is a huge deal when you use [if] conditional template tags and lets you do even more without writing any PHP code than before.
  • Pods::fields() – Now you can traverse relationship fields to get information about a field like Pods::fields( 'my_related_field.some_other_field' ) which would retrieve info about “some_other_field” even if it is on another Pod.
  • Pods::form() New support for the parameter “output_type” which lets you specify “div”, “ul”, “p”, or “table” (new default is “div”, previously it was using “ul”).
  • Shortcode New support for the shortcode parameter “form_output_type” which corresponds to the above Pods::form() improvement.
  • Shortcode New support for the shortcode parameter “blog_id” which lets you query data on another blog on multisite (must be enabled through the new PODS_SHORTCODE_ALLOW_BLOG_SWITCHING constant).
  • Post type arg support – Now supporting the delete_with_user argument for custom post types.
  • Show custom post types on Category/Tag archives – You can now choose to include posts from your custom post type on the Category and Tag archive pages.
  • Revamped i18n component – Our i18n component now interfaces with the new Pod editor screen for a better experience managing your translations per language.
  • Revision limit support – Now you have the ability to limit the number of revisions kept per post for a specific custom post type.
  • Customized placeholder for “Add title” – You can customize the placeholder used for the new post screen for a specific custom post type.
  • Pods Admin UI config abstraction – You can now extend the configurations for Pods, Groups, and Fields themselves with their own custom groups/tabs and fields. You can also modify existing ones. This is useful for plugins/add-ons extending Pods as it has now become more powerful.
  • Lots of fixes and tweaks along the way!

Check out these new Pods 2.8 related documentation pages

Breaking compatibility

  • New minimum required versions have been updated as follows which includes notices to let you know if you need to update something.
    • New minimum version required: WordPress 5.5+ (previously: WP 4.5+) — Going forward we will support the last two major WP releases on each major release of Pods.
    • New minimum version required: PHP 5.6+ (previously: PHP 5.3+) — Hey! You should take the time to update to PHP 7.4+ because there’s major speed improvements to be had 🙂
    • New minimum version required: MySQL 5.5+ (previously: MySQL 5.1+)
  • Refactored object handling for Pod and Field configurations — instead of passing around arrays we now are using a “Whatsit” strategy (that’s an endearing term but we use it for any kind of object configuration). Pod and Field configurations now use \Pods\Whatsit\Pod and \Pods\Whatsit\Field accordingly. This gives us flexibility to lazy load and pull things as-needed from the database instead of always pulling entire Pods and Fields configurations all at once. This also reduces how much we have to use/cache on each page further reducing overall memory usage on every page. It remains backward compatible in most array usage (see the ‘options’ note below).
  • Watch out for custom usage of $pod['options']['option_name'] or $field['options']['option_name'], just use $pod['option_name'] and $field['option_name'] to get/set your options. There’s some backward compatibility here but certain areas like PHP overloading can cause circumstances where you’ll get PHP errors. Full documentation of this will be made available on our new Dev Docs site that we’re working on, keep an eye out for that!
  • Public forms now render with the “div” output type (previously “ul”), you can change this by providing a different output_type to the Pods::form() or “form_output_type” to the shortcode.
  • If you have written custom field types, they should continue to work but you will want to be mindful to reach out to us to help you get them setup in our new React Field Type code that will be released in the near future. No ETA on this as it may be Pods 3.0 before our new React-based Custom Field Types are implemented fully for you to leverage.
  • CLEditor is no longer maintained and has been replaced with the React-based Quill.
  • The Pod Helpers component is no longer included in Pods and the Helpers API code is will no longer return helper data. If you want to continue using this functionality, the Pods Helper Add-On is available.

Overall Stability Improved

  • We’ve converted our PHPUnit tests over to Codeception and expanded our tests for all of the new structures that were introduced in Pods 2.8
    • Pods 2.7.x: 4,593 tests, 25,684 assertions
    • Pods 2.8:
      • wpunit (general): 702 tests, 1,759 assertions
      • wpunit (shortcodes): 26 tests, 110 assertions
      • wpunit (traversal for find/field): 3,972 tests, 34,569 assertions
      • restv1: 63 tests, 377 assertions
      • Total: 4,763 tests, 36,815 assertions
  • There are new JEST tests which cover many of the new areas of our new React functionality and have replaced our old JS tests
    • Pods 2.7.x: 1 suite, 17 tests
    • Pods 2.8: 26 suites, 151 tests

Want to help keep Pods on track? None of Pods 2.8 would have been possible without the help from our Friends of Pods.