The Not-Quite-Important !important

This new post has nothing to do with my current status in my 3Ts-style WordPress theme development learning, but it does have to do with just WordPress theme development in general. To be more specific, it’s the child themes I’ve created. Child themes are the safest, most "beginner" way to WordPress theme development, and for the past 10+ years that I’ve been using WordPress, I’ve always been stuck at child theme level. I’ve always wanted to develop new skills and go beyond child theme and reach at least the starter level theme to just completely a 100% custom theme developer level. This is the reason why I’m learning WP theme development using the 3Ts.

Going back on subject, I will be writing about what I’ve learned, or rather re-learned, one simple solution to this nasty CSS issue that have me stumped for over two weeks since I converted to Adrianne Codes.

The Issue

When I was building Adrianne Codes, I wanted to experiment with a different base parent theme to build a child themes with, as I always wanted to diversify myself with different parent themes including starter themes. But, there have been a lot of learning curves for me and I eventually went back to the parent theme that I’ve been using for all of my sites for years, the Ultra Theme by Themify.

All Themify themes have a built-in builder simply called the Themify Builder, in which you can create custom pages and posts with different layouts and other elements. It was very useful and handy to extend the limited options of the old WP Classic Editor before. Today, because of WP’s new Gutenberg blocks feature, Themify Builder has been completely rebuilt to match the Gutenberg blocks feature, so that it now acts as an extender for it. I’m still using both, but lately I’ve been using Gutenberg a lot as well. There is also a stand-alone Themify Builder plugin, which can be downloaded and installed for free and use it in your own free will.

On the Themify- enhanced Customizer section of the Dashboard, the customizations can be done with just dragging and dropping your choices and that the changes will apply on the Customizer’s preview. I have a habit of using a custom (non-Google Font) typeface for my headers and upload them using a plugin called Use Any Font. But for the body font, I always use Google Fonts, since it’s already built in the Customizer.

I originally wanted to use something that we normally see in IDEs/code editors, like the font I’m currently using now, Oxygen Mono, just so it will match with the whole Adrianne Codes theme. Unfortunately, all of my customizations did apply on the site except for the body font. Maybe for the developers and straight-up programmers, website aesthetics aren’t a big deal. But for me as a designer and developer, they are a big deal, and it has been driving me crazy.

In addition to this issue, my newly-converted personal art diary blog, The ADRICULOUS Life, is also having that same body font issue as this site, which drove me even more nuts. It also came to a point that because I was so annoyed with the body font issue that it even gave me less motivation to blog and just want to rage-quit altogether.

The "Remedies" that I used (and failed)

There are two things that may cause the customizations not being read by WordPress even after publishing the site after the changes were made: plugin incompatibility and caching.

I made sure I cleared the browser cache of all the browsers I currently use so that I’ll be able to view the site in multiple browsers and devices (namely my iPad and my phone) before I started attempting to remedy the issue myself.

First Attempt: Disabling and Enabling Currently Installed Plugins

The first solution that we are all aware of may be an issue with plugin incompatibility. And to find out which installed plugin that is causing this issue, we have to disable all plugins and re-enable them one by one until we find the "culprit" plugin. I placed the site on Under Construction mode and began the disabling/re-enabling installed plugins method.

Sadly, it turned out that it wasn’t a plugin incompatibility issue when I noticed that none of the installed plugins caused the body font mess. In fact, I also deactivated and deleted some of the plugins I no longer need to run this site. The next reason I came up with right after the plugin issue is another obvious one: cache.

Second Attempt: Clearing cache on all sides

There are three parts to clearing the cache: the browser side, the WordPress’s side, and the last, server side.

Browser Cache

It’s (somewhat) general knowledge for every user that when things you see on your browser don’t turn out right, you clear the browser’s cache. When you clear the cache and reboot your browser, things that you saw funky at first will all be fixed.

I cleared browser cache on all the browsers I use and in all different devices (Macbook Pro, Dell laptop, iPad, old Kindle, Samsung Galaxy Note 9 phone). I viewed it on all the browsers right after, but sadly, that didn’t view the changes I wanted.

WordPress Cache

If you own and maintain a WP-powered website, you never leave a site unfinished without installing a cache plugin, like WP Super Cache, W3 Total Cache, and so on. Before you make your changes in the Customizer, you usually go and clear the cache before you view it. After I made my changes, I also clear the cache using the plugins too.

I used three different caching plugins (WP Super Cache, W3 Total Cache, even my paid one, Hummingbird Pro) but sadly, none of them fixed the problem. Yes, I was very frustrated.

Server Cache

Last, but still important, it was time for me to reach out to my hosting support center. Because caching also exists in the server, I don’t have control over that. The support peeps can only do that from their end. I went ahead and made my contact with support for the issue.

I went through about 5-6 different support agents (the ticket gets rotated, not their fault) and provided me the same tips as the ones I did before contacting them. When none of them worked, then they cleared the cache from the server side to see if that would fix it.

Nope. It didn’t fix it.

To my own conclusion, it wasn’t the caching that’s causing this problem. It may be a glitch or a bug in the parent theme’s (Ultra) main code instead. So, I went to reach out to the Themify support forum and post the issue.

OMG, it’s CSS??

I was hoping that I didn’t have to do Custom hard-coded CSS to fix it, but from the replies of the Themify support theme, I had to. Not only that, it was a very simple fix too, which even frustrated me more and made me feel embarrassed as a developer.

I actually forgot that CSS has a property called !important. If it’s one thing that I avoid when I do have to hard-code CSS to fix one small thing, it’s !important.

To explain what !important does to the look of the website is that it prioritizes the element specified and overrides other similar elements to it. A full explanation of what it does is explained here.

The solution that the support agent gave me to fix the body font issue is simply this:

One line and that one little !important property added has finally fixed my body font issue. I tried the same code on my art diary blog and it also fixed the issue:

As I write this, I’m finally getting my cool down because I really wanted to slap myself for not thinking about the cause of the problem being the CSS and then forgetting that !important exists. I still have to be careful with using !important because if I’m not careful with where I’m putting that, the entire layout can really look messy.

Conclusion

I’m writing this so that I can remind myself the next time I run into an issue like this again. I made a new blog category called Tips so that I can just head over there to find my quick solutions.

It’s really good to go back to the basics again, which is why I’m doing bonus HTML/CSS project exercises with Skillcrush again, as they have updated a lot of their course contents.

Till next time!

P.S.

For those interested, in the near future, I’ll be adding a child themes tutorial in the Tutorials section. I just don’t know when yet.

P.P.S. (UPDATE – APRIL 2022)

I’m currently a bootcamp student at the moment and we just went through CSS. We have this annoying thing in CSS called CSS Specificity and this was the issue here. I’d still keep the !important solution on this old issue for this theme alone, however, using !important in a real-life code setting is actually bad practice. Maybe that’s why I never thought of this as I was going through this issue then. Luckily, the !important solution that I used to fix this theme did not affect my entire theme styling at all.