Support

Account

Home Forums Front-end Issues Blocks: Returning image URL in rest API

Solving

Blocks: Returning image URL in rest API

  • Hey all,

    I’ve got a custom block configured via this post here:
    https://www.advancedcustomfields.com/blog/acf-5-8-introducing-acf-blocks-for-gutenberg/

    It works when viewing the post in Gutenberg, however, I’m setting up headless WP. I took a step further to expose the blocks API here:
    https://wpscholar.com/blog/add-gutenberg-blocks-to-wp-rest-api/

    This works, and I can get all of the ACF field data as JSON. The only problem is with images – I want to return it as an image URL string, but they’re being returned as image ID’s no matter what setting I adjust in ACF:
    http://prntscr.com/ofxytl

    I could make a custom block separate from ACF, but I’d prefer to stick with ACF since it’s what I’m using for most of my content.

    The solution seems to adjust the attrs where the custom block is being made, but I don’t know where to find that in the ACF code. Can anyone point me in the right direction?

    Here’s my code:

    *Functions.php (registering the custom ACF testimonial block)*

    `
    function register_acf_block_types()
    {

    // register a testimonial block.
    acf_register_block(array(
    ‘name’ => ‘testimonial’,
    ‘title’ => __(‘Testimonial’),
    ‘description’ => __(‘A custom testimonial block.’),
    ‘render_callback’ => ‘my_acf_block_render_callback’,
    ‘category’ => ‘formatting’,
    ‘icon’ => ‘admin-comments’,
    ‘keywords’ => array(‘testimonial’, ‘quote’),
    ));
    }

    // Check if function exists and hook into setup.
    if (function_exists(‘acf_register_block_type’)) {
    add_action(‘acf/init’, ‘register_acf_block_types’);
    }
    `

    *functions.php (exposing blocks API)*

    `
    function registerBlockRest()
    {

    if (!function_exists(‘use_block_editor_for_post_type’)) {
    require ABSPATH . ‘wp-admin/includes/post.php’;
    }

    // Surface all Gutenberg blocks in the WordPress REST API
    $post_types = get_post_types_by_support([‘editor’]);
    foreach ($post_types as $post_type) {

    if (use_block_editor_for_post_type($post_type)) {
    // echo “post types is: ” . use_block_editor_for_post_type($post_types);
    register_rest_field(

    $post_type,
    ‘blocks’,
    [
    ‘get_callback’ => function (array $post) {
    return parse_blocks($post[‘content’][‘raw’]);
    },
    ],
    );
    }
    }
    }

    if (function_exists(‘registerBlockRest’)) {
    add_action(‘acf/init’, ‘registerBlockRest’);
    }
    `

  • Hey all,

    I’ve got a custom block configured via this post here:
    https://www.advancedcustomfields.com/blog/acf-5-8-introducing-acf-blocks-for-gutenberg/

    It works when viewing the post in Gutenberg, however, I’m setting up headless WP. I took a step further to expose the blocks API here:
    https://wpscholar.com/blog/add-gutenberg-blocks-to-wp-rest-api/

    This works, and I can get all of the ACF field data as JSON. The only problem is with images – I want to return it as an image URL string, but they’re being returned as image ID’s no matter what setting I adjust in ACF:
    http://prntscr.com/ofxytl

    I could make a custom block separate from ACF, but I’d prefer to stick with ACF since it’s what I’m using for most of my content.

    The solution seems to adjust the attrs where the custom block is being made, but I don’t know where to find that in the ACF code. Can anyone point me in the right direction?

    Here’s my code:

    *Functions.php (registering the custom ACF testimonial block)*

    
    function register_acf_block_types()
    {
    
    	// register a testimonial block.
    	acf_register_block(array(
    		'name'				=> 'testimonial',
    		'title'				=> __('Testimonial'),
    		'description'		=> __('A custom testimonial block.'),
    		'render_callback'	=> 'my_acf_block_render_callback',
    		'category'			=> 'formatting',
    		'icon'				=> 'admin-comments',
    		'keywords'			=> array('testimonial', 'quote'),
    	));
    }
    
    // Check if function exists and hook into setup.
    if (function_exists('acf_register_block_type')) {
    	add_action('acf/init', 'register_acf_block_types');
    }
    

    *functions.php (exposing blocks API)*

    
    function registerBlockRest()
    {
    
    	if (!function_exists('use_block_editor_for_post_type')) {
    		require ABSPATH . 'wp-admin/includes/post.php';
    	}
    
    	// Surface all Gutenberg blocks in the WordPress REST API
    	$post_types = get_post_types_by_support(['editor']);
    	foreach ($post_types as $post_type) {
    
    		if (use_block_editor_for_post_type($post_type)) {
    			// echo "post types is: " . use_block_editor_for_post_type($post_types);
    			register_rest_field(
    
    				$post_type,
    				'blocks',
    				[
    					'get_callback' => function (array $post) {
    						return parse_blocks($post['content']['raw']);
    					},
    				],
    			);
    		}
    	}
    }
    
    if (function_exists('registerBlockRest')) {
    	add_action('acf/init', 'registerBlockRest');
    }
    
  • Hello,

    Were you ever able to make any progress on this? I’ve just run into the same issue (ACF storing image id in json, instead of image url).

    -Adam

  • @metainteractive I did not :/

    I ended up ditching WP headless and moved to Contentful since I needed a more scalable and more customizable headless CMS – I’m working on a single, very large project vs working on many smaller projects, so Contentful was the right choice for me.

  • Yes please, also looking for a solution to this issue!

  • Our solution to this problem.

    We’ve adjusted the wp-rest-blocks plugin by spacedmonkey so it returns the image metadata. Only thing is that the name of the field always needs to have the word ‘image_data’ in it. See a forked version of the plugin here: https://github.com/pixelastronauts/wp-rest-blocks

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.