Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Font Awesome icons not working after v2.6.0 upgrade #1522
Great work as ever getting another update out - hope you managed to celebrate the New Year whilst completing the release!
I have uncovered an issue with the Font Awesome 5 support introduced in v2.6.0
MagicMirror Version: v2.6.0
Steps to Reproduce:
A workaround is to release an update to the fa4 module so that any icons are renamed per the font awesome 4 upgrade notes. However, to do so means the third party module will depend on v2.6.0 (i.e.
Also, if another fa4 module is added to the config after the upgraded fa5 modules, the problem recurs.
Whilst this shows this issues is in itself not a MagicMirror bug, it is triggered by MagicMirror allowing both versions of Font Awesome stylesheets to be included in the generated html.
Furthermore, it doesn’t look like either the end user (via
Quite a challenge indeed!
On the assumption that the goal is to adopt FA5 as the single FA library within MM and given FA do not recommend running FA4 and FA5 side by side in one project the path I would recommend is
All other options seem to rely on vendor specific work arounds within the core MM code which, depending on users configuration and developer support could trigger a variety of outcomes and support headaches.
I appreciate introducing such a roadmap presents some problems, but it does seem the cleanest way forward.
The main challenge is how to force the inclusion of the v4-shim if a module references to “fontawesome.css” in getStyles without requiring changes to the module code. i.e. include two css files for one getStyles reference.
I understand your approach, but I don't want to introduce a roadmap with breaking changes. Simplicity is key for MagicMirror².
We can probably support both FA versions by namespacing them to specific classes. If a module has the
Totally support the principle and will continue searching for solutions.
I guess I was put off by the official statement and conversations such as this one on stackoverflow citing similar issues with WordPress plugins.
To avoid (minimise) breaking changes, is it possible to move to step 2 (FA5 + v4 shim) now, but not plan for step 3?
Quick tests with a modified vendor file where “fontawesome.css” installs fa5, a dummy plugin which getstyles for the fa4 shim included last in the config and reverting getstyles in the default calendar module seem to work.
This gives backwards compatibility and leaves the adoption of fa5 in the hands of plugin devs based on how they wish to support the new prefixes (fas, fab, far etc)