Recent update broke how pods were used across several websites

I wish that it was an easy decision to not lock things down by default for existing sites but the defaults themselves were as sensible as they could be given the privacy/security issue at hand.

There is a doc page that goes over the new settings available: https://docs.pods.io/displaying-pods/access-rights-in-pods/access-rights-settings-in-pods/

And for power users such as yourself, you’ll find the customization options pretty flexible and I haven’t finished adding even more example code I’m working on yet.

Here’s the customization examples that show how to use constants and hooks: https://docs.pods.io/displaying-pods/access-rights-in-pods/customizing-access-rights-in-pods-with-constants-hooks/

• This reply was modified 1 year, 1 month ago by Scott Kingsley Clark.

You can place your customizations on the sites in question before upgrading them too.

One way to get around this would be to unrestrict display for dynamic features on each of the Pods in question.

You could also use PHP to embed content without any access checks since it only happens for displaying through shortcodes/blocks.

The issue isn’t that I can’t make things work with the new Access Rights. The issue is that it’s already built on a lot of websites, many of which I no longer maintain. I used the settings in the way they needed to be used to do what was needed in the previous system and now this update has broken everything that was set to non-public. I’m not saying you should have set the defaults differently. Setting dynamic_features_allow=1 and restrict_dynamic_features=0 for any EXISTING post type that was not set to public maintains the functionality as it was for everything existing, thus making it backward compatible. This would be easy to push out in a new update and would correct the issue across all of the websites. It could look something like this:

function fix_nonpublic_pods() {
    $pods_post_types = get_posts([
        'post_type' => '_pods_pod'
       ,'numberofposts' => -1
    ]);
    foreach ($pods_post_types as $post_type) {
        $is_public = get_post_meta($post_type->ID, 'public', 1);
        $dynamic_features_allow = get_post_meta($post_type->ID, 'dynamic_features_allow', 1);

        if (!$is_public && $dynamic_features_allow == 'inherit') {
            update_post_meta($post_type->ID, 'dynamic_features_allow', 1, $dynamic_features_allow);
            update_post_meta($post_type->ID, 'restrict_dynamic_features', 0);
        }
    }
}

That should work as a solution but you’ll want to be sure you go to Pods Admin > Settings > Clear Pods Cache after doing that to ensure the config changes are seen if using an object cache.

There’s also some new examples I’ve added that you can leverage in PHP or via Code Snippets:
https://docs.pods.io/displaying-pods/access-rights-in-pods/customizing-access-rights-in-pods-with-constants-hooks/#Unrestrict_all_dynamic_features_for_all_Pods

That snippet is not for me. That snippet is a suggestion for you to implement in a next release so that everybody doesn’t lose the previous functionality of their non-public pods that should be allowed within dynamic features.

To be clear, you’d like to see Pods have a new global setting that would unrestrict a dynamic feature (Display and/or Forms) with the admin accepting those risks?