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.
Published by
Chris Aldrich
I'm a biomedical and electrical engineer with interests in information theory, complexity, evolution, genetics, signal processing, IndieWeb, theoretical mathematics, and big history. I'm also a talent manager-producer-publisher in the entertainment industry with expertise in representation, distribution, finance, production, content delivery, and new media. View all posts by Chris Aldrich
Looks like the first benefit is that it works much better with Bridgy Publish.
I use a slightly modified version of TwentySixteen on my site where I disabled gravitar and Google Fonts. So up until I decided to enable Jetpack it didn’t call back up any third party services.
What changes has he made? Anything removed or added?
@ChrisAldrich, I’m not noticing a visual difference. What changed?
The TwentySixteen Indie forked theme has some subtle changes both under the hood and visually which we’ll have to begin better documenting in the GitHub repo for those who want to make the jump:
There aren’t a huge number of changes, so reading the GitHub list isn’t a bad exercise. It appears to be an excellent cookbook for how to convert other themes into more IndieWeb friendly versions, especially for those trying to add better microformats support which can be taxing at times. It’s making me itch to revisit some prior themes I was working on forking in the past including TwentyTwelve, TwentyFifteen, and Minnow.
Syndicated copies:
Some “under the hood” goodness!
I was experimenting with some tweaks to Twenty Seventeen but nothing this cool.
Okay, I think I need to read up on IndyWeb as an organization. Sounds really cool.
@joe4ska If you’re in the Pasadena area in the next few weeks, let’s have coffee and I can give you the top down to make the intro easier. Until then you can take a look at the wiki https://indieweb.org/Getting_Started or if you’re impatient try https://indieweb.org/Getting_Started_on_WordPress.
Syndicated copies:
@joe4ska A while back I wrote a general introduction to #IndieWeb for AltPlatform.org. You can find an archived copy of it on my site now: http://boffosocko.com/2017/07/28/an-introduction-to-the-indieweb/
Syndicated copies:
@ChrisAldrich Hmm, this looks good. I’ve been getting confused between formats and kinds. Think I’ll download it and give it a whirl!
Syndicated copies:
overview of the Post Kinds plugin and that covers the difference between post formats (a WordPress core feature) and post kinds (a plugin with more flexibility). You can find it at http://boffosocko.com/2017/08/11/post-kinds-plugin-for-wordpress/.
, if it helps, I’ve written anSyndicated copies:
@ChrisAldrich @raretrack Thanks Chris, this looks exactly what I need to know. Will have a thorough read.
Replied Chris Aldrich (Chris Aldrich | BoffoSocko)
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.
, 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 https://indieweb.org/WordPress_with_Bridgy#Spam 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: http://boffosocko.com/404. 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: http://boffosocko.com/2017/12/17/indieweb-friendly-twentysixteen-theme-fork/#comment-40355
I hope this helps to answer some of your questions.
Noob question time! I have installed the 2016 indieweb fork and the 2016 child theme, and activated the latter. But I notice from my themes page that the default 2016 theme is also installed. How can I tell which parent theme the child theme is using, so I can be sure it’s using the indieweb one?
Only a noob question because you asked it via a Known site! 😉
But it is a good one. Child themes only really need two files: the style.css and a functions.php. In the style.css file there’s a block of text at the top with details about the theme. One of the lines has the name “Template” and its value is the case-sensitive name of the parent theme’s folder in your /wp-content/themes folder. Thus to have your child theme pointing at the correct parent, you’ll want to modify this “Template” line appropriately.
FYI: If it helps, Smashing Magazine has a pretty thorough article on WordPress Child Themes and what they’re doing and how: https://www.smashingmagazine.com/2016/01/create-customize-wordpress-child-theme/