To the world of life learners and experienced developers, programmers, and enthusiasts everywhere: Happy New Year, 2022! I know I haven’t been blogging, or updating my code-learning journeys because, once again, I lost track with it and kept switching back and forth with other non-code-related things, such as continuing with my online art courses and dabbling with my hobbies that are treated more like my actual job than just plain hobbies. It’s a bad habit, I know, and that needs to stop, which is why we have goals and resolutions1 whenever and not necessarily just at the beginning of the brand-new year. As of this writing, I got 11 months and 1 week left for me to focus on these new goals in hopes that I can finally make myself better as a person, improve my responsibilities, and recreate a brand-new fulfilling life in the midst of this still-ongoing pandemic.
This year’s coding journey goals would hopefully be motivating, inspiring, and uplifting, so I do hope I don’t fail this time.
Taking advantage of my employer’s benefits
I recently started a brand-new full-time job as of mid-December 2021, though I can’t really say that it’s a job related to web dev, data science, or anything like that. However, what I do like about the company is that one of their benefits is for their employees to have a chance to attend chosen sources of education for career advancement or improvement. Information Technology2 is one of the huge parts of their career advancement program, and so, after several years of self-learning through online courses like Udemy and programs like in Skillcrush, I’m actually going to apply to study in an intensive bootcamp.
Here are some reasons why:
Company pays full tuition with no out-of-pocket costs coming from their candidates (employees) – major aid here! I won’t have to think about how I’m going to pay for the tuition at this point.
Specified bootcamp graduates also have the benefit of career guidance and help, especially with cleaning up LinkedIn profiles3, writing/cleaning up resumes, building better portfolios4, and lastly, improving with technical interviews5
It will also give me some time to unwind with work and focus on something that I love and enjoy: web dev/coding (in general) and art.
Having a guided learning experience would also motivate me to stay focused and keep going without getting distracted.
Something minor, but I can finally be more motivated in blogging here more and talking about the things I learned and actual topics related to coding and not babble things unrelated instead.
I know this is a short blog post, but there isn’t much to talk about at this point other than taking a huge leap of taking advantage of an employer benefit and make one of my lifetime goals of attending a coding bootcamp come true without much worries about the other stuff unrelated to the curriculum.7
There are other goals that I want to accomplish— or beginning to accomplish anyway— for 2022, but I’ll write about them in my other existing niche blogs. Here, it’s all about coding.
I decided to halt on the 3Ts development of WordPress themes and decided to work on overhauling my very simple-looking web dev portfolio first. Learning how to build WP themes using Twig and Timber (and TailwindCSS) is just something I’d like to add as an extra skill for my resume, 1 so it can wait. I have an unlimited access to the WP Theming with Twig and Timber in the first place anyway, so I can get back to it at another time. Right now, I want to have another attempt at learning how to build sites using SSGs2
My Past Journeys to Static Site Generators
Sometime in the mid-2010s (around 2015 or 2016 I think?), I was trying to get back to my early days of web designing/development by getting back into the anime site shrines community once more. Because of so many articles and books and other things that I’ve read for many years, finding better solutions to build better, cleaner sites, I started reading about the next new thing for websites and CMS systems: Static Site Generators.
Static site generators (SSGs) are a fast and lightweight alternative to heavy CMS systems like WordPress. I discovered SSGs around the same time as I was learning how to use Git and GitHub and building simple non-dynamic websites with GitHub Pages. Jekyll was the very first SSG software that I’ve come across and have been wanting to use it. But it took me about a year later that I finally gotten around to starting how to learn to build websites powered by Jekyll.
Unfortunately, Jekyll would require a lot of things installed in my system just to install it. The software was built using Ruby, and I have attempted to learn Ruby before.3 Not only that, I also needed Git installed (which I already did) and then install more gems before installing Jekyll. I actually tried attempting to learning it as of this writing. However, I’ve run into so many problems just getting Jekyll to work on my system, and it kept giving me errors when I try to view my newly-installed Jekyll site. I’m still working on getting it fixed by being brave and ask the folks at the Jekyll Help forum.
Sometime later, I discovered the second SSG I came across after Jekyll: Hugo
When I first opened this blog,4 I actually tried to rebuild my old Sakura & Syaoran Shrine5 using two things: MaterializeCSS and Hugo. I was able to build the main layout using MaterializeCSS, but I never had the time to start learning Hugo, and I abandoned it.
I no longer have the hard files anymore because it’s been so many years, however, I did create a repo of all those files, so at least I’d be able to download them from there and work on it again (maybe), once I finally got the grasp of learning how to build sites using Hugo.6
Why Hugo… again?
I want to run my portfolio completely lightweight and without the bloat, so I’m going back to SSG again. I decided to choose Hugo again, though I’m also looking into Sculpin (PHP-based), Pelican (Python-based) and even Gatsby (JS/React-based). There’s also an option of building a headless website using both WordPress and Gatsby, but that just sounds way too complicated. Maybe the latter may be a better option, but we’ll see in the future.
I did find a site that lists the Top SSGs here and it looks like Hugo is one of the highest being used there. It does have one of the easiest installation/setup procedures – you don’t even need to install Go (the language Hugo was developed from) or even have some knowledge of Go for you to create a Hugo site. Plus, (from what I read) compared to Jekyll, it’s blazingly fast and lightweight.
In addition, I’ve also gotten used to writing my blogs and articles using Markdown. When I was writing my (fan)fics years before, I was using a novel-writing tool with Markdown. I used Scrivener to write all my old fanfics years ago on my Windows laptop, then when I started getting active on my MacPro, I re-installed Scrivener. I kinda ditched Scrivener sometime later for Place to Write7 and lately, iA Writer.8 I now use iA Writer so that I’ll be able to sync my files (via Dropbox) to my Android-powered phone. When I get bored at work or during break, that’s when I retrieve my files and continue writing with whatever I’ve been writing.
As of late, even though Gutenberg has done a lot of wonders for this new generation of WP, I’ve been using a lot of Markdown lately and not even bother with the WYSIWYG formats like the Classic TinyMCE or even Gutenberg. The only time I use the block is on the first paragraph so that I can have that shiny Drop Cap on the first letter.
It looks like things are going well with my Hugo self-training. It’s almost there. Maybe.
I figured in the beginning that learning straight to the 3Ts would have a lot of learning curve, but I never thought that the curve would be that very steep. I haven’t progressed much with the course presented by Build Awesome Sites and still stuck with the setup. Actually, I had my first taste with the Timber basics and somewhat refreshing with what I know about Twig. I couldn’t remember when I had my first taste of Twig, but I am familiar with the PHP templating system for sure. Either way, I ended up following along with the video while trying to understand what we’ve been doing all this time. Maybe I’ll go back to the Udemy course or even furthermore by refreshing with basic WP theme development and basic PHP even. I actually found (and enrolled) in a TailwindCSS-specific course, so I’ll also be spending time with it as well.
Maybe I can finally rebuild my mini-portfolio using Tailwind CSS too. I thought about using WP at first but then the site would feel really bloated, so I decided to just use standard HTML/CSS one-page instead. It’s only a portfolio showcasing a few samples of my work, but I feel like I want to build more into it than the usuals. There is indeed so much that I could do, but until then.
As mentioned above, I decided to build my basics bootcamp course, coming from different sources that I’ve already paid for some ages ago. I’m just happy that these are unlimited courses. I’m one of those infamous hoarders of courses in which I purchase them but never actually start with them until much, much later. I’m guilty with that and I need to stop with that habit:
I’m also currently taking an SQL Development Bootcamp course at Udemy, but that’s more for data science/data analytics-related course. However, knowing SQL also helps working with the WordPress-powered databases quickly and efficiently when needed, but I didn’t include this particular course on my basics bootcamp list.
There are also some times that I do get distracted away from my code learning through my new/personal guilty pleasures. That’s why they’re called guilty pleasures. None of them (or maybe some?) are code learning-related, but in a way, they can be.
When in the mood, watching a variety of Asian dramas, especially period dramas and movies.4
My toddler nephew. Yes, he’s that lovable.
I eventually want to build my art portfolio on its own domain. But because I love to build things with my own "hands," I plan on using my newly-learned skills on development WP themes with the 3Ts5 and hopefully rebuild all of my WP-powered sites with a more optimized custom theme. That would be a major challenge, of course.
And…. maybe make more art that somehow relates to code.
Lastly, I’m discovering this whole no code methods in web development and in some cases, AI/Machine Learning. I’m interested in this too!
Hello! It’s been awhile. I haven’t been blogging here for a long time since I started self-learning how to develop custom WordPress themes with the 3Ts.1 But, both as a designer and a developer (or either one of the other), don’t you feel a little annoyed when you’ve made your custom changes in your site’s styling only to realize that one of your more important elements did not adapt the change you made and still remained at default? I’ve actually had this problem ever since I converted this site from The NINPOJineous to Adrianne Codes, and that was a very long time too.
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.
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.
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.
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.
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.
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!
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.
I got home from work and set up my laptop immediately so I can proceed to the next step. Just as I thought, I got another bunch of errors trying to install TailwindCSS via Homebrew and Node. It got me so furious that I wanted to just quit and drop altogether and cry about getting my money back for having such outdated setup requirements and steps,1 but instead, I decided to look around for solutions again and apply them without bugging anyone for help. Yes, I’m stubborn that way. Asking someone else is the last thing I would do if Google won’t help me.
The Issue and Steps to Solution?
The Terminal built in with my VS Code had come in handy, so I was quite happy. But once again, everything installed in my system beforehand were completely outdated. Even my Homebrew was outdated. So I had to go through the steps of updating my Homebrew and even try to update my currently installed Node and NPM. It didn’t help me much so I had to start over by removing Node/NPM and re-install them the installer file way. I finally got it to work.
Homebrew is such a lifesaver for me ever since I started digging deeper into using Mac/MacOS that I started to become reliable to it. Unfortunately for me, I don’t use it that often except when I’m following along coding courses and install things like Node:
Checked the version of Node/NPM to see if it’s installed in the first place. It was, but it gave me another message saying that I need to update it to the latest version.
Homebrew to the rescue! With just one single brew upgrade node, I thought my problems would be solved quickly. It didn’t. And then, I brew update to get Homebrew to work. Update was a success, however, from out of the blew after doing brew update node again, it did update it… except it won’t update Node/NPM because it said that Node/NPM doesn’t exist.
I used Homebrew again to install Node/NPM. It installed Node but it won’t install NPM because it said that I *didn’t have admin permissions to install Node/NPM*, even if my own account on my Mac is the admin of the system. Why?😭
After exhausting all my Googling energy, my second to last tip was to visit the NPM official site and (re-)install NPM as if it was the first time. That finally fixed the problem.
Using the latest version/fresh install of NPM, I was finally able to download TailwindCSS.
Setting Up a (Private) GitHub Repo
The only section that I still know the basics on, I turned to my old Skillcrush Git cheatsheet to create my repo for the TwiggyTim sample theme. But at the same time, I learned something new regarding the .gitignore file that is included in the original Timber starter theme pack. I followed instructions by adding certain files and folders in that file so that GiHub won’t include them into the repo.
When I started to initialize my twiggytim theme folder into a repo, I wasn’t very careful then. The Terminal gave me the message that the twiggytim folder had been re-initialized into a repo. It made me wonder whether I missed something or whatever. I proceeded with the usual committing of the files and then pushing them in my newly-created repo on GitHub. Because the instructor made his repo as a private repo, I did the same (for the sake of following the course).
I don’t know if GitHub (or Git even) made a few changes, but the name of the master branch changed (?) to main instead. Later on, I realized that maybe because it’s a private repo that the branch names are different from those of a public repo. Makes sense, i thought. Finally, when I tried to push my files to the private repo twiggytim, it gave me an error message:
I started panicking at first, then I read the error message quickly. I then realized that the twiggytim theme folder, which I renamed from the original Timber starter theme folder and moved it to a different directory, was still connected remotely to the original timber/starter-theme.git repo, which of course, I don’t have connections to. I did “star” it so I can follow Timber’s updates, etc. and I also visited the Timber GitHub account to ask for some bit of tech support regarding setting up my environment, but I went to the timber/timber repo for it, rather than the starter theme repo.
After reading that error message carefully, I went back to the starting steps again by removing the remote connection of the twiggytim theme from timber/starter-theme.git repo.
Finally, I successfully made my private repo and pushed all of my files into the repo, ignoring the other files and directories I included in the .gitignore file included. I can’t really link the new repo because it’s a private repo, so no one can see the files in there anyway, but a twiggytim repo does exist in my GitHub.
Now that I’ve got everything set up including the GitHub repo, I can finally proceed with the actual building of the sample starter theme.