Font Awesome Manager 1.2.7

[Alternadiv]

Professional approach: Profile the requests (with tools like XDebug) and analyse the profile.
Common approach: Do some educated guess and try disabling Add-ons until you've found the issue, take a look at debug output/queries.


You don't have to trun off the feature completely, just disabling the aditor (which does load a significant amount of JS) is enough.

Full editor JavaScript loaded upon initial page load for guests

If a forum does have writing before registering enable and a guest reads a thread, the editor does get initialized upon initial page load although the editor is usually way below the fold. This is a significant waste of resources in both bandwidth and JavaScript processing time as most of the...

xenforo.com

No, it is not. If you use Light icons additonally to Regular, that requires another font file (at about 185 KB) to be downloaded.
You'd really want to avoid that as fonts are critical for rendering.


I don't know, its' your forum

I'm going to reply to this here because it is no longer AMP related really.

I'm getting ready to install your FA manager but I'm curious... Could you technically display: none all FA icons (i, i:before, i:after, .fa, .fas, .fal, .far, .fab?) and then remove the .woff files to basically remove FA completely? Then you would go back and fix the buttons you broke as desired.

Do you think that is feasible as an even more extreme route of ditching FA for something else?

 

[Kirby]

Could you technically display: none all FA icons (i, i:before, i:after, .fa, .fas, .fal, .far, .fab?) and then remove the .woff files to basically remove FA completely? Then you would go back and fix the buttons you broke as desired.

Set

Build Mode = Manual
Automatically add missing icons = Yes
Load subsets only = Yes
Only use CSS for selected weight = Yes
Enable duotone icons = No

and you should basically get the absolute minimum FA subsets (after keeping it running with those settings for a while).

Though I don't think this has been tested extensively so far, YMMV.

 

[Mr. Jinx]

I saw an error when using the browser's dev tools. It is complaining about this in mobile view:

<style>@font-face{font-family:'Font Awesome 5 Pro';font-style:normal;font-weight:300;src:url(about:blank)}.fal{font-family:'Font Awesome 5 Pro';font-weight:300}</style>

about:blank ... is this right @Kirby ? Don't know where this is coming from, but when I disable this add-on, it is gone.
Everything works fine though!

 

[Alternadiv]

Set

Build Mode = Manual
Automatically add missing icons = Yes
Load subsets only = Yes
Only use CSS for selected weight = Yes
Enable duotone icons = No

and you should basically get the absolute minimum FA subsets (after keeping it running with those settings for a while).

Though I don't think this has been tested extensively so far, YMMV.

Sweet. I don't mind breaking icons in areas that are normally displayed as an icon without text, e.g. mail and alerts. I can work backwards and deal with that. The BB code buttons are probably the only ones I won't mess with.

I've been working on a style that is stripped of most of the UI bloat that isn't necessary within my site. My goal is to remove most visual distractions and potentially confusing links/pages/phrases/options because I have a lot of members that don't know forums. Basically, I want put the focus solely on the content and not so much on the fancy stuff, kind of like Wikipedia.

Also shooting for a killer PageSpeed score like @MattW achieved.

Work in progress:



