WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#11320 closed enhancement (invalid)

Feed Autodiscovery Missing?!

Reported by: miqrogroove Owned by:
Milestone: Priority: low
Severity: minor Version: 2.8
Component: Feeds Keywords:
Focuses: Cc:

Description

I was just informed by a Technorati staff member that their new blog bot ignores all blogs that are missing something like this in the HTML:

<link rel="alternate" type="application/rss+xml" 
  title="RSS Feed for my website" 
  href="/rss/" />

When I look in the default theme, the only LINK elements are for the stylesheet and pingback addresses. That's what I copied for my site as well, and thus the problem.

If WordPress is supposed to put those in the wp_head() output, it's not doing that. Yikes. *freaking out slightly*

Attachments (2)

header.php.patch (654 bytes) - added by miqrogroove 6 years ago.
header.php.2.patch (874 bytes) - added by miqrogroove 6 years ago.
Unhide Feed Discovery!

Download all attachments as: .zip

Change History (18)

@miqrogroove6 years ago

comment:1 @miqrogroove6 years ago

  • Keywords has-patch added

If it would look better, I could also add

 if ( '1' == get_option('blog_public') )

comment:2 @miqrogroove6 years ago

Also please excuse my lack of omniscience. Currently reading [10377]

comment:3 @miqrogroove6 years ago

  • Keywords has-patch removed
  • Severity changed from blocker to critical

Okay now I'm seeing automatic_feed_links(), and it's totally undocumented at http://codex.wordpress.org/Version_2.8

This is really very messy. Taking something out of headers.php and not putting it inside of wp_head() by default is not cool!

@miqrogroove6 years ago

Unhide Feed Discovery!

comment:4 follow-up: @dd326 years ago

IMO: That function call should stay in the functions.php file.

However, A PHP comment should be added that automatic_feed_links() needs to be called.

comment:5 in reply to: ↑ 4 @scribu6 years ago

  • Milestone 2.9 deleted
  • Resolution set to invalid
  • Status changed from new to closed

If you take a look at the generated code in the default theme, you will see the <link rel="alternate"> tag.

Also, I agree with dd32 that automatic_feed_links() should stay where it is.

comment:6 @nacin6 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from 2.8.4 to 2.9

And in turn, I agree with dd32 that a PHP comment should be added.

comment:7 @miqrogroove6 years ago

Thank you nacin. Obviously the code "works", but there has been an awesome documentation failure here.

comment:8 @miqrogroove6 years ago

  • Milestone set to 2.9
  • Version changed from 2.9 to 2.8

comment:9 @scribu6 years ago

Well, where's the patch, then? :-)

comment:10 @nacin6 years ago

I keep thinking that maybe it should be a default action to add feed links. It isn't really simplifying anything when you need to add automatic_feed_links() to functions.php.

This would align automatic_feed_links with any number of other actions tied to wp_head. Either it wasn't thought out when implemented or I'm missing something. The other actions tied to wp_head in default-filters.php:

wp_enqueue_scripts
feed_links_extra
rsd_link
wlwmanifest_link
index_rel_link
parent_post_rel_link
start_post_rel_link
adjacent_posts_rel_link
locale_stylesheet
noindex
wp_print_styles
wp_print_head_scripts
wp_generator
rel_canonical

If we go the comment route:
<?php // automatic_feed_links() called within functions.php to hook into wp_head and add feed links. ?>

That said, I really do think this should become a default hook.

comment:11 @nacin6 years ago

Related: #8878.

Adding add_action( 'wp_head', 'feed_links' ) as a default hook would open up issues where, unless people either add automatic_feed_links(false) to their theme or remove hard-coded feeds, they'll be referencing their feeds twice.

I think #8878 added an interesting twist to this, by introducing documentation and convention issues that can only be fixed by creating compatibility issues.

Crazy idea not likely to fly: Any properly coded theme (prior to the introduction of automatic_feed_links) called bloginfo('*_url') for the feed, which in turn called feed_links(*).

We can add feed_links as a default filter, then remove the default filter in feed_links. Thus, by the time you get to wp_head, if the theme already used proper feed links, then feed_links isn't called again via the default filter.

Thoughts? Sounds less crazy when I think about it more -- as long as it is documented.

comment:12 @miqrogroove6 years ago

There's no way to prevent people from doubling-up those headers in their own themes. For me, this whole mess started when I realized wp_head() was doing all sorts of new stuff that was duplicating what I had hard coded in header.php from 2.7, and I went on a deleting rampage using the default header.php as a guide.

The two simplest choices at this point are to change header.php or finish [10377] by hooking up wp_head(). Either way, the 2.9 release notes need to catch this kind of stuff.

comment:13 follow-up: @miqrogroove6 years ago

And while I'm thinking of it, if RSS headers require a separate function call, then why the hell doesn't that function output anything? I say, either hook up wp_head() properly, or put the function call back in header.php and make it do something other than hook back to wp_head().

comment:14 in reply to: ↑ 13 @Viper007Bond6 years ago

Replying to miqrogroove:

And while I'm thinking of it, if RSS headers require a separate function call, then why the hell doesn't that function output anything?

Why would it output something? It's registering actions.

If instead of registering actions, it outputted the actual <links> then there would be no way for plugins to stop it.

Trust me, a lot of thought and testing went into the automatic_feed_links() function when I wrote it so that it'd be easy to use while more importantly be backwards compatible.

And -1 to automatically determining if the theme has hard coded links or not. What if a blog had it's RSS link be to FeedBurner and not have bloginfo() be involved at all? There's many possibilities where such code would fail.

Stuff like that is never 100% reliable. Theme developers just need to stop being lazy. :P

comment:15 @lloydbudd6 years ago

  • Milestone 2.9 deleted
  • Priority changed from high to low
  • Severity changed from critical to minor
  • Type changed from defect (bug) to enhancement

comment:16 @miqrogroove6 years ago

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

milestone 2.9 deleted

Another ticket that's going nowhere fast. Let's forget about it. I can never bring myself to care about punted tickets.

Note: See TracTickets for help on using tickets.