Support

Account

Register Login

Home › Forums › General Issues › Why does add_field always clear the cache?

Solving

Why does add_field always clear the cache?

  • As the title suggests, does anyone know why the field caches are cleared whenever the field is registered? See L223-L224 of acf-pro/core/local.php @ version 5.3.0.

    It makes sense to us to only clear the object caches when the value is changed, unless this covers an edge case we’re unaware of?

  • Because the added fields are not added to the cache and the next time acf gets the fields the new field will be missing, so the cache for the field group’s fields needs to be cleared. Or at least that’s my understanding of it.

    Something similar can happen when you add a field group after getting the field groups… under some conditions. I have a couple of plugins that get all of the ACF field groups, and then adds new field groups based on the existing fields. In these plugins I need to manually clear the acf field group cache to get my new field groups to appear where they are supposed to.

  • This is very confusing. So here is what I am understanding is happening.

    The register acf group function is called. As WP / ACF doesn’t know if this field has been registered before or if it has changed, for good measure it is deleting the field set stored in object cache. Then it creates all the field again for this page load.

    This is madness. Object cache calls should never used to store data only used for a single page load. Persistent object caching is designed to keep data between user sessions. It the data is going to be created and deleted on the fly like this, a php / class level variable should used as it is none persistent.

    At the moment, these pointless deleting of objects in cache are resulting in for about 13% of my page load, every page load.

  • I’m not the developer, so I don’t know completely what the logic of the caching is.

    I do know that there is no persistent object caching built into ACF. ACF is using the WP cache, the same cache WP uses for storing post, meta and other values so that it does not do multiple DB calls to get the same value over and over again on a single page load.

    If you have this set up to be persistent, then that’s another topic.

    So here is what’s happening from what I understand
    — Check to see if there is a cached value
    —- Yes – USE IT
    —- NO – Get the value and store in cache

    This is generally the way caching works

    Your code is adding values after the value has been added to the cache. Therefore the next time the value is needed the cached value will be use. Since your value is not in the cache, if the cache is not cleared then your added value will not exist because the already cached value will be used. So the cache needs to be regenerated to include your new value.

    I’m sure that the developer is not regenerating everything every time. There are many different cache keys for different parts of the data and only the things that need to be generated are.

    If you are using a persistent cache added to WP then I would suggest adding you own object cache in your own code so that instead of rebuilding your local fields every time that you can use your own cached value to add the entire local field group in one call.

  • I am just using the standard memcache plugin and elasticache cluster in AWS. Nothing special about it. When using memcache, calls to the wp_cache_* functions are stored in a persistent object cache called memcache. Persistent object cache are used to speed up sites, because values like queries, meta and objects are stored and kept in between sessions.

    When looking through my new relic data I notice an extremely high number call to the wp_cache_delete function. This is account for around 11.2% of page load. On a high traffic site (multiple million a day), it account for a lot of computing power wasted.

    I want to get a deeper understanding of the reasoning behind this move and see if they plugin was tested using a persistent object cache.

    Thanks.

    Screen-Shot-....png

  • That’s not a question I can answer. I will mark the question for the developer to look at if he has time, but as a general rule he doesn’t actually visit this forum on a regular bases. This is a forum for ACF users to get help from other ACF users.

    But like I said above. If I was having this problem I would do my own caching of the field group I was building using PHP so that I was not actually rebuilding the field group on every page load. ACF is built to take advantage of WP core functionality and core does not include persistent caching.

  • For those who wish to help out can people please comment on the following files

    wp_cache_delete( “get_field/key={$field[‘key’]}”, ‘acf’ );
    wp_cache_delete( “get_fields/parent={$field[‘parent’]}”, ‘acf’ );

    In acf-pro/core/local.php on line 223.

    Let’s see what effect this will have. Hopefully these lines are not required.

  • For most people this may not have any effect, but if the field is altered after that field is put into the cache then when the field is displayed on the edit form it will be displayed as the cached value. Like I said, most of the time, for people that do not add any of acf filters that modify field settings, they probably won’t see any difference but removing the lines will mean that some acf filters will no longer function. I don’t know when this will happen, but it would be interesting to see what happens if others post any results.

  • Jumping in here,
    Those 2 lines are also causing about 10% of additional load time for me as well. This is only the issue when using Persistent Cache.

    I understand why they are deleted, but I agree with Spacedmonkey that it should be a static class variable instead of using the wp_cache or more preferbly ACF checks to see if persistent cache is enabled and doesn’t run those 2 lines.

    So the reason for the deletes is if you change the fields then they need to be deleted. Many persistent caches will have some sort of clear all cache method which a developer would know to use when they update the code. Therefore, it is those 2 lines of code should not run when persistent cache is enabled.

    So I think the main thing here is ACF needs to determine first if persistent cache is enabled and if so to not run those 2 lines.

    There are many ways to check for this, but the easiest that comes to mind would be to check if the file exists (wp-content/object-cache.php)

    Spacedmonkey,
    For now you can get around this by editing wp-content/object-cache.php
    Just edit the “wp_cache_delete” function to only run if the $key and $group don’t match those of the ACF calls.
    Just make sure when you update your fields that you delete the object cache.

    John and Elliot,
    Since many persistent caches with create and delete the wp-content/object-cache.php file on the fly it would make more sense for ACF to run the check. I would recommend that you look into this.

    Thanks

  • I’m just a helper here on the forums. The best suggestion I can give is to report this to [email protected].

  • I have been talking to Elliot about this over email. I have a patch for this bug, but I am not sure what he is going to do about it.

    The patched local.php is attached. All it does, is save the group to cache and only do the delete commands if something in the group has changed. It adds a get to memcache, but saves tonnes of deletes.

    Hope this helps.

    .

  • I am not able to download the attached file. I think the link might not be working properly or you might need to zip it first, but it’s fine as I got my own patch. Thanks for the update.

  • Sorry, not sure what happened there. See this gist with the local.php file

    https://gist.github.com/spacedmonkey/d5a4ae7ef4df86de10f7#file-local-php-L164-L173

    The highlighted lines are the important lines changed. We are using the on live and has fixed the issue for us.

  • @spacedmonkey

    Do you have any suggestions of articles/resources to learn more about WordPress performance on high traffic sites?

  • Hi guys

    This performance bug (with persistent cache) has been solved in recent versions of ACF PRO!

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

The topic ‘Why does add_field always clear the cache?’ is closed to new replies.