Matt Keys

I’ve been able to identify the bug causing this issue.

/wp-content/plugins/cost-calculator-builder/includes/lib/admin-notifications-popup/classes/ApiNotifications.php Line #26.

if ( false === $transient_data || get_option('_transient_timeout_' . $transient_name ) < current_time( 'timestamp' ) ) {

This looks innocent enough but if you know how WordPress handles transients it explains why this bug is coming up.

By default transients are stored in the database like a WordPress option. And in that case this code will work totally fine.

However once you enable object caching (which many hosting providers do for performance reasons), transients are no longer stored in the database. They are stored in memory with memcache.

And it is in that situation that the code above will always execute, because the call to get_option('transient_timeout' . $transient_name ) < current_time( 'timestamp' ) will ALWAYS evaluate as TRUE because that option does not exist. It doesn’t exist because with object caching/memcache, the transient is in memory, not in the options table in the DB.

And because it is always true, on every single page load in the admin area, it will phone home to promo-dashboard.stylemixthemes.com. This is why our server is getting hammered with these calls.

The solution is easy. The transient API takes care of expiring transients on its own, you do not need to check it yourself in the code. So the line I referenced should just read:

if ( false === $transient_data ) {

I will manually apply this fix to our servers to resolve this issue until it can hopefully be patched in the next version of this plugin.

hi James, can you reread my original post and look at the screenshot I attached? I agree if this was happening once a day it wouldn’t be much of a problem but that’s not what is happening.

Yes this section can be more ‘defensively’ coded to prevent this error, I’ll look to do that in the next update of this plugin. I’m still not sure why this is coming up on your site though, that code has been in place for some time without any other reports of issues. Presumably there is an edge case unique to your installation but hard to say.

Are you sure about that plugin version? That would be quite a bit out of date. 4.1.2 is the latest version.

If you are actually on that old of a version please update this plugin, and go re-save your ACF field groups with this icon field in them. Making sure to double check any settings along the way. In fact that is probably a good first step for you here either way. It feels like for some reason on your site those settings are stored properly in your DB.

This plugin does support repeaters. However you are definitely also seeing a bug. From the error you are seeing, it seems like there is already a value stored in the database under the ACF field key you are using for that icon field on the page that you are editing. And the format of that value is unexpected by this plugin and showing that error.

If it lets you select an icon and save the post you are editing, I’d expect the error to go away. In the next update this plugin probably needs to do more checking on the value in the DB before trying to json_decode() it.

• This reply was modified 2 weeks, 5 days ago by Matt Keys.

Well, I am able to reproduce the error you are seeing. I also see the error if you switch back and forth from preview to editing the block a couple times without duplicating the block.

I don’t have any answers unfortunately and I’m not actually sure if the fix for this would be within my plugin, in WordPress, or in ACF. Using my field within a block isn’t actually something I ever added to this plugin. It is something that ACF made available to all field types and required no changes on my end. So my thinking is this bug probably needs to be fixed within ACF, but I am not certain.

If I figure anything more out about it I’ll share here. Or release an update if it is something I can fix on my end.

Does this error continue after saving/refreshing the post you are editing?

Sorry I’m not sure there is. My first thoughts go to a DB query but it would take some skill and experimentation to execute.

The link you shared is for the older font awesome icons (v5) are you using v5 or v6 icons in the plugin?

It sounds like you have v6 icons enabled in the plugin but are expecting v5 formatting.

• This reply was modified 1 month, 1 week ago by Matt Keys.

I’m not sure why you feel that way but one is not more correct than the other.

I just released v4.1.2 which should help address this issue. This was only showing up on sites which call ACF fields/functions before ‘init’ which is why I was not able to reproduce the problem initially.

However moving this to ‘init’ seems to be more correct anyways and will resolve this issue for those sites which may be forcing ACF to load itself early.

I believe you will need to provide the JSON here. An example would be:

{"family" : "classic", "style" : "regular", "id" : "block-quote", "label" : "Block Quote", "unicode" : "e0b5"}

If you are unsure how to generate this JSON, it might be helpful to select an icon through an ACF field in one of your posts/pages and then look at the wp_postmeta table to find that value stored as you need it.

Well I am not 100% sure I follow what you are trying to do. What function exactly are you passing this array of arguments to?

It might be helpful to create a field and assign it to a post/page. And then go create a new post and select the icon you want, and look at the post meta for that page/custom field in the database to see how it is stored (big json string).

Yes, check out these two filters:

• ACFFA_fa_api_key: Filter to programmatically set the FontAwesome API key.
• ACFFA_fa_kit_token: Filter to programmatically set the FontAwesome kit token.

I saw this reported by another user and I wasn’t able to reproduce it in my environment. If a call to get_field or similar happens before ACF initializes itself it will initialize early and maybe that is causing this notice to appear?