We’ve been hard at work on Pods 3.0, which started out as Pods 2.4. We decided to up the version from Pods 2.4 to 3.0 due to some large performance improvement changes in our code architecture. Specifically, for memory usage and how we’re handling our objects for the inclusion of Field Groups and Loop Fields. There are more things coming in Pods 3.0 that I wanted to share with you all to get you excited about what we’ve been in the lab with..

Refactoring our objects: PodsObject

The new PodsObject architecture powers Pods, Fields, and Groups to reduce memory footprint of Pods and simplify data calls throughout API. The separate ‘options’ array usage has now been simplified and merged into the main flat array of options instead. New object-oriented methods are provided on each object for $pod->save(), $pod->delete(), $pod->duplicate(), $pod->reset(), and other various methods. These are familiar for the item-specific methods on the Pods class, but up until now have only been available inside the PodsAPI class. PodsAPI is backwards compatible and can be continued to use as needed, no methods have been deprecated as of yet.

The new object structure utilizes PHP ArrayAccess so that you can still access options through $pod[ ‘name’ ] and $pod[ ‘another_option’ ] and the class will pull the option from wherever it may be stored. It loads meta fields as needed instead of all at once. It also serializes and unserializes only core information, reducing cached data to 5% in some cases of what it used to store. These objects are what you normally have seen as large arrays inside of the Pods::pod_data property and field arrays inside of Pods::fields[ ‘field_name’ ], and elsewhere.

New Custom Heading and Custom HTML Field Types

These two new field types are intended to be used to add headings and blocks of HTML to Pods forms, allowing you to customize the look of your forms anyway you need to. The new Custom Heading field can be used to add a custom header to a form, and Custom HTML can be used to insert any blocks off HTML when needed in your field. Together these two fields can improve the appearance as well as the UI and UX of your forms. We’ll be adding more options for how headings work in each form display in the future, so we may potentially have tabs at the top for them.

Field Groups (Meta Boxes for Post UI, Headings for other forms)

In Pods 3.0 all fields will belong to a field group. Each field group will get its own meta box in the post editor or heading in other forms like the User edit, each with its own visibility rules. This will allow you to group fields together based on their purpose or hide a group of fields based on the post status or user role. You’ll be happy to know they are now supported in all of our content types including Advanced Content Types. Previously in Pods 2.0, you had the ability via code to add new field groups to a Pod, we hope you’ll enjoy having the new UI and architecture to work with to streamline creation.

Check out how it looks in the UI now below.

Loop Fields

Loop fields are something we’ve been working on for the past few years. We’ve gone through countless Design / UI iterations and have finally settled on one that works. We’re currently in the process of refactoring all of our field type JS to support Loop Fields and implement the new storage handler.

Check out the video demo of Loop Fields by our new contributor Curtis McHale below.

Features as plugins

Pods core contributor Phil Lewis and I have started to roll out the first few plugins for Pods that add features to and extend Pods to do new things. The first of which is Pods SEO which adds XML Sitemaps compatibility for Advanced Content Types and the WP SEO plugin. We’re also working on a new Export to Code plugin (currently in private beta) that will export your Pods configurations into PHP for registration within a plugin or theme. But those can’t hold a candle to our most exciting new project from Pods core contributor David Cramer, Pods Frontier.

Currently undergoing the final changes for a public beta, Pods Frontier takes Pod Templates to the next level adding auto-complete for magic tags in the code editor with traversal support! There’s a views-oriented feature for Templates now, which will let you define your Templates and set up the Pod parameters there for embedding in shortcodes and PHP in more than one place with shared (and overridable) parameters. But that’s the tip of the ice berg, as the feature set also includes the ability to setup multi-column layouts and forms through the UI!

Also in the works is something we’re calling Advanced Portable Packages, or Apps for short, which not only improve migration of Pods data between sites, but will allow for Pods-based plugins and themes to easily register the Pods configurations needed during deployment and installation on other sites. It will handle upgrades automatically so when field names and content types change, they’ll be renamed and updated properly, as opposed to how normal code registration works.

Example code to register a new App:

pods_register_app( 'my-app', 'path/to/your/package.json', array( 'name' => 'My App', 'version' => '1.5' ) );

Tutorials, Videos, More Documentation, Community Support

Our Community Manager Josh Pollock has had a task list that would scare away just about any other developer out there and he’s been whittling it down getting into every corner of the project and our wish list for improving the new user experience including new tutorials, video screencasts, and more documentation updates. You’ve also been seeing him around our Forums and GitHub, if you’ve had the privilege of getting one-on-one attention with him, be sure to thank him for all his hard work 🙂

Unit Testing and Logic Documentation

Pods core contributor Dan Stefan Oprean has been hard at work at getting us on track to full logic documentation and the associated unit test coverage that we’ve always wanted, we’ll post updates about that as it progresses.

Metamorphosis core plugin project for WordPress and Sunrise

Over the past few weeks I’ve been involved as the backup lead on the Metamorphosis core plugin project and collaborating with Mike Schinkel who has been sharing his experience with developing Sunrise, specifically which he’s done heavy architecting for that Pods could really really use in our very first iteration of Loop Fields. I’m a big fan of Mike’s and his proposed storage for repeatable data is extremely compelling compared to what we were about to implement. We’re working out the specifics right now, but there may be additional architecture from Mike’s projects that find their way back into Pods core.

Metamorphosis is going to change WordPress in the same way that real Custom Post Types support in WordPress 3.0 did. Custom fields will finally have an API for registration and their own built-in forms and varying field types. Yes, it will probably cause a few plugins to stop development or become unnecessary, but just like Pods and the introduction of Custom Post Types to WP core, our plugin use-cases remain generally unaffected. And just like Pods 2.0, future versions of Pods will continue to evolve right along with WordPress core and we welcome the standardization of custom fields for what seems to be a growing and very busy plugin space for Custom Post Types and Custom Fields. Luckily, we’ve had a lot of involvement from existing plugin developers in that space and we’re getting some great feedback and direction for the project based on real-world experiences, with their plugins combined usage by hundreds of thousands, maybe even millions of users.

Release Schedule

I know you’re all wondering, OK we love what we’re seeing here, but how much longer do we have to wait?

So time frame — Pods 3.0 right now is very alpha, not usable on test sites because we’ve been ripping out the old “huge array” architecture and switching to the better performing PodsObject class structure. Once that’s done, we’ll be running tests against the features again and will be revisiting Loop Fields with the new research gained from the Sunrise project and finish up the Field Editor revamp. We are a couple weeks out until we’re over that hump of getting PodsObject and Loop Fields finalized, but once that’s done, we’ll be pretty close and ready for an extended beta testing period. That point, we hope you’ll all join us in testing the living code out of Pods 3.0 to ensure no issues remain.

Well, that’s it for me, back to the code, be sure to follow @podsframework on Twitter or like the Pods Framework Facebook page for day-to-day updates as they go. You can find me in the normal place @scottkclark, over and out!