Pods Framework now integrates directly with Paid Memberships Pro which is a versatile membership plugin that lets you restrict content through recurring subscription payments.

The Pods Integration Add On for Paid Memberships Pro allows you to extend Paid Memberships Pro in ways never before possible. Not only can you add groups of custom fields directly to your Checkout page, you can also add them to Member Profiles, Extend Orders with new fields, or Extend Membership Levels.

You can also use the new Pods Blocks in Pods 2.8 to display information from Members, Orders, and Membership Levels.

Extending and displaying objects in PMPro has never been easier. Thanks to the Pods Framework and the efforts of the new Product Manager for PMPro, Scott Kingsley Clark — this sends Pods into a whole new direction.

Get ready for more integrations in the coming year as a result of the advancements made here!

Behind the Scenes: The powerful new Forms API in Pods 2.8

One of the things that’s very special about this integration is the new underlying API functionality that was built to allow short and concise integration with each PMPro object type.

Pods already has form(), the Pods Form block, and the Pods Form shortcode — but when it comes to embedding Pods fields directly into other pre-existing forms it has been an area of Pods that hasn’t received much abstraction… until now.

Using the following code, we can automatically render fields (on their own, within the existing <form> on a PMPro page). For this, we can also specify which section we want to get groups of fields for. In the PMPro Pods Integration, it allows groups and fields to specify which section(s) they will appear on.

The integration is quick and requires very little code.

pods_form_render_fields( 'pmpro_membership_level', $level->id, [
	'section_field' => 'pmpro_section',
	'section'       => 'after_billing_details_settings',
] );

Let’s break that down

1. We first tell pods_form_render_fields() which Pod name we need to render fields for.
2. Then we tell it which item ID we are editing, or 0 (zero) if not editing.
3. And finally, we pass in any limiting factors, in the example above we tell it we want to limit by the section field option pmpro_section and then the section value we want to limit by.

pods_form_render_fields( 'your_pod_name', $item_id, [
	'section_field' => 'your_section_field',
	'section'       => 'whatever_section_you_want',
] );

The full list of supported options for that third argument is useful because it can let you customize the rendered groups of fields to fit the needs of the form itself.

• render will let you choose how you want to output the groups of fields. Default is table but you can also use table-separated if you are rendering within an existing table, table-rows to just render rows of the form (using a colspan for the separator), and finally div-rows to output the groups of fields within normal <div> tags.
• section_field will let you limit by a specific section if you provide the section field to limit
• section will check the value of your section_field only only render groups/fields that match
• separator will let you choose to show a separator between groups of fields, even if they are tables. The options are before, after, and off if you don’t want it to show.
• heading can let you choose the heading tag used for the group titles. Default is h2.
• separated_heading will let you specify an additional heading to show directly after the groups of fields if needed, when using the render option for table-separated.

Now we need to save the field values

This part is even easier, all we need to do is call the one-line function:

pods_form_save_submitted_fields( 'pmpro_membership_level', $level_id );

Just like the pods_form_render_fields() example above, it needs to know which Pod name we want to save field values for, and which item ID we are saving them to. The item ID is important here because we do not want to create a new item.

pods_form_save_submitted_fields( 'your_pod_name', $item_id );

The full list of arguments supported is: pods_form_save_submitted_fields( $name, $object_id, $is_new_item = false, array $options = [] ) and you could pass in the section_field / section options again here if you’d like. Setting $is_new_item to true would just inform the Pods actions that run that it was a new item being saved which can be helpful for certain integrations/customizations.