Pods 3.2.1.1 Security Release 8 May 2024 8:16 AM (10 months ago)

This is a Security focused release

A security issue was responsibly reported and this release hardens security so that we properly enforce safe URLs for the Pods form submission confirmation page URLs.

Security hotfixes are now available

Are you running an older version of Pods? A special release has been prepared for each major version back to Pods 2.7 as per our Security EOL policy.

• Hotfix: Pods 2.7.31.3 – Download ZIP from WordPress.org
• Hotfix: Pods 2.8.23.3 – Download ZIP from WordPress.org
• Hotfix: Pods 2.9.19.3 – Download ZIP from WordPress.org
• Hotfix: Pods 3.0.10.3 – Download ZIP from WordPress.org
• Hotfix: Pods 3.1.4.1 – Download ZIP from WordPress.org
• Current: Pods 3.2.1.1 – Download ZIP from WordPress.org

Changelog

• Security hardening: Enforce safe URLs for Pods form submission confirmation page URLs. Props to the wesley (wcraft) / Wordfence for responsibly reporting this. (@sc0ttkclark)

EOL Security Support changes for older Pods versions 10 Apr 2024 8:17 AM (11 months ago)

Now that our usage chart is looking much more colorful after the new major releases we’ve put out in the past two years, it’s time to revisit EOL security support on them.

We have an official security policy in place which explains which versions are supported and which are EOL. Currently any version below Pods 2.7 is no longer supported for security updates.

The most notable change in that policy today is:

A new EOL date has been set for both Pods 2.7 and Pods 2.8 of December 31st, 2024.

This will reduce the overhead for our contributor team supporting those older versions as they can be very time consuming to backport changes to.

Pods 3.2 Feature Release: Meta Revisions and Block Bindings 25 Mar 2024 8:18 AM (last year)

What’s new in Pods 3.2?

This release started out as Pods 3.1.5 but it became clear that Revisions and Block Bindings were features of their own that deserved to be highlighted through a major release.

Changelog

• Feature: New support for Custom Field revisions in Pods that are Post Types that use Meta storage. You can optionally enable the feature per-pod or per-field. #7265 (@sc0ttkclark)
• Feature: New support for WordPress register_meta() for all Pods fields on meta-based Pods. You can enable this feature in Pods Admin > Settings > “Register meta fields”. (@sc0ttkclark)
• Feature: New support for specifying where your Custom Fields show in REST API responses for Pods that support that. You can choose from Object (response.field_name) or Meta (response.meta.field_name). (@sc0ttkclark)
• Feature: New support for Custom Fields in the new WordPress 6.5 Block Bindings API for the core/post-meta source. To use your custom fields there, you will need to enable “Register meta fields” in your Pods Admin > Settings and set your Pod to show it’s REST API fields in the “Meta” location instead of Object. (@sc0ttkclark)
• Feature: New custom binding source support for the WordPress 6.5 Block Bindings API. Specify your source as pods/bindings-field and then just pass the same arguments you would pass for a normal [pods] shortcode or block. This will bind that dynamic output to the block you are working with. (@sc0ttkclark)
• Feature: Now you can specify whether to default values for a Pods field when the field is empty. This works great for when you add a new field to a Pod and you want to edit an existing item that did not have a field value set. The default value will be used in that circumstance. (@sc0ttkclark)
• Feature: Support for multiple default values when working with a multi-select field. Now you can just separate your values with a comma and they will be set as the default values. (@sc0ttkclark)
• Feature: Now you can specify whether to evaluate magic tags for default values like {@user.ID}. (@sc0ttkclark)
• Tweak: New option for Pods shortcodes when used in plugins like Elementor to bypass detecting the loop and to just use whatever ID/post type is available. Use the bypass_detect_loop="1" attribute. #7269 (@sc0ttkclark)
• Tweak: Added first used and last installed Pods versions to the Site Health information to be more helpful with debugging. (@sc0ttkclark)
• Tweak: Improved the field label/description for Additional User Capabilities field in the CPT settings. (@sc0ttkclark)
• Fixed: Resolved an annoying issue when adding a new group or field where it would reset the Pod label to the name (slug) of the pod. (@sc0ttkclark)
• Fixed: Updated logic for default value handling when using magic tags for internal field configs to ensure the magic tags get evaluated. (@sc0ttkclark)
• Fixed: Resolve issue with pods_register_block_type() not clearing the known blocks cache when registering them. #7167 (@sc0ttkclark)
• Fixed: PHP fatal errors resolved with array_combine() usage from changes in WP 6.5. #7266 (@sc0ttkclark)
• Fixed: Custom capability fallbacks when the option is empty now properly fallback to the default capability using that post type name. #7250 (@JoryHogeveen)
• Fixed: PHP deprecated notice with trim(). (@sc0ttkclark)
• Fixed: Resolved plupload browse button references to prevent JS console errors. (@sc0ttkclark)
• Fixed: Resolved issue with window.wpEditorL10n calls to more safely check for it to prevent JS console errors. (@sc0ttkclark)
• Fixed: Updated the implementation of the compatibility hooks for set_transient and setted_transient hooks have the proper args expected sent. (@sc0ttkclark)
• Fixed: Empty REST API fields no longer show when the pod doesn’t support REST API. (@sc0ttkclark)
• Fixed: Restrict/unrestrict dynamic features logic now properly updates all of the associated Pod settings it needs to in the Access Rights Review screen. (@sc0ttkclark)
• Fixed: Empty arrays now return correctly in Pod / Group / Field settings instead of using their defaults when empty. (@sc0ttkclark)
• Fixed: Resolve potential issues with REST API in certain circumstances which would throw exceptions with the Pods REST API Messages object. (@sc0ttkclark)
• Fixed: Resolve issues when duplicating pods where the new pod name is over the limit and prevents creating the new pod correctly. (@sc0ttkclark)
• Fixed: Access Rights Review notice now only shows on existing installs updating from pre-3.1 instead of showing on new 3.1+ installs too. (@sc0ttkclark)
• Fixed: Accessibility issues with tabbing resolved for Pods Admin > Edit Pods table and Pods Admin > Edit Pod fields list table when working with row actions. #7196 #7198 (@heybran, @sc0ttkclark)

Pods 3.1 Feature Release: Access Rights Revamp 21 Feb 2024 2:54 PM (last year)

What’s new in Pods 3.1?

This is a Security focused release

While this release is meant to be as backwards compatible as possible, some aspects of security hardening may require manual intervention by site owners and their developers. Having trouble upgrading? Check out our Upgrade FAQ and Priority Upgrade Support form.

Important documentation for this release

• Access Rights in Pods
• Access Rights Settings in Pods
• Customizing Access Rights in Pods with Constants/Hooks
• Access Rights in WordPress core

Hotfixes are also available

Are you running an older version of Pods? A special release has been prepared for each major version back to Pods 2.7 but they do not include additional customization options and tools for Access Rights that are provided in Pods 3.1.

Note: The .1 versions of the hotfixes had a deployment problem on .org and were incremented to .2 to get around that issue.

• Hotfix: Pods 2.7.31.2 – Download ZIP from WordPress.org
• Hotfix: Pods 2.8.23.2 – Download ZIP from WordPress.org
• Hotfix: Pods 2.9.19.2 – Download ZIP from WordPress.org
• Hotfix: Pods 3.0.10.2 – Download ZIP from WordPress.org
• Full release – Download ZIP from WordPress.org

Changelog

