Reply to Chris Aldrich and Testing an IndieWeb Theme

Replied to Chris Aldrich (Chris Aldrich | BoffoSocko)

I’ve switched over to David Shanske’s IndieWeb-friendly fork of the TwentySixteen Theme tonight. Liking it a lot so far. Can’t wait to see what little surprises I run across under the hood and how we can potentially make it better for the community.

Really interested Chris in what David Shanske’s theme might have to offer. Having spent some time lately trying to get my head around the ‘motor under the hood’, I am wondering about the difference between David’s approach to fork the 2016 theme, compared to your approach of creating a child. Is there simply fors and againsts for both? Or is one more ideal? Just wondering as per usual.

2 responses on “Reply to Chris Aldrich and Testing an IndieWeb Theme”

  1. Aaron, generally most of the “motor under the hood” should be handled by the WordPress core code and any plugins you use. The rest (how it all looks) is generally up to your theme, though themes have the capability and prerogative to build a lot of plugin-like functionality into a special file labeled functions.php.
    The TwentySixteen theme doesn’t have a lot of additional cruft built in, but from an IndieWeb perspective, it (and most other themes honestly) doesn’t support microformats version 2 classes very well. Moving parts like webmention and micropub use these underlying microformats to make your website to website communication cleaner, better, and prettier. Thus David’s fork of the TwentySixteen theme adds these pieces where they should be. (Honestly a well-built modern theme would have had them from the start, but sadly web standards aren’t always as standard as one might expect.) David also adds some small amount of custom code to better support integration with some of the IndieWeb specific plugins, though honestly most of them work as you’d expect even without these small pieces of code that more tightly integrate his theme to those plugins.
    Now to the second part of your question–the child theme. Child themes allow users to make (usually) small tweaks to themes (and how they look) without completely overriding the parent theme. Thus if you prefer to have different link colors, for example, on your website, you can set up a child theme which simply has a few lines of code that has the CSS to target just that piece. Your WordPress install will call both your child theme and the original parent theme in such a way that your child’s preferences will override the parent’s. Primarily this is done because to effectuate the changes otherwise, you’d have to make them directly to the parent theme’s files, which is fine, but when the parent theme is updated (for increased functionality or security reasons) all of your manual changes will disappear and need to be rewritten. Some child themes only cause one or two small CSS changes to the parent and others have hundreds not only to the CSS style files but to the underlying code functionality as well.
    As an example, David’s theme fork does several things including removing the TwentySixteen Theme’s original post formats support. If I still wanted to keep that functionality for some reason, but I like all the other things his fork does, I could simply add some code to my child version and voila–I’ve got that piece back without needing to manually change everything else. Future updates he makes won’t affect my manual changes or cause me to need to reprogram the things I changed.
    At a minimum child themes really only need two files: a style.css file and a functions.php file. They can contain more depending on the amount of things you want to change about the parent theme. My child themes usually have a small handful of CSS tweaks to change some of the layout, typography, and colors on my site and the functions.php file has a snippet of code from that prevents Akismet from marking webmentions as spam. Other than that, my theme looks and acts almost 99.9% like the parent theme, because that’s what’s controlling it in fact. Since I was moving from using the TwentySixteen (master) theme as my parent to David’s forked version of it, I only needed to download his version to my install and change a few lines to my original child theme to make it repoint to the new parent. Why would I do this? By using his fork, I’m getting better microformats support that wasn’t written into the original version of TwentySixteen, but by simultaneously using my child theme, I’m bringing along a few niceties for display that I’ve modified over the last two years.
    Another common change in child themes is to change the display of particular pages or posts on your site. Perhaps you want a custom 404 page? Then you can include a 404.php file in your child that provides different code than the parent, and bang! you’re in business: Or maybe you want to change just how your /tag/education/ page displays, but none of your other /tag/ pages? You can include custom pieces of code in your child to change how the templates work for just the pages or posts you want to target.
    The last bit of subtlety, just to make sure you’ve got it: because David forked the original TwentySixteen, it has become my new “parent”. Thus if the TwentySixteen theme changes or updates, I don’t benefit from those changes at all. I would have to rely on David to port those changes over to his fork–something I suspect he’d probably do given that he’s actually using it on his own website.
    In case you missed it, I also wrote a brief synopsis elsewhere in the comments of what David’s fork brings to the table:
    I hope this helps to answer some of your questions.

Leave a Reply

Your email address will not be published. Required fields are marked *