Before I test a manual site backup and restore (not using plugins,) I thought I would play around a little bit with my site theme and customize it to my liking. I got myself into more work than expected. That’s usually the case.
There were a few things I wanted to alter to focus on readability, but I didn’t necessarily want to switch the entire theme of the website from light to dark. That would be the complete opposite of my intent, ruining everything with high contrast.
I wanted the main content wrapper to remain the classic white background with black text. I wanted to make the main nav and the footer a dark color to redirect attention to the main content. Since I’m taking two different approaches to contrast; icon color, hyperlinks, and selection color has to be complimentary to the background color….what a wild ride. Not to mention, I now know what a colophon is!
Some edits have to be made to the footer.php file. The “custom css” editor built into the admin appearance panel, adds css edits to the site database. I didn’t want to be altering the main theme’s style.css file directly either. This meant I had to create a child theme.
I was able to setup a child theme for each virtualhost following the directions from the WordPress Codex. It’s actually pretty simple (minus hunting for the
wp_enqueue_style() parent function call) to create a new theme directory, copy the code for a styles.css and functions.php that uses the “parent theme” as a dependency at page load, done.
Any alterations can now be made directly to the respective css files in the child theme, without affecting the parent theme! Any customization will now be unaffected by theme updates! This is the way it should have been from the beginning…. No more of that ‘paste everything here’ custom css editor blob.
Now about that backup and restore… Maybe I’ll save that until next week!