WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#27031 closed defect (bug) (fixed)

Twenty Fourteen theme assumes all archive pages are list views

Reported by: netweb Owned by: lancewillett
Milestone: 3.9 Priority: normal
Severity: normal Version: 3.8.1
Component: Bundled Theme Keywords: has-patch
Focuses: Cc:

Description

@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.

Attachments (3)

27031.patch (485 bytes) - added by Frank Klein 7 years ago.
27031.2.patch (476 bytes) - added by MikeLittle 7 years ago.
updated patch see comment
27031.3.patch (683 bytes) - added by lancewillett 7 years ago.
A CSS-only approach

Download all attachments as: .zip

Change History (14)

@Frank Klein
7 years ago

#1 @Frank Klein
7 years ago

  • Keywords has-patch needs-testing added

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

#2 @lancewillett
7 years ago

  • Milestone changed from Awaiting Review to 3.9

This ticket was mentioned in IRC in #wordpress-themes by lancewillett. View the logs.


7 years ago

#4 @obenland
7 years ago

  • Keywords ui-feedback added

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?

#5 @lancewillett
7 years ago

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

#6 @johnjamesjacoby
7 years ago

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.

Last edited 7 years ago by johnjamesjacoby (previous) (diff)

@MikeLittle
7 years ago

updated patch see comment

#7 @MikeLittle
7 years ago

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)

Last edited 7 years ago by MikeLittle (previous) (diff)

This ticket was mentioned in IRC in #wordpress-themes by lancewillett. View the logs.


7 years ago

@lancewillett
7 years ago

A CSS-only approach

#9 follow-up: @lancewillett
7 years ago

  • Owner set to lancewillett
  • Resolution set to fixed
  • Status changed from new to closed

In 27587:

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

#10 in reply to: ↑ 9 ; follow-up: @johnjamesjacoby
7 years ago

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.)

#11 in reply to: ↑ 10 @lancewillett
7 years ago

  • Keywords needs-testing ui-feedback removed

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.

Note: See TracTickets for help on using tickets.