Support

Account

Register Login

Forum Replies Created

  • See also: https://github.com/WordPress/gutenberg/issues/14878

    In my case the bug only presents when I have scrollbars set to always show in OS X, as described in that GiHub issue. When scrollbars are set to show “Automatically based on mouse or trackpad” there is no flickering.

    Until the fix finds its way into WP core that might be a workaround if you are on OS X.

  • I knew you’d be across it, John!

    Though I’m not sure I would call it a hack. It seems cleaner than having to explicitly pass an ID to every call to the_field/get_field?

    Speaking of which, I just ran across a similar problem when using ACF Post Objects inside ACF Gutenberg Block render templates:

    https://support.advancedcustomfields.com/forums/topic/post-objects-setup_postdata-and-get_field-in-acf-blocks/

    I am interested to know if this is something you’ve come across before John?

  • I think it is possible to nest setup_postdata() while also avoiding multiple calls to wp_reset_postdata(). This can be achieved by storing the post object that you want to revert to in a variable, and later running setup_postdata() on it.

    Untested code to demonstrate:

    // Inside the main loop.

// Setup outer post object.
// Store it in $outer_post_object so that we can revert to it later.
$outer_post_object = get_field('my_field');
$post = $outer_post_object; // override $post
setup_postdata($post);

// Later on, setup an inner post object
$inner_post_object = get_field('my_sub_field');
$post = $inner_post_object; // override $post
setup_postdata($post);

