Understrap: Font Awesome 5

Created on 7 Feb 2018  Â·  55Comments  Â·  Source: understrap/understrap

Good morning Holger.

Do you have plans to change to Font Awesome 5 (free) in understrap?

Most helpful comment

Basically I just had a bad feeling adding a mixed free/premium resource into UnderStrap.
Another problem: All live sites using UnderStrap + FA 4.7 icons in there own content or templates have to change the markup manually (class="fa" into class="fas") after updating UnderStrap. Can result in hunderets of live websites having this ugly "missing font" symbols on it....

Adding both isn´t an option because of its impact (100kb + )...
But sticking with 4.7 till the end of the world isn´t an option, too.

Maybe the best soulution would be to remove FA completely from any internal UnderStrap resources (npm/gulp/scss/css) and markup, but add an option to integrate FA 4.7, FA 5.0 or none of both as external CDN resource in the themes customizer. Than you can stick with 4.7, activate 5.0 or disable both (and save some kb´s).

If "4.7" is the default setting no one should have a problem after an update.

UnderStrap itself just use the "down" icon to indicate a dropdown which can be replaces easily by scss/svg whatever

Any opinions/thoughts on this? Anything I miss out?

All 55 comments

I'd love to get this worked out. I use FA5 on all my projects, and even if I remove FA4 from the package.json, FA4 is still downloaded likely because it'd a dependency of Bootstrap. So I have to manually delete all the FA4 assets every time I update. I'm not smart enough to know how to remove the FA4 dependency and replace it with FA5.

I just commented out the contents of understrap-child/sass/assets/font-awesome.scss after adding FA5 to header.php.

@axlright
I've just done it on a fresh copy of understrap.

the package.json dependency is now called "@fortawesome/fontawesome-free-webfonts": "^1.0.3"

The gulp task copy-assets needs to be modified according to the new FA folder structure

// Copy all Font Awesome Fonts
    var stream = gulp.src(paths.node + '@fortawesome/fontawesome-free-webfonts/webfonts/*.{ttf,woff,woff2,eof,svg}')
        .pipe(gulp.dest('./fonts'));

// Copy all Font Awesome SCSS files
    gulp.src(paths.node + '@fortawesome/fontawesome-free-webfonts/scss/*.scss')
        .pipe(gulp.dest(paths.dev + '/sass/fontawesome'));

clean-vendor-assets also needs a slight update

gulp.task('clean-vendor-assets', function () {
  return del([paths.dev+'/js/bootstrap4/**', paths.dev+'/sass/bootstrap4/**', './fonts/fa*.{ttf,woff,woff2,eof,svg}', paths.dev+'/sass/fontawesome/**', paths.dev+'/sass/underscores/**', paths.dev+'/js/skip-link-focus-fix.js', paths.js+'/**/skip-link-focus-fix.js', paths.js+'/**/popper.min.js', paths.js+'/**/popper.js', (paths.vendor!=''?(paths.js+paths.vendor+'/**'):'')]);
});

After running npm install make sure the files in ./fonts and ./src/sass/fontawesome are replaced

