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!
Tagged: 2.0 RSS Toggle Comment Threads | Keyboard Shortcuts
-
sc0ttkclark
-
sc0ttkclark
Pods 2.0 has arrived!
Background
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!
Bug Reports / Feature Requests
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.
Big Thanks to our Sponsors!
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!
What’s new?
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.
- Slick new interface, fully revamped to make managing your Pods easy and stress-free
- Large performance enhancements using transients and object caching (reducing queries per page load in both dashboard and site to the lowest possible number, sometimes that’s ZERO)
- New Upgrade wizard screens designed by RD2 will help you upgrade from previous versions and report any potential known issues beforeit actually upgrades your site
- We’ve partnered with Automattic to offer 1 free month of VaultPress service to users upgrading from Pods 1.x, you will see the offer in the upgrade screens.
- We’ve also partnered with iThemes to offer 25% off of a BackupBuddy license to users upgrading from Pods 1.x, you will see the offer in the upgrade screens.
- Add New Pod wizard guides you through creating or extending content types with custom fields
- Create New Content Types
- Custom Post Types
- Custom Taxonomies
- Advanced Content Types (each type lives in it’s own table, outside of the WP object architecture)
- Extend Existing Content Types
- Post Types (Posts, Pages, Existing Custom Post Types)
- Taxonomies (Categories, Tags, Existing Custom Taxonomies)
- Media
- Users
- Comments
- Create New Content Types
- Choose to store your data using meta-based storage (default) or custom table-based storage
- New Field Editor and Field Types
- New Field Type options built in (no more input helpers for most common input types!)
- Date / Time – Date, Time, or both
- Number – Plain Number or Currency
- Text – Plain Text, Website, Phone, E-mail, or Password
- Paragraph Text – Plain Paragraph, WYSIWYG (TinyMCE or CLEditor, or add your own), or Code (Syntax Highlighting)
- Color Picker – Choose colors, because colors are great (Using the default WP color picker, Farbtastic in 3.4)
- Yes / No – You can’t really go wrong with a checkbox, but we’ve added a few charms to make it stand out
- File / Image / Video – Upload new media or select from existing ones with our Media Library integration, or use a simple uploader, your choice
- Relationships – Relate any item, to any item of any WP object type or another Pod, now with improved Bidirectional relationship support
- New Field Type options built in (no more input helpers for most common input types!)
- New grouping fields API on the Add/Edit forms for Post Types, Taxonomies, Media, Users, and Comments (We’re adding a management UI for this coming in 2.1)
- New Shortcode popup integration with TinyMCE editor (now provide one-off templates within the shortcode itself)
- New Widgets (and provide one-off templates within the widget itself)
- New Form UI front and back
- New Attachments option available for File Uploads allows you to click “Attach” and select media items from the normal built-in WP Media Library pop-up
- New Componentsallow additional functionality to be enabled but not loaded if you don’t want/need them
- Pod Templates
- Pod Pages
- Pod Helpers
- Roles and Capabilities
- Add / Edit Roles (Administrator, Editor, etc..)
- Add / Edit Capabilities for each Role
- Markdown Syntax for Paragraph Text fields
- Migrate: Import from Custom Post Type UI
- Import Custom Post Types and Taxonomies created by the Custom Post Type UI plugin
- Import them all, or choose a few
- Optionally cleanup the Custom Post Type UI options when done, removing the imported objects from it’s control
- Basic WPML Integration and confirmed Polylang compatibility
- Fully Localized interface and error messages! All of our text strings in the plugin now run through the i18n functions. We don’t have any translations yet, but we’re looking at getting GlotPress setup for translators to start getting in.
- Requires at least WordPress 3.4 and is tested against WordPress 3.4 and 3.5 releases
Not sure about Pods 2.0 yet? Screenshot time!
-
hsatterwhite
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.
-
sc0ttkclark
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!
-
-
sc0ttkclark
Enhanced Field Types
We spent some time tonight and landed on an enhancement we hope you will enjoy… We’ve broken out the Text, Paragraph Text, Number, and Date / Time fields into groups of field types!
Check them out in the beta now, or look below for a quick view of how it looks. You might even realize you missed a field capability you hadn’t noticed before
You can click the image above to enlarge.
-
sc0ttkclark
Differences between 1.x and 2.0
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.
Pod() class
The Pod() class has had a makeover! Below are some new things you can do, we hope you enjoy the changes.
Calling the Pod() class
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.
Old
// 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 );
New
// 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_field
Old
// 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' );
New
// 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 );
findRecords
Old
// 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 );
New
// 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 );
NEW: Call API methods right from the Pods object!
// 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 );
-
sc0ttkclark
Reflecting on WordCamp San Francisco 2012
“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/
-
sc0ttkclark
New Component: Import Post Types and Taxonomies created by the Custom Post Type UI plugin
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.
-
sc0ttkclark
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).
-
sc0ttkclark
Pods 2.0 – Full Feature List
Below is a full list of features for Pods 2.0, mostly highlighting new features / changes.
- Slick new interface, fully revamped to make managing your Pods easy and stress-free
- Large performance enhancements using transients and object caching (reducing queries per page load in both dashboard and site)
- New Upgrade wizard screens designed by RD2 will help you upgrade from previous versions and report any potential known issues before it actually upgrades your site
- We’ve partnered with Automattic to offer 1 free month of VaultPress service to users upgrading from Pods 1.x, you will see the offer in the upgrade screens.
- We’ve also partnered with iThemes to offer 25% off of a BackupBuddy license to users upgrading from Pods 1.x, you will see the offer in the upgrade screens.
- Add New Pod wizard guides you through creating or extending content types with custom fields
- Create New Content Types
- WP Objects
- Custom Post Types
- Custom Taxonomies
- Custom Content Types (each type lives in it’s own table, outside of the WP object architecture)
- WP Objects
- Extend Existing Content Types
- Post Types (Posts, Pages, Existing Custom Post Types)
- Taxonomies (Categories, Tags, Existing Custom Taxonomies)
- Media
- Users
- Comments
- Create New Content Types
- Choose to store your data using meta-based storage (default) or custom table based storage
- New Field Editor and Field Types
- New Field Type options built in (no more input helpers for most common input types!)
- Date / Time
- Date
- Date Format (m/d/Y etc)
- Toggle on/off HTML5 Input
- Time
- Time Format Type (12 hour / 24 hour)
- Time Format
- Toggle on/off HTML5 Input
- Time + Date
- Both noted above combined
- Date
- Number
- Plain Number
- Format (localized ie: 20,000)
- Choose # of Decimals
- Currency
- Currency Sign
- Currency Placement
- Format (localized ie: 3.000,00 vs 3,000.00)
- Choose # of Decimals
- Plain Number
- Yes / No
- Checkbox
- Radio Buttons
- Dropdown
- Text
- Plain Text
- Allow Shortcode
- Allow HTML
- Allow Markdown Syntax (with included Component)
- E-mail
- Maximum Length
- Toggle on/off HTML5 Input (type=”email”)
- Phone Number
- Format / International (ie: +1 123-123-1234)
- Enable / Disable Extensions
- Toggle on/off HTML5 Input (type=”tel”)
- Website
- Format (ie: with or without the www, include http:// etc)
- Maximum Length
- Toggle on/off HTML5 Input (type=”url”)
- Password
- Minimum Length
- Maximum Length
- Plain Text
- Paragraph Text
- Plain Text
- Allow Shortcode
- Allow HTML
- WYSIWYG
- TinyMCE
- CLEditor
- Allowed HTML Tags
- Allow Markdown Syntax (with included Component)
- Plain Text
- Permalink (url-friendly)
- Color Picker (Using the default WP color picker, Farbtastic)
- File Upload
- Single Select
- Plupload
- Attachments (WP native UI)
- Multiselect
- Plupload
- Attachments (WP native UI)
- Limit # of Files
- Restrict File Size
- Restrict File Type (image files, video files, or custom list of extensions)
- Excluded Image Sizes (for images, excluded from auto-resizing)
- Single Select
- Relationship
- Related To
- Custom List (line separated)
- Other Pods
- Post Types
- Taxonomies
- Users
- Comments
- Single Select
- Dropdown
- Radio
- Autocomplete
- Multiselect
- Multiselect
- Checkboxes
- Autocomplete
- Related To
- Date / Time
- Advanced Options
- CSS Class Name
- Default value
- Choose to dynamically populate value from query
- Access level permissions (only let admins or editors edit a field)
- Custom RegEx validation rules and messages
- Set Maximum Length for field (for strings and numbers)
- New Field Type options built in (no more input helpers for most common input types!)
- New grouping fields API on the Add/Edit forms for Post Types, Taxonomies, Media, Users, Comments, and Custom Content Types (UI coming in 2.1)
- New Shortcode popup integration with TinyMCE editor (and provide one-off templates within the shortcode itself!
- List items
- Show detail of an item
- Show a field from an item
- New Widgets (and provide one-off templates within the widget itself!)
- List items
- Show detail of an item
- Show a field from an item
- New Form UI
- New Attachments option available for File Uploads allows you to click “Attach” and select media items from the normal built-in WP Media Library pop-up
- New Components allow additional functionality to be enabled but not loaded if you don’t want/need them
- Gravity Forms Integration
- Map a Gravity Form’s fields over into a Pod of any type (so many combinations!) to save automatically when the form is processed
- (Disclosure: The above link is an affiliate link that pays the Pods Foundation if you make a purchase, any funds will go towards additional development of our Gravity Forms integration, please use it!)
- Roles and Capabilities
- Add / Edit Roles (Administrator, Editor, etc..)
- Add / Edit Capabilities for each Role
- Markdown Syntax for Paragraph Text fields
- Migrate: Import from Custom Post Type UI
- Import Custom Post Types and Taxonomies created by the Custom Post Type UI plugin
- Import them all, or choose a few
- Optionally cleanup the Custom Post Type UI options when done, removing the imported objects from it’s control
- Gravity Forms Integration
- Basic WPML Integration (Disclosure: This link is an affiliate link that pays the Pods Foundation if you make a purchase, any funds will go towards additional development of our WPML integration, please use it!)
- Requires at least WordPress 3.4 and is tested against WordPress 3.4 and 3.5 releases
-
Kurt M
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.
-
sc0ttkclark
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
-
-
sc0ttkclark
Pods core table structure differences between Pods 1.x, Pods 2.0 Alpha, and Pods 2.0 Alpha 32
Pods 1.x
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:
- wp_pod – This table was used to store an index of every pod item you create, along with some core information. It was like a ‘wp_posts’ table in a way. It wasn’t my decision but I believe the reason behind it was the same as wp_posts, but it could also have been the fact that the old Manage Content interface had all of the items together (but filterable by pod), which proved to be harder to manage in certain circumstances. Since around Pods 1.10 when we merged Pods UI, our interface has been separated out for a better UX while the table itself remained in place.
- wp_pod_types – This table was used to store a list of all of the Pods you created and their corresponding options.
- wp_pod_fields – This table was used to store a list of all of the fields for the Pods you created and their corresponding options.
- wp_pod_templates – This table was used to store a list of all of the Pod Templates you created.
- wp_pod_pages – This table was used to store a list of all of the Pod Pages you created.
- wp_pod_helpers – This table was used to store a list of all of the Pod Helpers you created.
- wp_pod_rel – This table is used to store a information on each relationship or file field you have for a pod, on a per-item basis. It makes it easy (and perform better) for MySQL queries to do more complex things with fewer joins and hacks.
- wp_pod_tbl_* – These tables are created for every Pod you create. Every non-relationship and non-file field you create, gets it’s own table column sculpted around the field type it is. A number field becomes a number column, a date field becomes a date column, and so on.
Pods 2.0 Alpha
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:
- wp_pods – This table was used to store a list of all of the Pods you created and their corresponding options.
- wp_pods_fields – This table was used to store a list of all of the fields for the Pods you created and their corresponding options.
- wp_pod_objects – This table was used to store a list of all of the Pod Templates, Pages, and Helpers you created.
- wp_pods_rel – This table is used to store a information on each relationship or file field you have for a pod, on a per-item basis. It makes it easy (and perform better) for MySQL queries to do more complex things with fewer joins and hacks.
- wp_pod_tbl_* – These tables are created for every Pod you create or extend (opt-in, the default is to not create a new table and use native meta-based storage). Every non-relationship and non-file field you create, gets it’s own table column sculpted around the field type it is. A number field becomes a number column, a date field becomes a date column, and so on. The old Pods 1.x wp_pod table was merged into these, so each pod table is exactly what you want and need, letting you remove the name, created, updated, and author fields for the content types that don’t need it.
Pods 2.0 Alpha 32
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:
- wp_pods_rel – This table is used to store a information on each relationship or file field you have for a pod, on a per-item basis. It makes it easy (and perform better) for MySQL queries to do more complex things with fewer joins and hacks.
- wp_pod_tbl_* – These tables are created for every Pod you create or extend (opt-in, the default is to not create a new table and use native meta-based storage). Every non-relationship and non-file field you create, gets it’s own table column sculpted around the field type it is. A number field becomes a number column, a date field becomes a date column, and so on. The old Pods 1.x wp_pod table was merged into these, so each pod table is exactly what you want and need, letting you remove the name, created, updated, and author fields for the content types that don’t need it.
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.
- _pods_pod – Pods and their options
- _pods_field – Pod fields and their options
- _pods_object_template – Pod Templates and their options
- _pods_object_page – Pod Pages and their options
- _pods_object_helper – Pod Helpers and their options
Tableless Mode to be introduced in Pods 2.1
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.
-
bakaburg1
I think I’m missing something…
Wasn’t using custom tables for pods stuff lighter and with a smaller footprint than wordpress meta system?
-
sc0ttkclark
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.
-
-
sc0ttkclark
Introducing the new Pods 2.0 Upgrade screens
Upgrading Pods to new versions has previously been a silent background process. Things were done, you weren’t given substantial information in case of an error, and there was no UI to guide you through the process. No more!
Our new Pods 2.0 Upgrade screens will guide you through upgrading from Pods 1.x to Pods 2.0, and any future upgrades that may be necessary throughout Pods 2.x – and it’s beautiful! Thanks to the incredibly generous RD2 team and designer Rey Latham for making this happen!
We’ve also partnered up with iThemes to offer 25% off of any BackupBuddy license! BackupBuddy is the all-in-one WordPress backup plugin that lets you backup, restore, migrate, and do it all locally or remotely to a number of different services. Together, we’ve got you covered for whatever your needs are during the upgrade process and beyond.
Screenshots
-
davidangel
Aww man, looks awesome!
-
anditko
Nice and clean design that fits the admin theme. Great job!
-
sc0ttkclark
Upping the requirements for Pods 2.0 to WP 3.4, it only makes sense that our next awesome version uses the latest and greatest, as support for previous versions would be something of a patchwork quilt with all the actions/filters/functions being unavailable, giving users a suboptimal experience with a reduced functionality plugin. It also will help reduce support issues!
Pushing our latest patches in and updating to Pods 2.0 Alpha 14 today. Prepping features for the beta testing period about to hit in a couple of weeks.
bjornet is discussing. 
Kurt M are discussing. 
bakaburg1 are discussing. 
anditko and 
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.