// Later on, when you want to revert to $outer_post_object
// Instead of wp_reset_postdata(), do this:
$post = $outer_post_object;
setup_postdata($post);

    Using this technique you can have as many nested setup_postdata() as you like.

  • You might be looking for the mode option for acf_register_block?

    https://www.advancedcustomfields.com/resources/acf_register_block/

    It sets the block’s default display mode, either “edit” or “preview”.

    Using the supports option you can disable toggling between modes, too. So you could disable the preview mode entirely if you want.

  • The fix described in this github issue did the trick:

    https://github.com/elliotcondon/acf/issues/743

    To apply the fix to ACF Pro 5.8beta3, change the following portion of pro/assets/js/acf-pro-input.min.js:

    addSortable:function(t){this.$collection().sortable({items:".acf-gallery-attachment",forceHelperSize:!0,forcePlaceholderSize:!0,scroll:!0,start:function(t,e){e.placeholder.html(e.item.html()),e.placeholder.removeAttr("style")}})

    becomes:

    addSortable:function(a){this.$collection().sortable({items:".acf-gallery-attachment",forceHelperSize:!0,forcePlaceholderSize:!0,scroll:!0,start:function(t,e){e.placeholder.html(e.item.html()),e.placeholder.removeAttr("style")},update:function(t,e){a.$input().trigger("change")}})

  • @philf Your plugin works like a charm! Thank you for taking the time to make it.

  • @wpfangirl makes an excellent point. Although I originally assumed that blocks would completely replace custom fields, I now see that they serve very different purposes, and can co-exist.

    One area that meta fields shine is that is is easy to display them outside the post’s content, or perform data operations on them: retrieving a single piece of data from another post, or comparing two dates, for instance.

    Blocks, on the other hand are for formatting the main content area of a post. If your data only ever needs to be displayed on a single post, then a block might be a good fit.

  • I don’t think there is an official timeframe for the release of 5.8, but Elliot said on Twitter that he is aiming for February or March.

    I have been playing with Gutenberg Blocks today in 5.8 beta 3, and it works really well for me.The post-TinyMCE world isn’t seeming quite as bleak now.

    I see blocks and custom fields working in tandem, rather than having to choose one approach or the other. They fulfil different roles:

    Blocks are useful for formatting a single “blob” of content, such as a blog post. They are a replacement for everything we would previously have put into TinyMCE (duh).

    Custom Fields are useful for data that needs to be displayed or acted on outside of that “blob”. For example start and end dates for an event. Sure, you *could* save the dates inside a block, but it is much easier to perform date comparisons on meta data, the way we’ve always done with ACF.

    At this stage my only gripes about how ACF integrates with Gutenberg is that the “hide editor” option doesn’t work, nor is it possible to display custom fields above the editor.

    It is great to hear that Elliot is working on this, though (per the github issue that John linked to). If/when we can hide the editor then I think we will have arrived at a happy place.

    In the meantime I came up with a workaround that effectively removes the Gutenberg editor, leaving only the title and ACF fields. The trick is to disable ALL block types for your CPT:

    add_filter('allowed_block_types', 'my_allowed_block_types', 10, 2);
function my_allowed_block_types($allowed_blocks, $post) {
  if( $post->post_type === 'myCPT' ) {
     return array();
    }
}

  • I don’t think there is an official timeframe for the release of 5.8, but Elliot said on Twitter that he is aiming for Feb or March.

    I have been playing with Gutenberg Blocks today in 5.8 beta 3, and it works really well for me.The post-TinyMCE world isn’t seeming quite as bleak now.

    I see blocks and custom fields working in tandem, rather than having to choose one approach or the other. They fulfil different roles:

    Blocks are useful for formatting a single “blob” of content, such as a blog post. They are a replacement for everything we would previously have put into TinyMCE (duh).

    Custom Fields are useful for data that needs to be displayed or acted on outside of that “blob”. For example start and end dates for an event. Sure, you *could* save the dates inside a block, but it is much easier to perform date comparisons on meta data, the way we’ve always done with ACF.

    At this stage my only gripes about how ACF integrates with Gutenberg is that the “hide editor” option doesn’t work, nor is it possible to display custom fields above the editor.

    It is great to hear that Elliot is working on this, though (per the github issue that John linked to). If/when we can hide the editor then I think we will have arrived at a happy place.

    In the meantime I came up with a workaround that effectively removes the Gutenberg editor, leaving only the title and ACF fields. The trick is to disable ALL block types for your CPT:

    add_filter('allowed_block_types', 'my_allowed_block_types', 10, 2);
function my_allowed_block_types($allowed_blocks, $post) {
  if( $post->post_type === 'myCPT' ) {
     return array();
    }
}

  • This bug has been fixed in 5.7.9

  • I can confirm this bug. In our case it was a mandatory date field in a repeater that triggered the JS error, even if no instances of the repeater had been added to the page.

    WP 5.0 (with Classic Editor plugin installed) and ACF Pro 5.7.8, in our case.

  • Although I can’t remember precisely what problem I was having when I opened this thread, I have marked it as solved. Good work John!

  • I can confirm that when following the steps in my original post, no ghost data is displayed on the front end within a regular while (have_rows) loop.

    I wish I had mentioned in my original post what steps to take to get the ghost data to display on the front end, but six months later I’m afraid can’t remember!

    Perhaps, as John suggests, there was some other factor at play. Perhaps I was accessing data outside an ACF loop. Or maybe the behaviour of ACF has changed since February to fix my initial problem.

    Hopefully Michelle’s testing will be able to shed some light.

  • I can’t remember why the undeleted field data bothered me, but I imagine it was the same as Michelle: it was showing up on the front end.

    Certainly it was problematic enough that I opened a bug report.

    In any case, when data is deleted but not removed from the database that feels like a bug to me.

    The way that I imagine you would fix this problem is by deleting the data from wp_postmeta via AJAX when the user deleted the Flexible Content row. I imagine this would be much more efficient than trying to clean it up when the post is saved.

  • Haha – yeah when I figured it out I felt a little sheepish. But knowing that someone else had the same problem makes me feel a little less foolish!

  • It was just me being a dumbass. In ACF Pro (and possibility newer versions of ACF free?), when “Allow Null?” option is set to “Yes” for your field a small cross appears at the right-hand side of the field, which allows the user to clear the value.

  • ACF has a filter for controlling what buttons are shown in the TinyMCE WYSIWYG editor:

    http://www.advancedcustomfields.com/resources/customize-the-wysiwyg-toolbars/

  • P.S. The version numbers I mention above refer to ACF Pro. I’m not sure if ACF free version is affected, or if it uses the same numbers.

  • Same here. The problem is with 5.1.9.1. Rolled back to 5.1.8 and it works again.

    In my case here’s what happened:

    – I could use “Screen Options -> Show on Screen” to reactivate an ACF meta box.
    – That would work for the specific page
    – If I navigated to another page and reactivated its meta boxes, meta boxes for all other pages would disappear again

  • If you want a more targeted approach, run the field through wptexturize (http://codex.wordpress.org/Function_Reference/wptexturize).

    echo wptexturize(get_field('my_field'));

    Although the_content filter works, in addition to wptexturize it runs your content through a bunch of other transformations that might be undesirable, wrapping it in paragraph tags for instance.

  • Same thing here. To elaborate on the bug, in my case the problem occurs when flexible content field names are duplicated.

    e.g.

    Flexible Content Layout #1
    Name: type1
    Fields: subfield1

    Flexible Content Layout #2
    Name: type2
    Fields: subfield1, subfield2, subfield3

    get_sub_field(‘subfield1’) will only work for rows of layout ‘type1’. For a row of layout ‘type2’ fields with unique names will display (‘subfield2’, ‘subfield3’), but the field with a duplicate name will return empty (‘subfield1’).

    Downgrading to 5.1.0 fixed the problem.

  • @Twansparent It’s certainly hard to decide whether a Repeater or a Custom post Type is the better approach. For an image gallery a Repeater is far more user friendly to edit, but if the Repeater grows too large I suspect performance and usability will suffer.

    P.S. I realised that my custom function to generate pagination links is totally redundant since WP’s native paginate_links can be used instead. Facepalm. I’ve updated my blog post accordingly.

  • I just wanted to say thanks to Elliot and Twansparent. Your contributions to this thread helped me implement pagination for a Repeater.

    I’ve written up my solution on my blog:

    http://f6design.com/journal/2014/03/06/paginating-an-advanced-custom-fields-repeater/

    It’s similar to the code Twansparent posted in this thread, but leverages WordPress’ native pagination permalink structure (e.g. /gallery/page/2), so there is no need to do any custom URL rewriting. My pagination is different too, in that it generates pagination links identical to those created by WordPress’ paginate_links function, e.g.

    << Previous 1 … 4 5 6 7 8 … 23 Next >>

    Hope that’s helpful to someone.

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