• Security hardening: Introduced new access checks and additional fine-grained control over dynamic features across any place in Pods that allows embedding content or forms. This only applies to usage through Pods Blocks or Shortcodes. Using PHP will continue to expect you are handling this on your own unless you pass the appropriate arguments to the corresponding Pods methods. (@sc0ttkclark)
• Security hardening: Prevent using the Pods Views Block / Shortcode to embed any files outside of the current theme. Props to the Nex Team / Wordfence for responsibly reporting this. (@sc0ttkclark)
• Security hardening: Prevent output of user_pass, user_activation_key, and post_password through Pods dynamic features / PHP. These values will be set in Pods references to **************** if they were not-empty so you can still do conditional checks as normal. While Scott was already aware of this in pre-planned security release work, additional props go to the Nex Team / Wordfence for responsibly reporting this too. (@sc0ttkclark)
• Security hardening: Prevent more unsavory PHP display callbacks from being used with magic tags in addition to those already prevented. Props to the Nex Team / Wordfence for responsibly reporting this. (@sc0ttkclark)
• Feature: Access rights > Access-related Admin notices and Errors can be hidden by admins in a new setting in Pods Admin > Settings > Security. (@sc0ttkclark)
• Feature: Dynamic Features > Dynamic features (Pods Blocks and Shortcodes) can be disabled by admins in a new setting in Pods Admin > Settings > Security. (@sc0ttkclark)
• Changed: Dynamic Features > New installs will now default to not allowing all SQL arguments to be used by dynamic features. Existing installs will default to only allowing simple SQL arguments. All SQL fragments are checked for disallowed usage like subqueries. This can be set in a new setting in Pods Admin > Settings > Security. (@sc0ttkclark)
• Feature: Pods Display > The Display-related Pods Blocks and Shortcodes have additional checks that limit access to content based on the user viewing it. For Post Types that are non-public, they must have access to the read capability from that post type as a normal user. For displaying content from Users, they must have access to list_users capability to view that. Read more about how access rights work with Pods (@sc0ttkclark)
• Feature: Pods Forms > The Pods Form Block and Form Shortcode have additional checks that limit access to creating/editing content based on the user submitting the form. For Post Types that are non-public, they must have access to the ‘create’ capability from that post type as a normal user. Forms that submit to the Users pod, now require that the submitter must have access to the create_users or edit_users capability to create or edit that user. Read more about how access rights work with Pods (@sc0ttkclark)
• Feature: Pods Forms > The Pods Form Block and Form Shortcode now have a new option to identify the form with a custom key you choose that will get passed to various access-related filters so that developers can override access rights more easily. (@sc0ttkclark)
• Feature: Pods Forms > When a user has access to create or edit content through a Pods form for a post type, the post_content field is cleaned based on the level of access they have to prevent inserting unintentional shortcodes or blocks. (@sc0ttkclark)
• Feature: Markdown functionality has now been replaced by the Parsedown library for better security and performance and it’s uniquely prefixed so it prevents future conflicts with plugins using the same library. (@sc0ttkclark)
• Changed: Pods Views > One of the breaking changes in this work is that the Pods Views Block / Shortcode dynamic feature is now disabled by default and must be enabled for new and existing installs. This can be done in a new setting in Pods Admin > Settings > Security. (@sc0ttkclark)
• Changed: Display PHP callbacks > New installs will now default to only allowing specific callbacks to be used. This defaults the specific callbacks allowed to esc_attr,esc_html which can be further customized in Pods Admin > Settings > Security. (@sc0ttkclark)

Background on this release

There were no known attempts to take advantage of the issues resolved by this release. Most of the issues have never even been reported to the Pods team aside from responsible disclosures to us by Wordfence through a security researcher where noted.

On a personal note — This is a release that I’ve been personally planning since WordCamp US in August 2023 when I realized that most people using Pods don’t recognize what WordPress does for Access Rights and Pods isn’t doing enough to elevate that. I’ve been developing this in depth, automated testing, and doing user testing. I’ve worked evenings, weekends, holidays, and in my otherwise free time to ensure that the end result is clean, secure, and reduces headaches for the existing sites that upgrade. I’ve probably spent somewhere around 100 hours of my time on this so that we didn’t have to pay extra development costs and our support could keep going from the already thin Friends of Pods budget.

The other issues and security problems I discovered along the way were addressed accordingly. I did my very best to address everything holistically and as clean as possible. I knew I had to backport everything to previous Pods releases which each had different minimum WordPress versions and minimum PHP versions supported. Nothing was easy and everything was time consuming to get right.

All that is to say — this was a lot of work! None of it would be possible without your support through Friends of Pods and Pods Pro by SKCDEV.

Extra special shout out for all of the moral support and help from these people who made life a little less solitary as I had to work on this in complete secret:

• Jim True
• Courtney Robertson from GoDaddy
• Jo Minney from House Digital
• and Jamie VanRaalte from Beaver Builder

Pods Introspective: 15 years later 9 Oct 2023 11:54 AM (last year)

Yesterday, I quietly celebrated the 15 year anniversary since Pods was released by Matt Gibbs on October, 8th, 2008. I found out about Pods that same week and then I jumped into heavily using it on my own web projects at work. Over a short time, I became more involved in support and development contributions which eventually led to me leading the whole project.

By the way, Matt Gibbs went on to release the FacetWP (2013) which just turned 10 this year 🎉

What WordPress was like back then

Back then, we were pushing the confines of WordPress at the time when Pods was released. Custom post types weren’t officially a thing until WordPress 3.0 was released a year and a half later in 2010. There were plugins at that time which customized the edit post screen to support custom fields. You’ll never believe this but one of those plugins is also still around after all of these years! Custom Field Template was released just over a month before Pods was. That plugin is the only custom field plugin predating Pods that has survived. Even Custom Write Panel was short lived and hey do you remember Flutter or the subsequent fork Magic Fields?

That got me thinking about longevity and how we all did or didn’t make it to this point. I believe many competing plugins were swallowed by the great Advanced Custom Fields effect. ACF was first released in 2011 over two years after Pods came on the scene. But pretty much immediately it garnered interest because Elliot Condon had a knack for great UI and was able to monetize it early on to help it grow. While Pods and other plugins lacked in UI, ACF made it easy to understand with its limited focus on custom fields and it looked dapper while doing it.

ACF wasn’t the only plugin that gobbled up market share from Custom Field plugins — there were other projects like Meta Box (2011), Types (2011, now premium-only via Toolset), Custom Field Suite (2011, a fork of ACF by Matt Gibbs), Fieldmanager (2012), CMB2 (2014), and many others. Each plugin that hit the scene would all compete for the same sort of people who would otherwise have enjoyed using a plugin like Pods or ACF. Competition is healthy and there still remains a variety of different options for Content Type / Custom Field plugins for WordPress out there.

Over time, those bigger plugins probably demotivated a few contributors of various smaller plugins and APIs out there. They became less frequently updated and the releases to address WordPress compatibility inevitably slowed. Some plugins were closed or became inactive on WordPress.org while some are inactive but remain available on GitHub repositories. But that didn’t seem to happen with Pods — we stuck around even though we had 1/20th of the usage share of our largest commercially-backed competitor ACF.

Financial health

With Pods, we received very few donations initially in the early years. I don’t have all of the records from back then but we probably got less than $100 in donations total. Then I ran a Kickstarter fundraiser for Pods 2.0 and landed a very lucky Automattic sponsorship after that. Eventually with the start of the Friends of Pods program, we started gaining momentum again. Then, as Gutenberg brought the Block Editor into WordPress, we saw the Automattic sponsorships overall get redirected to Block/React focused projects. This set us back on resourcing and our funding never really recovered to the same level since then.

Then a year later, Pods 2.8 brought Pods into the world of Blocks and React. It was expensive, time consuming, and difficult. But we couldn’t have done it without the knowledge and expertise of Zack Rothauser.

Pods Foundation, Inc currently receives about $1,400 in monthly and $8,700 in annual donations which gives us about $25,000 budget (excluding payment processing fees) to work with every year. We spend around $1,400-$2,000 monthly towards our paid support and development contributors Jory Hogeveen (Keraweb) and Paul Clark. The remaining amount goes towards domains, hosting, invoicing SaaS, and software. There’s not much wiggle room, and I’m not even getting paid from any of the donations for my own time. Everything donated to Pods goes right back into Pods.

I’d love to find new ways to bring sponsorships and donations into Pods to help build major features that can take Pods to the next level. I’m still thinking about what that looks like going forward.

Time is an investment

We just released Pods 3.0 a month ago and there’s barely been more than a month or two between maintenance releases the entire time Pods has been around. Think about that… even during the time we were building major feature releases, we were also putting out maintenance releases (x.x.1+ versions) with bug fixes and enhancements. Heck, some times we released a feature during a maintenance release like during the period between Pods 2.7 (2017) and Pods 2.8 (2021) just to keep everyone on their toes.

There hasn’t really been time for a breather to stop and think about what we’ve done and where we’ve been. We did ALL of this work together. Contributors have poured thousands of hours of volunteer time or sponsored time. I’ve poured thousands of hours of my own time into Pods and worked nights, weekends, holidays, between jobs, and while on PTO.

We all helped to keep Pods alive for these 15 years of ups and downs in WordPress and yet Pods is still here. We have remained steadfast and unwavering in its commitment to help others do more with WordPress. That wouldn’t be possible without every one of our contributors helping with code, support, docs, and the donors who help make it all possible. There is no shortage of competitors which have commercial funding and ACF has made its way to being owned by WPEngine. And yet the Pods project is still free and active.

As I think about what has happened in the past 15 years of my life — it includes marriage, two children, first house, second house after we sold the first, illnesses, surgeries, freelance work, agency work, fully remote work, left agency work to build products, left product work to build platforms, and well… that whole pandemic thing. It’s been a really fun ride and I’m excited to see what we do next as a project.

The Release Timeline