all @import statements in `./sass/assests/font-awesome.scss needs to be updated:

$fa-font-path:        "../fonts" !default;

@import '../../src/sass/fontawesome/variables';
@import '../../src/sass/fontawesome/mixins';
@import '../../src/sass/fontawesome/core';
@import '../../src/sass/fontawesome/larger';
@import '../../src/sass/fontawesome/fixed-width';
@import '../../src/sass/fontawesome/list';
@import '../../src/sass/fontawesome/bordered-pulled';
@import '../../src/sass/fontawesome/animated';
@import '../../src/sass/fontawesome/rotated-flipped';
@import '../../src/sass/fontawesome/stacked';
@import '../../src/sass/fontawesome/icons';
@import '../../src/sass/fontawesome/screen-reader';
@import '../../src/sass/fontawesome/fa-solid';
@import '../../src/sass/fontawesome/fa-regular';

I think this works fine, but IMO a PR needs to reflect the changes to FA in the theme. Such as options to select whether FREE or PRO is installed, if we want brands installed or not, etc.

@0dp This is super rad. Let me run it through my brain and I'll hit you back. I use Font Awesome 5 Pro and generally get all the Sass loaded and comment out the weights I'm not using. I'm usually using fal and fab.

THANKS!

@0dp You are spot on with this. I'm still trying to get the Pro files to load properly via NPM. I'll give a shout out when I have something complete to show.

Basically I just had a bad feeling adding a mixed free/premium resource into UnderStrap.
Another problem: All live sites using UnderStrap + FA 4.7 icons in there own content or templates have to change the markup manually (class="fa" into class="fas") after updating UnderStrap. Can result in hunderets of live websites having this ugly "missing font" symbols on it....

Adding both isn´t an option because of its impact (100kb + )...
But sticking with 4.7 till the end of the world isn´t an option, too.

Maybe the best soulution would be to remove FA completely from any internal UnderStrap resources (npm/gulp/scss/css) and markup, but add an option to integrate FA 4.7, FA 5.0 or none of both as external CDN resource in the themes customizer. Than you can stick with 4.7, activate 5.0 or disable both (and save some kb´s).

If "4.7" is the default setting no one should have a problem after an update.

UnderStrap itself just use the "down" icon to indicate a dropdown which can be replaces easily by scss/svg whatever

Any opinions/thoughts on this? Anything I miss out?

First I want to make it clear that I am not interested in unnecessary complications of this theme.
That said, one approach to the above questions/issues would be to include a preinstall installation script, that would allow users to setup and configure the theme to their liking. It would mean that without running the script, a standard setup would apply. But running the script would allow for fine-tuning. ie. setup preferred version of FA to use, or not to use. It could even allow for additional options, like theme name, author information, git init etc.
There would also have to be a pre- / post- update script as well.

Just an idea 😸

I agree width _0dp_. A preinstall installation script would be a good option.
But I would see these option only in a child-theme - or should it maybe a xtra child-theme width FA5???

And you have right _holger1411_ with your bad feeling of using a free/premium resource and on the other hand by using a child-theme it should be not a problem to build in FA5 for the one who wants.

Thanks for the suggestions.

@DUGeCommerce it should probably be for both, because one might use understrap as the foundation for a theme that has it's own independent child theme.

I'm a fan of keeping all font files local rather than using an external CDN. It's one of the great assets of the understrap workflow - lean code, fewest possible css files.

It's truly unfortunate that at some point, all the people with "legacy" FA4 are going to have to update from fa ... to faX ... depending on whether it's a brand icon, free non-brand icon or paid pro non-brand icon.

@holger1411 when you talk about not wanting to add both due to the 100kb size increase, could both be added and have the @import... in sass/theme.scss commented out for one with a nice comment instruction to choose the option best suited for the individual? FA4 could then be left as the default for a while longer and switched at some reasonable point in the future, and people who don't want to migrate all their fa ... to faX ... markup could choose to keep the original FA4?

For what it's worth, I can't get the paid FA5 fonts to load via npm. Adding my npm authentication token and adding a dependency like "@fortawesome/fontawesome-pro-solid": "latest", will not add the full webont with scss etc and rather only adds the svg .js files.

@axlright

For what it's worth, I can't get the paid FA5 fonts to load via npm. Adding my npm authentication token and adding a dependency like "@fortawesome/fontawesome-pro-solid": "latest", will not add the full webont with scss etc and rather only adds the svg .js files.

There is a trick to it, and their documentation is not 💯

https://fontawesome.com/how-to-use/use-with-node-js#pro

npm i --save @fortawesome/fontawesome-pro-webfonts

and your dependency looks like this:
"@fortawesome/fontawesome-pro-webfonts": "^1.0.3"

@0dp You are awesome. I tried most every version of that I could yesterday. In the package.json, this works perfectly based on your suggestion:
"@fortawesome/fontawesome-pro-webfonts": "latest",

I was trying to load each weight separately as a webfont and also a million other things. Their documentation isn't so hot you're right.

Thanks! On to swapping out the copy-assets functions. I actually don't have fontawesome listed anywhere in clean-vendor-assets but maybe I have an old version. I'll double check.

Owe you a beer x4!

@0dp Thanks for all your help. My setup is marginally different from yours, but here goes in case it helps anyone else. This is how I replaced FA4 free version with the FA5 Pro version:

1) Add a file at the root of the install called .npmrc with this in it:

@fortawesome:registry=https://npm.fontawesome.com/YOUR-NPM-TOKEN-NOT-YOUR-LICENSE-KEY

2) Add this as the only font awesome dependency in package.json

    "@fortawesome/fontawesome-pro-webfonts": "latest",

3) Edit the copy-assets section in gulpfile.js to have these two sections in place of the existing ones related to Font Awesome:

// Copy all Font Awesome 5 Pro Fonts
    gulp.src(basePaths.node + '@fortawesome/fontawesome-pro-webfonts/webfonts/*.{ttf,woff,woff2,eof,svg}')
        .pipe(gulp.dest('./fonts'));

// Copy all Font Awesome 5 Pro SCSS files
    gulp.src(basePaths.node + '@fortawesome/fontawesome-pro-webfonts/scss/*.scss')
        .pipe(gulp.dest(basePaths.dev + '/sass/fontawesome'));

4) I ended up deleting the entire file at ./sass/assests/font-awesome.scss and instead added these lines to ./sass/child-theme.scss so that ./src/sass/fontawesome/fontawesome.scss stays updated with any changes that get pulled in

@import "../src/sass/fontawesome/fontawesome";
@import "../src/sass/fontawesome/fa-brands";
@import "../src/sass/fontawesome/fa-light";
// @import "../src/sass/fontawesome/fa-regular";
// @import "../src/sass/fontawesome/fa-solid";

And that way I can comment in and out the @import for the weights I'm using in each project.

5) Added this to my own ./sass/theme/_custom-variables.scss (or declare anywhere that's reasonable)

$font-path: "../fonts"; // set to fully formed url after publishing for criticalcss incorporation
$fa-font-path: $font-path;

And that way I can use $font-path for other locally hosted fonts like Google fonts.

This all works like a gem. Thanks again for your help!

This is why an install script would be useful. Below is a crude write-up
a1. would you like support for fontawesome? (Y/n)
if yes:
b1. would you like support for version 4 or 5 (?4/5)
if 4 add: font-awesome to dependencies
c1. would you like support for fa-pro? (y/N)
if free: add @fortawesome/fontawesome-free-webfonts to dependencies
if pro: enter your token: XXX
exec: touch .npmrc && echo "@fortawesome:registry=https://npm.fontawesome.com/$TOKEN" > .npmrc
add: @fortawesome/fontawesome-pro-webfonts to dependencies

@0dp @holger1411 I'm not smart enough to make an install script, but this does seem like a pretty awesome solution.

The only other solution I could think of would be to add dependencies for both FA4 free and FA5 free in the package.json, split the FA4 and FA5 files out into separate directories within ./src/sass/fontawesome when copy-assets runs, add all of the actual webfonts and then let people choose which to use via commenting out @include lines in the ./sass/child-theme.scss

Then leave the FA5 Pro people to fend for themselves. Hopefully if they're dedicated enough to pay for a font, they can edit these files themselves - with some help from the community :-)

@axlright, the thing is all occurrences of FA icons in the theme has to be replaced based on your choice of dependency, and so on. So one has to be the default if you choose not to run any commands(install it directly from within WordPress).
With an install script we would be able to configure files automatically, based on user input (preferences).

The easiest solution of them all would simply be to include our above steps to the documentation. But we need to think about the future as @holger1411 said.

I really don't know, but how powerful is the theme customizer; would we be able to achieve something with that?

Yup. Should be possible. However, I think the barebone-Customizer is a PITA. Personally prefer to use https://github.com/aristath/kirki which is much less of a pain - but causes bloat, of course. But yeap - possible.

All of the sudden, removing FA entirely and simply write up a doc page on integration dosn't sound like such a bad idea 😱

@0dp I agree / understand that if FA is included, one needs to be the default and baked in via compiled css especially for people installing directly via the WordPress installer.

Searching through the theme php files, it looks like only the pagination has built in Font Awesome icons (...?...) and if that's the case, those chevrons could be replaced with unicode characters - not so elegant but wouldn't leave people high and dry with missing icons. Anyone who manually added icons then will need to be responsible for maintaining their customizations. Things change. At some point, the world is going to move on from FA4.

I think that adding FA5 as an option via commenting in and out @includes in the main _theme.scss could work as an easy way to give anyone who is going to compile their own Sass an option. @holger1411 used to do this with an option to load up BS3 (though I never tried using it). Same with options for including Contact Form 7 styling. Something needs to be the default, of course.

I'm down with helping to create / maintain install documentation for those looking to add / change FA versions. Not including Font Awesome isn't the worst idea. It's not even listed as a preferred icon set on Bootstrap itself.

And the install script is another great idea.

I think we have a great few options, reasoning and documentation here.

Thats right. And thanks for everyone joing the discussion - anyway, this is not a democracy - it´s @holger1411 ´s repo and he will have to make the final decision. Heads up though, I guess he´ll be open to any improvements/suggestions that may evolve from this discussion ;)

We should set up something like a program flowchart to decide which option to choose.
Personally I´m totally into @0dp ´s solution with a setup script! I can totally work with that (but wouldn´t be able to set it up..)

But we (those involved into this thread) are _developers_. The question is - what does the MAJORITY of UnderStrap users look like? Are they a.) Developers or b.) Users?
Judging from a good amount of issues (parent as well as child issues) I´d assume most of them are "users" or "low-level-WP-Developers". I´d wonder if more than 30% of them had ever heard of "NPM" or console commands and could work with those without more problems.

The question is now: Do we want to elevate UnderStrap to a theme that is just usable for real developers or make it still compliant to work with the usual John Doe/0815 User?
Just an assumption: As @holger1411 is already selling commercial child themes, I guess he´d be following the latter. But I can´t speak for holger, so thats really just an assumption. So I guess he´d be going to adopt it for the casual "Luser" (In German "DAU" ["Dümmster anzunehmender User"] or "low level User" for the international community) and I´m totally backing up this approach.

Make it usable for the dumbest @ss around - thats what "progressive enhancement" is all about. From this base on, there may be a progressive approach.

So in my opinion, it´d be best to:

  1. Include the standard - OLD - fontawesome statements by default to keep up compabitility with any "old theme" and non-user-interaction.
  2. When the theme is updated - with the new options _available_ but not being set as _default_ - an admin message should be displayed for (imho) at least 5 of the following versions: https://codex.wordpress.org/Plugin_API/Action_Reference/admin_notices which should point to the according customizer options.
  3. Within Customizer some new options would have to be included.
  4. Upon selection, the above mentioned script should be run to rewrite the code. (or anything comparable)

Just an idea. What do you think?

Two more very personal opinions:

  1. From my point of view, ANY commercial extensions should definitely NEVER EVER be embedded into a non-commercial project!
  2. There should not even be - in my opinion - the option to choose that from the customizer.
    BECAUSE.
  3. The usual John Doe will never ever know how to handle it.
  4. And will always go for the "PRO" Version (because it sounds "badass") - without knowing what it´s all about, or on how to setup the license key and such which will lead to even more confusion and issues which we all do DEFINITELY NOT want to have!
  5. Developers will know. Or can be taught via a readme. Problem solved.

P.S. my username is @John_Doe_0815

All joking aside, I'm the worst at npm and really only stand to learn. I'm happy to support any decision that's made. I'm good at (and like) writing / maintaining documentation.

I'd also like to find ways to share some of the things I've learned. It seems that a good handful of people in this community who have created useful customizations that others could benefit from. I'd love to share mine with others.

TL:DR I will help by it's above my bad npm skills pay grade to make any decisions.

Thanks for all your contributions!

I think the best move is if 'normal' end users never are to be exposed to these choices and features.
First time they will be exposed is via @Thomas-A-Reinert 's suggestion using admin_notices with deprecation notices and finally a notice when FA5 has become the default.

I've been toying a bit with a preinstall script that interrupts npm install to rewrite package.json and modify files based on choices made in an interactive prompt. So far it's looking promising

Hey guys, just out of curiosity, is there an official way yet to completely remove font-awesome 4.7 from the latest version of UnderStrap? And perhaps a guide on extending the npm module packages (after we install UnderStrap), so that developers have a choice in adding the latest version of font-awesome 5 to the theme?

To me this seems to make the most sense. It puts less stress on you guys to keep up with font-awesome's version control, and it allows developers to extend the UnderStrap theme (or child theme) via npm.

Hey @blachawk
For now the closest official documentation is found in this thread.

This will be added in the documentation at some point, but this is a topic that is still being discussed.

@0dp what about the _path.scss file? should anything be modified there to reference FA5 assets?

...\wp-content\themes\understrap\src\sass\fontawesome\_path.scss

I followed all your steps above, but the site is still referencing...

fontawesome-webfront.woff2?v=4.7.0

Through Chrome developer tools when I visit a WP page.

@blachawk Fontawesome5 doesn't have a _path.scss. So if you're seeing that, you haven't installed
Fontawesome5 properly or something has gone wrong.

Can you document your setup?

@blachawk as @axlright said. walk us through the path you took. 😄

  • If I download understrap.zip file from https://understrap.com/ , activate it, and then go into the theme folder, there is a src/sass/font-awesome/_path.scss file already there.

  • @0dp, I then followed steps you mentioned above completely, and that _path.scss file is still there.

After running npm install make sure the files in ./fonts and ./src/sass/fontawesome are replaced

Was your npm installprocess suppose to "erase" the existing font awesome files in that directory and replace them with newer font awesome files? Or am i suppose to physically go in and replace these files?

Not sure where the disconnect is coming from..

That is correct! The theme comes packed with FA4, You'll have to do a bit of spring cleaning before proceeding with the steps. You can use clean-vendor-assets to nuke the files in src/
No npm install will only install the dependencies aka. node modules. The modified copy-assets handles copying over the fonts and scss files to the src folder.

Thank you @0dp
I think the problem is that I didn't physicaly update the files within the ./fonts and ./src/sass/fontawesome folders with font awesome 5 files. That is now complete and my development site is now allowing me to view FA5 icons.

I'm good. Thanks!

We´ll have a tut on how to integrate FA5 pretty soon with our upcoming documentation.

We´d need some guinea pigs to confirm that it works as expected though. Anyone with it?

Hi, guys! I manage to use fontawesome 5 free by _refering not the file_ "fontawesome.css" _but_ "all.css". Beside the fact I don't know the reason why, I strongly advice to do the same. In my case all I want was a reference of icons, so I hope it could help you out.

@Thomas-A-Reinert was there ever a tut completed and/or added to the documentation?

First things first: https://usdocu.tarthemes.com/ - the actual state of the docs.
Repo Link is: https://github.com/Thomas-A-Reinert/Understrap-Documentation
If you care to contribute clone the repo and submit pull requests.

Hi @colinoakes . Well the whole (documentation) thing stalled at a certain point. because we all had a good amount of client requests etc.. I personally ain´t freelancing anymore for bout two month now and into a WHOLE different topic (Voice Applications).

As long as anyone else is trying to complete the docs, I´ll quality-check and will merge and release. But I´m definitely not going to iterate on to the 95% I already contributed anytime near soon. Feel free to do so.

I know this is an old issue and closed, but I'd really like to see the font-awesome removed alltogether. I'm currently trying to figure out how to remove 4.7 as plugins im using already include 5, but I don't want to have to make any changes to someone else's plugin. My preference would be for FA to be completely removed and handled by the end user if they want it.

Brett you can remove FontAwesome by commenting out @import
"assets/font-awesome"; in theme.scss and re-compiling the stylesheets. Hope
that helps.

On Tue, Jun 9, 2020 at 10:00 AM Brett Thomas notifications@github.com
wrote:

I know this is an old issue and closed, but I'd really like to see the
font-awesome removed alltogether. I'm currently trying to figure out how to
remove 4.7 as plugins im using already include 5, but I don't want to have
to make any changes to someone else's plugin. My preference would be for FA
to be completely removed and handled by the end user if they want it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/understrap/understrap/issues/547#issuecomment-641354447,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGDBQ3DYHEDMX3KE54OBZKLRVZFCJANCNFSM4EPRBO7Q
.

Brett you can remove FontAwesome by commenting out @import "assets/font-awesome"; in theme.scss and re-compiling the stylesheets. Hope that helps.
…
On Tue, Jun 9, 2020 at 10:00 AM Brett Thomas @.*> wrote: I know this is an old issue and closed, but I'd really like to see the font-awesome removed alltogether. I'm currently trying to figure out how to remove 4.7 as plugins im using already include 5, but I don't want to have to make any changes to someone else's plugin. My preference would be for FA to be completely removed and handled by the end user if they want it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#547 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGDBQ3DYHEDMX3KE54OBZKLRVZFCJANCNFSM4EPRBO7Q .

Well, not exactly. Draw your attention to line 100 and line 103.

https://github.com/understrap/understrap/blob/ebefea3f43e92d3f9006b9a7f91e2a761694da85/inc/extras.php#L86-L109
Removing that FA 4 dependency is addressed in #1106.

Brett you can remove FontAwesome by commenting out @import "assets/font-awesome"; in theme.scss and re-compiling the stylesheets. Hope that helps.
…
On Tue, Jun 9, 2020 at 10:00 AM Brett Thomas @.*> wrote: I know this is an old issue and closed, but I'd really like to see the font-awesome removed alltogether. I'm currently trying to figure out how to remove 4.7 as plugins im using already include 5, but I don't want to have to make any changes to someone else's plugin. My preference would be for FA to be completely removed and handled by the end user if they want it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#547 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGDBQ3DYHEDMX3KE54OBZKLRVZFCJANCNFSM4EPRBO7Q .y

Unfortunately I don't want to have to recompile stuff, I want all the plugin files exactly as they are in the repo and to not have to worry about updates. I really don't want to have to add deployment scripts just for the theme. Am I better off using a different bootstrap theme? We're literally not using any parts of the theme other than the basic bootstrap styles and js. I'm a skilled developer I just try to spent my time outside of wordpress when possible.

We're literally not using any parts of the theme other than the basic bootstrap styles and js. I'm a skilled developer I just try to spent my time outside of wordpress when possible.

If you are _literally_ not using _any parts_ of the theme, i.e. your theme is completely independent of UnderStrap (?!), why not just get a copy of the compiled Bootstrap CSS and JS?

It would be strange if you were using this theme but not using any part of this theme at all lol

@pattonwebz Ha that's exactly how I use (don't use) the theme. I don't use any of the stock page templates or the footer or really even the header. I just use it to compile Bootstrap and other packages. Maybe that's a huge waste of time!

@axlright do you use a child theme for that? The impression I got from the comment above I took overly litterally because it seemed quite funny. They could mean they are using a child theme too which I think makes a lot of sense for a use case where someone wants base styles but to customize the templates without needing to touch the parent theme at all.

@pattonwebz Oh totally. Always a child theme. But to your point, I'm using a theme but not using most of it. The Bootstrap navwalker is awesome! I think that's your doing...

It would be strange if you were using this theme but not using any part of this theme at all lol

lol, yeah that probably wasn't clear. I installed the theme just because I wanted the most basic bootstrap integration. We're not using any of the extra theme functionality or even page templates I believe. We use elementor with custom widgets that pull data from our api and display using bootstrap css and js. I'm not using any kind of child theme (i think? lol), maybe i'm better off just integrating bootstrap myself? I honestly don't know, as I know next to nothing about wordpress themes and only what I need to about wordpress development.

Our nav menus are even made with elementor, rather than using bootstrap. My assumption was that I would need a theme made to work with bootstrap to not run into conflicts with wordpress's main css, but maybe that was wrong. I don't handle working with any of the theming or content myself in our sites (thats why we went with wordpress), so excuse my ignorance.

Bootstrap has great documentation on how to create your own build system to use with a WordPress theme for instance. You would still have to create a theme for WordPress though, and you would maybe find situations where you would have to add bootstrap specific css and so on.

Introducing understrap, all that work has already been done and it's ready for you customization and modification.

Removing FA should be a breeze. And if you worry about updates and build systems. Don't worry.

Fork the repo, clone it, make the edit, and push it your own fork. You will never have to do it again

Bootstrap has great documentation on how to create your own build system to use with a WordPress theme for instance. You would still have to create a theme for WordPress though, and you would maybe find situations where you would have to add bootstrap specific css and so on.

Introducing understrap, all that work has already been done and it's ready for you customization and modification.

Removing FA should be a breeze. And if you worry about updates and build systems. Don't worry.

Fork the repo, clone it, make the edit, and push it your own fork. You will never have to do it again

I guess I don't understand why such a simple need should require losing the ability to have automatic updates. Imo a plugin/theme installable via the internal directory should be user friendly for MOST applications. I know I can make this work if I need to and want to put in the effort, but let's be honest...that's not why any skilled developers use wordpress. Most wordpress installs are already using some type of JS combiner, so why do the final files need to be combined? I doubt I'm alone in simply not needing the font-awesome CSS and not caring about your nav walker or other items using the classes.

Why not just have an option in the settings that includes the font-awesome 4.7 files if you want it, and doesn't if you don't? There's a shim for the fa4 class names in in fa5, and is probably the easiest option for someone to use your nav walker or slides with fa5. I was testing another bootstrap theme that had the option, but the support isn't the same which is what makes this project great.

Update and further clarification on my opinion (which is still the same):
I actually ended up setting up a dev environment, because I'm actually working on gutenberg block for bootstrap, as well as replacements for elementor(+pro) blocks, and the custom blocks we wrote for that. Some of the biggest issues regarding this theme can probably be solved with better documentation. Half of the links I found were to some dead domain, and then I found lots of conflicting and/or incomplete installation documentation, and not all of it is this repo's fault...but needs to be addressed.

I'm personally on a mac because it runs linux underneath, and I don't use virtualization containers for local development...which probably compounds things a bit. On a mac at least, you no longer want to install node or nvm via the homebrew package manager...and I think this is a relatively new thing (at least it was for me). Trying to install understrap with node led to hours of frustration. I clearly missed something, but even after clearing homebrews version of node/nvm, and using the current best practices, I couldn't get past errors.

It seems like this is the suggested install route for a developer according to the documentation on the repo itself. My favorite part about this though, is wordpress' own documentation currently is telling someone who wants to develop gutenberg blocks to install node with 'brew install node', lol. I don't know if the errors are related to lingering traces of the homebrew install in my setup or issues in the package itself, because other people have similar reports here.

I think maybe installing this theme via composer might be a better option for many developers working with PHP. I can copy and paste code from my other deployment scripts I'm already using for wordpress and other PHP apps my company runs to handle the composer installations. We don't do much nodejs work, so we don't have that kind of stuff as handily sitting around. You can use scripts and option prompts to handle asking about what font library they want to use, etc so even if this is developer centric it can still be easy and clear.

I get that nodejs stuff is required for the boostrap compilation, but my experiences with setting up javascript toolchains has never been fun as someone who doesn't work with it every day. But when it comes down to it, everything I need would simply by solved by the theme not making the assumption that I want fa4.7 included, with an option to turn it off in the settings.

You should work with a child theme @epoplive
As such you are still able to receive the updates while keeping your customizations.

You should work with a child theme @epoplive
As such you are still able to receive the updates while keeping your customizations.

Perhaps I'm unclear on what benefit that would have when the only customization I'm looking for is to not have an outdated version font awesome included.

I totally understand what you are saying. But as you can see this topic has been discussed for two years now. In the meantime fontawesome 6 is on its way 🙈🙉🙊

I totally understand what you are saying. But as you can see this topic has been discussed for two years now. In the meantime fontawesome 6 is on its way 🙈🙉🙊

Yeah, that's why I just want the FA css to not be included. :(

If people are still discussing adding 5, I will have the same problem when I switch to 6, lol. Would you be open to a PR that splits the css into a separate file and uses a configuration option? I think a possible way to handle the icons would be to have an overridable map for the icon classes. Imo a second css request is a fair tradeoff for wanting an old version included by the theme.

PR's are always welcome.

Though I can't guarantee it will be merged. That is unfortunately only the owner who can

Was this page helpful?
0 / 5 - 0 ratings

Related issues

davidshq picture davidshq  Â·  4Comments

davidshq picture davidshq  Â·  3Comments

jonnymaceachern picture jonnymaceachern  Â·  4Comments

typeplus picture typeplus  Â·  5Comments

revamperdiaries picture revamperdiaries  Â·  5Comments