-
Notifications
You must be signed in to change notification settings - Fork 19
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
Comments
@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? |
@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 |
@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. |
@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. |
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!
The text was updated successfully, but these errors were encountered: