Load fontawesome form absolute path in source

[bracas]

For us it caused issue when we try to hook it to rename wp-paths

As I see it the fa fonts will not be loaded through hide my wp because they are called from CSS with relative paths and we can’t hook that call. Which seems to have been added while you changed to V5?

Can we solve this?

add_action( 'wp_enqueue_scripts', 'enqueue_load_fa' );
function enqueue_load_fa() {
    wp_enqueue_style( 'load-fa', 'https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css' );
}

But oad v5 and from self hosted and not maxcdn?

[friech]

Hi Bracas,

Thank you for writing in but sorry I am not entirely certain of your issue, it seems you’re trying to load FontAwesome 4.7.

If so, then please import that to your child theme’s style.css file using the CSS @import Rule. (Just keep in mind that you have this on your child theme, as this might create a conflict in the future.)

Cheers!

[bracas]

No that was just a dummy version of how to do it. It is not implemented… asking you guys.

You CSS load the fontawesome instead of fire it in the source code which we can not hook and rewrite the url with. CSS @import is bad web standard and should not be used, you guys should know that this should be avoided for performance of a website.

What we want it to proper load the fontawesome so we can hook and rewrite the wp-content path for that file. The loading technique used now is always reported as slow network due to how you developed it and neither can our hide my wp hook into this path since you used CSS to load the fa fonts with relative paths.

[christian]

Hey @bracas,

We’re sorry for the @import suggestion.

You are correct that FontAwesome is called from the Stack’s CSS. That is not a bad practice nor improper implementation. That is even best as all the theme CSS (except of the builder’s CSS) are combined and minified in one CSS file. If you look at the contents of https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css, that is similar in with the Stack’s CSS. Use a CDN and it will essentially be the same.

There is no support for changing the URL. And generally, users would use a CDN and that is the recommended method to host resources outside of your site.

Regarding the “Slow network” issue, I believe you’re referring to the browser’s warning. It is not critical but I will post this in our issue tracker so our development team would be made aware of this case and might give feedback in due time.

This is not related to the path. As you can see in the screenshots below, using the source even from FontAwesome’s CDN will still have this issue.

Thank you for understanding.

[bracas]

I was saying css import was bad practice and so well using relative paths for most issues. But that’s just my opinion.

We do not want CDN not about that.
We want to fetch rewrite the wp-path to our branded one to hide wp-content which works for everything expect this path and have worked for over a year. That’s why we ask and hide my wordpress developer confirmed it’s due to the relative paths and it’s fired though CSS and not visible in the source code. So his plugin can not hook and rewrite it.

Can I rewrite it in child functions to use absolute path?

Ok good that should be solved but if you say this does not affect any performance of the fonts or the site over all or isn’t bad coding. I hope that’s the case it’s fine with the error. But we have to solve the other issue.

[christian]

Overriding it is the same as before with the exception that you will need to override the Stack’s CSS rather than overriding the FontAwesome CSS separately. It is the changes in FontAwesome that called for the change in the structure in the theme by the way.

I’m going to provide the steps you need to take but I’m not going to detail as this is outside the scope of our support. If you are not comfortable with doing this, you will need to consult with a third party developer.

1. Edit the URLs in the parent Stack’s CSS
2. Copy the CSS file in your child theme. You can put it anywhere in the child theme since you’re going to enqueue it in the next step.
3. Enqueue it your child’s functions.php.
4. Dequeue the parent’s CSS.

Hope that leads you to the right direction.

[bracas]

Could you send me which files located where and the enqueue and dequeue code in the functions.php and I know for sure I followed the steps correctly. thanks

[christian]

The Stack’s CSS is in \framework\dist\css\site\stacks and it is enqueued with the handle x-stack

For enqueue and dequeue code, please check the links below:

https://developer.wordpress.org/reference/functions/wp_enqueue_style/
https://codex.wordpress.org/Function_Reference/wp_dequeue_style
https://codex.wordpress.org/Function_Reference/get_stylesheet_directory_uri

Here’s a sample code to be added in functions.php:

add_action( 'wp_enqueue_scripts', 'use_my_css', 99 );

function use_my_css() {
  wp_dequeue_style( 'x-stack' );
  wp_enqueue_style( 'my-css', get_stylesheet_directory_uri() . '/my.css' );
}

Please watch this video to see that it would work when followed correctly. Also note that this guide is a basic example. This might not be the best for your project.

This is as far as we can go regarding this case. If this does not work for you and if this causes issues now or in the future, please consult with a third party developer.

Thank you for understanding.

[bracas]

Ok we will have a look at above but when I change:

…/…/…/…/
to
wp-content/themes/pro/framework/

It breaks it, tried to change in the parent file?

[rad]

Hi @bracas,

Where did you change that? You should use get_stylesheet_directory_uri() to get the path of the child theme, or get_template_directory_uri() to get the parent’s directory. An example is this

The get_template_directory_uri() returns example.com/wp-content/themes/pro/
Then get_stylesheet_directory_uri() returns example.com/wp-content/themes/pro-child/

You don’t need to actually add your own path. And if you customize the path, those functions will follow accordingly, like example.com/wp-hidden-this/themes/pro/. And since the path is changed, the font icons will be loaded according to that new path. I understand that you wish to hide the path, you don’t need to change them statically, just change it through WP configuration and the rest should follow. Except again, if you have custom code that uses static path like you provided.

Thanks!

[bracas]

I don’t think I follow how to do it.

We use hide my wordpress but it can not hook and rename the path of wp-content if it’s absolute paths.

[rad]

Hi @bracas,

I see, in that case, I would recommend contacting a developer for this one. All icons are loaded relative to the path, in which path configured by Wordpress. And it’s only normal for stylesheets since the browser automatically resolved to the stylesheet path which should have no effect to loading speed.

What’s slower are images added or embedded through HTML but with the relative path, they must be served with absolute path.

Thanks!

[bracas]

Dunno what you are talking about in the latest answer?

We just want the theme means your product to fire in absolute paths instead of relative. Can we sort that thanks… we are for sure not the only one rewriting these paths on frontend with .htaccess file.

Let me know.

[rad]

Hi @bracas,

And turning the relative path to absolute would require customization which we can’t provide, hence, I recommend contacting a developer.

What I was referring is just comparison between images path through HTML, and icons path through CSS. And it’s only normal for CSS to have a relative path which has no performance issues at all. CSS is a static file so it can’t have any absolute path within it, and compared to HTML, paths in HTML are configurable through PHP or any content processing code. While in CSS, it’s not, since they are just CSS code that runs on the browser and not on the server.

Hence, if you really wish to set them into absolute path within CSS, then you must edit the core files and change them and any issues resulted from customization are something we can’t cover. And a developer is more recommended for this changes.

You can also check this https://stackoverflow.com/questions/10058167/wordpress-3-3-relative-paths-in-css

Wordpress is a modular system from different authors and developers, you can’t always set them in the static path, else, it will cause future issues and bug. Like in the migration, backups, and etc.

And htaccess has no relation to the theme, it’s a Wordpress core file for permalinks and rewrite. It would only mask the URL, but it’s still relative to the domain configured in htaccess.

Thanks!