How much does Pods cost?
Pods is free and will remain free, but check out how much effort it’s taken to get it to where it is today!
Pods is free and will remain free, but check out how much effort it’s taken to get it to where it is today!
The Pods Framework has been around since late 2008. Planning, design, development, and testing started in 2010 for Pods 2.0 leading to an Alpha release on January 2nd, 2012. Beta was released on August 12th, 2012. Now Pods 2.0 has finally arrived, as of September 21st, 2012!
After our soft launch, we’ve been working on bug fixes for the past few weeks to ensure maximum stability and backwards compatibility before going full force with our 2.0 announcement. That point has been reached and we’re ready for the flood of new users that awaits, including our awesome Pods 1.x users who are anxious to upgrade.
Have at it, and most of all — Enjoy the freedom of developing any type of content with any type of field that you can think of for WordPress!
Please report bugs and suggest features in our GitHub Issues area. We’ve got an awesome feature line up for Pods 2.1 that is already in progress, we’ll announce our 2.1 testing program in the next month. Pods 2.1 is scheduled to be released alongside WordPress 3.5 on December 5th, 2012.
We have to really thank Automattic and Matt Mullenweg for all they’ve done to help us, we honestly could not have finished Pods 2.0 and taken it to the next level without their support.
RD2 provided some awesome UI design work for our new 2.0 upgrade screens.
MarkNet Group provided extra help when we needed it to keep the project going over the past two years, major kudos!
Below is a feature list that goes over what 2.0 offers, we hope you enjoy it as much as we have while we’ve used it on our own projects.
Holy Cow in a plugin Scott! I’ve been looking at it since Thursday afternoon and it’s absolutely wonderful. The UI is great, intuitive, and very forgiving when you’re making mistakes. Love seeing how far you’ve come with Pods as it is by far one of the most powerful plugins/frameworks/extendomatic-in-a-box things to to ever happen to WordPress.
I’m a big fan of how you re-vamped “Helpers”. Using it as a custom post type with the built-in WordPress revisions feature is spot on smart. This is honestly the first time I’ve ever looked at Pods 2.0 in any of its forms. The really cool thing to me is that you created “Helpers” in a way that provides flexibility and history. Using Code Mirror for syntax highlighting, storing it as a custom post type, and utilizing WordPress’ built-in revisions function takes “Helpers” light years beyond what it was in the 1.x.x releases. As a long time user of Pods I’m completely overjoyed with Pods 2.0!
Again, thanks for all that you’ve contributed to the WordPress community.
It’s messages like these that make what I do worth it. That’s exactly what I set out to do for Pods 2.0, so I’m very glad that was successful!
Had my chat with Mark Jaquith today over the security behind the new Pods 2.0 Forms, it wasn’t a full security audit but Mark was consulting me on what we’re doing and has confirmed that what we’re doing will be secure. We’ll setup a full security audit (boy that’ll cost some $$$, we’d better start saving up now) when 2.0 gets closer to being ready or shortly after release.
So many of our users enjoy the awesomeness that is Gravity Forms! It’s been in the works for a while now but I’ve finally got some traction on this. I’d like to take a moment and get everyone’s input on what they’d like to see this new Add-on do, how it would work, etc.
BTW, this would be a free add-on available to any Gravity Forms license holder! I know Add-ons are restricted to only those who have the Developer License, but we’ll be maintaining / supporting this one separately. Might even bundle it with the Pods plugin itself (just running a check to see if Gravity Forms is installed and if so including the GF-specific code.
Some features I’m looking at out of the door:
1. Another face for publicForm – in which you create your Gravity Form and point it at a Pod, choose which fields go where, and when people fill out the form it will save data to a specific Pod via the PodAPI.
2. Add drop-downs, radios, and checkboxes to your Gravity Form based on Pod data, keeping things dynamically populated and up-to-date with your Pod items as opposed to having to update a static list of items all the time. Think of how Pods lets you add Relationship fields, except in GF and pointed only at Pods.
My two favourite plugins, together at last
Absolutely. I’m putting off using pods because i need to accept user data via grav forms and publish the data in a post. I would love to do this via PodAPI making the use of custom fields redundant and publishing data via pods.
This would be awesome!
That would be amazing.
I had my meeting with one of the GF developers and he’s given me a lot of information to work with. So now it’s just a matter of finishing up 2.0 and getting onto this feature for 2.x
That is so cool! Pods and Gravity would be like peanut butter and chocolate!
So I’ve used GForms a ton and some of their addons a little and the best integration between GForms and Pods would be to sync up and existing form to an existing pod. Perhaps the approach should be a “mapping” approach. Select a form and then select the appropriate pod fields that should be populated. There’s potential for a lot of redundancy here since a big part of Pods is the “public forms” functionality. But I guess the appeal of gravity forms is that there’s a slick GUI for creating the forms.
Mapping is exactly where I’m headed in #1 of my above comment.
I like the idea very much, can’t wait to see it in action
Is this still in the works?
Yes, I’ve got a significant amount of code for this, it needs to be a little more generalized, and then have the UI tied into it so devs don’t have to do a ton of extra coding for normal day-to-day field mapping.
Thought came up through Bjornet’s recent question – attaching comments to file uploads / images. Right now, we store the relationship itself and the order — but not meta data. It would be useful in Pods 2.0 to at least build in functionality to the DB table itself for this so people can extend infinitely through the new standard.
As for the standard itself, anyone have any ideas how to fit meta data for a field within the current PodAPI::save_pod_item function? I’ve got my own, but I’m interested in other opinions.
This same question comes up as we think about how to duplicate multi-fields to relate to each other as well as the original Pod item. Yes, some of these duplicate fields can be Pod-powered (sourced / stored as their own Pod items) but what about for one-offs?
I think duplicatable groups of fields should always be stored as a related Pod even if it’s only a single field. Perhaps the related Pod table could be created automatically when the field or group of fields is labeled as duplicatable, so the user doesn’t have to do it manually. Maybe certain Pods like these could even be labeled as a “dependent” Pod that is hidden and can’t easily be edited outside of the main Pod.
This is the way Drupal CCK does it I believe. I’m not opposed to this, just wondering how to handle existing context like with File / Image uploads.
If you plan to have some way to “group” fields inside a pod, I guess that there may be the option to add helpers to the group as a whole, as for having better different fields interacting for UI purposes. Groups themselves may have some other field options, too.
bjornet 8:23 pm on September 5, 2012 Permalink | Log in to Reply
I really appreciate you for showing this, this example helps me as developer to set a decent pricetag on my work and of cause understand the tremendous amount of work you guys have put into Pods.