Stoat - Where?

The Case For Feeds As Classes

If you were expecting something on life in Japan here, sorry to bore you! Normal service will resume shortly, I promise).

A few days ago, I made a suggestion to the WordPress Hackers lists to restructure WP’s feed handling into a class-based system. There has been a lot of discussion recently on the list of where to go with feeds, with people arguing both for a complete overhaul and for minor tweaks. There was also quite a debate on whether to drop support for some older feed types to reduce maintenance.

My suggestion was greeted with deafening silence, largely in part because I totally misconstrued Owen Winkler’s meaning in the original thread, resulting in a post wildly out of context, but also maybe because many people don’t see the need to rewrite what works now. Either that, or they just totally disagreed and were too polite to say so.

I was still interested, however, so I spent an hour or two putting together a basic prototype for a class-based feed architecture. You can find this file here. You should note that the code is definitely a prototype, is far from complete and hasn’t actually even been parsed. The framework is what is important here, not the details at the moment, especially if this is shot down in short order. But anyway, following is a rationale for why I think this is a good route to go:

• Centralised Data Source: At the moment, each feed gets the data it requires as it is being built. This means four duplications of data-grabbing code that need not happen. A centralised source can hold all the information needed by all flavours of feeds, reducing maintenance to a single point, which is easily updateable.
• Cacheable: With a centralised data source we can also cache easily and use that to build the feeds instead of making lots of function calls and database accesses each time a feed is required. This cached data source can be updated whenever a post or comment occurs, asynchronously, so that the user is not affected.
• Extensible: This structure enables plugins to add new feed types very easily, by simply creating a new class. This would allow for the addition of feed types that are standardised while WordPress is in a development cycle. A recent example of this is Atom 1.0, for which support still does not exist and currently could only be added by altering the core. The same ability to add feed types also allows us to remove outdated types from the core if we wanted and offload them into plugins.
• Pluggable: At the moment, with the available action hooks, you can add to feeds, but you can’t modify or remove data. Allowing access to the data source allows us to make data alterations before the feed is written. These could either be pre-processed and cached, or on-the-fly as the feed is about to be constructed. Separating the feed head, body and footer allows us to filter information at any point in the feed for maximum flexibility.
• Simplification: With a list of defined feed types and classes, we can automatically generate the correct type of feed using PHP’s dynamic binding to the right class. A call to $wpfeed->output() gets the job done, for all kinds of feeds, even plugin-defined ones. We can use the defined feeds array to generate rewrite rules simply too, so that we don’t have to add them by hand each time.
• Backwards Compatibility: Recent changes to WordPress, dubbed the Changeset of Destruction will break lots of plugins, so I’m not sure if this is even an issue, but it would probably be possible to maintain backwards compatibility with existing action hooks by output buffering their actions and adding them to the feed.
  Anyway, there are probably reasons I haven’t thought of why this is all viable, so please feel free to let me know why this is all a bad idea. The one point I would argue with is that it’s fine as it it. I really think this area of WordPress could do with a bit of a workover, even if this isn’t the solution.