Add support for Fontawesome 5

[ghost]

Since Fontawesome 5 is now available and uses SVG's it would be nice to provide support for this within Gantry5. Fortunately Fontawesome do provide a mechanism to retain backwards compatibility with fontawesome 4 codes through the use of their "shim" - please see...

https://fontawesome.com/how-to-use/upgrading-from-4

[pplopx]

+1

Thanks!

[810]

any progress?

[wbarnes]

+1 Thanks, I am also interested in updates?

[XaRz]

+1 Thanks! we want new fa5! 👍

[adoewa]

+1 tnx

[webhelpus]

I'd like to be able to 1) easily use the new Font Awesome 5 icons (which are amazing) and 2) be able to use the Pro version too. (they just released their beta CDN)

[pplopx]

Indeed, the CDN Pro of FA5 is now online (beta)!

A suggestion: to implment the free version it is enough to include the files (and the corresponding code) in the distribution of Gantry, as usual. I understand that the solution for FA5 Pro users should be to be able to use this new CDN. I have not yet studied the method well, but it seems that each user would have to include a token that FA provides us with.

Since I suppose that the distribution of Gantry can not include the exclusive icons of the FA5 Pro subscription by license terms, I suggest that the Gantry implementation offer as an alternative a setting that if it is filled with the code of the token, ignore the files of the version free included with Gantry and work directly with the CDN Pro.

I think it should be possible to do so and it could be a smart solution. I can provide Gantry developers with access to the test token if they do not get it directly from the FA guys.

[webhelpus]

For Now, pro users can add the CDN to their Head in Page Settings. You'll have to enter the codes and won't have a GUI in Gantry.

[paolavness]

Is there an ETA on this? Specifically, it would be good to be able to access the Icons in simplecontent and infolist particles in Grav.

Could you give guidance on where to edit these particles in the backend to access the new icons?

[thexmanxyz]

@webhelpus better way would be to override page_head.html.twig, base.html.twig and layout.html.twig this way it would be general available however IDK if there are any incompatibilities. Didn't do a test but this should basically work.

[thexmanxyz]

@paolavness I listed the files above which should be overriden if you want to use an other css file like it will be needed for FA5, but didn't test. However these are the files which <link> the default gantry FA version.

[webhelpus]

@thexmanxyz Adding the CDN worked for me. I just had to manually put in the codes and search for the codes on the Font Awesome website, but they have improved it so much that it's easy to do. I've got it to work on the site I'm building right now using my method.

[paolavness]

thank you @thexmanxyz. I'm getting more of a handle on it all. I've installed the FA5 fonts and files and for now, from the gantry admin UI, am simply referencing the FA5 styles in the in the Icon (input.icon) field rather than searching via dropdown F4 list. Its working a charm :)

[thexmanxyz]

@webhelpus I know it works the way you did it, however there are reasons I suggest to adapt it with overrides. You are loading the whole CSS files two times for absolutely no reason, you have unnecessary CSS rule overrides for everything that concerns FA. I would at least suggest overriding page_head.html.twig instead of messing around and loading two versions of FA. But how you like ;)

[N8Solutions]

@thexmanxyz just wanted to point out a typo. You mean the page_head.html.twig 😉

[webhelpus]

@thexmanxyz Good point. I'll make my adjustments accordingly.

[thexmanxyz]

@webhelpus

• media\gantry5\engines\nucleus\templates
• administrator\components\com_gantry5\templates\partials

[pplopx]

@thexmanxyz et al

Is it safe to do it with overrides? When I tried this same approach, Gantry's dashboard broke. The dashboard makes intensive use of FA icons also in backend. Many times a call with code is not enough. Could they publish the modifications exactly and how would it work? I understand that it is a patch until the Gantry development team implements it, are there dates for this?

Thanks!

[thexmanxyz]

@pplopx I can't 100% tell if it safe with overrides :P. Especially with changes on the admin site. So no guarantees at all from my side. However just changing the page_head.html.twig for front end matter should work without any issue. That said, you won't have any support from backend icon selectors and stuff for FA5 symbols. You have to rely on text inputs. Be aware that you don't replace the original files. And also mind the link @marktaylor46 has provided above (shim for v4).

[thexmanxyz]

@pplopx I tested now myself, backend works with shim but is broken at some points, frontend works mostly also with JS, SVG and shim.

[pplopx]

Thanks, okay. I am testing it on my dev site and I will comment on the news.

[Legolasindar]

+1 Yes please.

[N8Solutions]

Any official update for this? I have a project I'm working on now where I need to implement FA5.