I thought it would be interesting to gather a list of major events in Pods lifespan that includes major/noteable features. Check out what I’ve put together below.

Pods 3.0 Feature Release: Conditional Logic for Fields 13 Sep 2023 7:23 AM (last year)

What’s new in Pods 3.0?

Big ticket features

• Conditional Logic for Fields – You can now choose to show or hide a field based on the value of another field. More will be expanded into this functionality in the future. 🎉
• Command Palette support for WordPress 6.3+ – You can now contextually go to the Edit Pod screen for the matching Pod configuration of that post type directly from the Edit Post screen.

Breaking compatibility

• New minimum WP version required: WordPress 6.0+ (previously: WP 5.7+) — We will continue to support at least the last two major WP releases on each major feature release of Pods but we made an exception for this release.
• New minimum PHP version required: PHP 7.2+ (previously: PHP 5.6+) — Hey! You should take the time to update to PHP 8.1+ because that is the lowest version actively supported by The PHP Group.

Other changes

• Added: Set up backward compatible updates to our prior depends-on and related logic for internal conditional logic prior to Pods 3.0 so they now properly translate over to the new format required.
• Added: When importing and exporting Pods packages, they now include the list of active components.
• Fixed: All known PHP 8.x compatibility issues have been resolved
• Fixed: Media saving issue has been resolved when the Media Modal fields are disabled, it now saves fields as expected.
• Fixed: Improved compatibility with Polylang.
• Fixed: Redirects after deleting a Pod now send to the current site dashboard instead of hardcoded /wp-admin/ link.
• Fixed: When extending a post type or taxonomy it will now use the associated post type or taxonomy label when setting up the pod so it matches.
• Fixed: Resolved problems with saving the featured image from frontend forms when a post type supports featured images.
• Fixed: Don’t show SQL errors when getting relationship data for forms if the debug display is disabled in WP.
• Fixed: Improved tooltip appearances with better color contrast.
• Removed: The Tribe Common library has been removed from Pods and it will alleviate conflicts from plugins like The Events Calendar and Event Tickets going forward.

What’s coming next with Pods 3.1 and Pods 3.2?

• Pods 3.1 – In the short term, we are working on a feature that came up after doing extensive research into a flexible solution to better manage and explain user capability access to the WordPress core content types. This feature will be released in the coming weeks as it was not quite ready for the 3.0 release timeline we initially hoped for.
• Docs focused release cycle – We are doing something different with our following release cycle for Pods 3.2. Instead of immediately moving onto Pods 3.2 development, we will be entirely focused on Documentation, Tutorials, and Video content.
• Pods 3.2 – Before that next release cycle ends in Spring 2024, we will send out notifications to all donors with a link to vote on the next Pods 3.2 feature that we will build.

Pods 3.0 Beta 1 is available for testing 28 Apr 2023 9:45 AM (last year)

How to get Pods 3.0 Beta 1

1. You can download Pods 3.0 Beta 1 directly from GitHub here or read more about the release.
2. Upload the ZIP to your WordPress site over your existing Pods install to update it or install it standalone.

Be sure to test on Staging / Development / Local environments. This is a beta release and there is always potential that it could include bugs that may interrupt your Production environment.

What’s new in Pods 3.0

What we need you to test

• Conditional Logic for Fields – You can now choose to show or hide a field based on the value of another field. More will be expanded into this functionality in future 3.x releases. 🎉
• Try out various conditional logic settings and see if you notice any problems in the field editing interface or the forms when conditional logic is evaluating your rules.

Also there’s a new helpful Composer conflict resolution

• We added a new filter pods_tribe_common_vendor_autoload which will now let you remove conflicting libraries from loading so your own libraries can continue to be used when that occurs. If you want to resolve a conflict so it does not interfere with your own code you can remove a key from this array.

Breaking compatibility

• New minimum WP version required: WordPress 5.8+ (previously: WP 5.7+) — We will continue to support the last two major WP releases on each major feature release of Pods but we made an exception for this release.
• New minimum PHP version required: PHP 7.2+ (previously: PHP 5.6+) — Hey! You should take the time to update to PHP 8.1+ because that is the lowest version actively supported by The PHP Group.

Check out these updated Pods 3.0 related documentation pages

What’s coming in Pods 3.1

• We are doing something different with our next release cycle. Instead of immediately moving onto Pods 3.1 development, we will be entirely focused on Documentation, Tutorials, and Video content.
• Before that next release cycle ends in Fall 2023, we will send out notifications to all donors with a link to vote on the next Pods 3.1 feature that we will build.

Pods 2.9.12 Maintenance Update 9 Mar 2023 7:43 AM (2 years ago)

This update includes a great deal of additions, tweaks, and bug fixes that we’ve been working on over the past month.

• Added: WP-CLI > Added a new wp pods tools flush-cache WP-CLI command to flush the Pods caches. To flushes caches for a specific Pod, use wp pods tools flush-cache --pod=your_pod (@sc0ttkclark)
• Added: DFV > Introduce window.PodsDFV.detectForm() and window.PodsDFV.detectField() helper methods to normalize everything going into the DFV API. (@sc0ttkclark)
• Added: DFV > window.PodsDFV methods now accept null for pod, itemId, and formCounter values in various methods which will automatically detect+use the first pod, itemId, and formCounter on the screen. (@sc0ttkclark)
• Added: API > New PHP function pods_is_demo() will allow Pods to offer streamlined demos using the one-click WASM demo. (@sc0ttkclark)
• Added: API > New PHP function pods_clone_objects() and pods_clone_object() assist in cloning objects primarily used through callbacks. (@sc0ttkclark)
• Added: API > New PHP function pods_debug_log() allows for logging exception messages that do not need to be shown on the screen. (@sc0ttkclark)
• Added: API > New PHP function pods_get_item_object() allows for getting the WP object for an item based on the object type. This is similar to get_metadata() in WP core but as a general solution for any object. (@sc0ttkclark)
• Added: API > New Pods::has_rows() method can be used instead of Pods::total() to just check if there were any rows returned. (@sc0ttkclark)
• Added: Pods Field Output > You can now traverse into the fields parent (Taxonomies) and post_parent (Post Types) as relationships like parent.name or post_parent.post_title. This also works for post_author. (@sc0ttkclark)
• Added: Pods Field Output > You can now call post_thumbnail.title, post_thumbnail.caption, post_thumbnail.description, post_thumbnail.mime_type, post_thumbnail.alt_text, post_thumbnail.width, post_thumbnail.height, post_thumbnail.filesize, post_thumbnail.dimensions, post_thumbnail.filename, and post_thumbnail.extension, and image metadata using post_thumbnail.image_meta.copyright. This also works for other attachments. (@sc0ttkclark)
• Tweak: Edit Field Modal > Added additional text below the Required option when editing a boolean field to clarify that only the “Yes” option counts as valid. (@sc0ttkclark)
• Tweak: Pods Field Output > Added full $params from Pods::field() to the filters pods_data_map_field_values_custom, pods_data_map_field_values_map_value, and pods_data_map_field_values_map_value_pre_check. (@sc0ttkclark)
• Tweak: Pods Field Output > Bypass mapping values when in the form context to prevent conflicts with Avatar fields and other fields. (@sc0ttkclark)
• Tweak: Migration > Abstracted the migration process on first edit of a Pod to detect orphaned fields on future edits with a notice on the screen about the repair. (@sc0ttkclark)
• Tweak: API > Split up cache flushing method PodsAPI::cache_flush_pods() into a separate method PodsAPI::cache_flush_groups() and PodsAPI::cache_flush_fields() to more easily flush specific object types. (@sc0ttkclark)
• Tweak: API > Passing more context into pods_podsrel_enabled() usage for future iteration work on certain areas of the code. (@sc0ttkclark)
• Fixed: Edit Field Modal > Attempt to auto-fix pick_object for display when it is set to “pod” but the real object is “post_type” or “taxonomy”. #7007 (@sc0ttkclark)
• Fixed: Components > Fixed PHP warnings with the Translate Pods component (@JoryHogeveen)
• Fixed: Pods Shortcode > Bypass showing the Pods Shortcode button on TinyMCE editors when on an Elementor edit screen. (@sc0ttkclark)
• Fixed: Stats Opt-in > Don’t show the opt-in message on Pods content screens, only show it on pages under the Pods Admin menu. (@sc0ttkclark)
• Fixed: Relationship Modal > Updated CSS to prevent the modal from being narrow. #6996 (@pedromfm, @sc0ttkclark)
• Fixed: DFV > Handle false values as null properly to prevent JS TypeErrors. #6963 (@sc0ttkclark, @spiderneo)
• Fixed: API > Normalize object_type for PodsAPI::get_table_info(). #7007 (@sc0ttkclark)
• Fixed: API > Return 0 for {@user.ID} when logged out instead of null. #6979 (@jeiseman, @sc0ttkclark)
• Fixed: API > Return empty string when user context used instead of null for certain fields. (@sc0ttkclark)
• Fixed: API > Use static cache for PodsMeta::groups_get() instead of static variable to allow flushing the groups cache. (@sc0ttkclark)
• Fixed: Object Cache > When serializing Whatsit object, prevent serialized Closures being cached through Pods Alternative Cache. (@sc0ttkclark)
• Fixed: Pods Field Output > Resolved issue with the fields parent (Taxonomies) and post_parent (Post Types) so they return the ID as they used to in previous Pods versions. (@sc0ttkclark)
• Fixed: Pods Field Output > Resolve dot notation for attachments and post_thumbnail fields fallbacks when calling object fields like post_thumbnail.ID. #7005 (@sc0ttkclark)
• Fixed: Bidirectional Relationships > Now using the correct related limit for bidirectional relationships instead of unlimited. (@sc0ttkclark)
• Fixed: Admin Columns integration > Resolved PHP warning with substr() usage. #7014 (@sc0ttkclark)
• Fixed: Pods Find Queries > References to .meta_value should always join the meta table when using a table-based Pod that supports meta-based storage. #7009 (@sc0ttkclark)
• Fixed: API > Fixed filter_by_date usage of sprintf() to prevent PHP warnings. #6980 (@sc0ttkclark)

