Add Rel-Feed Link to Header

[dshanske]

When the front page is not the posts page, proposing that Core add a link in the header to the actual posts page, using the rel=feed designator.

​https://blog.whatwg.org/feed-autodiscovery

Example

<link rel="feed" type="text/html" href="/posts" title="Posts Page" />

This would allow a system to figure out where the posts page is.

[desrosj]

Thanks for this, @dshanske.

This seems fine to add, but I'd like to do a bit more reading. Is there any more up to date documentation? Everything I am finding is really old.

I'll mark as good-first-bug.

[dshanske]

​https://indieweb.org/rel-feed Does this work?

[cameronamcintyre]

Added new action to wp_head that checks the current page status and adds the link element if required.

[bogerekanzu]

Added the unit tests for the Add Rel link to feed in the header

[dshanske]

Shouldn't be closed till it is merged.

[garrett-eclipse]

Added @since to docblock and fixed the Unit Tests as they were failing.

[garrett-eclipse]

Thanks for the patch @bogerekanzu I've uploaded 46227.3.diff to fix the Unit Tests as they were failing.

I also updated the docblock for rel_feed_for_posts to include the @since and a reference to wp_head.

In the Unit Tests the dom functions were failing and some CS issues addressed as well.

Please take a look and test.
Cheers

[SergeyBiryukov]

46227.3.diff​ has some unrelated changes from #44878, needs a refresh.

[chetan200891]

Refreshed patch.

[audrasjb]

Hey there, thanks for the patch :-)

Shouldn't we check if there is something returned by get_option( 'page_for_posts' ); before displaying any bit of HTML code?

[adhitya03]

Move get_option( 'page_for_posts' ) into the "if"

[adhitya03]

Correcting the indentation, sorry

[adhitya03]

move get_option( 'page_for_posts' ); into the condition where it is used and ensure that get_option( 'page_for_posts' ); will always return the ID of the static page because it will run only if the posts page use static page.

[audrasjb]

Hmm, we also need to check if a blog page has been defined. That was the idea of my previous comment.

[adhitya03]

If users do not select any static page to display the posts page.

[adhitya03]

Hi @audrasjb

I am sorry if I hard to understand your point, I this is my first contribution to the core. I have updated the patch.

[garrett-eclipse]

Reintroduce Unit Tests from 46227.4.diff that got lost. Note: These probably shouldn't live in document-title.php though.

[garrett-eclipse]

Hello All, Thank you for the patches to date on this.

