Twenty Fourteen theme assumes all archive pages are list views

[netweb]

@johnjamesjacoby: via ​#bbPress2504

... twentyfourteen theme assuming all archive pages are list views. Custom post type archives can have their own templates, and shouldn't be subjected to blog post styling.

In the twenty fourteen_body_classes() function, what happens if we change the is_archive() check to is_post_type_archive( 'post' ) ?

lancewillett:

Good points, and yes -- that solution should work without changing existing behavior.

[Frank Klein]

A quick visual check seems to confirm that this change doesn't impact the theme. A second look would be welcome.

[obenland]

Do we really want to limit this to the post post type?
While it may not work for BuddyPress, this might still be desired for other CPTs.

Takashi, can you weigh in?

[lancewillett]

My feeling was that the plugin should filter the body_class itself, and Twenty Fourteen shouldn't have to account for CPTs by default.

[johnjamesjacoby]

TwentyFourteen assumes every archive is a list-view, then hides the entire content body of each single post with CSS when viewing on a mobile device.

In my opinion, no plugin (or child theme for that matter) should need to perform additional, proprietary steps to make custom post-type archives function and display normally.

To duplicate outside of bbPress:

• Add this to an mu-plugin of your choosing:

add_action( 'init', function() {
	register_post_type( 'jjj', array(
		'labels'               => array(),
		'public'               => true,
		'publicly_queryable'   => true,
		'show_ui'              => true,
		'show_in_menu'         => true,
		'show_in_nav_menus'    => true,
		'show_in_admin_bar'    => true,
		'menu_position'        => 50,
		'menu_icon'            => 'dashicons-calendar',
		'capability_type'      => 'post',
		'has_archive'          => true,
	) );
} );

• Create some new posts with this new type.
• Visit your: domain.com/jjj/ where 'jjj' is the assumed archive slug
• Shrink your browser width to trigger the mobile responsiveness
• Watch the faux-calendar content disappear

In this imaginary scenario, an events plugin with an archive of events just lost all of its content because of an overly aggressive CSS rule. If the intent is to simplify the blog view by hiding the content of each post, we should target the blog view explicitly and keep other plugins out of harms way.

[MikeLittle]

updated patch see comment

[MikeLittle]

Investigating this as part of UK WP Contributors day, this patch does not seem to work. Codex documentation ​http://codex.wordpress.org/is_post_type_archive indicates is_post_type_archive() will return false for anything other than a custom post type.
A better solution is to test the return from get_query_var( 'post_type' ). Attached patch (27301.2.patch) uses this method.
This also retains JJJ's case, i.e. it doesn't apply the class to custom post types.

(Thanks to help from 1st time contribs Dave Pullig, Rhys Wynne, Paul Riley)

[lancewillett]

A CSS-only approach

[lancewillett]

In 27587:

Twenty Fourteen: make sure we only hide post content on small screens for default post types: post and page. Fixes #27031.

[johnjamesjacoby]

Replying to lancewillett:

In 27587:

Twenty Fourteen: make sure we only hide post content on small screens for default post types: post and page. Fixes #27031.

This CSS-only approach does not fix shortcodes in page content; they will still have their content hidden. This is a common use-case; many plugins rely on shortcodes to output their unique functionality theme-side in pages, (bbPress specifically, in my case.)

[lancewillett]

Replying to johnjamesjacoby:

This CSS-only approach does not fix shortcodes in page content

Do you mean a CPT or a "page" post type? The PHP fix would also continue mean hiding entry-summary and entry-content containers on "post" and "page" post types, so even there using a shortcode in a page or post (not a CPT) would be hidden.