Meaningless adjacent post links for pages

[mdgl]

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.

[nacin]

I agree these should not be generated for pages.

[alexander.rohmann]

Fix for #21658

[alexander.rohmann]

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() )
		return;
	adjacent_posts_rel_link();
}

[SergeyBiryukov]

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

[SergeyBiryukov]

In 28641:

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

props alexander.rohmann.
fixes #21658.

[nacin]

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.

[kitchin]

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.

[kovshenin]

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

[SergeyBiryukov]

In 28770:

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

props kovshenin.
fixes #21658.