Font Awesome field not detected in ACF 5 latest update.

It looks like your plugin got deactivated somehow, can you go into your admin plugins area and make sure it is activated?

The plugin is tested on ACF 5.7.9, and I would have heard from lots of users by now if there were major issues there.

Same issue here.
We have font-awesome ACF plugin on auto-activate – no remove via TGM Plugin Activation: https://github.com/thomasgriffin/TGM-Plugin-Activation

1: font-awesome field is not available as a field option in ACF Pro 5+
2: The FA icons are disappearing from all of our hosted sites where the field data is included via PHP (save_format = ‘element’)

> inbox us if we can be assistance in debugging – we have been using this wonderful plugin for several years and have a lot of sites to run compatibility testing on.

• This reply was modified 6 years, 2 months ago by dj.cowan.

We believe we have located the issue:

line 107 acf-font-awesome.php

add_action( 'after_setup_theme', array( new acf_plugin_font_awesome, 'init' ), 0 );

changed to

add_action( 'plugins_loaded', array( new acf_plugin_font_awesome, 'init' ), 0 );

Changing the action hook from “after_setup_theme” to “plugins_loaded” resolved all of our issues… although we haven’t tested extensively

• This reply was modified 6 years, 2 months ago by dj.cowan.

interesting, I changed the plugin to register itself on after_setup_theme in the latest version, to give peoples theme functions.php time to register the new “ACFFA_override_major_version” filter. This filter has to be registered before the ACF field is registered, and ‘plugins_loaded’ is too early.

Is there something unique about how ACF Pro is being included in your environment?

• This reply was modified 6 years, 2 months ago by Matt Keys.

ACF Pro is loaded as a plugin in the normal way; handled by WP and in the default plugin directory.

@mattkeys I’ve redacted your ask for FTP access and placed your account on moderation.

https://www.ads-software.com/support/guidelines/#being-mod-watched-or-banned

I’ve deleted your offer to login to your user’s site. I’m am 100% sure you mean well but please never ask for credentials on these forums.

https://www.ads-software.com/support/guidelines/#the-bad-stuff

Now for the why: The internet is a wonderful place full of very nice people and a few very bad ones. I’m sure everyone here is very nice however, by giving some ones keys to your house you are trusting they wont steal anything. Likewise the person who takes the keys is now responsible for the house FOREVER.

If something was to go wrong, then you the author may well legally become liable for damages, which they would not normally have been as their software is provided without warranty.

Please be aware that repeatedly asking for credentials will result in us asking you to repeatedly stop before escalating up to the plugins team.

It’s not necessary to ask for that access. There are many ways to get information you need and accessing the user’s site is not one of them. That’s going too far.

• Ask for a link to the https://pastebin.com/ log of the user’s web server error log.
• Ask the user to create and post a link to their phpinfo(); output.
• Ask the user to install the Health Check plugin and get the data that way.
• Walk the user through enabling WP_DEBUG and how to log that output to a file and how to share that file.
• Walk the user through basic troubleshooting steps such and disabling all other plugins, clear their cache and cookies and try again.
• Ask the user for the step-by-step on how they can reproduce the problem.

You get the idea.

Volunteer support is not easy. But these forums need to a safe place for all users, experienced or new. Accessing their system that way is a short cut that will get you into real trouble in these forums.

Hey @jdembowski,

I understand your comments. I was unaware of this policy.

I personally choose to live my life by a different set of principles. I believe that people are generally good. I prefer to trust in people and their intentions and have not been afraid to extend my time/help in this way to diagnose issues for people.

We all put ourselves at risk in one way or another through the decisions we make every day through the choices we make ( driving, eating, etc ). Everyone has their own acceptable level of risk and something that seems appropriate to me might not to another.

I am very good at debugging WP/plugins. But debugging without access is a whole other art form. Thinking about times that I have debugged issues directly on my users environments in the past. There are some that may have been solvable given enough back and forth. But I know for sure that there are others that I never would have solved without being able to directly debug/log data at critical points in the code as things execute in an environment exhibiting the issue.

I do not own this forum, and I am subject to its policies, so I will abide by them. But I wanted to share my feelings/philosophy on this anyways as this has been bugging me since reading your comments this morning.

Matt Keys

Thank you @tncdesigns and @djcowan for submitting this issue, and @djcowan for your help.

I’ve learned more about the factors that cause this bug to appear on some installs and not others that I’ve tested on. It looks like if your theme or a plugin you use makes a call out to any ACF functions (like get_field) *before* WP fires its ‘init’ hook, ACF will initialize itself early to keep working.

This allows you to use ACF fields in places like the functions.php file. However when this happened my field would not be registered because it was on the after_setup_theme hook, which in that scenario would not have fired yet.

I’ve reworked the plugin to still register itself properly in these scenarios. Please let me know if you run into any further issues after updating to v3.0.1.

Thanks,

Matt Keys

Update looks good and s working as expected in our development environment.
Thank you for your prompt resolution of the issue – especially given the time of year. Seasons greetings and thanks again.