Support

Account

Register Login

Forum Replies Created

  • Ahhh, that explains a lot of weird stuff that had been going on.
    Thanks a lot for pointing it out, completely missed this!
    (It might be useful if this was somehow even passingly mentioned here, IMHO)

  • No idea if this helps, but I recently had to get a CPTs ACF metafields displayed in an ACF Block. This is what I put in the blocks template:

    $eventdate = get_post_meta( get_the_ID(), 'client_event_date', true );
$eventstarttime = get_post_meta( get_the_ID(), 'client_event_starting_time', true );
$eventendtime = get_post_meta( get_the_ID(), 'client_event_ending_time', true );
$eventtype = get_post_meta( get_the_ID(), 'client_event_type', true );

if( $eventdate ) {
	$eventdate = strftime('%A, %d. %B %Y', strtotime($eventdate));
	
	echo '<div class="eventdate"><h4>';
    echo $eventdate;
	if ( $eventstarttime ) { 
		$eventstarttime = strftime('%R', strtotime($eventstarttime));
		echo ', from ' . $eventstarttime;}
	if ( $eventendtime ) { 
		$eventendtime = strftime('%R', strtotime($eventendtime));
		echo ' to ' . $eventendtime; }
		echo '</h4></div>';
	if ( $eventtype ) {
		
	}
} ?>

    Note that this is obviously rendered identically in the editor as on the frontend – which is the reason I’m browsing these forums, trying to find a way to reliably change a Blocks output when in the Block editor 🙂

  • Not sure if this is helpful, but here’s a setup I’ve been using:
    *acf-blocks-plugin.php
    **blocs/blockname/blockname.php
    **blocs/blockname/blockname_template.php
    **blocs/blockname/blockname_style.css

    In *acf-blocks-plugin.php I’m calling

    // Get plugin Path directory
if ( !defined( 'FP_PLUGIN_PATH' ) ) {
    define( 'FP_PLUGIN_PATH', plugin_dir_path( __FILE__ ) );
}
if ( !defined( 'FP_PLUGIN_URI' ) ) {
    define( 'FP_PLUGIN_URI', plugin_dir_url( __FILE__ ) );
}

    and then

    add_action('acf/init', 'fp_acf_init');
function fp_acf_init() {

	// check function exists
	if( function_exists('acf_register_block_type') ) {

		// register the Product Select block
        include( FP_PLUGIN_PATH . 'blocks/prodselect/prodselect-block.php');

		// register the Product Image Select block --> Images with lightbox
        include( FP_PLUGIN_PATH . 'blocks/prodimage/prodimage-block.php');

    Inside a **blocs/blockname/blockname.php there’s the usual ACF block code

    // register the products filter block
acf_register_block_type(array(
	'name'				=> 'fp_blocklink',
(…)
	'post_types' 		=> array( 'post', 'page', 'fp_produkt'  ),
	'render_template'   => FP_PLUGIN_PATH . '/blocks/blocklink/blocklink-template.php',
    'enqueue_style'     => FP_PLUGIN_URI . 'blocks/blocklink/blocklink-style.css',
));

    I’m not really sure the enqueue_style makes much sense, TBH, but the rest seems to be working OK so far.

  • Like others, we’re thinking of changing as many sites as possible from Google Maps to OSM, and for this reason the ability to use OSM natively in ACF would be very welcome.

    Of course, this’d be even better if the OSM field also supported the more detailed address subfields that are now in the native Map field, so we could easily search or filter for city or post code.

  • While it is probably possible that some wp-config files might go public, it is a risk that premium plugins like Gravity Forms, WP Migrate DB Pro and Admin Columns Pro are willing to take, and have been for quite a while.

  • Did you try to echo the CSS location in the render template? Does it give a valid URL?

  • Actually, the solution was embarrassingly simple and obvious: for some reason ACF hadn’t updated from 5.8b4 to the lastest stable version.
    When I noticed yesterday, I updated manually to 5.8.1, and now everything seems to work brilliantly, as is customary with ACF.

  • Pretty sure we’ll be able to use ACF for both blocks and meta fields in the future too, since it’s basically what Elliot states is planned for ACF 6: https://twitter.com/wp_acf/status/1133564632101031936

  • Still haven’t had much luck with this so far.
    Conditionals using (id_admin()) or `$current_screen = get_current_screen();
    if ( method_exists( $current_screen, ‘is_block_editor’ ) && $current_screen->is_block_editor() ) {` just made the block editor stop being able to save the page.

  • Besides putting the required field in the classic below-the-post-content position, nope.
    Haven’t tested ACF Pro 5.8 Beta 3 yet, but I’m not really expecting this to be fixed anyway.

  • This reply has been marked as private.

  • Added second screenshot with slightly more explanation.

    Bildschirmfo....png

  • +1
    Just re-entered ACF licenses in a bevy of sites after doing Migrate DB updates. Having this solved in an official way, like Gravity Forms (and Migrate DB Pro), would be really nice.

  • Actually, and unfortunately, I have nothing more than what I found on their documentation, since I had to stop using external service altogether (clients wish is my command, and so on) and go with a slow WP-native database-search solution.

    Sorry!

  • Hi James,
    I indeed found the solution, by following the WPGmaps guide, which thankfully is a bit more detailed than ACP’s somewhat sparse “you have to register the API” 🙂

    Thanks,
    Phil

  • Thanks wube, creating page-specific option subpages has helped me a lot.
    However, I’m not sure as to why you duplicate your field groups – why not simply assign the same field group to the various option pages?

  • Brilliant, thanks!
    As usual: the solution is quite obvious.

  • I fully appreciate this, especially since I happen to think ACP to be among the very best things to happen to WordPress, and in my humble view it is executed flawlessly.

    Maybe it would be enough to make sure there’s at least a short page for every field type in ACP, so simple-minded folks like me don’t begin to question their own sanity searching for it.

    BTW, I’ve been able to solve the problem using WP and PHP functions. I still have no idea if I could have used any of those handy ACP functions, though.

  • Hi Jonathan

    thanks!
    I knew it would be something obvious.

  • Yes, the taxonomy is registered for all post types that use it:
    register_taxonomy( "year", array( "attachment", "concert", "interpret", "composer", "longread" ), $args );

    Could the error be in how the taxonomy is registered and what ACF uses as taxonomy name (“year” vs “concert_year”)?

  • Hi Jonathan

    the taxonomy field is indeed set to map to the post (if I understand it correctly): Create, Save and Load Terms are all set to Yes.

    The taxonomy is shared between this post type, three more custom pst types, and an options page, if that makes any difference.

    Thanks for any+all hints!

    -Phil

  • Setting the Relational Post Object to write back to the post (the german translation for this function is not entirely cleat BTW), changing the taxonomy selector to Radio Button (drop down seem to have a bug, as it mixes taxonomies translations) and opening and re-saving every member CPT did the trick, with the following code:

    $tax = get_field_object("department");
$taxnum = $tax['value'];
$taxtax = $tax['name'];
$dept = get_term( $taxnum, $taxtax );
$deptname = $dept->name;

    Now for the same fun in a repeating field group… yay!

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