(I don't know why debug shows memory at 3.8 though?)

 

[Alternadiv]

Holy crap. I was at a 58 on mobile yesterday (not solely because of Font Awesome). After fixing some things and installing this, 91! I still have some other stuff to tweak yet.

 

[Joe Link]

Disabling that option will increase CSS and probably font download size as well.

Can you post the HTML & CSS for the location shown on the screenshot?

You're right, with that option unchecked it loads the full fa-duotone-900.woff2 (188kb) in addition to fa-duotone-900-min.woff2.

HTML:



CSS:

::before



::after

 

[Joe Link]

@Kirby

Just to be sure, I re-wrote everything following the example in the font-awesome pseudo-element guide and the accompanying codepen. Still having the issue, just can't seem to get that secondary layer (\10f005) to render.

 

[Kirby]

You're right, with that option unchecked it loads the full fa-duotone-900.woff2 (188kb) in addition to fa-duotone-900-min.woff2.

I was able to reproduce this issue and will provide a fix in RC 3.
Unfortunately this is a bit complicated and therefore does require a fair amount of code changes.

So right now the only way to use duotone icons is to disable option Load subsets only

 

[Joe Link]

I was able to reproduce this issue and will provide a fix in RC 3.
Unfortunately this is a bit complicated and therefore does require a fair amount of code changes.

So right now the only way to use duotone icons is to disable option Load subsets only

Awesome! Really happy you were able to find and duplicate it (and willing to fix it).

 

[hasanakyuz]

a great plugin, but some icons are lost and some icons are corrupted. How do I fix this?

 

[Kirby]

I unfortunately can't make sense of those screenshots.

Please read the FAQ on missing icons and how to fix that.
The easiest way usually is to enable Automatically add missing icons and keep that enabeld for some time; you might also want to increase Log Level to Info and keep that enabeld for some time as well.

If you use duotone icons you will have to disable option Load subsets only for now (Reference).

If you use 3rd party styles that do use other icon fonts further adjustments to settings might be required.

 

[hasanakyuz]

@Kirby the first image shows the status before installing the plugin, the other images show the status after installing the plugin.

 

[mazdas247]

Hi, this indeed has helped the pagespeed insights. But help me understand. If styles/fonts/fa is ephemeral (say, wiped every time my server reboots), ho will this impact this plugin? Do I need to persist this folder somehow? Or is this smart enough to understand the files are missing and re-creates them on-the-fly?

I am attempting to deploy this application in a container orchestrator (k8s, or ecs, etc) and having to persist these folders really puts me in a pickle.

Thanks for a good plugin!

 

[Kirby]

If styles/fonts/fa is ephemeral (say, wiped every time my server reboots), ho will this impact this plugin?

The files would be missing and (depending on the settings) you could end up with all icons missing.

Do I need to persist this folder somehow?

Yes. Directory styles basically must be persistent.
If it is not, you will run into problems sooner or later as other Add-ons as well as XenForo itself (on One-click/From ZIP Install/Uninstall/Upgrade) and probably Styles (on Import) will write to this folder.

Or is this smart enough to understand the files are missing and re-creates them on-the-fly?

No. You could manually run a rebuild, but taht would be inefficient as it would invalidate client caches.

I probably could add an option to store the files under data which would solve this usecase, but as said before - other Add-ons/Functions could still write to that directory anyway.
Another option could be to embed the font files in CSS (this can be enabled in style properties), though you should test the impact on performance.

 

[Jake B.]

@Kirby Looks like this add-on creates files in the styles/fonts directory. This is causing issues with deployment processes since that file gets deleted on deploy, and will also have issues on environments with multiple web servers where the styles directory isn't synced between them. Can this be changed to go into the data filesystem instead? styles cannot be persisted between deployments, and the data filesystem goes into an S3 bucket

 

[mazdas247]

Thanks for the reply Kirby. And to echo @Jake B. Post above, for XF to scale it's likely you need multiple web nodes. And synchronizing live folders between multiple nodes reliably is a big challenge.

 

[Kirby]

Can this be changed to go into the data filesystem instead?

I don't particularly like the idea of storing the files in data instead of styles for a few reasons:

1. data/Kirby/FontAwesomeManager (or smth. like that) doesn't look as nice as styles/fonts/fa, but that's just personal preference
2. Having the files in data would slightly worsen rebuild performance for everyone due to Flysystem overhead
3. Having the files in data could worsen runtime performance and create issues in some scenarios (see usecases below)

There are a few usecases to consider when thinking about this

1. Site is run of server(s) that do have persistent read-write access to styles and data is accessible through an OS filesystem mount.
   This usecase is easy and wouldn't benefit from moving the files to data
2. Site is run of server(s) that do have persistent read-write access to styles and data is not accessible through an OS filesystem mount
   This usecase wouldn't benefit either, in fact runtime performance might get worse if the site is not run of a full site CDN (eg. font files might get accessed through a different domain/host which requires a separate HTTP connection) and could lead to CORS issues (as already reported by some users).
   Without additional configuration (which might not be possible on some hosts), the suggested change could also prevent HTTP/2 push from being usable in this usecase
3. Site is run of server(s) that do not have persistent read-write access to styles
   This usecase could benefit from having files in data, but the problems mentioned in usecase 2) still would apply

Therefore I don't think I will change the default behaviour as it would only be beneficial for one usecase.
Though I will add an option to use a Flysystem (not necessarily data, could be a completely new one to allow maximum flexibility) instead of the filestem at styles.

For those who fall into usecase 3) right now and use S3 I'd either embed the fonts or

1. Copy the contents of styles/fonts/fa to S3
2. Configure a (caching) reverse proxy for https://www.domain.tld/styles/fonts/fa to S3
3. Mount S3 to styles/fonts/fa via s3fs/goofys/riofs etc.

This would allow to keep the files in S3 and be compatible with the current code.

Last but not least:
Running on multiple nodes and keeping read-write filesystem access (which is required to be able to install/upgrades Add-ons via ZIP from ACP anyway) isn't thaaat complicated - we do that in production.

 