You can read the full change log for this release on the Development tab of our WordPress.org plugin page.

Pods 2.9.11 Security / Maintenance Update 19 Jan 2023 12:42 PM (2 years ago)

This update includes a security fix and other updates:

• Security: Fix nonce verification check when deleting a pod. Thanks to Rafshanzani Suhada for responsibly disclosing this through Patchstack (@0xshdax, @sc0ttkclark)
• Compatibility: Improved compatibility with PHP 8.1+ (@sc0ttkclark)
• Tweak: Removed some of the jQuery dependency for Pods DFV, the only part that remains is jquery-ui-sortable for File fields (to be further refactored into React at a later point). (@sc0ttkclark)
• Fixed: Updated the tribe-common library which had an older version of JWT included. (@sc0ttkclark)
• Fixed: Remove debug output on the Tools page when no actions needed to run. (@sc0ttkclark)

You can read the full change log for this release on the Development tab of our WordPress.org plugin page.

Pods 2.9.4 Maintenance Update 21 Sep 2022 7:03 AM (2 years ago)

This update includes 6 features, 2 enhancements, 1 change, 1 tweak, and 21 bug fixes, here are a few of them:

• Feature: New block alert! “Pods Single Item – List Fields” opens the doors towards listing a list of fields in variety of format styles automatically for you. You don’t have to write any HTML, just specify the field(s) you’d like to show and let the block do the rest for you. The block will display the Field Labels and the Field Values in a nice readable format. Display formats available include: ul, ol, dl, p, div, and table. Want to show all but a few fields? Just specify which fields to exclude if that’s what you’re after 🙂 (@sc0ttkclark)
• Feature: New {@_all_fields} magic tag (or $pod->field('_all_fields') call) will automatically output all field values for the current Pod item in the specified format which includes showing the Field labels. Specify the format using this syntax: {@_all_fields.ul} (default is ul, but ol, dl, p, div, and table are also supported). (@sc0ttkclark)
• Feature: New {@_display_fields....} magic tag (or $pod->field('_display_fields....') call) will automatically output all field values for the current Pod item in the specified format which includes showing the Field labels. Specify the format using this syntax: {@_display_fields.ul.field_name|another_field|related_post:post_title} (default is ul, but ol, dl, p, div, and table are also supported) — Separate your fields with a pipe “|” character and then if you need to traverse into any relationship field then just traverse each level with a colon “:” character between those fields. (@sc0ttkclark)
• Feature: New pods_data_field() function allows you to get special data fields directly instead of requiring you to use a full Pods object. (@sc0ttkclark)
• Feature: New Repair tool on the Pods Admin > Settings > Tools page helps to repair Pod, Group, and Field configuration issues that can be annoying to deal with or would normally require Database access to resolve. (@sc0ttkclark)
• Feature: You may not have known about it before but we’ve expanded our existing Pods DFV JS API, you can access it through the window.PodsDFV object. Methods include: getFields( pod = '', itemId = 0, formCounter = 1 ), getField( pod, itemId, fieldName, formCounter = 1 ), getFieldValues( pod = '', itemId = 0, formCounter = 1 ), getFieldValuesWithConfigs( pod = '', itemId = 0, formCounter = 1 ), getFieldValue( pod, itemId, fieldName, formCounter = 1 ), setFieldValue( pod, itemId, fieldName, value, formCounter = 1 )
• Enhancement: You can now choose what field mode you would like to use for REST API fields. The default mode is raw values, but you can choose to return rendered values or both raw+rendered values as an object to work with. #5198 (@sc0ttkclark)
• Enhancement: You can now specify a custom display separator for repeatable fields to use when rendering. #6892 #6890 (@JoryHogeveen)
• Changed: Resetting a Pod has been removed from the Pods Admin > Edit Pods page, instead of clicking “Delete All Items” there, you can now access this directly from Pods Admin > Settings > Cleanup & Reset as the new “Delete all content for a Pod” option. You can specify the Pod you want to delete content for and it explains exactly what you can expect from running it. (@sc0ttkclark)
• Tweak: Updated Pods Admin > Help page now lists more add-ons and where to get them / get support for them. (@sc0ttkclark)
• Fixed: Relationship/file fields that are hidden on the screen will now have all field values referenced instead of only the first value when multiple is enabled for that field. #6913 (@sc0ttkclark)
• Fixed: Legacy WP-CLI commands for Pods are now showing up again, however they will be replaced in a future release with a more comprehensive solution. In the meantime, you can use those commands by calling wp pods-legacy and wp pods-legacy-api.
• Fixed: Prevent conflicting filter calls when filtering things other than post_title in the Display Field in Selection List option. #6909 #6907 (@therealgilles, @sc0ttkclark)
• Fixed: The autocomplete field now lets you click the “X” delete icon properly instead of starting drag-and-drop event. #6905 #6878 (@JoryHogeveen)
• Fixed: Resolved saving multiple files to a Media pod which would result in only the first file being saved. #6450 (@sc0ttkclark)
• Fixed: Resolved TinyMCE media button handling in some cases so that it checks the correct place in the field configuration. #6569 (@sc0ttkclark)
• Fixed: Resolved overflow issues in small screens for relationship field List View. #6542 (@sc0ttkclark)
• Fixed: Resolved issue with some TinyMCE scripts not being included on certain screens that use the TinyMCE WYSIWYG field. #6525 (@sc0ttkclark)
• Fixed: Autocomplete field AJAX calls are now able to correctly reference the field object for code-based registered fields. #6896 (@naveen17797, @sc0ttkclark)
• Fixed: Resolved read-only fields functionality which was initially missing from the Pods 2.8+ DFV functionality. #6875 #6583 (@zrothauser, @sc0ttkclark)

You can read the full change log for this release on the Development tab of our WordPress.org plugin page.

Pods 2.9 Feature Release 9 Aug 2022 2:32 PM (2 years ago)

Big ticket features

• Simple Repeatable Fields – You can now make any field into a repeatable input that supports multiple values 🎉
• File-based Configurations – Register file-based configurations using JSON or YML format and Pods will automatically pick them up from your theme or other custom locations you specify via code.
• WPGraphQL Integration – The initial integration for WPGraphQL has been merged from the WPGraphQL Integration Add-On for Pods Pro by SKCDEV. The Add-On itself will continue to be developed with new features that are focused on Advanced Content Types and other enhancements in the future that will still remain outside of Pods core.
• Drag and drop fields to another Field Group – Did you add a new Field Group and now you want to move some of your existing fields to it? Just drag and drop and you are all set.
• Stability Improvements – We introduced 284 new automated tests with 2,343 new assertions to make sure new features and code structures are operating at their best. The total testing stats now stand at 5,059 tests and 39,215 assertions.
• And many other tweaks and fixes can be found in the changelog.

Breaking compatibility

• New minimum version required: WordPress 5.7+ (previously: WP 5.5+) — We will continue to support the last two major WP releases on each major feature release of Pods.
• No minimum PHP version changes at this time (currently: PHP 5.6+) — Please be aware that PHP 7.2+ will be required for the Pods 3.0+ feature release. You should take the time to update to PHP 8.0+ because there’s major speed improvements to be had 🙂

Check out these updated Pods 2.9 related documentation pages

