Home Forums ACF PRO Pruning Orphaned Flex-field Data


Pruning Orphaned Flex-field Data

    • KMDG

    • March 27, 2020 at 1:45 pm

    Hello, I’m hoping for some insights into an issue I’m having. For a variety of reasons I need to prune leftover data from ACF fields when a post is saved. I’ve already read over similar topics (this one being very informative: and I’m fine with wiping out all ACF data attached to a page before saving it (all I care about is a single flex-field and its contents, so all my fields are effectively prefixed by the flex field, which itself has a unique name).

    The issue I’m having is that bizarrely, the deletion process seems to continue to occur even as the post is being saved, leading to some of the new data being deleted as well (some of the data from the first flex row). I’m not sure how or why this would happen – if I run the SQL directly, then save the page, everything works perfectly – but if I tie it into acf/save_posts I always get a partial deletion (tossing in a sleep(X) seems to adjust how much is deleted, making me think that PHP execution is continuing while the SQL runs, but I’ve not seen this happen before and I’m not sure how to stop it – also I would have thought the table would be write locked).

    Here’s an example of the SQL I’m running:

    DELETE FROM wp_postmeta
    WHERE wp_postmeta.post_id = 15543
    AND (
         meta_key LIKE 'page_builder_%'
         OR meta_key LIKE '_page_builder_%'

    Anyone have any ideas that would make sense of this behavior for me?

  • What is the priority of your acf/save_post action?

    Also, I can’t be sure without seeing your action filter. The DB query to delete should be done before ACF inserts new data, so I can’t see why the deletion would continue while the update is being done.

    Also, you may need to clear the meta cache for the post after you do the query. Here is what happens when a field is updated, what WP does.

    First it does a query to see if the value is already in the DB. However, if the value is the the cache then it does not to the query and instead uses the value from the cache. If the new value and the old value are different then it does an update query, but if they are the same it may or may not do the update query (I have never been able to sort out why it sometimes does the update and other times does not).

    There may also be a case where all of the data will be deleted but nothing new will be saved. This could happen if you update a post without making any changes to ACF fields. There is a hidden field for ACF that is a flag indicating if anything was updated. If this flag is not set then ACF will not update values but and your acf/save_post action might not be called.

    • KMDG

    • March 28, 2020 at 2:34 am

    Thanks John, that is very helpful.

    Here’s the entirety of the function, its set to priority 0:

    public static function remove_orphans($post_id) {
            global $wpdb;
            $result = $wpdb->query($wpdb->prepare("
                DELETE FROM {$wpdb->postmeta}
                WHERE {$wpdb->postmeta}.post_id = %d
                AND (
                    meta_key LIKE '".static::PAGE_BUILDER_ACF_FIELD."_%'
                    OR meta_key LIKE '_".static::PAGE_BUILDER_ACF_FIELD."_%'

    It’s very straightforward, hence my confusion.

    The cache is interesting, I will give that a shot in a little bit and let you know if it works… Based on your description that does seem like it could be the source of some odd behavior.

    I don’t think it will be an issue in normal operation if this process gets skipped when no changes are made, but I would like to be able to force it so that I don’t have to go through everything and make arbitrary changes to trigger an update – do you know of an easy way to do so and/or what’s the name of the field ACF uses to track that?


  • I should clarify

    an acf/save_post action with a priority of < 10 will always be called

    The ACF built in acf/save_post action which runs at priority 10 will be called but may not update anything if it detects no changes have been made.

    • KMDG

    • March 28, 2020 at 3:29 pm

    I need to do some additional testing (due to how destructive this operation can be), but initial testing seems to indicate that running wp_cache_flush() immediately after the deletion does indeed fix the problem.

    Thanks a bunch, hopefully that’s all it needed!

Viewing 5 posts - 1 through 5 (of 5 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.