[Jake B.]

1. data/Kirby/FontAwesomeManager (or smth. like that) doesn't look as nice as styles/fonts/fa, but that's just personal preference

That seems like an entirely non-issue, I don't think anyone is looking at the filepath of resources on their browser and being upset by something called data instead of styles. You can see this happening if you upload an image through one of the relevant style properties in the admin panel as well (Logo, for example I believe)

1. Having the files in data would slightly worsen rebuild performance for everyone due to Flysystem overhead

What trigger builds to run? I'd imagine this would also be a non issue, especially in cases where flysystem is ultimately just writing to a local file which is going to be the case for the most people

Site is run of server(s) that do have persistent read-write access to styles and data is not accessible through an OS filesystem mount
This usecase wouldn't benefit either, in fact runtime performance might get worse if the site is not run of a full site CDN (eg. font files might get accessed through a different domain/host which requires a separate HTTP connection) and could lead to CORS issues (as already reported by some users).

This use case would absolutely benefit, on deployment processes that don't use entirely new images (as I'll get to below) and also don't use S3 we have an NFS share for internal_data and data that are linked to with a config.php edit through the native filesystem, and data is served directly on the load balancer rather than being passed in from one of the individual web servers, which only handle PHP requests. And if someone has their data mount on something that isn't correctly setup the fonts being served from there are only going to encounter the same issue as all avatars, attachment thumbnails, uploaded videos, etc.

Therefore I don't think I will change the default behaviour as it would only be beneficial for one usecase.
Though I will add an option to use a Flysystem (not necessarily data, could be a completely new one to allow maximum flexibility) instead of the filestem at styles.

This should do what we need, thanks!

For those who fall into usecase 3) right now and use S3 I'd either embed the fonts or

1. Copy the contents of styles/fonts/fa to S3
2. Configure a (caching) reverse proxy for https://www.domain.tld/styles/fonts/fa to S3
3. Mount S3 to styles/fonts/fa via s3fs/goofys/riofs etc.

This would allow to keep the files in S3 and be compatible with the current code.

I thought about doing something along these lines as well just using the NFS share we already have for the code_cache. However, your files are being inserted directly into the default styles/fonts/fa directory, which doesn't work with our deploy process, and would result in XF's files being overwritten

Running on multiple nodes and keeping read-write filesystem access (which is required to be able to install/upgrades Add-ons via ZIP from ACP anyway) isn't thaaat complicated - we do that in production.

read-write filesystem access is definitely a no-go for most of our environments, many of them run on services like ECS and have no persistent filesystem except an NFS mount for the code_cache and the add-on zip uploader is disabled as everything gets deployed through a CI/CD tool.

 

[Kirby]

What trigger builds to run? I'd imagine this would also be a non issue, especially in cases where flysystem is ultimately just writing to a local file which is going to be the case for the most people

Modifing a phrase, editing a template, changing the node icons of a forum (if using an Add-on that uses FA for node icons), changing public navigation, modifying notices, modifying help pages, modifying ads, ... basically any action thaht touches entities that might reference FA icons and that change their in-use list of FA icons.
The overhead most likely wouldn't be large, but rebuilds would definitly be slower and require more disk operations (to allocate tempfiles for pyftsubset calls).

This use case would absolutely benefit [...], we have an NFS share for internal_data and data [...] is served directly on the load balancer rather than being passed in from one of the individual web servers

Depending on the capabilities of your loadbalancer, this can already be configured with the current code - move styles/fonts/fa to data and add back a symlink to the new location, configure the loadbalancer to use the new location for requests to styles/fonts/fa - Done.
This does work just fine with HAProxy.
So I really don't see a (huge) benefit of storing the font files in data for this usecase.

 

[Jake B.]

Depending on the capabilities of your loadbalancer, this can already be configured with the current code - move styles/fonts/fa to data and add back a symlink to the new location, configure the loadbalancer to use the new location for requests to styles/fonts/fa - Done.
This does work just fine with HAProxy.
So I really don't see a (huge) benefit of storing the font files in data for this usecase.

That only potentially works on that specific use case though, and even in that case it wouldn't update when new builds are made because the files generated by this add-on are inserted into the same directory as the XF default fontawesome icons, so if I symlinked all of that and XF updates FontAwesome the deployment process would overwrite that with the old versions in the copy of it from the NFS share. Even if they were split into a separate directory that's not of as much use for environments running off of Docker images which have no sort of persistent filesystem and relies entirely on S3 for the data and internal_data filesystems and has an NFS share mounted for code_cache with a config.php edit pointing at it