What’s coming in Pods 3.0

• Conditional Logic for Fields – Allow choosing when to show/hide certain fields based on the values of other fields.

Field Guide to Pods 2.9 26 Jul 2022 6:07 PM (2 years ago)

What’s new in Pods 2.9

Big ticket features

• Simple Repeatable Fields – You can now make any field into a repeatable input that supports multiple values 🎉
• File-based Configurations – Register file-based configurations using JSON or YML format and Pods will automatically pick them up from your theme or other custom locations you specify via code.
• WPGraphQL Integration – The initial integration for WPGraphQL has been merged from the WPGraphQL Integration Add-On for Pods Pro by SKCDEV. The Add-On itself will continue to be developed with new features that are focused on Advanced Content Types and other enhancements in the future that will still remain outside of Pods core.
• Drag and drop fields to another Field Group – Did you add a new Field Group and now you want to move some of your existing fields to it? Just drag and drop and you are all set.
• Import and Export Pods Settings – The Migrate Packages component now supports importing and exporting Pods Settings.
• No-follow links for Website fields – Specify whether you’d like website links that you output to have no-follow or not.
• Stability Improvements – We introduced 284 new automated tests with 2,343 new assertions to make sure new features and code structures are operating at their best. The total testing stats now stand at 5,059 tests and 39,215 assertions.
• And many other tweaks and fixes can be found in the changelog.

Breaking compatibility

• New minimum version required: WordPress 5.7+ (previously: WP 5.5+) — We will continue to support the last two major WP releases on each major feature release of Pods.
• No minimum PHP version changes at this time (currently: PHP 5.6+) — Please be aware that PHP 7.2+ will be required for the Pods 3.0+ feature release. You should take the time to update to PHP 8.0+ because there’s major speed improvements to be had 🙂

Check out these updated Pods 2.9 related documentation pages

---

Pods 2.8.9 Maintenance Update 31 Jan 2022 8:33 AM (3 years ago)

Today we released the Pods Framework 2.8.9 Maintenance Update on WordPress.org.

This update includes 20 bug fixes and 4 enhancements, here are a few of them:

• Added: There’s a new tool at Pods Admin > Settings > Tools that will let you “Recreate missing tables”. This will run the logic used to create those tables needed by Pods. This is currently just for wp_podsrel but will eventually include all other table-based Pods too. #5795 (@sc0ttkclark)
• Added: Are you interested in seeing how much data your Pods are storing? You can now add &pods_include_row_counts=1 to the Pods Admin > Edit Pods URL and see how many Data Rows, Meta Rows, and Relationship Rows are associated to each pod. This is a hidden feature and will be added in the future as a link directly within the Edit Pods screen. (@sc0ttkclark)
• Added: Support for alignment and custom classes on Pods Blocks. Disabled support for Anchors until they are officially resolved for dynamic blocks in core. (@sc0ttkclark)
• Fixed: Abstracted the meta saving into PodsMeta::save_meta() so that it can be used to remove duplicate logic in other methods and implemented it for meta fallback for simple relationship compatibility saving in integrations like Paid Membership Pro. (@sc0ttkclark)
• Fixed: Additional work on preventing unnecessary queries from other plugins with our Meta API integration. #6379 (@sc0ttkclark)
• Fixed: Resolved issues with 00:00 times when HTML5 inputs are enabled for Date/Time fields. #6256 #6382 (@zrothauser, @sc0ttkclark)
• Fixed: Some times after updating to 2.8, a Pod may have orphaned fields that exist outside of groups. This normally gets handled during the first time you edit a pod but now we have an additional count check to see if the field counts match as expected when editing a pod so it can trigger that process even after the first edit in 2.8. #6384 #6302 (@sc0ttkclark)
• Fixed: Cleaned up and abstracted the logic to build the field name used in DB queries for a field. #6270 #6411 (@sc0ttkclark, @jamesgol)
• Fixed: Resolved Date/Time field issues on certain browsers/OS combinations. #6318 #6300 (@sc0ttkclark, @zrothauser)
• Fixed: Better prevent recursive loops when saving meta from third parties. #6391 (@sc0ttkclark, @mircobabini)

You can read the full change log for this release on the Development tab of our WordPress.org plugin page.

Side note: You may have noticed that blog posts aren’t happening for every single maintenance release. This is because I’ve been personally busy and I normally handle the release posts so if I don’t do it then it won’t appear here. I’m looking into how I can automate the posts to automatically publish from GitHub releases when I post them there, but for now it’ll just have to continue being manual.

Introducing: Pods Integration for Paid Memberships Pro plus a Behind the Scenes look at our new powerful Forms API in Pods 2.8 26 Oct 2021 8:06 AM (3 years ago)

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.

Pods 2.8 Feature Release 18 Oct 2021 9:00 AM (3 years ago)

6+ years and 2.7k+ commits went into the incredibly vast features of the Pods 2.8 release that is now free for everyone to enjoy.

Big ticket features

• Field Groups – You can now separate Fields into their own Groups on any Pod 🎉
• Better Performance – Pods now loads more quickly, uses less memory, and auto-loaded options have been reduced up to 95%!
• New Pod Editor – The new Edit Pod screen has been completely rewritten in React and uses our new REST API saving separately for the Pod, Groups, and Fields.
• New Field Types – We added two new layout-related field types — Heading and HTML.
• New Pods Blocks – We are excited to introduce our new Pods Blocks which allow you to List Items, show a Single Item, display a Single Item Field, show a Public Form, or embed a View (any file) from your theme / child theme. We also included compatibility with the WordPress 5.8 Query Loop blocks!
• New Pods Blocks API – For those creators out there looking to get ahead with some common custom block needs, our new Pods Blocks API allows you to register your own blocks.
• New REST API – Our new REST API endpoints (11 endpoints total) allow for managing Pod configurations.
• New WP-CLI commands – Our new WP-CLI commands (24 commands total) allow for managing Pod configurations.
• New Editor option for WYSIWYG fields – The Quill Editor is now officially supported for WYSIWYG fields.
• Now implementing a new core library – Pods 2.8 now uses the same core library that the fantastic plugins The Events Calendar and Event Tickets use. This gives us access to some great abstractions that we don’t have to build or maintain ourselves as part of Pods. We’ll be tapping into more of that magic as time goes on too.
• Stability Improvements – We introduced 304 new automated tests with 11,131 new assertions to make sure new features and code structures are operating at their best.

Breaking compatibility

• New minimum required versions have been updated as follows which includes notices to let you know if you need to update something.
  • New minimum version required: WordPress 5.5+ (previously: WP 4.5+)
  • New minimum version required: PHP 5.6+ (previously: PHP 5.3+) — Hey! You should take the time to update to PHP 7.4+ because there’s major speed improvements to be had 🙂
  • New minimum version required: MySQL 5.5+ (previously: MySQL 5.1+)
• Refactored object handling for Pod and Field configurations — we now lazy load and pull things as-needed from the database instead of always pulling all Pods and Fields at once. It remains backward compatible in most array usage — see the Field Guide for more details.
• Public forms now render with the “div” output type (previously “ul”).
• CLEditor is no longer maintained and has been replaced with the React-based Quill.

For a more comprehensive and complete list of features, enhancements, and backwards compatibility changes — Read the Complete Pods 2.8 Field Guide.

Check out these new Pods 2.8 related documentation pages

What’s coming in Pods 2.9

• Simple Repeatable Fields – Make fields repeatable so that you can enter multiple sets of text, websites, phone numbers, emails, passwords, content, code, dates, numbers, currency, oEmbeds, or colors.
• JSON/YML based configurations – Create your file-based configurations for Pods, Groups, and Fields which means you can commit them to version control (Git/SVN) based on your workflow needs.

In the interest of transparency, the complete development costs for Pods 2.9 will be $6000 and all donations (monthly, annual, or one-time) will contribute towards the fundraising goal. As soon as we meet our goal, we can be in beta within days and release Pods 2.9 within a month after that.

UPDATE – November 19th, 2021 – We met our fundraising goal of $6000 thanks to the great people behind Gravity Forms. We are working hard on getting the features in Pods 2.9 completed and will post more updates on our Twitter / Slack when we have an update on progress.

Pods 2.8 Release Candidate 2 is now available 5 Oct 2021 6:47 PM (3 years ago)

Pods 2.8 Release Candidate 2 is now out! The official release is just days away now, Pods 2.8 will be released on October 12th at noon (UTC-5). It’s time to get your final testing finished and report any bugs you find along the way.

Check out the official Pods 2.8 Field Guide for information about what’s new in Pods 2.8, how to test, and how to report any bugs you find.

• 

• 

