2.9.19.1 - February 21st, 2024

Security 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. There were no known reports and no known attempts to take advantage of the issues resolved by this release except where noted.

Read more about How access rights work with Pods for more details including new filters/snippets that can provide limited access.

Upgrade now to Pods 3.1 to get the full benefits of the new Access Rights feature with additional customization settings available.

• 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)
• Security hardening: All SQL fragments used by Dynamic Features are checked for disallowed usage like subqueries. (@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 > 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)

2.8.23.1 - February 21st, 2024

Security 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. There were no known reports and no known attempts to take advantage of the issues resolved by this release except where noted.

Read more about How access rights work with Pods for more details including new filters/snippets that can provide limited access.

Upgrade now to Pods 3.1 to get the full benefits of the new Access Rights feature with additional customization settings available.

• 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)
• Security hardening: All SQL fragments used by Dynamic Features are checked for disallowed usage like subqueries. (@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 > 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)

2.7.31.1 - February 21st, 2024

Security 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. There were no known reports and no known attempts to take advantage of the issues resolved by this release except where noted.

Read more about How access rights work with Pods for more details including new filters/snippets that can provide limited access.

Upgrade now to Pods 3.1 to get the full benefits of the new Access Rights feature with additional customization settings available.

• 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)
• Security hardening: All SQL fragments used by Dynamic Features are checked for disallowed usage like subqueries. (@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 > 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)

3.0.10 - December 11th, 2023

• Fixed: The safe rendering handler for Pods Blocks now properly passes along context to all Pods Blocks so that they work within Query Loops again and other places they could take on context. (@sc0ttkclark)
• Fixed: Resolved PHP 8.3 deprecation notice with get_class() usage. #7225 (@netlas, @sc0ttkclark)
• Fixed: File fields using the direct plupload option will properly avoid uploading files above the limit and handle uploading multiple files without losing all but the first file in the file list. #7138 (@sc0ttkclark, @pd-cm)

3.0.9 - December 7th, 2023

• Feature: Added support for disabling Quick Edit for custom post types for sites on WP 6.4+. (@sc0ttkclark)
• Tweak: Revamped the Pods Blocks error handling so it looks nicer. (@sc0ttkclark)
• Tweak: Updated the default values used for "Add New" labels to use "Add New {singularLabel}" instead to follow WP core's direction. (@sc0ttkclark)
• Fixed: Custom capability types now save as empty and remain empty as intended. When empty, they will default to the current post type name and a placeholder shows what that would be. #7218 (@sc0ttkclark)
• Fixed: Added more handling for SQL errors for Pods Blocks. #7207 (@sc0ttkclark)
• Fixed: Resolved WP debug notices when calling wp_cache_flush_group by checking if wp_wp_cache_supports( 'flush_group' ) first. (@sc0ttkclark)

3.0.8 - October 20th, 2023

• Fixed: Resolved the hooked var handling for pre-save hooks in PodsAPI::save_pod_item() that was broken in Pods 3.0. #5532 #7195 (@sc0ttkclark, @olivierguerriat, @HmCody)
• Fixed: Resolve PHP deprecated notice in the PodsUpgrade class. #7190 (@sc0ttkclark)

3.0.7 - October 19th, 2023

• Fixed: Avoid duplicate fields showing up when registering fields manually through pods_group_add() instead of through normal DB or file-based configs. #6317 (@sc0ttkclark)
• Fixed: Resolve cases where Settings pod types would treat every save as a new item. (@sc0ttkclark)
• Fixed: Swept through the codebase to fix all remaining return type issues with PHP 8+ for the most common extended/implemented methods. (@sc0ttkclark)

3.0.6 - October 2nd, 2023

• Fixed: Resolved a plugin conflict with The Events Calendar / Event Tickets plugins that was introduced in 3.0.5. (@sc0ttkclark)
• Fixed: PHP deprecated notices resolved for return types in PHP 8+ (@sc0ttkclark)

3.0.5 - October 2nd, 2023

• Tweak: Added the "full" image size to the reference list in the Pods Template editor. #7183 #7184 (@JoryHogeveen)
• Fixed: PHP deprecated notices resolved for WYSIWYG field. #7182 (@sc0ttkclark)
• Fixed: Relationships with user capabilities filtered will now work as expected in more cases when using WP multisite. #7181 #7185 (@JoryHogeveen)
• Fixed: Enforce single value for inputs instead of arrays of values in single format for file/relationship field. This resolves issues with Conditional Logic not seeing the initial value on reload. (@sc0ttkclark)
• Fixed: Normalize numbers when doing conditional logic comparisons. (@sc0ttkclark)
• Fixed: Add new options to trim content of fields by removing empty p tags, trimming whitespace at the end of lines, and removing extra lines. Default those to off (previously they were just always on). (@sc0ttkclark)
• Fixed: Add tribe() backward compatibilty function for Pods add-ons that still call that function. This only gets included by Pods when Tribe Common is not detected on the site. (@sc0ttkclark)
• Fixed: Resolve file/relationship lookups for settings pages that are DB vs file-based configs. (@sc0ttkclark)

3.0.4 - September 25th, 2023

• Fixed: Resolve bidirectional removal issue from Pods 2.x where bidirectional relationships would not have the current item removed when you removed that related item. (@sc0ttkclark)
• Fixed: Added repair tool to address the potential for invalid conditional logic saved to the DB in early Pods 3.0 releases or future cases, this is when conditional logic stores a rule that ends up being a long serialized PHP string that contains a serialized PHP array. (@sc0ttkclark)