[newkind]

Not yet, this is not a trivial task as it can sound. If we will be implementing this we have to maintain backwards compatiblity with FontAwesome 4, toggles for changing FontAwesome switching, updates to Icon Picker for both versions, support for FA5 Premium owners (by ie. custom location file detection for premium files), support for all supported variants like font files, svg's and different packages of the FA5 like brands etc.. This issue is much, much bigger than you might think. If you need it right now, use the FA5 font files and implement them in your theme like any other font.

[ghost]

I will add that if all you want is to use FA5 in your own content using the FREE version then it's fairly straightforward to do that. You just need to load FA5 in the base outline > page settings via their CDN. Using the code here:

<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.2.0/css/all.css" integrity="sha384-hWVjflwFxL6sNzntih27bfxkr27PmbbK/iSvJ+a4+0owXq79v+lsFkW54bOGbiDQ" crossorigin="anonymous">

Then you can use it in a custom html particle/module (or anywhere else that you can add html) like this <i class="fas fa-apple-alt fa-fw fa-2x"></i>

Obviously though any existing particles that use the Gantry 5 font picker won't see the FA5 icons at all.

I hope that helps.

[Legolasindar]

This work great for me @marktaylor46 thanks

[N8Solutions]

@marktaylor46 Thank you for your suggestion! I'd like to add that this works even for Pro accounts. For Pro accounts, the CSS code provided in our accounts includes our specific Key so that code should be added to the Head section under Page Settings instead of the code you provided. You add the domains to your account where you will be using FA5 and once the CDN has been updated with your domains FA5 works brilliantly throughout the site. You just have to update all the FA codes to their FA5 counterparts.

[ghost]

@N8Solutions Good, glad to help. :)

[AndiLeni]

Is there a way to add a costum icon-font to the icon picker?

[ghost]

No you cannot add a custom font to the font picker as explained above - it's not a trivial undertaking.

Regards, Mark.

[AndiLeni]

Thank you very much for you answer!

Regards Andi

[Shorece]

@marktaylor46 very good!!!

[jmshey90]

Can't we add a new YAML field, such as input.fa5, so you can use either/or from that level. Rather than worrying about backward compatibility, it introduces a new type that people can use at their leisure. FA5 has been out for 2 years, which effectively means input.icon is going to be decreasingly useful. You don't have to include all the new features, but just so that you can do the most basic of selections from the picker.

[pplopx]

+1

This is a good approximation for those who still use FA4. Having two options would provide full compatibility. Some configuration option would suffice to set one or the other version by default.

[thexmanxyz]

@muffindcc @pplopx But be aware that every particle using input.icon has to be updated for FA5. That is something that might confuse many people (having both fa4 and fa5 icon pickers).

[ghost]

Yep, so, that's currently well over 160 Rockettheme particles that would have to change to accommodate this extra field setting... in other words, if and when FA5 get's fully implemented it won't be like that. Also, don't forget all the third-party developers who would need to change their particles too.

I think my workaround above is the least pain option for now.

[jmshey90]

@muffindcc @pplopx But be aware that every particle using input.icon has to be updated for FA5. That is something that might confuse many people (having both fa4 and fa5 icon pickers).

Why would it? It would be a brand new YAML type, that would only be included going forward, or people could add themselves. It would be the quickest way of getting a FA5 picker without any backward compatibility problems. Simply, no templates would need updating at all.

This isn't about deploying FA5 on the frontend, which your workaround is sufficient for, but purely about the backend. Obviously we can use FA5, but the idea of the Gantry interface is to make it easier for admins.

[jmshey90]

Obviously a fully updated input.icon solution that would allow you to switch between versions would be perfect. But from a practical point of view, we've had FA5 for nearly 2 years, and there hasn't been any traction on this, so sometimes its better to implement something small but functional, then never update it at all, as there aren't any resources to do it "properly".

[ghost]

Feel free to do a pull request if you think you have a solution. I very much doubt that the developers are going to get any time to implement this for the reasons they have already given.

[thexmanxyz]

@muffindcc It doesn't make sense to add another field type as long as there is no official support from the template / framework. However the FA5 implementation in the end will look like. @marktaylor46 also said the obvious thing, when FA5 will be implemented everything from that point on will be FA5 and there will be no need for an additional field (or as you recommended the feature might contain the option to use either FA4 or FA5 within the picker). I see no reason to implement an explicit field type for the meantime like you suggested. Also it would be necessary to override each YAML file not having that field type set for the icon picker manually by the site admin. So it is far from an ideal solution.

