Matt Keys
Forum Replies Created
-
You’ll be happy to hear a new contributor will be joining this project to bring it up to spec for FA7. I know I am! Getting him onboarded now so look to see changes soon.
Forum: Plugins
In reply to: [Advanced Custom Fields: Font Awesome Field] Font Awesome 7 Support?me {the at sign} mattkeys { dot } me
Forum: Plugins
In reply to: [Advanced Custom Fields: Font Awesome Field] Font Awesome 7 Support?That’s a question I’ve been asking myself too. My life has gotten busy with some projects outside of the development world so I am currently figuring out where these open source projects fit in.
I don’t have an answer yet. But I don’t think I will have FA7 support in the near future.
I haven’t had an opportunity to test with FA7 yet but my assumption is that an update to my plugin will be required to support it.
Forum: Plugins
In reply to: [Advanced Custom Fields: Font Awesome Field] Bulk-updating Icon versionCompatibility mode tries to automatically fix the issues you were seeing the warning about. So you may run into far fewer, or perhaps even no remaining icons that couldn’t be fixed automatically.
But there could still be some icons that couldn’t automatically be resolved which would need to be fixed manually.
Forum: Plugins
In reply to: [Advanced Custom Fields: Font Awesome Field] Bulk-updating Icon versionHello @adejones,
That warning you are trying to get rid of is trying to tell you something important. Basically the ACF field for your FontAwesome no longer knows which icon has been previously selected. So re-saving that page could remove the icon from the front-end.
I wrote more about why this happens here: https://ww.wp.xz.cn/support/topic/upgrading-to-fontawesome-6-icons/.
Matt Keys
Generally speaking, it would go very near wherever you were already using
the_field( 'my_fa_icon' );Like maybe you had some markup like this:
<div class="container">
<div class="my-icon-wrap">
<?php the_field( 'my_fa_icon' ); ?>
</div>
</div>That would be converted to something like this:
<div class="container">
<div class="my-icon-wrap">
<?php
$icon_object = get_field( 'my_fa_icon' );
$icon_family = isset( $icon_object->family ) ? 'fa-' . $icon_object->family : '';
$icon_id = isset( $icon_object->id ) ? 'fa-' . $icon_object->id : '';
$icon = "<i class='" . $icon_family . " " . $icon_id . "' aria-hidden='true'></i>";
echo $icon;
?>
</div>
</div>Exactly where you decide to put the code comes down to developer preference/style, but something like in my example above would certainly work.
Forum: Plugins
In reply to: [Cost Calculator Builder] Improper enqueuing of jQueryWe are on the latest version of this plugin now. I do see that there were many changes to vue js as you mentioned.
However the issue I pointed out in this ticket still exists, it still is loading jQuery on every page of our site, wether that page uses this plugin or not.
Please stop loading jQuery everywhere it is hurting our sites page speed performance.
Shoot, you are right it still isn’t working with SVG icons. It was for me for a moment but I think I checked too quickly after switching from WebFonts to SVG and the kit just hadn’t updated yet.
Can you confirm you are using SVG icons too? I wonder if this is something we might need FontAwesome to look at.
It is worth mentioning why fa-custom is there to begin with. “Custom” is the styleName within the FontAwesome nomenclature for these custom uploaded icons. My plugin always outputs the Family (fa-kit), Style (fa-custom), and ID (fa-drapes) classes when generating an icon. I believe this is correct, but it seems in this case it was not considered in the FontAwesome JS renderer.
It is possible in a future update to this plugin I may break this standard if enough people are running into this issue and it isn’t something that FontAwesome can correct on their end. Currently you are the only one I’ve heard from on this (lucky you). If I change this to remove the fa-custom class I run the potential of causing more issues by removing a class that other users may be targeting in their CSS/JS. So I plan to let this play out for a little bit and see what kind of feedback I get from users, or what changes come down the line from the FontAwesome team.
Let me know if you have any issues with that workaround I gave you though and I’d be happy to help. Sorry you’ve been dealing with all of this!
Hey thanks for reaching out, I do remember this conversation with the FontAwesome team. I believe a fix is coming in a future release that will basically tell the JS to ignore the ‘fa-custom’ family class when rendering. But they stated it will only help ‘going forward’ and it sounds like that might only be for FontAwesome 7.
I did mention a possible workaround to them which it sounds like you’ve looked at a little. Currently if you have the icon set to return the “Icon Element” you would get something like this:
<i class="fa-kit fa-custom fa-drapes" aria-hidden="true"></i>Changing the output to “Icon Object” would change what is returned to something like this:
stdClass Object
(
[element] => <i class="fa-kit fa-custom fa-drapes" aria-hidden="true"></i>
[class] => fa-kit fa-custom fa-drapes
[id] => drapes
[family] => kit
[style] => custom
[prefix] => fa-kit fa-custom
[hex] => \57346
[unicode] =>
[svg] => stdClass Object
(
[SVG data here I am going to ignore for this example]
)
)Using the data in this object, you can build your own icon element to look however you need/want it to. You could do something like:
$icon_object = get_field( 'my_fa_icon' );
$icon_family = isset( $icon_object->family ) ? 'fa-' . $icon_object->family : '';
$icon_id = isset( $icon_object->id ) ? 'fa-' . $icon_object->id : '';
$icon = "<i class='" . $icon_family . " " . $icon_id . "' aria-hidden='true'></i>";In this example, if you were to echo $icon you would get:
<i class="fa-kit fa-drapes" aria-hidden="true"></i>This thread is marked ‘resolved’ but this bug is still present in the latest version of this plugin. In addition to the area I reported earlier, the same bug is present on line #88 of
calculator-builder/includes/lib/admin-notices/classes/STMDashboard.phpHello @becreativemedia,
Sorry for the late reply I was out on vacation and am just catching up. These two plugins used to work together, but I do see the problem you are experiencing.
Or at least I did briefly. Switching my kit settings from “SVG” icons to “Web Fonts” fixed the issue. But then going back to SVG the issue came back again.
However by going into the official FontAwesome plugin settings and clicking “Refresh kits data” while having the kit configured to use SVG icons, everything seems to work happily together again.
Let me know if that fixes it for you too.
Matt
- This reply was modified 1 year, 2 months ago by 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 asTRUEbecause 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.