lol, you’re kind of losing me here, but I’ll try to answer from what I’m following in your topic.
Yes, there is currently a bug in the framework with the logic of how single post meta is determined. It doesn’t work properly because of the typo you saw referenced in the other thread. This will be fixed in the next update. But this doesn’t really have anything to do with the post formats tutorial you’re linking to other than the fact that you’re switching to use a template part that no longer accommodates that setting.
So why is this? — This is because the whether or not meta info shows on the single post page is ultimately determined by what’s in that template part.
Putting the current framework bug aside, by default, the framework uses
content.php to display single posts, and that is the only thing that file is responsible for. And so it holds a simple check to determine whether or not the single post meta shows.
So, if you follow this tutorial, you’re now changing the entire structure of how things work, and so you need to accomodate for that in your template part files.
For example, if you create a
content-link.php, and you want to use that for Link format posts on both a post list and single posts, and you want that single post meta option to still work, you need to accomodate for that something like this:
<?php if( themeblvd_get_att( 'show_meta' ) ) : ?><?php themeblvd_blog_meta(); ?><?php endif; ?>
This is difficult to explain. I don’t really have it documented yet how the
themeblvd_set_att function work, but basically that’s how I’m passing parameters through to the template parts. So for example when the page loads (current bug aside), the framework looks for it being a single post, then determines whether or not to set “show_meta” parameter as true or not. But by checking
if( themeblvd_get_att( 'show_meta' ) ) : in the template part file, we can see if it’s currently set to show or not.
However this is sort of tricky because on the post list, this isn’t going to be true and so the meta info won’t show there. It seems to me that it would be most logical that if you were going to the extent of programming in your post format files, you’d just remove the option for the user and determine yourself, as the developer, how posts should look in each scenario.