Pods 2.8 Release Candidate 1 is now available 7 Sep 2021 11:45 AM (3 years ago)

Pods 2.8 Release Candidate 1 is out! We are extra excited because this means that we are just a couple of weeks away from final release. Now is the time to refresh your staging sites and load up Pods 2.8 RC 1 to do your pre-launch testing for your sites.

Check out the official Pods 2.8 Field Guide for information about what’s new in Pods 2.8, how to test, and how to report any bugs you find.

• 

• 

Pods 2.7.30 Maintenance Update 12 Aug 2021 11:59 AM (3 years ago)

Today we released the Pods Framework 2.7.30 Maintenance Update on WordPress.org.

This update includes the following fix:

• Fixed: Prevented a few PHP notices from showing on the new WordPress 5.8+ widgets screen.

You can read the full change log for this release on the Development tab of our WordPress.org plugin page.

Pods 2.7.29 Maintenance Update 4 Aug 2021 3:13 PM (3 years ago)

Today we released the Pods Framework 2.7.29 Maintenance Update on WordPress.org.

This update includes the following improvement and fix:

• Security: Clean up post type and taxonomy labels so they avoid potential output escaping problems in WordPress core (@sc0ttkclark, reported by Muhammad Daffa via WPScan)
• Friends of Pods: Updated CTA text about our 2021 donor goals. (@sc0ttkclark)
• Added: Support for Timezones in datetime / time fields. #6042 (@JoryHogeveen)
• Added: Support for Pantheon WP Native Sessions plugin. (@sc0ttkclark)
• Enhancement: Optimized the PNG image assets using PNG8+Alpha with ImageAlpha and ImageOptim. #6028 (@lowwebtech)
• Fixed: Hidden fields now properly submit correctly. (@sc0ttkclark)
• Fixed: Post type `has_archive` no gets set to a false properly when disabled. #6069 (@JoryHogeveen)
• Fixed: Resolve PHP `strlen()` warnings when validating text values being saved. #6062 (@pd-cm, @sc0ttkclark, @JoryHogeveen)
• Fixed: Sorting URLs in `PodsUI` include `post_type` and `taxonomy` when Advanced Content Types are set to be underneath a Post Type’s top level menu. #6040 (@JoryHogeveen)
• Fixed: Fallback to the manage fields in `PodsUI` for reordering when reorder fields are not overridden. #6058 (@JoryHogeveen)

You can read the full change log for this release on the Development tab of our WordPress.org plugin page.

Pods 2.7.28 Maintenance Update 20 May 2021 3:11 PM (3 years ago)

Today we released the Pods Framework 2.7.27 Maintenance Update on WordPress.org.

This update includes the following improvement and fix:

• Added: New upload directory option for File fields using Plupload that lets you choose to customize which directory the files end up in. #6021 (@JoryHogeveen)
• Added: Relationship fields now support custom selectors in the REST API. You can specify my_field.some_field to output a specific field in your REST API options for each relationship field. (@sc0ttkclark)
• Added: New pods_image_for_post() and pods_image_url_for_post() functions have been added for certain page builders like Oxygen. (@sc0ttkclark)
• Added: New query variable prefix option (num_prefix) for PodsUI instances. (@sc0ttkclark)
• Added: pagination_type and pagination_location options for PodsUI instances to support more flexible pagination options. (@sc0ttkclark)
• Enhancement: Implement search and sort field sets for PodsUI instances to more easily specify which fields are searchable or sortable. (@sc0ttkclark)
• Fixed: PHP fatal errors no longer occur for avatar fields in certain situations. #6007 (@JoryHogeveen)
• Fixed: PHP fatal errors no longer occur for PHP 8 in certain situations. #6012 (@JoryHogeveen)
• Fixed: Resolved an issue with relationship fields not outputting their full data to the REST API when the related object is not a valid pod. (@sc0ttkclark)
• Fixed: Resolved an issue with not saving the fields for the extended Media pod when making update requests through the REST API. (@sc0ttkclark)
• Fixed: Implemented a temporary PHP 7.4+ fix for Freemius. (@sc0ttkclark)
• Fixed: Searching WP-based objects in PodsUI interfaces now resolves to the proper fields. (@sc0ttkclark)

You can read the full change log for this release on the Development tab of our WordPress.org plugin page.

Pods 2.7.27 Maintenance Update 20 Apr 2021 3:07 PM (3 years ago)

Today we released the Pods Framework 2.7.27 Maintenance Update on WordPress.org.

This update includes the following improvement and fix:

• Added: Support taxonomy and other object field filters in Pods::find(). #5994 (@JoryHogeveen)
• Added: WP 5.7 filter_by_item and filter_by_date labels. #5959 (@JoryHogeveen)
• Added: pagination_type shortcode param. #5977 (@JoryHogeveen)
• Enhancement: Allow ID as parameter for pods_audio() and pods_video(). #5999 (@JoryHogeveen, @sc0ttkclark)
• Enhancement: Use correct pagination item classes. #5179 (@JoryHogeveen)
• Fixed: Polylang compatibility for populating default field values. #5879 (@Chouby, @JoryHogeveen)
• Fixed: Prevent incorrect sanitizing of option fields since 2.7.25. #5909 (@JoryHogeveen)
• Fixed: Traversal display filters for single and multiple relationships. #5985 (@JoryHogeveen)
• Fixed: Support capitalized file extensions. #5975 (@sc0ttkclark, @JoryHogeveen)
• Fixed: Resolved PHP notice in the PodsAPI. #5952 (@JoryHogeveen, @sc0ttkclark)
• Fixed: Resolved PHP notice when using ?pods_debug_sql=1 on Pods Admin UI screens. (@sc0ttkclark)
• Fixed: Stop tracking Freemius add-ons and rely on just Pods itself. #5981 (@sc0ttkclark)
• Fixed: Prevent potentially unsafe HTML tags from being used in admin menu text. (@sc0ttkclark, props to Hagai Wechsler and Daniel Elkabes from WhiteSource Software)

You can read the full change log for this release on the Development tab of our WordPress.org plugin page.

Field Guide to Pods 2.8 11 Feb 2021 11:24 AM (4 years ago)

What’s new in Pods 2.8

Big ticket features

• Field Groups! You can now add Field Groups to any Pod 🎉
• Better Performance – Pods now loads more quickly, uses less memory, and can handle even more large complicated configurations you throw at it. Auto-loaded options have been reduced up to 95%!
• New Pod Editor – The new Edit Pod screen has been completely rewritten in React and uses REST API saving separately for the Pod, Groups, and Fields.
• New Field Types – We added two new layout-related field types — Heading and HTML.
• New Pods Blocks – We are excited to introduce our new Pods Blocks which allow you to List Items, show a Single Item, display a Single Item Field, show a Public Form, or embed a View (any file) from your theme / child theme. We also included compatibility with the new WordPress 5.8 Query Loop blocks!
• New Pods Blocks API – For those creators out there looking to get ahead with some common custom block needs, our new Pods Blocks API allows you to register your own blocks.
• New REST API – Our new REST API endpoints (11 endpoints total) allow for managing Pod configurations.
• New WP-CLI commands – Our new WP-CLI commands (24 commands total) allow for managing Pod configurations.
• New Editor option for WYSIWYG fields – The Quill Editor is now officially supported for WYSIWYG fields.
• Now implementing a new core library – Pods 2.8 now uses the same core library that the fantastic plugins The Events Calendar and Event Tickets use. This gives us access to some great abstractions that we don’t have to build or maintain ourselves as part of Pods. We’ll be tapping into more of that magic as time goes on too.
• Stability Improvements – We introduced 304 new automated tests with 11,131 new assertions to make sure new features and code structures are operating at their best.

Even more improvements

• New field option – Now supporting the ability to turn on/off the trimming of whitespace (default: on) for text-based field types (text/wysiwyg/etc).
• Pods::field() – New Pods::field() / magic tag options for various new special notations including: Pod information, Field information, Item list information, and more. This is a huge deal when you use [if] conditional template tags and lets you do even more without writing any PHP code than before.
• Pods::fields() – Now you can traverse relationship fields to get information about a field like Pods::fields( 'my_related_field.some_other_field' ) which would retrieve info about “some_other_field” even if it is on another Pod.
• Pods::form() – New support for the parameter “output_type” which lets you specify “div”, “ul”, “p”, or “table” (new default is “div”, previously it was using “ul”).
• Shortcode – New support for the shortcode parameter “form_output_type” which corresponds to the above Pods::form() improvement.
• Shortcode – New support for the shortcode parameter “blog_id” which lets you query data on another blog on multisite (must be enabled through the new PODS_SHORTCODE_ALLOW_BLOG_SWITCHING constant).
• Post type arg support – Now supporting the delete_with_user argument for custom post types.
• Show custom post types on Category/Tag archives – You can now choose to include posts from your custom post type on the Category and Tag archive pages.
• Revamped i18n component – Our i18n component now interfaces with the new Pod editor screen for a better experience managing your translations per language.
• Revision limit support – Now you have the ability to limit the number of revisions kept per post for a specific custom post type.
• Customized placeholder for “Add title” – You can customize the placeholder used for the new post screen for a specific custom post type.
• Pods Admin UI config abstraction – You can now extend the configurations for Pods, Groups, and Fields themselves with their own custom groups/tabs and fields. You can also modify existing ones. This is useful for plugins/add-ons extending Pods as it has now become more powerful.
• Lots of fixes and tweaks along the way!