But to make things from now on easier I will create a project that at least allows to automatically add FA5 compatibility + the option to switch between FA4 and FA5. This will not cover the input field problem. But at least it allows to quickly upgrade the site to FA5 or switch back to FA4. I will keep you updated here.

[mahagr]

Merged the pull request. So at least there's an option to disable FA. :)

[thexmanxyz]

@mahagr Really appreciate, that we have that option now 👍

[newjie]

Do we have this implementation already? I still can't choose new icons in a icon picker.

[newjie]

I will add that if all you want is to use FA5 in your own content using the FREE version then it's fairly straightforward to do that. You just need to load FA5 in the base outline > page settings via their CDN. Using the code here:

<link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.2.0/css/all.css" integrity="sha384-hWVjflwFxL6sNzntih27bfxkr27PmbbK/iSvJ+a4+0owXq79v+lsFkW54bOGbiDQ" crossorigin="anonymous">

Then you can use it in a custom html particle/module (or anywhere else that you can add html) like this <i class="fas fa-apple-alt fa-fw fa-2x"></i>

Obviously though any existing particles that use the Gantry 5 font picker won't see the FA5 icons at all.

I hope that helps.

I tried this but many fa4 icons are broken in icon picker. What I did is downloading the whole fa5 library and self-host it instead of using your CDN, could this be the reason?

I can manually input the fa5 code to override icon picker's default though. For example, replace fa fa-facebook with fab fa-facebook works, as shown in the picture.

[mahagr]

Merged FA5 improvements from @thexmanxyz also.

Admin always uses FA5 web fonts with FA4 shims installed.

There are still some issues, like icon selection does not change in the administration when you select FA4 vs FA5.

We may also need to force disable FA4 when using a theme that uses FA5.

[ghost]

Couldn't we have Fontawesome version selectable on "page settings" base outline (not overrideable by outline and have it default to FA4? To my mind you want to use one or the other and unlikely to want to use both?

Icon picker then just uses whichever version is active?

We need to make it backwards compatible so existing sites carry on working as they are.

Wouldn't that also make it easier to add FA6 (or whatever comes next) with an update in the future too?

Obviously any particles that has already selected icons would need to be updated and saved again if you changed FA version but that shouldn't be a surprise.

[thexmanxyz]

@marktaylor46 It is actually already default to FA4. It would not be the common case to have FA4 on one outline and FA5 on another but this should not harm at all it just gives freedom as we support both but only one is actually loaded. It is already selectable on page settings. Version selection is also already there.

All sites will keep working as we did not touch the FA4 as it is. But nonetheless we need to skip that pseudo-elements as they are unsupported. A switch to a higher version can be easily done already as we have a FA dashboard. So I assume you simply did not check #2550.

Obviously any particles that has already selected icons would need to be updated and saved again if you changed FA version but that shouldn't be a surprise.

That is completely wrong. Therefore we have the FA4 shims. When there is a old class name that indicates a fa4 symbol it will be still working as that is the purpose of the fa4 shiming added with #2550.

[ghost]

I haven’t checked anything I was just asking questions and expressing views in response to @mahagr comments. I personally wouldn’t want to see the two versions in play at the same time. I haven’t looked how it works but what about inheriting particles that use fa4 on one outline and use fa5 on another outline. Anyway I was just expressing views so you can just ignore everything I said.

[mahagr]

To be honest, we do need one place to set either FA4 or FA5 or we cannot show the right icon picker in the admin. Also, there needs to be a way in the theme to prevent using the wrong version of FA.

Remember that many of the SCSS files contain icons, but do that in character codes, which get broken when FA5 version changes.

[thexmanxyz]

@marktaylor46 Alright, didn't know that you not checked the PR. That's just fine I think my PR should answer all your questions concerning the current state. You are right actually we should really do that globally per template and NOT allow outline based changes because that might confuse users and lead to error states if you don't consider your version when creating outlines (but this only happens when you use FA5 icons, FA4 icons are not affected because of the shim).

Don't want to ignore, sorry for the harsh reply.

@mahagr You are right with both things. Actually FA5 should always be loaded within Admin there should be only FA4 shim in backend for the icon picker. The correct solution might be to change the picker in dependence of the theme selected FA version if possible. The FA version should not be overridable per outline. Maybe also consider to only offer FA option if the template supports it.

TBH we should completely drop those pseudo-elements in CSS that is something that also template developers should consider and move towards because it isn't really well supported with FA5 and it won't be in future releases. That is at least my information state.