Make WordPress Core

Opened 12 years ago

Closed 10 years ago

#21658 closed defect (bug) (fixed)

Meaningless adjacent post links for pages

Reported by: mdgl's profile mdgl Owned by: sergeybiryukov's profile SergeyBiryukov
Milestone: 4.0 Priority: normal
Severity: normal Version: 3.4.1
Component: Posts, Post Types Keywords: has-patch
Focuses: template Cc:


In WP 3.3 we removed a number of obsolete <link> elements from the page header leaving just those with rel="next" and rel="prev" generated by function adjacent_post_rel_link_wp_head() in file wp-includes/link-template.php [see #18128].

This change brings the function of these links into sharper relief and raises several concerns. Presently, they are generated only for singular pages/posts that are not attachments.

Such links make some kind of sense for ordinary posts, because these can be considered to be part of an ordered collection where the next/previous relationship is meaningful. It may also make sense for custom post types, depending on the use to which they are being put.

For pages, however the links generated refer to the next/previous pages as they happen to be stored in the WP database and these are unlikely to have any meaningful relation to the originating page.

Others have reported performance and other problems with browsers such as Firefox that use these links to prefetch content [see #12603, #14382 and #19018].

You can see their point! If I'm viewing page "about" what are the chances that I will next want to view the page "contact" just because this happens to have the next sequential ID in the WordPress database?

At the very least, I believe that these links should not be generated for pages. Better still would be to follow Google's advice [see #18672] and use these just for paginated content (i.e. individual posts/pages [with <!--nextpage-->] or archives [including blog home]). Some potential patch code is available against #18660 which raised a similar issue. Links between adjacent posts can be left to the usual navigation elements within the page body.

Attachments (2)

bug-21658.diff (424 bytes) - added by alexander.rohmann 10 years ago.
Fix for #21658
21658.diff (407 bytes) - added by kovshenin 10 years ago.

Download all attachments as: .zip

Change History (12)

#1 @nacin
10 years ago

  • Component changed from General to Template
  • Keywords needs-patch added

I agree these should not be generated for pages.

#2 @nacin
10 years ago

  • Milestone changed from Awaiting Review to Future Release

#3 @nacin
10 years ago

  • Component changed from Template to Posts, Post Types
  • Focuses template added

#4 @alexander.rohmann
10 years ago

  • Keywords has-patch added; needs-patch removed

Added an is_page condition.

 * Display relational links for the posts adjacent to the current post for single post pages.
 * This is meant to be attached to actions like 'wp_head'. Do not call this directly in plugins or theme templates.
 * @since 3.0.0
function adjacent_posts_rel_link_wp_head() {
	if ( !is_singular() || is_attachment() || is_page() )

#5 follow-up: @SergeyBiryukov
10 years ago

  • Milestone changed from Future Release to 4.0

! is_singular() || is_attachment() || is_page() is equivalent to ! is_single().

#6 @SergeyBiryukov
10 years ago

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

In 28641:

Adjacent links in wp_head() should only be generated for posts, not pages.

props alexander.rohmann.
fixes #21658.

#7 in reply to: ↑ 5 @nacin
10 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Replying to SergeyBiryukov:

! is_singular() || is_attachment() || is_page() is equivalent to ! is_single().

Actually, it's not. is_single() applies to all custom post types, including posts, but not including pages, and including attachments in some situations.

is_singular is equivalent to is_single || is_page. It's technically defined as is_attachment but is_attachment is always paired with is_single XOR is_page.

Essentially, this commit has now added these for attachments while removed them from pages.

#8 @kitchin
10 years ago

If we drill down to the level of $post rather than query, we can use
$post->post_type == 'post'
or more generally
post_type_supports( $post->post_type, 'trackbacks' )
or a new support feature 'rel_links'
post_type_supports( $post->post_type, 'rel_links' )

Themes that want more control can replace adjacent_posts_rel_link_wp_head() with a conditional call to adjacent_posts_rel_link();

If we're staying at the query level rather than getting $post, seems we need yet another is_ function and property, for clarity at least.

10 years ago

#9 @kovshenin
10 years ago

Add the is_attachment() check back in 21658.diff.

#10 @SergeyBiryukov
10 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 28770:

Don't generate adjacent links in wp_head() for attachments.

props kovshenin.
fixes #21658.

Note: See TracTickets for help on using tickets.