Forum Replies Created

Viewing 15 replies - 1 through 15 (of 935 total)
  • Plugin Author Matt Keys

    (@mattkeys)

    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.

    Plugin Author Matt Keys

    (@mattkeys)

    me {the at sign} mattkeys { dot } me

    Plugin Author Matt Keys

    (@mattkeys)

    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.

    Plugin Author Matt Keys

    (@mattkeys)

    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.

    Plugin Author Matt Keys

    (@mattkeys)

    Compatibility 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.

    Plugin Author Matt Keys

    (@mattkeys)

    Hello @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

    Plugin Author Matt Keys

    (@mattkeys)

    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.

    Thread Starter Matt Keys

    (@mattkeys)

    We 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.

    Plugin Author Matt Keys

    (@mattkeys)

    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.

    Plugin Author Matt Keys

    (@mattkeys)

    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!

    • This reply was modified 1 year, 1 month ago by Matt Keys.
    • This reply was modified 1 year, 1 month ago by Matt Keys.
    Plugin Author Matt Keys

    (@mattkeys)

    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 reply was modified 1 year, 1 month ago by Matt Keys.
    • This reply was modified 1 year, 1 month ago by Matt Keys.
    Thread Starter Matt Keys

    (@mattkeys)

    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.php

    Plugin Author Matt Keys

    (@mattkeys)

    Hello @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.
    Thread Starter Matt Keys

    (@mattkeys)

    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.

    Thread Starter Matt Keys

    (@mattkeys)

    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.

Viewing 15 replies - 1 through 15 (of 935 total)