I just gave access to a group of users and developers to our new documentation area, they also now have access to post on this development blog to keep everyone updated. They now have access to add/edit docs for 1.x and 2.0 documentation. If you think you’d like to help out, just reach out and let us know.
We’re going to use this post to keep track of the deprecated functions and methods for you to reference at a glance. Pods 2.0 is backwards compatible, but we recommend you update your usage as you’re able to so you avoid any headaches down the road.
The Pod() class has had a makeover! Below are some new things you can do, we hope you enjoy the changes.
The Pod() class has been renamed to Pods(), your old code should point at the new class and methods though, but you should take advantage of the new usage which is much easier to use and understand.
// Get data for a pod $mypod = new Pod( 'mypod' ); // Get data for an item $mypod = new Pod( 'mypod', $id_or_slug ); // Maps to findRecords $mypod = new Pod( 'mypod', $params );
// Get the pod object $mypod = pods( 'mypod' ); // Get data for an item $mypod = pods( 'mypod', $id_or_slug' ); // Maps to the new find method $mypod = pods( 'mypod', $params ); // NEW! Get the pod object, find data, output each item using the template echo pods( 'mypod' )->find( $params )->template( 'template/name' );
// Get a field's value $value = $mypod->get_field( 'my_field' ); // Get the value of 'name' from the related field's item(s) $name = $mypod->get_field( 'my_related_field.name' ); // Order the return of the related field values $value = $mypod->get_field( 'my_related_field', 'name DESC' );
// Get a field's value $value = $mypod->field( 'my_field' ); // Get the value of 'name' from the related field's item(s) $name = $mypod->field( 'my_related_field.name' ); // Order the return of the related field values $params = array( 'name' => 'my_related_field', 'orderby' => 'name DESC' ); $value = $mypod->field( $params ); // NEW: Get the first value of the related items, just like get_post_meta( $id, $key, $single ) works $params = array( 'name' => 'my_related_field', 'single' => true ); $value = $mypod->field( $params ); // NEW: Get the first value of the related items, just like get_post_meta( $id, $key, $single ) works $value = $mypod->field( 'my_related_field', true );
// Get 15 records, ordered by name descending, where the name isn't Buster $mypod->findRecords( 'name DESC', 15, 'name != "Buster"' ); // Get 15 records, ordered by name descending, where the name isn't Buster $params = array( 'orderby' => 'name DESC', 'limit' => 15, 'where' => 'name != "Buster"' ); $mypod->findRecords( $params ); // Get 15 records, ordered by name descending, where the name isn't Buster $params = array( 'orderby' => 'name DESC', 'limit' => 15, 'where' => 'name != "Buster"' ); $mypod = new Pod( 'mypod', $params );
// Get 15 records, ordered by name descending, where the name isn't Buster $params = array( 'orderby' => 'name DESC', 'limit' => 15, 'where' => 'name != "Buster"' ); $mypod->find( $params ); // Get 15 records, ordered by name descending, where the name isn't Buster $params = array( 'orderby' => 'name DESC', 'limit' => 15, 'where' => 'name != "Buster"' ); $mypod = pods( 'mypod', $params ); // Get 15 records, ordered by name descending, where the name isn't Buster $params = array( 'orderby' => 'name DESC', 'limit' => 15, 'where' => 'name != "Buster"' ); $mypod = pods( 'mypod' )->find( $params );
// Add an item // It maps to PodsAPI::save_pod_item, does not pass the current ID $mypod->add( $params ); // Save an item // It maps to PodsAPI::save_pod_item, automatically passes the current ID for you $mypod->save( $params ); // Delete an item // It maps to PodsAPI::delete_pod_item, automatically passes the current ID for you, or you can set another $id to be deleted $mypod->delete( $id ); // Duplicate an item // It maps to PodsAPI::duplicate_pod_item, automatically passes the current ID for you, or you can set another $id to be deleted $mypod->duplicate( $id );
“The problem was fear of failure. When it came to my own work, I wanted all three — Features, Stability, AND On-time — and I didn’t want to accept my own limitations. Lesson learned, and since WordCamp San Francisco 2012, Pods 2.0 has now gone beta!”
“[a] benefit to me learning about Unit Testing is that I can now use that same knowledge to improve how Pods 2.x is developed while maintaining stability.”
#WCSF 2012 had a profound effect on me, I go into more detail about it on the RD2 blog:
http://www.rd2inc.com/blog/2012/08/my-time-at-wordcamp-san-francisco-2012/
Check out this new component we created yesterday. It can be enabled under Pods Admin > Components. It will walk you through the simple process of migrating your Custom Post Types and Taxonomies directly from Custom Post Type UI into Pods 2.0 — It will import all of your labels and settings, so you can now save all of that time instead of doing it manually.
Pods Contributors – If you’re looking to get Pods 2.0 credit (even if your work was redone or refactored), let me know via e-mail and I’ll make sure you’re listed on the official contributors list coming out soon. Please include your full name, your website, your podsframework.org username, the company you are with and the company’s site (if you wish a company to be listed).
Below is a full list of features for Pods 2.0, mostly highlighting new features / changes.
We are sticking to our core template engine which uses {@field_name} syntax for outputting fields. It is definitely possible to filter before it hits our engine so you can override with any template engine you’d like. Good plugin idea for you 
Pods is free and will remain free, but check out how much effort it’s taken to get it to where it is today!
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.
You may not have been aware of this, but Pods 1.x installs custom tables to store it’s information in a way that’s usually standard for standalone PHP projects. Here’s the table list we had in Pods 1.x, 7 core tables in all:
In Pods 2.0, we set out to develop code that performs better and to optimize our database table structures. In that process, we reduced the number of tables substantially down to 4 core tables in all:
While developing Pods 2.0, Automattic started giving us attention and moved forward to officially sponsor our development. We consulted with their server team over at their VIP hosting platform and determined that some of our 2.0 tables could be reduced even further. As a result, Pods 2.0 as of Alpha 32 now has only 1 core table in all:
Where did they all go? They’re now stored as post types and custom post meta fields. Don’t worry, you don’t have to learn new code, our API remains the same and you can now utilize our API to do even more. We interface with WP_Query and the WP object post/meta update functions. We’re also storing full Pods and their options in transients for even more performance and less MySQL queries per page.
It’s still not ready for primetime on the VIP hosting service, but in Pods 2.1, we’ll make our custom core tables completely optional. Individual Pod tables are already only created as an opt-in process when creating / extending content types in Pods 2.0, so that option will be removed if the tableless mode is enabled in 2.1. The wp_pods_rel table will also not be created or used, and instead the native meta tables for each content type will be used to store that relationship information. Pods 2.0 already stores a backup copy of relationships in wp_postmeta to make that transition easier.
We’re looking forward to further improving Pods throughout 2.x, thanks for hanging in there throughout our ever evolving project.
I think I’m missing something…
Wasn’t using custom tables for pods stuff lighter and with a smaller footprint than wordpress meta system?
We didn’t need as many tables as we had in 2.0 anyway, we could have accomplished the same thing with just two core tables, wp_pods and wp_pods_rel, where wp_pods served as the table to store Pods, Pod Fields, Pod Templates, Pod Pages, and Pod Helpers. But if we’re reducing tables, we might as well go into Post Types as the performance and footprint is greatly reduced through our usage of Transients and Object caching already. So, yes, on a data side it is a smaller footprint to have custom tables than to use Post Types and Meta, but reducing custom tables ensures that Pods can scale on larger hosts that have architecture-limitations when it comes to custom tables (Like WP VIP has, among others).
We’ll still have package import/export available just like in Pods 1.x.
Something in 2.x I’d like to see is the implementation of a standard template engine vs building yet another one. Does anyone have any preference here, or are there other engines you’d like to vote for if you had the choice? Well, you have the choice! Community decision time!
Which template engine should we use?
My question is “what are you aiming to achieve with a template engine?”
In my experience they are usually incorporated with the goal of making it easier for non-technical people to modify page templates. But PHP IS a template engine. For trivial cases, PHP code is not that much more unreadable or harder to use. For more complex cases, I’ve never seen a Template engine with a syntax that makes things any easier for non-technical people, and you often run into limitations that require rolling up the sleeves and writing it in pure PHP anyway.
In the end you have to learn another syntax that is proprietary and less general purpose, you add a layer of parsing to slow things down, and in the end it’s no more productive for devs or friendly for non-devs. Just my two and a half cents.
Good points, this is really just a preliminary question. We are progressing things in 2.x to allow for a bit more non-php functionality that could be securely/safely handed off to non-programmers for use within normal WP content areas. It’s just a step further than our current templating, which only offers single variable usage. Rather than write our own proprietary and less general purpose parsing layer, we’re just openly looking at other solutions to perhaps integrate with.
I agree – template engines just add more bulk and I don’t really see the point.
I hope that Pods won’t go the direction a lot of other plugins go of trying to make it so “easy for non-technical people” that the plugin ends up bloated and difficult for actual developers to use. There is already a lot of stuff out there for non-technical people…we need good WP tools for actual development! I’d rather have a command line scaffolding tool than pages and pages of GUI configuration any day.
Smarty, please!
Mustache for sure. That will lead to awesome front-end JS template wizardry using the same templates.
What about HamlPHP?
Actually, I have a better idea (I guess). I don’t you guys define an IPodsTemplateParser interface and let the community contribute the template engine implementations? I would be happy to integrate HamlPHP. IF all it takes is to implement an interface. Yii Framework has something like that, and it was really easy to integrate with.
That’s doable, we’ll go that route. No complex templating built in, it’ll only be the [pods] shortcode and magic tags. If you want to enable other templating engines, you can certainly hook into the template output filter which will allow you to do just about anything you’re after with any templating engine you prefer.
If the template output filter happens BEFORE the evaluation of the actual output, then yes. That’s all it’s needed. Because the template processor will need the environment to correctly process the template. Actually, (I just had a quick look at the pods code and came back) I didn’t see any variables available to the template (Correct me on this if I’m mistaken on this, it’s been a long time since I used Pods). If I’m right, it would be nice to add a variable $pod available to the template containing the current pod to be displayed. Anyway, it seems that the best way to hook a template parser would be using the ‘do_template’ hook, but I think you shouldn’t process magic tags, or at least, make it optional, because it can conflict with weird template languages.
Right, you would essentially plug your own template engine in, which would take over entirely from the built-in templating we have through Magic Tags {@field_name}
Handlebars, please (Mustache ++)
An additional advantage to going setting the parser up as an API instead of a core piece would be making caching much more extensible. For instance, pods could check and see that the install has an object cache running and provide the option “Do you want to cache this template? If so for how long?” then use the api to server a cached object instead of rendering the template.
Shhhh, stop telling all the 2.1 secrets
Sorry about all the typos … it’s still early out here.
New site is launched, it’s been a long time coming and it’s awesome that it’s done. There’s still so much that we’d like to do to make it better so it will continue to be an evolution.
Thanks to Tim Sheehan and Ben Favre for their help with the site, could not have done it without them! Main site design by Iron to Iron, tweaked further by Tim Sheehan.
Great job guys! Congratz
Looks and feels great. Thanks to all involved!
Site looks great guys! Excellent work!
Begin with the User Guide. If that doesn't help, check out the Forums. If you're still stuck, we try to be readily available to chat via IRC in #podsframework on freenode. There's also a Developer Directory if you're looking to hire a developer or firm.
Get news, code snippets, and development updates from @podsframework on Twitter
Scott Kingsley Clark
Phil Lewis 
Siobhan McKeown 
Mike Green
Dan Stefan Oprean
Jonathan Christopher
Matt Gibbs
If you love Pods and want to support its continued development, please consider donating. Any donation will help us cover development time for new features, bug fixes, server costs, and other project expenses.
You can always contribute your ideas, code, and time by joining the discussion over at our Dev Blog.
Kurt M are discussing. 
bjornet is discussing. 
bakaburg1 are discussing. 
Which template engine have you decided to go with?
I’m seeing Pods as an alternative to ExpressionEngine, so I’m hoping it’s something similar to theirs. Smarty is as close as I could find. I’m a front-end only designer, hence why I prefer EE’s templating to WP’s, so I’m hoping it doesn’t end up being another language in itself.
That would be a deal breaker for me.
Heroframework.com uses it and that’s the closest CMS to EE out there.