Check out these new Pods 2.8 related documentation pages

Breaking compatibility

• New minimum required versions have been updated as follows which includes notices to let you know if you need to update something.
  • New minimum version required: WordPress 5.5+ (previously: WP 4.5+) — Going forward we will support the last two major WP releases on each major release of Pods.
  • New minimum version required: PHP 5.6+ (previously: PHP 5.3+) — Hey! You should take the time to update to PHP 7.4+ because there’s major speed improvements to be had 🙂
  • New minimum version required: MySQL 5.5+ (previously: MySQL 5.1+)
• Refactored object handling for Pod and Field configurations — instead of passing around arrays we now are using a “Whatsit” strategy (that’s an endearing term but we use it for any kind of object configuration). Pod and Field configurations now use \Pods\Whatsit\Pod and \Pods\Whatsit\Field accordingly. This gives us flexibility to lazy load and pull things as-needed from the database instead of always pulling entire Pods and Fields configurations all at once. This also reduces how much we have to use/cache on each page further reducing overall memory usage on every page. It remains backward compatible in most array usage (see the ‘options’ note below).
• Watch out for custom usage of $pod['options']['option_name'] or $field['options']['option_name'], just use $pod['option_name'] and $field['option_name'] to get/set your options. There’s some backward compatibility here but certain areas like PHP overloading can cause circumstances where you’ll get PHP errors. Full documentation of this will be made available on our new Dev Docs site that we’re working on, keep an eye out for that!
• Public forms now render with the “div” output type (previously “ul”), you can change this by providing a different output_type to the Pods::form() or “form_output_type” to the shortcode.
• If you have written custom field types, they should continue to work but you will want to be mindful to reach out to us to help you get them setup in our new React Field Type code that will be released in the near future. No ETA on this as it may be Pods 3.0 before our new React-based Custom Field Types are implemented fully for you to leverage.
• CLEditor is no longer maintained and has been replaced with the React-based Quill.
• The Pod Helpers component is no longer included in Pods and the Helpers API code is will no longer return helper data. If you want to continue using this functionality, the Pods Helper Add-On is available.

Overall Stability Improved

• We’ve converted our PHPUnit tests over to Codeception and expanded our tests for all of the new structures that were introduced in Pods 2.8
  • Pods 2.7.x: 4,593 tests, 25,684 assertions
  • Pods 2.8:
    • wpunit (general): 702 tests, 1,759 assertions
    • wpunit (shortcodes): 26 tests, 110 assertions
    • wpunit (traversal for find/field): 3,972 tests, 34,569 assertions
    • restv1: 63 tests, 377 assertions
    • Total: 4,763 tests, 36,815 assertions
• There are new JEST tests which cover many of the new areas of our new React functionality and have replaced our old JS tests
  • Pods 2.7.x: 1 suite, 17 tests
  • Pods 2.8: 26 suites, 151 tests

Pods 2.7.26 Maintenance Update 8 Jan 2021 3:05 PM (4 years ago)

Today we released the Pods Framework 2.7.26 Maintenance Update on WordPress.org.

This update includes the following improvement and fix:

• Fixed: Prevent PHP warnings in the components/Templates/includes/element-pod_reference.php file. #5914 (@JoryHogeveen)
• Added: New filter pods_shortcode_detect_from_current_post allows you to override whether a shortcode should detect the post object outside of the loop (default is only when in_the_loop()). This helps to fix problems that are part of the integration which the free Pods Beaver Themer Add-On uses. (@sc0ttkclark)

You can read the full change log for this release on the Development tab of our WordPress.org plugin page.

Introducing: Pods Pro by SKCDEV, Pods 2.8 in QA, & New YouTube Videos 31 Dec 2020 7:00 PM (4 years ago)

I quietly worked on some cool new stuff in 2020. Something different, more specialized, and able to expand Pods even further for those who need it…

Let me introduce you to: Pods Pro by SKCDEV

What is Pods Pro by SKCDEV?

I’ve heard feedback from so many people — everyone wants to take Pods further for new solutions to even newer problems. Page Builder integrations, Form integrations, and even more content tools — it’s totally within the wheelhouse of Pods to do these things and do them well. However, these kinds of add-ons are much more specialized and don’t really belong in Pods core.

This is where Pods Pro by SKCDEV will come into play.

Pods is maintained and supported by the loving infrastructure of the Pods Foundation. That focus really must remain on Pods core itself, without which none of this is possible. That’s why SKC Development is going to run separate premium add-ons so as to not syphon funding away from the long term goals of Pods.

With this separation — the key is that Pods retains its roots of free community-focused efforts while Pods Pro by SKCDEV is financially independent from the free plugin. It’s a win-win, even if it’s a little new/confusing right now.

What about Friends of Pods?

Friends of Pods is here to stay! It will continue to fundraise and take in donations so that the Pods project can grow and live a long and fruitful life. We wouldn’t be where we are with Pods without the support from this community. Our hope is that many new friends will take advantage of the discounted Pods Pro pricing as Pods Pro builds out specific features to meet their needs.

We didn’t hit our funding goal for Friends of Pods in 2020 (200 recurring donors) but that is totally understandable given the vast impacts of COVID-19. My work through Pods Pro by SKCDEV is also intended to help bring in additional funding (through a discount) to the Friends of Pods program in an effective way that donations alone haven’t provided.

Will Friends of Pods get a discount?

Pods Pro by SKCDEV will be available at a discount if you become an Active Friend of Pods. That’s right! Because there’s a way to support Pods and get the new specialized add-ons from Pods Pro at the same time, you won’t have to pick one or the other.

Just become an Active Friend of Pods ($60+ yearly) and claim the reward on the Friends site. It will send you to a special Pods Pro URL with Friends-exclusive discounted pricing. Full details on the Pods Pro by SKCDEV pricing page.

Future Pods Pro by SKCDEV expansion

Through my work on Pods Pro by SKCDEV, I’ll be able to offer more features through add-ons, create custom/unique add-ons for people, and offer new premium support options. I’ve got big plans for Pods Pro by SKCDEV, stay tuned over there throughout 2021!

Wait, I have more Pods Pro by SKCDEV questions!

There’s a lot more detail on the Pods Pro by SKCDEV pricing page, check out the FAQ section below the pricing for everything you’re looking for.

There are more great third party free/premium add-ons

Pods Pro by SKCDEV isn’t the only option when you’re looking to do more with Pods. There are free/premium add-ons out there that extend Pods or offer Pods-specific functionality within third-party products themselves.

Pods continues development as usual

Pods 2.8 and the subsequent Pods 2.9 / 3.0 releases will continue as planned. There’s really no change in direction for Pods itself, certain features and expansions still belong in Pods as we continue pushing forward with development.

Pods vs Pods Pro by SKCDEV clarifications

There’s been some confusion about Pods vs. Pods Pro by SKCDEV and I wanted to make sure it was easy to understand how everything works in the new structure.

What the Pods Foundation handles

• Pods is the free plugin
• Pods Foundation is the organization behind sponsorships/donations/funding of the Pods free project and free add-ons (aka me, I fund Pods Foundation where needed for dev costs like the significant dev costs of Pods 2.8)
• Friends of Pods is the donation program that brings in donations into the Pods Foundation to pay for development costs of the free project and the free add-ons. Pods donations go ONLY to supporting Pods core, not any premium Pods Pro by SKCDEV add-ons.

Pods Pro by SKCDEV is running as a separate entity through SKC Development

What SKC Development handles

• Pods Pro by SKCDEV is a set of premium add-ons
• SKC Development is the organization behind funding of the Pods Pro premium work (aka this is all me, I’m paying for / doing the work)
• To help fund Pods Foundation and the free project, there is a discount for Pods Pro by SKCDEV through becoming a Friend of Pods as an extra ‘thank you’ for your support and to help bring more funding to Pods.

Legal problems that led to this separation

