Change the way Generateblocks accesses post_meta

Hi there,

Which plugin did you utilize for storing ACF data in a custom table? There might be a feature within the plugin that enables retrieval of data from this custom table, which could be beneficial for use in GenerateBlocks.

Hi there,

at this time GB can only retrieve from standard post meta and some ACF fields using get_field ( if using GB Pro ).

To target a different fields saved in other tables would require a different solution.
For exmaple: Does it work with an ACF Shortcode ?

What do you mean by get_field in GB Pro?

Means GB Pro uses get_field() to fetch the ACF data. In your case, it might require the GB Pro plugin.

but it seems that post_meta of the blocks of conditions and others is still not working.

what do you mean by blocks of conditions and others? Can you specify some actual cases?

I’ve read through the plugin’s documentation and it appears they have provided a function to retrieve data from the custom table. You can refer to it here:
https://acf-custom-tables.abhisheksatre.com/docs/functions/get-custom-table-field/

To cover what GB does:

GenerateBlocks Free, can only retrieve the current post meta using get_post_meta

GenerateBlocks Pro, simple ACF Fields that have the Show in REST API enabled should show in the Dynamic Data -> Post Meta field options. Choosing one of those will use the get_field function.

GenerateBlock Pro, Remove Container Condition only works with get_post_meta.

So if there is a simple ACF Field that GB can find it should work exactly as the ACF Shortcode
But the Remove Container Condition will not work with a field that is not visible via get_post_meta

And currently there is no way to change that behaviour. For now you will need to use ACF Shortcodes or render_block etc. In the future we plan to add tighter integration with ACF.

If you need help with removing a container based on the state of an ACF Field then this snippet will help as an example of how to do it with render_block:

add_filter( 'render_block', 'remove_block_content_if_condition_empty', 10, 2 );

function remove_block_content_if_condition_empty( $block_content, $block ) {
    // Check if we are not in the admin and the block has the CSS class 'condition-one'
    if ( !is_admin() && isset( $block['attrs']['className'] ) && strpos( $block['attrs']['className'], 'hide-on-condition' ) !== false ) {
        // Check if the condition is empty
        if ( empty( get_field('condition') ) ) {
            // If condition is empty, remove the block content
            return '';
        }
    }
    // If in admin or condition is not empty, return the block content as it is
    return $block_content;
}

If the Custom Field is available in the current post editor then it will show in the list – see here:

https://app.screencast.com/DQisugVLwyYso

As long as thats working there, then it means GB can find the ACF Field name view REST and if possible will use the get_field function.

When you do get_field() without specifying any ID it will use the current post.
So if you use an ACF Field in a query loop it will look at the current post in the loop to get the value.