• Resolved helenagwyn

    (@helenagwyn)


    I’m having issues since the new update with my custom callbacks not working anymore. This is for example part of my code.

    wp-config.php

    define( 'PODS_DISPLAY_CALLBACKS_ALLOWED', 'format_pods_date,vertaal_leesverder');

    functions.php

    function format_pods_date($input_date) {
    return date_i18n("j F Y", strtotime($input_date));
    }

    function vertaal_leesverder($id) {
    return __('Lees verder ...', 'project-name');
    }

    template

    {@startdate,format_pods_date}

    {@ID,vertaal_leesverder}
Viewing 8 replies - 1 through 8 (of 8 total)
  • Plugin Support pd

    (@pdclark)

    Apologies, should work with wp-config.php revised to:

    define( 'PODS_DISPLAY_CALLBACKS', 'customized' );
    define( 'PODS_DISPLAY_CALLBACKS_ALLOWED', 'format_pods_date,vertaal_leesverder');

    …due to includes/access.php:1513-1524

    Thread Starter helenagwyn

    (@helenagwyn)

    Sorry, still not working. The settings-page is still listing them as well. Anything I need to change there?

    Plugin Support pd

    (@pdclark)

    The configuration you’ve specified works in testing here. Please verify there is not an additional page builder causing conflicts, or specify what the unexpected output is.

    Here were the situations I tested:

    wp-config.php

    These two lines were added to wp-config.php.

    The first line corresponds to and overrides Display Callbacks option on WP Admin > Pods Admin > Settings — setting it to Customized (…).

    The second line corresponds to Display Callbacks Allowed. Setting the list in wp-config.php causes a function name prefix to not be required.

    define( 'PODS_DISPLAY_CALLBACKS', 'customized' );
    define( 'PODS_DISPLAY_CALLBACKS_ALLOWED', 'format_pods_date,vertaal_leesverder');

    functions.php

    I tested these as specified and with minor modifications to verify output changed when placed in different locations. I tested them defined in a plugin and in the theme’s functions.php.

    function format_pods_date( $input_date ) {
    return date_i18n( 'j F Y', strtotime( $input_date ) );
    }

    function vertaal_leesverder($id) {
    return __('Lees verder ...', 'project-name');
    }

    template

    I tested this by extending the Post post type by adding a Date field named startdate.

    In a default WordPress configuration with Gutenberg, I opened the default Hello World! post tested each of these in a shortcode block:

    [pods]
    {@startdate,format_pods_date}
    {@ID,vertaal_leesverder}
    [/pods]

    …where the above would auto-detect name="post" and id="1" for the Hello World! post being viewed.

    And with a named Pod template:

    [pods template="Test 1"]

    Where the Test 1 Pods template contained:

    {@startdate,format_pods_date}
    {@ID,vertaal_leesverder}

    In both cases, the out was the expected:

    6 September 2026
    Lees verder …

    …where the only difference was that the first version had the two items on separate lines due to WordPress post content formatting applying to the template, while the template="Test 1" version placed the date and Lees verder ... on the same line, because using a named template kept template formatting separate from post formatting.

    Conclusion

    • Check for page builders or other formatting filters which may be conflicting with output
    • Try the named template version if template is being listed inline
    • Try turning off other plugins, page builders, or switching to a default theme to rule out conflicting functionality
    Thread Starter helenagwyn

    (@helenagwyn)

    I installed a new wordpress using the default 2025-theme, added the two lines in wp-config and the two functions in the themes functions-file, so no plugins or page builders. I’m still getting:

    Thread Starter helenagwyn

    (@helenagwyn)

    Apparently I had to add the following to functions.php as well:

    add_filter( 'pods_access_callbacks_custom_prefix', function( $prefix ) { return ''; });

    I also noticed that <style>-tags are stripped when used in templates. Is there a way around that?

    Plugin Support pd

    (@pdclark)

    There was a recent change which would remove inline <style> tags from templates…

    If variables / magic tags are not needed, an HTML block or code field should both work. The first would store the CSS outside of Pods, the second would move the <style> content into a field.

    If calculations or variables etc are necessary, a PHP shortcode or action attached to wp_head or the_content or similar would be usual routes. There are also WP functions for inline styles, but I believe they have to be associated with other non-inline CSS files.

    Plugin Author Scott Kingsley Clark

    (@sc0ttkclark)

    I believe I already have a fix for the style tag issue, I’ll look today to confirm

    Plugin Author Scott Kingsley Clark

    (@sc0ttkclark)

    I’m going to also make it so if you set the constant then it will bypass the prefix requirement too.

Viewing 8 replies - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.