Menu icons not showing, how to optimize / remove / merge scripts & stylesheets

[siriusmw]

Hi, what are the menu icons/boxes showing on this child theme, and how do we correct it? Thank you!

[link removed]

http://postimg.org/image/h3o0aj1s9/41c1311d/

• This topic was modified 7 years, 3 months ago by Jason Bobich. Reason: Edited title to be more descriptive of issue
• This topic was modified 7 years, 3 months ago by Jason Bobich. Reason: Removed link to customer website

Topic

[Jason Bobich]

HI,

Did you recently update WordPress? First off, I just want to point out that the first thing I noticed is that you’ve got a bunch of CSS added through the custom CSS option on our theme options page. However, this along with any other CSS the theme needs to output from Theme Options is not done so correctly because of an issue with WordPress 4.2. In order for all this to work, you need to have the latest version of the theme.

http://themeblvd.com/changelog?theme=commodore

Now, about your icons, your server is shooting back a 403 error code when trying to retrieve the required icon font on your server.

See screenshot: [removed screenshot]

Have you uploaded the theme manually with an FTP program? Maybe double check the file permissions of the font files at:

/wp-content/themes/{custom theme name removed}/framework/assets/plugins/fontawesome/fonts/

See here and your server’s response: [link removed]

• This reply was modified 7 years, 3 months ago by Jason Bobich. Reason: Removed links that shows customer's website url

[siriusmw]

Hello, How do I just disable the menu font icons, please?

[Jason Bobich]

I guess you could just hide them with CSS:

#primary-menu .sf-sub-indicator {
  display: none;
}

I know you’re looking just for an easy fix, but I would really look at what I said above and try to figure out what you’ve done incorrectly in putting the theme files on your server. Because even with hiding the icons with CSS, you’ve still got your site trying to load resources in the background that aren’t there, and it’s going to add extra lag to the load of your site.

[siriusmw]

https://github.com/FortAwesome/Font-Awesome/issues/1119

How do we fix this? (Checked forums already.)

And how do we lower the number of js calls to the site to speed it up? 50% of load is js queries. (Did the custom-name child theme, or something else on our side, cause this?)

Thanks!

[Jason Bobich]

Hi,

By default all this works fine in the theme on mobile. Can you please provide a live link to the issue?

As far as JS goes, you should look into using a plugin like w3 total cache. Anything outside of something like that would be code customizations you’d need to make.

[Jason Bobich]

@siriusmw Please start a topic to address your issues. I will not share the link you sent privately but you need to start a topic to discuss the issues. Please keep in mind I do not provide customization and do not offer paid work, however I will do my best to point you in the right direction with any issue that may require customization.

[Jason Bobich]

Apologies, I didn’t realize you were the original poster. We can continue in this topic.

[siriusmw]

No problem. I think we’re ok. I’m migrating 100s of sites, so I’m not always finding myself in the right place on these support areas that require login. Publically-posted comments are not in our best interest, when competitors often use them to pitch clients about issues we discuss. Thank you for your help, you’ve been wonderful.

[Jason Bobich]

Publically-posted comments are not in our best interest, when competitors often use them to pitch clients about issues we discuss.

I have removed your client’s URL from the above posts in this topic. And if your username has any significance to your brand, you can change how your name is publicly displayed here on our forums by going to your account settings page. Use the menu in the top right corner of the website and go to Your Name > Account Settings.

https://github.com/FortAwesome/Font-Awesome/issues/1119
How do we fix this? (Checked forums already.)

I have looked at your site on my iPhone (through the link you sent privately) and all of the FontAwesome icons show on the main menu when I look at your site on my iPhone. I have a feeling you fixed the issue with the file permissions, but maybe you just had the previous issue cached in your mobile browser.

permissions …

In the future, when you install a new theme, I would suggest uploading the theme.zip file through your WordPress admin themes pages. This way, you won’t have to worry about any of these kinds of permission issues. The issues you’re running into (originally with the FontAwesome icons) is not something that other customers face by default. So, something was originally wonky with how were you were manually handling the files through FTP or whatever.

However now, if you were to say delete the theme entirely, and then install again through WordPress dashboard, because the theme is in the same directory it was previously, you’ll still have the old permissions you were messing with.

Anyway, you definitely don’t need to give write permissions to physical files of the theme. You’re right, this is bad practice. The default and standard setup for files in general on a server is: files should be 644 and directories (folders) should be 755.

… Merging is a huge task with so many style sheets in your structure.

This isn’t something you want to do, anyway, through your child theme. You’d want to use a plugin like JetPack or W3 Total Cache. This will make updating in the future very difficult if any of these scripts or stylesheets change, which they will.

I’ll illustrate my point more further about this after I cover a few other things…

… your child theme update overrides the stylesheet when the files are loaded into the custom child theme

You never need to update the child theme, and this is the purpose of a child theme. You continue to update the parent theme, while the child theme remains in place. Now, with that said, a parent theme update may require that you change or adjust something in your child theme to be compatible.

But over time, we have changed the structure of the default child theme provided, but it doesn’t mean you ever need to actually update it each time you make a parent theme update. You only need to edit the child theme if something in it doesn’t work with a parent theme update. This is generally why you make updates in some sort of staging environment before going live.

