FontAwesome inclusion in frontend should be optional in GiveWP v3

[fidoboy]

Right now all Font Awesome css and font are being included in /give/build/baseFormDesignCss.css but may be the WordPress theme or other plugins already includes Font Awesome, so this becomes unnecessary and duplicate resources loading into the browser. My suggestion is to add a switch in GiveWP v3 settings to allow disable Font Awesome CSS and font files in front end. This way, if FA is being loaded by another methods GiveWP doesn't need to load them again and it still could keep using symbols and styles from this font. It should display an advert to the user into the settings where it says that it leaves the responsability into the user hands because disabling FA load assumes that it's being loaded by other ways.

[canny[bot]]

This issue has been linked to a Canny post: FontAwesome inclusion in frontend should be optional in GiveWP v3 :tada:

[kjohnson]

Hey @fidoboy, thanks for providing feedback.

To keep with the workflow to make sure that the right people see this feedback, I have migrated your feedback to https://feedback.givewp.com.

See https://feedback.givewp.com/feature-requests/p/fontawesome-inclusion-in-frontend-should-be-optional-in-givewp-v3

Please add yourself as a voter to help prioritize the feedback.

[fidoboy]

Hey @fidoboy, thanks for providing feedback.

To keep with the workflow to make sure that the right people see this feedback, I have migrated your feedback to https://feedback.givewp.com.

See https://feedback.givewp.com/feature-requests/p/fontawesome-inclusion-in-frontend-should-be-optional-in-givewp-v3

Please add yourself as a voter to help prioritize the feedback.

Thanks. I believe that this is a must have for any wordpress plugin because Font Awesome usage is very extended and it's not always necessary to load it again and again with every plugin. With a single switch into the settings page many resources duplicated can be avoided easily. So in GiveWP v3 this should be done. Just separate the CSS and fonts files and make a conditional call to the enqueue if the option is activated, that's all.

[github-actions[bot]]

This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 14 additional days. Note, if this Issue is reporting a bug, please reach out to our support at https://givewp.com/support. If this is a feature request, please see our feedback board at feedback.givewp.com — that’s the best place to make feature requests, unless you’re providing a PR.

[jonwaldstein]

For context, the included font-awesome css is the free one which is pretty slim. It was intended for backwards compatibility with v2 form's classic & multistep template styles which used a mix of font awesome class names and unicodes. The challenge comes with consistency of icons used in the framework vs offloading to an unknown external resource.

However, in v3 forms scripts and styles are isolated inside the form, so not sure if a theme loading font-awesome would actually have an effect inside the form.

The most notable place we're using font-awesome classnames n v3 forms (that I can think of) is for gateway icons here - but there are other instances using unicodes as well as people using custom css - we would need to think about before changing how this works.

[fidoboy]

For context, the included font-awesome css is the free one which is pretty slim. It was intended for backwards compatibility with v2 form's classic & multistep template styles which used a mix of font awesome class names and unicodes. The challenge comes with consistency of icons used in the framework vs offloading to an unknown external resource.

However, in v3 forms scripts and styles are isolated inside the form, so not sure if a theme loading font-awesome would actually have an effect inside the form.

The most notable place we're using font-awesome classnames n v3 forms (that I can think of) is for gateway icons here - but there are other instances using unicodes as well as people using custom css - we would need to think about before changing how this works.

I was talking about the frontend only, not backend. So the issue is a redundant loading of the fonts in frontend. This issue can be easily solved by letting the user to decide if load the font or not. If it is already loaded by another plugin / theme, then it has no sense to load it again.

In GiveWP advanced settings you only need to add a switch to activate/ deactivate the font loading in frontend pages.

[jonwaldstein]

@fidoboy to clarify, our v3 forms that are created using our visual form builder are completely isolated on their own route inside an iframe. This was intentional to avoid conflicts upstream from themes and plugins. So, if a theme or plugin is loading font-awesome, it would have no affect on the donation form.

However, I do think a more reliable approach for our forms is to use the SVG icons directly from their js package, instead of using their web fonts and classnames. It would help preserve the integrity of the icons and avoid conflicting with other versions of font-awesome.

[fidoboy]

@fidoboy to clarify, our v3 forms that are created using our visual form builder are completely isolated on their own route inside an iframe. This was intentional to avoid conflicts upstream from themes and plugins. So, if a theme or plugin is loading font-awesome, it would have no affect on the donation form.

However, I do think a more reliable approach for our forms is to use the SVG icons directly from their js package, instead of using their web fonts and classnames. It would help preserve the integrity of the icons and avoid conflicting with other versions of font-awesome.

Well, that thought is not entirely correct because static resources, like the fonts, are cached. So using an already downloaded font is faster. Even using the necessary SVG only instead the font is worse if FontAwesome is already loaded.

[jonwaldstein]

@fidoboy The (v3) donation forms will not accept scripts from external plugins or themes unless they specifically hook into the donation form enqueue process. So if a theme loads font-awesome for example, the fonts will not be loaded into the donation form. The only way to load any script, including font-awesome into the donation form would be to physically hook into givewp_donation_form_enqueue_scripts and load the script.

When I talked about using svg icons directly, it was from an internal framework perspective - so we are only loading what we need to use for specific purposes.

[fidoboy]

@fidoboy The (v3) donation forms will not accept scripts from external plugins or themes unless they specifically hook into the donation form enqueue process. So if a theme loads font-awesome for example, the fonts will not be loaded into the donation form. The only way to load any script, including font-awesome into the donation form would be to physically hook into givewp_donation_form_enqueue_scripts and load the script.

When I talked about using svg icons directly, it was from an internal framework perspective - so we are only loading what we need to use for specific purposes.

I understand it now. So then the GiveWP needs to load the same FontAwesome version than the already included into the theme (or other plugins) to benefit from the browser caching OR it will be better to load only the needed glyphs in SVG format to save bandwidth.

[jonwaldstein]

@fidoboy yes, exactly.

[github-actions[bot]]

This issue is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 14 additional days. Note, if this Issue is reporting a bug, please reach out to our support at https://givewp.com/support. If this is a feature request, please see our feedback board at feedback.givewp.com — that’s the best place to make feature requests, unless you’re providing a PR.

[github-actions[bot]]

This issue was closed because it has been stalled for an additional 14 days with no activity.