• Pods Foundation is not legally allowed to sell products in Texas due to the original filing status as a Non-Profit in the state, even though it does not hold Non-Profit status at the federal level (Pods Foundation is not a 501(c)(3) organization)
• Releasing premium add-ons to help fund Pods in this way covers all of the needs/requirements

If you have any other questions or confusion here, don’t hesitate to reach out on our Slack.

Pods 2.7.25 Maintenance Updates 28 Dec 2020 11:43 AM (4 years ago)

Today we released the Pods Framework 2.7.25 Maintenance Update on WordPress.org.

This update includes the following improvements and fixes:

• Added: Custom no access message for templates.
• Fixed: Ensure compatibility with the WordPress 5.6 jQuery update.
• Fixed: Better support multiple languages in the Relationship AJAX search.
• Fixed: Better support caching of the avatar images/data and integrate with the `get_avatar_data` filter.

You can read the full change log for this release on the Development tab of our WordPress.org plugin page.

Pods 2.7.24 Maintenance Updates 5 Nov 2020 9:12 AM (4 years ago)

Today we released the Pods Framework 2.7.24 Maintenance Update on WordPress.org.

This update includes the following fixes:

• Fixed: Fix media [each] loop if no media Pod exists.
• Fixed: Fallback to default display field if custom option is invalid for relationship fields.
• Fixed: Use pathinfo to properly validate file extension.

You can read the full change log for this release on the Development tab of our WordPress.org plugin page.

Pods 2.7.23 Maintenance Updates and Enhancements 30 Oct 2020 10:00 AM (4 years ago)

On October 30th, we released the Pods Framework 2.7.23 Maintenance Update on WordPress.org.

This update includes the following updates and enhancements:

• Added: Support auto-templates for taxonomies, users and comments.
• Added: Allow function calls in all tags, not just template tags.
• Added: Support custom image sizes for all image field types in magic tags.
• Enhancement: Implement PHP 5.4 session_status() function.
• Enhancement: Allow WP objects to be passed in pods().
• Compatibility: Enqueue DFV scripts when editing the page with Beaver Builder to fully support the media window.
• Fixed: HTML entities for relationship fields UI.
• Fixed: Avatar should always return a square image.
• Fixed: Removed empty filter in ui/admin/setup-edit-field.php.
• Fixed: Remove source maps from production builds.

You can read the full change log for this release on the Development tab of our WordPress.org plugin page.

Pods 2.7.22 Maintenance Update with WordPress 5.5 compatibility 13 Aug 2020 10:06 AM (4 years ago)

Today we released the Pods Framework 2.7.22 Maintenance Update on WordPress.org.

This update includes the following fixes:

• WordPress 5.5 compatibility fixes for postbox headers and jQuery
• PHP error prevention for preview links in Advanced Content Types as well as magic tags with post thumbnails
• UI fixes for filters shown on the admin and in the frontend
• And a few other bug fixes

You can read the full change log for this release on the Development tab of our WordPress.org plugin page.

Pods 2.7.21 Maintenance Update, Friends of Pods Progress Report, and Pods 2.8 Status 4 Jul 2020 10:12 AM (4 years ago)

This week, we released the Pods Framework 2.7.21 Maintenance Update onto the WordPress.org Plugin Repository. This update includes the following fixes and updates:

• Support for traversing through serialized metadata in magic tags and Pods fields
• Support get_query_var() in pods_v()
• New WYSIWYG field option to customize editor height
• Clean up for the Pods::field() method
• Fixed encoding issues with certain relationship inputs
• Lots of bug fixes and small enhancements!

You can read the full change log for this release on the Development tab of the WordPress.org Repository

Friends of Pods Progress Report

We have made even more progress over the past couple of months since our call for support at the start of the year and our last progress update in March. Despite everything going on in the world, people still had room in their hearts and in their budgets to become a Friend of Pods. We are incredibly grateful that we’ve increased our recurring (monthly/yearly) friends count to the current 108/200 donors which is almost double the amount since our last update in March. As you can see by the projection chart below, if we continue the best-case trend, especially after we release Pods 2.8 we should hit our 200 donor goal by the end of 2020!

How does all of this bode for Pods itself? We now have enough in our monthly budget to keep maintenance releases flowing but that still means things like Pods 2.8 itself are taking longer than we had planned due to limited resources. We continue to do our best to offer as much support as we can in our Slack and WordPress.org plugin forums. We’re doing what we can and our community has been pitching in where they can which has continued to be helpful! Another big shout out to Jim True who is the backbone of our Community Support and has continually donated so much of his own time outside his full-time job commitments. By the way, if you aren’t already there — be sure to join us on Slack — Find out more about our Live Slack chat >>

We have some more add-ons in the works so keep an eye out as we get our first official batch of add-ons out to our friends in the coming month or so.

Pods 2.8 Status

Progress on Pods 2.8 itself has continued forward and we’re at about 90% of the way there. We will continue this month to get to a point where we can offer an Alpha or Beta release for curious people to check out. Stay tuned for more details as the month progresses — as always our Live Slack is the best place to get up-to-the-minute updates from our team as things happen. Our Friends of Pods even have their own channel where they get even more updates, among other chat perks.

We are enthusiastic about the features in Pods 2.8 so far, including the brand new Pods Blocks that will ship within Pods itself for free. This feature will let you build new blocks through code and get access to some of our starter blocks that operate how our shortcodes work but with better interfaces. We also have a new REST API powered by some of the underlying code from The Events Calendar by Modern Tribe that can manage configurations for Pods, Groups, and Fields. This REST API is also directly translated into an easy to use WP-CLI interface with minimal code so that our future REST API work will automatically become available as WP-CLI commands. There’s a ton of really cool stuff we’ve worked on for Pods 2.8 and we’re excited to get it in your hands.

Pods 2.7.17 + Pods Gravity Forms 1.4.3 Maintenance Updates, Friends of Pods Progress Report, and Pods 2.8 Status 26 Mar 2020 1:47 PM (5 years ago)

We have just released the Pods Framework 2.7.17 Maintenance Update onto the WordPress.org Plugin Repository. This update includes the following fixes and updates:

• Added support for changes in WordPress 5.4
• Fixes for some PHP 7.4 notices
• Added User pod fields to the privacy export data (for WordPress 5.4)
• Added a new callout for the Friends of Pods program to get more visibility into our need for additional support
• Integrated Freemius to support our upcoming Friends exclusive add-ons
• Added new ACF backwards compatibility functions so you can use the same theming functions like the_field() and have them map to Pods data even if you don’t have ACF activated
• Lots of bug fixes and small enhancements!

You can read the full change log for this release on the Development tab of the WordPress.org Repository

Pods Gravity Forms 1.4.3

We also just released a few fixes for our Pods Gravity Forms plugin that include:

• Fixed pre-population handling for relationship fields
• Prevent errors when form doesn’t exist by the time it gets to our hook

Friends of Pods Progress Report

We have made progress over the past couple of months since our call for support at the start of the year. Of course, things don’t always go as planned and there are understandably plenty more things going on in the world to worry about for folks. We haven’t met our goal of 200 recurring donors for the year yet, but we’re now at 67/200 recurring donors which is almost double the amount we started with this year.

We have integrated a new Friends of Pods callout in the admin area of the Pods plugin itself to help bring attention to it as many people may be unaware that we are seeking donations and sponsorships. That should give us some additional traction over the next few months and we’ll post another update as soon as we hit another milestone. Become a Friend to help us reach our goal of continuing to grow Pods features >>

We have also built the first new Friends exclusive add-on. This add-on and others will be made available to our Friends based on their membership level or total donations over time. More on this when we release this first add-on officially!

How does all of this bode for Pods itself? We have enough in our monthly budget to keep at a reduced dev capacity but that means things like Pods 2.8 itself is taking longer than we had planned due to limited resources. We also have had to scale back on how much support we are able to offer in our Slack and WordPress.org plugin forums. We’re doing what we can and our community has been pitching in where they can which has been so helpful! Big shout out to Jim True who is the backbone of our Community Support and has donated so much of his own time outside his full-time job commitments that we’re still having people mistake our Slack support for Premium Support! Be sure to join us on Slack — Find out more about our Live Slack chat >>

Pods 2.8 Status

Progress on Pods 2.8 itself has continued forward, but we’ve hit some snags in the React admin interfaces we’ve been building that have caused considerable delays with development there.

The good news is that we now have a new REST API powered by some of the underlying code from The Events Calendar by Modern Tribe that can manage configurations for Pods, Groups, and Fields. This REST API is also directly translated into an easy to use WP-CLI interface with minimal code so that our future REST API work will automatically become available as WP-CLI commands. There’s a ton of really cool stuff we’ve worked on for Pods 2.8 and we’re excited to get it in your hands.