Dedicated WordPress hosting sites like WP Engine have cool features for doing this, that are good for folks that are looking for an easy, automated solution for staging.

We have a custom-named child theme…do we upload your child as named?

It doesn’t matter what you name your child theme or if you even use the one we provide, really. We just provide it as a starting point for those who don’t know how to create one.

Can you help us to merge these sheets …

And how do we lower the number of js calls to the site to speed it up? 50% of load is js queries.

We’re not really doing anything out of the usual — aside from maybe having more than you’re used to? But this is for good reason, as I’ll explain in a moment. We’re enqueuing all scripts and stylesheets in the standard WordPress way.

If there are any stylesheets or scripts you don’t want included in your site, you can use the standard functions in WordPress, wp_dequeue_script and wp_dequeue_style.

So, you can use this approach for any theme you use and all of your plugins (assuming everyone is doing things the way they should). None of this is really theme-specific, just general info. You’d use these functions from your child theme’s functions.php

First, you need to identify of the handles of the scripts and stylesheets you want to remove.

For stylesheets, you can do this by simply looking at the source of your site on the frontend.

For scripts, you have to actually look in the theme code or plugin code. You can search any plugin or theme directory of files for wp_enqueue_script and you’ll find where any scripts are being included.

For this Commodore theme, look at /framework/includes/frontend.php.

So, from your child theme’s functions.php, you can do it for whatever theme and all plugins, in one shot.

/**
 * Example of removing stylesheets and scripts 
 * that have been enqueued. Using priority 100 
 * on add_action() so that we know it's coming 
 * after everything.
 */
function my_denqueue_script() {

	// Remove stylesheets
	wp_dequeue_style('fontawesome');
	// And so on...

	// Remove scripts
	wp_dequeue_script('flexslider');
	wp_dequeue_script('roundabout');
	wp_dequeue_script('nivo');
	wp_dequeue_script('magnific_popup');
	// And so on...

}
add_action('wp_enqueue_scripts', 'my_denqueue_script', 100);

Now, if these stylesheets and scripts were all merged into one mashed up CSS file and JavaScript file by default, you would not have this level of flexibility to pick and choose which ones you do or don’t want through the standard WordPress enqueue system. That would be the real mess.

And then, to actually merge your final production site stylesheets and scripts together, you’d use plugin like JetPack or W3 Total Cache to do it programatically.

---

Does this solve things for you? Any questions after all that? I know it’s a lot to digest, but a lot of that info is fairly general to WordPress. So I think if you read and digest it carefully, it will really help you going forward any sites you’re creating with WordPress from any theme author.

[siriusmw]

Thank you! That was quite comprehensive and much appreciated! The problems are because the site was on FreeBSD, and migrated to cpanel using tools. The permissions on FreeBSD were the issue.

Caching will be handled, but is not normally necessary with other themes. The confusion with the child is that your updates include a child theme upload. Do we load the child theme directory as is, if our child is named specifically? I didn’t, and everything looks fine.

Thank you again. Working with so many themes and authors and lack of consistency in the community, (“standard” is relative – especially when there are individual style sheets with themes that offer pre-set options) makes this a bit more of a challenge, but understanding your methods and assumptions (cached, fallback, etc.) really helps!

Best to you!
Debbie

[Jason Bobich]

The confusion with the child is that your updates include a child theme upload.

I’m honestly not 100% sure what you mean when you say this. — Are you talking about the “All files and documentation” ZIP package from ThemeForest? This is just the full package that is included when anyone buys the theme, which includes a sample child theme (for optional use, just an example). You always have access to the latest “All files and documentation” when you go to your ThemeForest Downloads page. So, I’m wondering if that’s what you mean when you say “your update”?

Would it be less confusing if you setup in-dashboard updates? — http://support.themeblvd.com/theme-update-instructions/#themeforest

Or, if you like doing it manually through FTP, cPanel, or whatever, from your ThemeForest downloads page, just download the “Installable WordPress files only” zip package. That way, you only download the updated WordPress theme files, and not the other miscellaneous stuff like documentation, child theme example, PSD files, etc.

Do we load the child theme directory as is, if our child is named specifically?

Again, you don’t need to update the child theme when updating the parent theme. And your child theme (style.css name and directory name) can be named however you want.

[Jason Bobich]

I think I may see a major reason for you confusion. — I can see you’ve updated the parent Commodore theme to the latest version, however the bug with previous Commodore versions and WordPress 4.2+, which comments out all of the generated styles in the <head> is still there.

This tells me either (1) you didn’t update all files of the theme (this specifically corresponds to /includes/theme-functions.php), (2) maybe there’s some sort of server cache serving old theme files, or (3) you’re overriding the functionally that was fixed somehow from your child theme.

Here’s the specific fix in the theme that allows for the CSS you’re putting into Custom CSS option on your theme options page to work with WordPress 4.2+

So make sure you’ve updated all files of the theme, and there’s no server cache that would be serving old theme files. And make sure if you’re overriding things in the commodore_css() function from your child theme, you account for that change.

[Author]

Replies