Pods Access Rights – Admin only notice – ‘Pods single item’ block

I just noticed something weird that makes the whole thing work with my previous created page and ‘Pods single item’-block.

On the page where I inserted the ‘Pods single item’-block under this blocks options on the right panel, initially I left the ‘SLUG OR ID’ field empty. Now when I put in anything random like ‘asdf123’ the content shows up.

Is this supposed to work like that? What’s the purpose of the block-options-field ‘SLUG OR ID’ if I can put any random stuff in there?

Kind regards
rico34

The missing detail is likely the note under the Access Rights tab on the Custom Settings Pod:

Capabilities preview
Below is a list of capabilities that a user will normally need for this content.

Read capability: manage_options
Edit capability: manage_options

The challenge is that WordPress by default does not have read_options and write_options capabilities, but only manage_options, so to avoid security issues, Pods defaults to using manage_options to read a Setting in a Block context, which is accessible to non-administrators.

This causes some disconnect, as some options should perhaps be readable to users who cannot write them, but WordPress / MySQL do not have row-level permissions at the database level like systems such as PostgreSQL, MS SQL, or Oracle. The consequence is that permission to read specific options is typically done per-use-case at the PHP level.

The quickest workaround is to enable access to your desired option/setting via a shortcode, then enable shortcodes in Pods templates:

define( 'PODS_SHORTCODE_ALLOW_EVALUATE_TAGS', true );

…in wp-config.php

Then, in a theme functions.php or plugin:

<?php
add_shortcode(
    'foobarbaz',
    function( $attrs = [], $content = '', $tagname ) {
        return get_option( 'foo_bar', 'baz' );
    }
);

…where the shortcode here would be [foobarbaz], the name of the Pods Setting Page is foo, and the name of the field on that settings page is bar.

So the name of the option is the settings page name and the field name separated by an underscore.

If the setting has no value, get_option() will return the second argument, in this case 'baz', but could also be an empty string, '' meaning display nothing if there is no value set.

So in this example [foobarbaz] will output baz or whatever is input into the field bar on Settings Page foo.

Variations on this approach within a Pods template context might include using a magic tag helper function, for example {@user.ID,fu_means_good_luck}, where fu_means_good_luck is the name of a function which takes the current user’s ID as an argument, then might return any value based on a global setting, that user’s profile, or a mixture of these, such as lucky number for Tuesday:

function fu_means_good_luck( $user_id = 0 ) {
    return sprintf(
        'Your %s number for %s is %d.',
        get_option( 'foo_kind_of_number', 'lucky' ),
        date( 'l' ),
        intval( $user_id * 3.14 * rand( 112, 358 ) )
    );
}

…where the above example would output “Your lucky number for Tuesday is X.”

If nothing is set in field kind_of_number on settings page foo, or awesome instead of lucky if that is typed into the field.

If the current day of the week is Tuesday, it will say that, and the lucky number X will be the user’s ID times 3.14 times a random number between 112 and 358.