parent/content.php loaded

Creating Post Formats

Initially I decided to run with Post Formats as a way to specifically generate output for diagnostic purposes.  Turns out that doesn’t work and will not work (by WP dev choice).  There was a lot of work on this page – much of it valuable to understand.  But at process #5, it’s a show stopper.  NEW custom post formats are not permitted.

Serves me right for PRESUMING that WordPress allowed this feature to be extended and customised.  No, I’m not being a smart ass – everything else is so extensible, I simply presumed (in error) that this would be too.  After reading Otto’s remarks, I get it.

Supposedly, to do what I’m trying to do is more the realm of a custom taxonomy – the way things were done before (and after) post formats.  This is exactly what I was deliberately trying to avoid as it seemed stupid to require a whole taxonomy set for a slight variation on layout.

I need to rethink what I’m doing here – the WordPress devs are clearly smart folks. So if my thinking is at odds with their implementation, statistically it’s ME that’s got the bull by the horns.

Ugh.

Process

  1. Start with official doco http://codex.wordpress.org/Post_Formats – talking about the default-available formats, function reference and how to add support for themes, post types, styling and post formats with child themes.
  2. At the bottom of the official doco is what looks like a GEM – http://dougal.gunters.org/blog/2010/12/10/smarter-post-formats/ – smarter is always good!  It talks about template parts.  Hrm, this is important….
    1.  A lot of people are just talking about having a massive IF statement within the loop.  If its a post format of gallery, {insert html here} else…blah blah.  I think that Dougal Campbell is right – this is insane.  The nature of post formats is re-styling the same structure.  Why duplicate all of it?
    2. The net result (allegedly) is quite literally: the_loop -> get_template_part (‘foramt’, get_post_format)-> end loop.  All he has to have is files named format-{PostFormatType}.php - the loop just loads it.  If one isn’t present, it loads the fallback format.php.  Also works for child themes in that if the format-specific file isn’t found, it falls back to format.php and if that isn’t found, it falls back to the parent theme.
    3. Then there’s discussion about overhead and template loads.  Finally, in in the comments, Rev. Voodoo looks awesome on this page: http://www.rvoodoo.com/projects/wordpress/wordpress-tip-post-formats-get-template-part-loop-php-and-maximum-child-theme-compatibility/
    4. This is a little odd – the twentytwelve theme doesnt HAVE a loop.php file.  Bit of back research and I came to the conclusion that loop.php usage is outdated and ‘the old way’.  What I do notice is that the files I’m working with all have this:
      <?php while ( have_posts() ) : the_post(); ?>
          <?php get_template_part( 'content', get_post_format() ); ?>
      <?php endwhile; ?>

      So I think Voodo’s brain work is now part of the default WP rollout – I have a series of default files named content-{Content-Type}.php like content-aside.php, content-image.php etc.

    5. Starting to weird out here. Taking action #3 below: yes, these content-type files are exactly that – post formats.  Cool.  But:
      1. on loading the post format test page with such a post, my index.php template file does not report having loaded
      2. content-aside.php from the parent theme WAS used (cool)
      3. If I visit the home page, it confirms both index.php and my parent theme’s content-aside.php loaded.
      4. Looks like the template heirarchy is kicking in *BUT* my child theme has index.php (no other template files at this stage).  So the heirarchy is NOT falling back to “index.php” – it’s falling back to my parent theme IN PREFERENCE to childtheme/index.php.  Ok – figured it out and documented it on the new CONCEPTS page.
  3. After action #5, I stopped for the day.  It’s now the day after and it strikes me that I want to condense up reporting.  So, let’s implement a jQuery script to allow collapsing sections.  This got large, so I’ve broken it off into a separate post about working with jQuery.
  4. No research this time – going blind – see action #7. Bad idea – lets look at http://codex.wordpress.org/Post_Formats#Formats_in_a_Child_Theme which directs me to http://codex.wordpress.org/Plugin_API/Action_Reference/after_setup_theme as I need my own function in my chid/functions.php file to support and add the post type.
  5. Not working!  Try the WP theme support generator - still fail.  Go back to research and find http://markjaquith.wordpress.com/2010/11/12/post-formats-vs-custom-post-types/ and http://ottopress.com/2010/post-types-and-formats-and-taxonomies-oh-my/ – custom post formats DO NOT EXIST (for good reason, annoying, but good enough IMO).

Actions

  1. Copy index.php from /wp-content/themes/{parent-theme}/ to /wp-content/themes/{my-child-theme}/ – the very basis of child theming.  I copied index.php because it is the base template file of last resort when nothing else is loaded.  If I’m going to start screwing around with dev stuff, it makes sense to have my catch all ready!
  2. Confirm my new index.php is taking hold – it is.  Pretty straight forward really.  Cool.  To help out, I added an absolute div to the top center of every page that reports which template loaded – I’m sure that will be handy later when the difference between one template and the next isn’t huge.
  3. So is Voodoo’s info already done and WP3.5 (with my TwentyTwelve child)?  Is it already kitted up with post formats by default? Modify my parent theme’s content-aside.php and write a post as an aside.  Here’s that post.
  4. Feeling a bit lost, so go through and document every bloody file so it self reports as to what the hell loaded!  In hindsight, this probably should have been step ZERO.  Understanding gained – refer back to that post. We’re good now :)
  5. Copy sidebar.php from parent to child (see unrelated action #1).
  6. Picking this up the next day.  Another unrelated action – see Working with jQuery.
  7. Process #4:
    1. Create child/content-report.php by copying content-page.php from the parent.
    2. Stop in disugst. See process #5.

The net result I took away was this:

  • Trying to create a custom post format is fundamentally bad and a misperception of what they’re for.
  • If your theme doesn’t support post formats OR you want to override the post formats that your child theme supports, you can use this (“bwd” is my personal prefix I’m using to document what’s mine):
add_action( 'after_setup_theme', 'bwd_add_postformats' );
function bwd_add_postformats(){
     add_theme_support( 'post-formats', array( 
         'aside',
         'gallery',
         'image',
         'link',
         'quote',
         'status',
         'report'
        ) 
    );
}

Unrelated Actions

  1.  At action #4, I tagged every file to self-report its own inclusion.  Since I now know exactly what sidebar file is loading & where, modify that to include two short of lists of critical info: a list of available taxonomy names & a list of available post type names.
  2. At action #6, decided I wanted collapsible divs for my post formats.  See Working with jQuery.  Success!  Test post is here.
parent/comments.php loaded