Site logo

Archived topic

Custom field in Archive element

32 replies · Started by Dan on September 21, 2021

Viewing posts 16–30 of 33

No problem :)

Hi Ying,
I have uploaded the site to a staging env.
Can you please look into the custom field not showing up?

The element name is: Catalog Post Categories and Tags Layout
and I've added a post meta heading that should pull in the custom field 'short_description'
I pasted the site's credentials below.

Thanks for your help,
Dan

Hi there,

it shouldn't really matter if the CF is registered via a block or a meta box.
I notice that the field type is set to wysiwyg ... which may be the issue. Does it work if its set to a plain text field?

Hi David,
I change the CF to be a text field, but still no go.
more info in the private window

Hi David, have you had a chance to check?
Thanks,
Dan

Hmmm... not sure on this, i can only assume the the fields are 'sub_fields' of the parent group field.
Might be worth checking with ACF on that. And if thats the case you would need an ACF Shortcode to retrieve those values.

Hi David, this field is not a sub-field.
it's a regular text field:
<h2 class="description"><?php the_field('short_description');?></h2>

GP is not pulling in anything from that, even not the 'before text'.

Dan

GP only outputs the frontend PHP/HTML if the Dynamic Data type returns a valid value. Thats ALL of the markup including before text. As nothing is being output it means that GP cannot either find the meta key or the value or its an unsupported field type.

This is the method that GP uses to get Post Meta ( Custom Fields )

get_post_meta( get_the_ID(),'add_your_meta_key', true);

Which should work if the Meta Key contains a single value ( not a sub/nested field ) and is stored in the Post Meta.

I had a nose around re: ACF Blocks, and i looks like the Block data is stored in the post_content ( not the post meta ):

https://support.advancedcustomfields.com/forums/topic/where-are-acf-blocks-fields-content-stored/#post-121109

Which isn't retrievable via block elements as it cannot parse the post_content for this meta.

I did find this tutorial which explains how to retrieve data stored in a block. But it would require a Shortcode or other function to implement that in a block element:

https://portalzine.de/dev/php/advanced-custom-fields-get-gutenberg-blocks-data/

Thanks David for looking into this.
This is a big issue since using ACF with blocks is the new standard with CF and not having the option to pull in the custom data into a GP template element kin of misses the point of using the template.
Is there a GP filter to look for the value and add it as a post meta?

I also found this thread on GH:
https://github.com/AdvancedCustomFields/acf/issues/83

Do you think that this filter would work in order to display post meta within the GP element template:

add_filter('acf/load_value', function( $value, $post_id, $field ) {

  global $post;
  $maybe_post_id = $post->ID;
  if ( is_admin() && function_exists( 'acf_maybe_get_POST' ) ) {
    $maybe_post_id = intval( acf_maybe_get_POST( 'post_id' ) );
  }
    
  if( $maybe_post_id !== $post_id ) { 
    $value = get_post_meta( $maybe_post_id, $field['name'], true );
  }
  return $value;

} , 10, 3);

This code works, but I'm not sure how efficient it is:

add_filter( 'wp_insert_post_data', function ( $data, $postarr ) {
	if (0 === $postarr['ID']) {
		return $data; // This is a brand new page, nothing to do here.
	}

	// Unslash because the ACF blocks are slashed, might interfere with other blocks?
	$blocks = parse_blocks( wp_unslash( $data['post_content'] ) );
	// $acf_block_definition = acf_get_block_fields(['name' =>'acf/comic']); // unused but might be useful.
	foreach ( $blocks as $block ) {
		if ( 'acf/catalog' !== $block['blockName'] ) {
			continue; // Only parse acf/catalog blocks.
		}
		$acf_metas = $block['attrs']['data'];

		foreach ( $acf_metas as $meta_key => $meta_val ) {
			// Possible test for key's with that start with <code>_</code> as these (most of the time) contain the field_H@sh.

			// Not tested with groups and repeaters.
			update_post_meta( $postarr['ID'], $meta_key, $meta_val );
		}
		break; // Only save the first catalog block on the page, again your use case might differ.
	}

	return $data; // We never touched $data, that's fine.
}, 10, 2 );

Problem here is ACF is doing there 'own thing' - whereas with GP we stick to core functions and the core WP principles. Integrating with 3rd party plugins that are using abstract methods is always a concern ie. ongoing maintenance and redundant code if the 3rd party changes direction. But ACF integration is something we are looking at... in regards to ACF Blocks well ...

... reading through that GIT issue - it sounds like something ACF need to address ie. provide the option to store Post IDs and push data to the post_meta tables.

That filter if it works looks to be returning block data to the Post Meta tables. If that is the case then GP should be able to see it ie. get_post_meta will find it.

The alternative approach is to NOT use ACF Blocks. Instead just use the regular options. Then you can add a Block Element to display the ACF content on your single post ( or create an entire single post content template ) and style the output with GenerateBlocks in the Element.

Thanks David,
that filter does work, the reason for using an ACF block is that's it's very flexible and allows also for repeater fields.

That new code ( thanks for sharing - i didn't see it on my last reply :) ) should only fire when the data is being initially written to the database. So front end performance shouldn't be affected.

correct, it does not take the data retroactively but only after save / update of the post.

This archived topic is closed to new replies.