Make WordPress Core

Opened 8 years ago

Closed 8 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:


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 8 years ago.
header.php.2.patch (874 bytes) - added by miqrogroove 8 years ago.
Unhide Feed Discovery!

Download all attachments as: .zip

Change History (18)

#1 @miqrogroove
8 years ago

  • Keywords has-patch added

If it would look better, I could also add

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

#2 @miqrogroove
8 years ago

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

#3 @miqrogroove
8 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!

8 years ago

Unhide Feed Discovery!

#4 follow-up: @dd32
8 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.

#5 in reply to: ↑ 4 @scribu
8 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.

#6 @nacin
8 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.

#7 @miqrogroove
8 years ago

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

#8 @miqrogroove
8 years ago

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

#9 @scribu
8 years ago

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

#10 @nacin
8 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.

#11 @nacin
8 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.

#12 @miqrogroove
8 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.

#13 follow-up: @miqrogroove
8 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().

#14 in reply to: ↑ 13 @Viper007Bond
8 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

#15 @lloydbudd
8 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

#16 @miqrogroove
8 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.