Use more specific selectors in the CSS — so that the new style overrides the existing ones.
Or (less desirable) you can use !important to force an override if the above approach just won’t work.
I had tried the !important rule, but didn’t meet w/ any success. Also, I went back and bumped up specificity a bit, but this isn’t working either.
I changed “.caret” to “.navbar .nav .dropdown-toggle .caret” as my selector.
I’m going to take a look at the header.php file and see what is going on. I wonder if it has anything to do w/ the order of which the page is inheriting the stylesheets.
Yeah, I was going to mention the order as well…although !important should still override that. If you post a link to your site, someone can look at it. Make sure your class vs. id are valid. Also, always a good idea to validate your HTML and CSS just to be sure you don’t have coding errors that are tangling this up…
The sitelink is here, for now: http://www.summithme.com.php53-3.dfw1-1.websitetestlink.com/
I checked the order, and although it looks like the links to my style.css and other css files come after the parent-theme’s linked sheets, the parent-theme’s stylesheets are having a strange tendency to override styles that follow, whereas those links that come later link to styles that should be overriding the first styles declared. This is evident in the webink plugin I am using. I set my html, body and p elements to use fonts designated by the webink plugin. Although the header pulls in these styles after the page loads the parent theme’s styles, the parent theme’s styles are still taking precedence in some instances, judging by what I’m observing using Chrome dev tools and firebug.
I appreciate your input, and if you have any ideas, I’m all ears.
Any reason you are using that plug-in rather than a child theme to do custom CSS?
Not sure what you mean. Are you talking about the WebInk plugin? This is actually Extensis’s endorsed method of incorporating their WebInk font service into a WP blog. I’m not really settled on it though. It seems to add a bit of bulk to the head.
I am still kind of green to webfonts, but my understanding is that if you use @font-face, you have to have a font-file hosted remotely on your server. I think this requires purchasing the font family outright, which licensing can be pretty expensive and limited on certain fonts. However, the font-services seem to allow you to license fonts at a pretty reasonable price per client per year, so this is more palatable for small biz clients.
If you have any other suggestions, though, I’m certainly open to education on this, but I believe this is likely best on another thread or forum perhaps. You can email me links to nathan(at)thought-well.com if you have any suggestions.
For now, I turned it off as well as other plugins (GravForms, ACF, WooDojo) to see if maybe this is causing any issues w/ the aforementioned issue. It still persists 🙁
Ah, okay, I did not realize it was to add fonts — yes, you are correct on those assumptions. But since that plug-in seems to be problematic, you might want to check out Google Fonts — as those seem to be widely used — plug-in is here:
http://wordpress.org/extend/plugins/wp-google-fonts/
But I’m also confused because it does not appear that you are actually using a child theme ??
You are right. Although my theme in the admin panel is currently set to the child theme, and the editor under my appearances menu allows me to pull up and edit the child theme, the child theme doesn’t seem to be loading and this seems to be the reason why it isn’t affecting/overriding as I’d expect it to. That’s weird, because if the child theme was set up incorrectly, my thoughts would be that it would be broken and unable to be loaded in the admin… I had experienced this once or twice when I first started using WP.
Guess I better double check this to see if maybe there is a discrepancy… although in the past it would just be broken. Maybe I have a path or something set incorrectly.
I’m going to take a closer look at this…
I completely removed both the parent and child themes, re-uploaded the parent, reworked the child theme from scratch, re-uploaded and the issue still remains. I’m totally stumped… but it does indeed show in front end dev tools that the WP site is in fact loading the stylesheet from the parent directory, even though the child theme is activated and is working as normal from the back-end admin console. The child theme has to be set up correctly because it is working from the admin end, but the site just seems to bypass it altogether when it loads in the browser.
