Support

Account

Register Login

Forum Replies Created

  • Okay, sorry for having created this thread. Turns out, that if I cleared my cache for the “add new post” page in the dashboard that cleared it up. Hopefully this helps out anyone searching for this issue, though ACF is in the clear!

  • Thanks, John.

    For anyone following along, this is the SQL query to get this done if your fields are simple fields (not repeaters or flexible):

    DELETE FROM wp_postmeta WHERE wp_postmeta.meta_key = "custom_field_name" OR wp_postmeta.meta_key = "_custom_field_name"

  • So all of my posts are now Gutenberg, and all old fields are now custom blocks, and all old data are now in the blocks and in the post content verses meta data.

    I still have my old Field Groups enabled and not-deleted.

    The field names are exactly these:

    • intro-summaries
    • tldr-box
    • features-hero
    • features-alt
    • item-1-affiliate-link
    • item-1-brand
    • item-1-image-url
    • item-1-bottom-line
    • item-1-pros
    • item-1-cons

    The “item-1” ones have variants that say “item-2” and “item-3” as well.

    There’s almost zero way that WordPress or myself have any other meta-keys that match these right? I’ve never used normal custom fields. Only ACF, and only Yoast. I doubt Yoast is using these.

    So what should I do here?

    1) My understanding is that if I delete the Field Groups, the data for these fields will still exist in the posts. Would they then be considered orphaned and a database cleaner plugin find them?

    2) Alternatively, I understand that there’s something about going through your posts and deleting all these content in these fields, setting them to be blank. Does that then remove these entries in the database or are they still there but blank? If this will delete them then I’ll happily grind it out and make them blank in the post edit screen.

    3) The third option is deleting the Field Groups and then running a SQL query on the database.

    Can anyone guide me here to the surefire way to get rid of these entries that doesn’t involve me nuking my site? (I’d take a backup first of course).

  • Alright, I’m documenting this in case anyone in the future needs it. Took extra care to put the right search terms in the thread title, etc.

    Here’s what I got working. Don’t use acf/update_value. You want to use ‘acf/save_post’.

    Next, in functions.php, for some reason using `if( if_page_template(”) )’ was not working at all. It was causing the field to be deleted.

    But you had to “qualify” it in some way to make sure you’re only running on the right custom post template. So what I did was a check to see if the field I’m copying from exists, and it ONLY exists on that custom post template. So that check works out.

    Here’s the code:

    // Take the first WYSIWYG ACF field and copy it into the_content() in order to populate the_excerpt()
function my_acf_copy_content( $post_id ) {
  if ( get_field('acf_site_text_box_top') ) {
    $value = get_field('acf_site_text_box_top');
    wp_update_post( array( 'ID' => $post_id, 'post_content' => $value ) );
    return $value;
  }
}
add_filter('acf/save_post', 'my_acf_copy_content', 20);

    Be careful because without the qualifier, it flat out deletes your entire post on any post not using that custom field, which you then have to retrieve from the revisions.

  • Sorry to bump this thread like this.

    So my attempt above in the functions.php, while wrapped in the is_page_template() didn’t copy to the_content(); It actually just wiped that WYSIWYG box entirely, deleting the content from it.

    I removed the IF is_page_template(); and it worked though…

  • Okay, I’ve answered my first question. This seems like a no-go inside the page template (though I seem to have an error).

    I think it’s going to have to go into functions.php and it SEEMS like I can wrap it in an if statement for is_page_template(‘single_custom_post_template.php’)

    But I’ve done that and it’s not working.

  • @hube2
    I saw something on Stack Overflow about writing some function to copy everything in ACF for a post over to the normal the_content(), and that would allow these Table of Contents plugins to continue to function (since they can’t read ACF fields).

    It was using some ACF filter like “full-text” to copy over to the normal database table for post content. Do you know if this would run through all of the fields in order and copy them in order? If I could do that, the Table of Contents plugins could still read the headers in order.

    What a pain. I’m likely going to have to tell the client that his expectations aren’t going to align with reality.

  • I’m using and have only used Beta 4… Have you submitted details of this as a support ticket? I’ve read that the developers don’t read these forums. I’ve submitted a ticket before and had a timely response. Best of luck!

  • I’m only typing this in hopes it helps you narrow down your issue. I’m using render callbacks (to a function and not a php template file). I have none of the issues you describe. I have not tried a render template at all, so I can’t comment there.

    I can edit in preview mode or edit mode (I default to preview mode) and both will reflect the changes in preview mode either immediately (in preview mode) or when I swap to preview mode from edit mode.

    So far I’m only using text fields, paragraph fields, and checkboxes.

  • I just came here to post about this. I’m really hoping that this won’t appear in the stable 5.8. This is an absolute no-go for me as a speed optimization freak. Does anyone have more insight about this? Good on joshf on figuring out how to dequeue it already, but perhaps it’s needed for the development team in the time being?

  • Elliot said that he’s working on 5.7.12 and hoping to get it out today, then moving to 5.8 beta-4 which will include the 5.7.12 changes and any new work towards getting 5.8 officially released so we can get to building custom blocks.

  • Elliot said he hopes to get 5.7.12 out today that includes all the fixes.

  • I posted in this thread as my first post and it never appeared 🙁 So @dhuyck, you feel confident that nothing fundamental will change when 5.8 gets the official release? All of your blocks will continue to function and maybe at this point 5.8-beta3 is just down to bug hunting and optimizations? I’m scared to commit but I really need to get going on custom blocks.

    Also, if you’re on 5.8-beta3 and 5.8 gets released, will it prompt a normal update within the WordPress Plugins Dashboard?

  • I’m tempted to use 5.8-beta3. I’m about to convert my main site to Gutenberg. I’ve done everything I can in preparation except start converting the posts. I need to make about 5 custom blocks for some categories. I plan on converting the categories I can without ACF for now and hope that 5.8 officially is released by the time I’m done.

    But I’m also nervous about that because 5.8 has been in the works for… 4-5 months now? I’m not dogging the ACF team at all. Gutenberg was a huge ordeal and big mess. But I wish we could get some kind (any kind) of indicator at a time to arrival for 5.8 so we can make educated choices about how to move forward.

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