Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SVG+JS runs in entire WP Admin (not just the Editor) #193

Open
STV11C opened this issue Dec 20, 2022 · 4 comments
Open

SVG+JS runs in entire WP Admin (not just the Editor) #193

STV11C opened this issue Dec 20, 2022 · 4 comments

Comments

@STV11C
Copy link

STV11C commented Dec 20, 2022

Hey @mlwilkerson ,

I have almost finished adjusting my theme to (optionally) use the SVG Kit (for max performance purposes) by refactoring my pseudo-elements icon instances.

However, I noticed that the SVG+JS runs in the entire WP Admin (not just the Editor) which then breaks other pseudo FA icon instances from other Plugins and custom admin pages.

I was wondering your thoughts to overcome this?

Note that I don't want to use SVG+JS and Pseudo-elements options, as performance is my goal here. Cheers!

@mlwilkerson
Copy link
Member

@STV11C yeah, that is a challenge. What to do... 🤔

It might require some kind of additional configurability. There's a similar problem that I saw over in the [support form here(https://wordpress.org/support/topic/font-awesome-javascript-files/).

The thing is, there seem to valid use cases for having Font Awesome enabled on all admin pages. For example, a plugin developer may use Font Awesome icons as part of their plugin's administrative user interface.

There's been discussion on this also over on #86

Clearly, in a case where there's a conflict on some pages, it would be nice to be able disable Font Awesome from loading on those pages, at least, to resolve the conflict. The default, though, has been that it's enabled.

Seems like we may need a filter like the one proposed on the linked issue, to leave it on by default, but allow it to be turned off using a filter.

Thoughts?

@STV11C
Copy link
Author

STV11C commented Dec 20, 2022

@mlwilkerson Thanks for the reply.

To clarify, I still want/need FA loaded in the Admin, but not the SVG+JS version (even though I want it on the frontend).

Using the SVG+JS in my opinion is for the frontend rendered version to optimise performance.

Why not use the FA webfont version in the WP Admin even when SVG+JS is turned on?

Then on the frontend is renders the SVG+JS version.

I hope that clarifies the issue I'm facing. Thanks.

Regards

@mlwilkerson
Copy link
Member

@STV11C Thanks for the clarification. That sounds like a whole other matter, then. It sounds like you'd like to be able to have the plugin load SVG/JS for front end pages, but Webfont/CSS for admin pages.

That sounds to me like it would lead to some confusing and extra-complex configuration situations. It would really be quite a significant change to how both the plugin works, and how it works to support Font Awesome Kits.

For example, when using a Kit, the user selects the Technology in the Kit's settings, and the WordPress plugin simply loads that kit, however it's configured. The plugin would have no way of changing the kit's internal settings to cause different kinds of kit loading to occur based on which WordPress page is active (i.e. whether it's on a front end or admin page).

It seems that if you wanted more custom behavior like that, you'd need to do some custom loading of Font Awesome instead of using this plugin. That would probably require self-hosting instead of loading a Kit using the normal kit loader script from the Font Awesome Kit CDN, since you'd want to be able to control which Font Awesome technology is being loaded, based on which WordPress page it is, rather than letting the kit loader script load one technology or the other, according to its Technology setting.

@STV11C
Copy link
Author

STV11C commented Dec 21, 2022

@mlwilkerson Thanks again for the quick reply. Yes I agree it's messy. No probs and I will override the FA pseudo icons in the problematic WP Admin pages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants