Home Forums Backend Issues (wp-admin) Support for Persistent Object Cache


Support for Persistent Object Cache

  • Hello all. We’re using the free version of ACF (4.4.8) with wordpress 4.5.3 along with memcached for persistent object caching.

    We’ve noticed that after creating an ACF group and associating it with a post-type, the ACF fields do not appear in the posts “add new” or “edit post” pages.

    Removing object-cache.php (and, in effect, disabling memcached), makes ACF work as expected. You can now see ACF fields in the “add new” and “edit post”.

    Can someone confirm that ACF 4.4.8 does not work along side persistent object caching? Is there a work around or is the solution to simply disable memcached as I’ve described?

    Does ACF5 support persistent object caching / memcached?

  • Update: I’m seeing the same issue on ACF 5.3.10

    Any help is appreciated.

  • Hi @nicka

    ACF should be working with persistent object caching. It’s possible that there’s something on your site that causes this issue. Could you please try to reproduce the issue on one of the WordPress’ stock themes (like Twenty Sixteen) with other plugins deactivated? If it disappears, then you can activate the theme and plugins one by one to see which one causes the issue.

    If it’s possible, could you please try it on a newly installed WordPress?

    If the issue persists, could you please open a new ticket here: Also, please don’t forget to explain the issue again.

    Thanks 🙂

  • Since 5.4.0, /core/cache.php explicitly adds “acf” to a non-persistent-cache group via calling wp_cache_add_non_persistent_groups().

    So for some reason it has been determined that ACF should not use the persistent cache.

    Why? What’s the logic there and why can’t it be overruled without hacking this file?

    HOWEVER, if you look at wp_cache_add_non_persistent_groups(), it does nothing! It’s an empty function in WP core. So I dunno what to think.


  • Hi @alicam

    Thanks for the post.

    Since version 5.4, the author chose to set update_cache() to false since this has been noted to significantly increase the speed of get_posts() queries. This must be the reason behind this change.

  • Could you provide more info on why persistent cache is skipped by ACF?

    We’re using ACF with WPEngine with ‘Object Caching’ enabled, and ACF skips caching entirely resulting in all calls to ‘get_field()’ being pulled directly from the DB. When we disable ‘Object Caching’ ACF uses the transients API, and it works much more efficiently.

    Can you explain this choice? Why does ACF doesn’t play well with ‘Object Caching’?


  • This is definitely still a big problem. SiteGround’s Memcached Redux-based object caching does not allow refreshing any ACF field values anymore. We’re running ACF PRO 5.6.1.

    What’s the plan or next step here? This is trivial to demo/reproduce, please get in touch if you need access to a staging environment.

  • Ikraav, we’re still having the same issue, even after commenting the line
    wp_cache_add_non_persistent_groups('acf'); inside the plugin ‘cache.php’ file.

    But, after some more investigation it seems like this is happening due to the object cache being full. Since the object cache is full ACF cannot write data to it and ends up retrieving all content from the DB directly.

    You might be having the same issue.

  • Hi,

    Please advise.

    We are on ACF free version 4.4.12. Our website’s front page is entirely generated by ACF fields (get_field etc) — the client (a non IT person) wanted to be able to edit the home page by herself when website launched.

    The website was launched recently, and already we have faced issues twice.

    What happened:

    1. I enabled CloudFlare, but home (front-end) was not appearing properly, I disabled CF. But then ACF field group stopped showing in the back-end, and disappeared from the front-end as well — only header and footer of home page was loading. The SiteGround staff were able to fix the issue after two days of back and forth.
    2. Today, the client updated the home page (changed and image, text), and although ACF field group was loading fine in back-end, the ACF fields disappeared from the home page — again, just header and footer appearing.
    3. This time SiteGround were not able to help — restoring an old backup made no sense. I discovered this and it pointed me in the direction to solve the problem.

      I was able to solve the issue by disabling Memcached in cPanel and renaming the home page slug, clearing cache — did multiple things.

      For now, the website is fine. But I need to make sure this does not happen a third time 🙁

      Can you guys please advise anything? What change I need to make.

      I’m under fire.

  • @arslan I don’t see anybody working on this, so your only choice is to disable Memcached.

    SG head of tech has confirmed to me their platform is not to blame and they’re rather awaiting a “fix” from ACF, whatever this means.

    I’m pretty sure at least the root cause could be identified by a single day debugging session, but who’s going to undertake it? I don’t have skilled enough resource available to do this for a while. ACF team seems to be staying mostly quiet here, too. Anybody else?

  • Thank you lkraav.

    I am keeping memcached disabled for now.

    Additionally, I’ve re-written the home page template using get_post_meta. Now even if I delete (just as a test) the ACF home page field group, the home page keeps working.

    Do you think re-writing template using get_post_meta is s ‘solution’ — should enabling memcached break the site still?

  • Any progress on this front? The silence is terrifying.

  • Bump! Please turn attention to this issue!

  • upgraded from 5.7.10 -> 5.7.12 and so far it looks like that fixed the issues I was having with json config not being saved and certain parts on the front-end not being rendered using object cache. using simple-cache plugin
    …so far. lookin good.

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

The topic ‘Support for Persistent Object Cache’ is closed to new replies.