I took a moment to read through the reference material (​https://blog.whatwg.org/feed-autodiscovery) and feel we're going in the wrong direction here.

The 'feed' relationship is to indicate that the reference document is a syndication feed NOT a page.
"we have introduced a new feed relationship which indicates that the referenced document is a syndication feed. This now allows you to link to several different feeds containing different content which are not necessarily alternate versions of the page."

In WP feed <link>'s are introduced in several places with the alternate relationship attribute in many cases the issue with them is that they aren't 'necessarily alternate representations of the page' which is where the feed relationship comes in as it 'allows you to link to several different feeds containing different content which are not necessarily alternate versions of the page.'

"The feed keyword can also be used in combination with alternate to say that it is specifically the feed for the current document."

So to my understanding the existing feed <link>s should be updated to use 'rel="feed"' with the exception of the blog page itself which should use 'rel="feed alternate"' as the feed is actually an alternate representation of the page.

The existing locations which should be looked at;
Ones I feel should just be 'rel="feed"' unless they reside on the blog page;

• Blog RSS - ​https://github.com/WordPress/WordPress/blob/master/wp-includes/feed-atom-comments.php#L57
• Feed Link - ​https://github.com/WordPress/WordPress/blob/master/wp-includes/general-template.php#L2835
• Comment Feed Link - ​https://github.com/WordPress/WordPress/blob/master/wp-includes/general-template.php#L2846
• Multi-Feed Link - ​https://github.com/WordPress/WordPress/blob/master/wp-includes/general-template.php#L2932

Ones I feel should be 'rel="feed alternate"';

• Comment Feed - ​https://github.com/WordPress/WordPress/blob/master/wp-includes/feed-atom-comments.php#L49
• Search Feed - ​https://github.com/WordPress/WordPress/blob/master/wp-includes/feed-atom-comments.php#L53
• Comment Link - ​https://github.com/WordPress/WordPress/blob/master/wp-includes/feed-atom-comments.php#L91
• Atom Feed Link - ​https://github.com/WordPress/WordPress/blob/master/wp-includes/feed-atom.php#L35
• Atom Feed Link - ​https://github.com/WordPress/WordPress/blob/master/wp-includes/feed-atom.php#L67

In no way am I a RSS/Atom Guru so would love some insight from a more experienced dev, @dshanske any thoughts?
*I very well may be wrong in which case sorry for the scare.

As well this is an enhancement and not a bug so shouldn't be on a minor milestone as it's not a reversion introduced in 5.2 so moving into 5.3 for further discussion.

I apologize to those who already submitted a patch as I had done, I should have delved deeper initially.

*Note: All quoted text comes from the reference material - ​https://blog.whatwg.org/feed-autodiscovery

[dshanske]

Your statement is correct. However, I only scoped this ticket to adding the link for rel-feed when the front page of the site is not the posts page, as this adds a defined benefit we don't have now...allowing for feed discovery in a not unpopular case.

Suggesting the second issue...adding it to rel-alternate situations, should be a separate ticket.

[garrett-eclipse]

Thanks @dshanske I appreciate you feeding back there.

So I understand a bit more the issue here and make sure I'm on the same page...

In a default WP install with a Homepage, which isn't the posts page, that homepage already has a link to the feed - <link rel="alternate" type="application/rss+xml" title="Rel Feed » Feed" href="http://rel-feed.local/feed/">. This is a rel="alternate" link but should instead be updated to a rel="feed" throughout the site except when it's on the posts page where it should be a rel="feed alternate".

So this request would be to take this line - ​https://github.com/WordPress/WordPress/blob/master/wp-includes/general-template.php#L2835
And update it as follows;
echo '<link rel="feed' . ( is_home() ? ' alternate' : '' ) . '" type="' . feed_content_type() . '" title="' . esc_attr( sprintf( $args['feedtitle'], get_bloginfo( 'name' ), $args['separator'] ) ) . '" href="' . esc_url( get_feed_link() ) . "\" />\n";
*Which changes that feed link from alternate to feed for all pages and then appends alternate if it's on the actual blog page.

Am I correct in that assumption? Just want to be sure before heading down that path.
Thanks

[dshanske]

Actually no. I was proposing a link to the html feed page, not the rss one.

[dshanske]

You are correct about the application of rel-feed otherwise, by the way. Although my concern in removing the alternate is that it has been there for so long that it would break RSS readers expecting it.

[johnbillion]

46227.8.diff​ is missing the call to add_action as seen in 46227.7.diff​ .

[davidbaumwald]

This enhancement needs a direction an implementation. With version 5.3 Beta 1 releasing tomorrow, this is being moved to ‘Future Release’.

[adhitya03]

1. Add missing add_action in 46227.8.diff
2. Delete function rel_feed_for_posts() that shows three times in 46227.8.diff

[dshanske]

I think the latest iteration accomplishes the goal of linking to the posts page explicitly when the home page is not also the posts page. This has been a significant problem in finding where you can get a HTML page with all the posts on a site.

[davidbaumwald]

This ticket still needs a review, and with 5.4 Beta 1 landing tomorrow, this is being moved to Future Release. If any maintainer or committer feels this can be included in 5.4 or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

[davidbaumwald]

With 5.5 Beta 1 releasing tomorrow, this is being moved to Future Release. If any maintainer or committer feels this can be resolved in to, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

[rebasaurus]

Updating @since to reflect 5.6

[hellofromTonya]

5.6 beta 1 is in less than 2 weeks. @stevenkword Is this ticket on your radar to land in the 5.6 milestone? If yes, what's next to move it forward? If no, is it okay to punt?

[audrasjb]

patch refreshed against trunk

[audrasjb]

@rebasaurus thanks for the refresh! Though we prefer to use "5.6.0" than "5.6" :)

[dshanske]

Again, summarizing for a dev-note. "In WordPress 5.6, when the posts page of your site is not the front page, a non-visible link will be added to the page, marked as rel='feed', type="text/html' to allow the posts page to be found."

[davidbaumwald]

With 5.6 Beta 1 releasing tomorrow and this being a low priority, this is being moved to Future Release. If any maintainer or committer feels this can be resolved in time, or wishes to assume ownership during a specific cycle, feel free to update the milestone accordingly.

[audrasjb]

Patch refreshed for WP 5.7

[audrasjb]

@johnbillion patch refreshed against trunk :)

[johnbillion]

This all looks good, however the test appears to be useless. The document HTML is loaded from the $test_link_str within the test, not from the page that's loaded as a result of calling $this->go_to('/').

In order to test this properly:

• Load the actual HTML from the request. I don't believe that this is done anywhere in core's tests currently, as go_to() doesn't render the template. For this a new test method would be needed which returns the complete template output. ​Here's an example from one of my plugins.
• Add an unhappy path test to ensure the link does not get output when the front page is also the page for posts.

Also, cc @jonoaldersonwp for an SEO sanity check on this if you don't mind?

[audrasjb]

As per today's bug scrub, let's move this ticket to Future release so it can be handled in time for WP 5.8. If we have a patch and unit tests in time for 5.7 beta 1, please feel free to move it back to milestone 5.7.