Implement a JSON feed using rssjs.org spec

[nacin]

We've talked for years about a simple /feed/json/ endpoint. It usually gets bogged down immediately by everyone realizing we don't know how we should expose that data. There isn't a spec or anything like that.

​http://rssjs.org/ was a proposal by Dave Winer last year to create a JSON-based RSS pseudo-standard. Essentially: Let's use exactly what RSS 2.0 exposes, in the way that it exposes it, but in JSON form.

I'm sure someone will mention rmccue & co's JSON API, but they are not mutually exclusive in the slightest. It would be super cool if every WordPress site had a consumable JSON feed.

I think /feed/rssjs/ might make more sense than /feed/json/. It hasn't taken off as a standard, so maybe not. (Or, we could be the ones to drive its adoption.)

[rmccue]

+1 on JSON-based feeds. It's something we should try and push heavily for, but it will need to be properly specified. XML is actually a better fit for this type of data, since the attribute + data model is needed in a few places, but a properly designed JSON feed could work around that at the same time. I'm pretty fond of killing XML, especially RSS.

-1 on Winer's "specification". Apart from it not being a proper specification (and Dave Winer is hardly the best at writing those either), it's just RSS as a JSON object. Something like this should be designed, lest we end up with a RSS 0.9/0.91/0.92/1.0/2.0 (all being mutually incompatible) situation again.

Personally, I'd base something off the Atom specifications, but with slimming down and reworking for JSON constraints.

(Also worth noting that as part of the JSON API stuff, I'd like to add a JSON rewrite endpoint, so avoiding naming anything until we've formed a roadmap would be nice.)

[pento]

To be fair, rss.js is the same as RSS 2.0, which hasn't been superseded since its release 11 years ago, and isn't likely to change any time soon. It's a naming scheme that everyone is familiar with, and we know that it'll support everything /feed/ already does.

If we do go with rss.js, I'd be inclined to call it /feed/json/, as it's a JSON-ified version of /feed/.

[rmccue]

Replying to pento:

To be fair, rss.js is the same as RSS 2.0, which hasn't been superseded since its release 11 years ago, and isn't likely to change any time soon. It's a naming scheme that everyone is familiar with, and we know that it'll support everything /feed/ already does.

The reason I don't like it is exactly because RSS 2.0 has changed since its release, without bumping the version. While changes can seem superficial, they can still affect parsing. One of the reasons SimplePie has so much damn code is because of changes like this.

Apart from this, there's no actual specification here, so parsing it would be near impossible. For example, is the /rss/channel/item/*/title field HTML or text? Much like RSS, probably both, with no reliable indication.

If we do go with rss.js, I'd be inclined to call it /feed/json/, as it's a JSON-ified version of /feed/.

I'm happy with /feed/json/ being used, but it should be based on a spec (or at least spec-like document), not a proposal with just an example as the implementation.

[pento]

Having played around rss.js a bit, I can confirm that it's terrible. The primary problems are:

• As @rmccue mentioned, the spec for RSS 2.0 exists, but it isn't good
• JSON has no standard method for extensions, so there's no equivalent of the namespaces we use in the RSS2 feed

Next experiment: ​Activity Streams! I've written a sample plugin based on ​this plugin, it's showing significantly more potential.

​There's a repo, too.

[rmccue]

Replying to pento:

• JSON has no standard method for extensions, so there's no equivalent of the namespaces we use in the RSS2 feed

Sidenote: not really an issue, everyone just ignores namespaces in RSS anyway (the namespace for RSS itself is actually not defined).

Next experiment: ​Activity Streams! I've written a sample plugin based on ​this plugin, it's showing significantly more potential.

​There's a repo, too.

I'd be happy with Activity Streams, since it seems like there's actual work behind it. We should definitely skip to the ​2.0 draft rather than 1.0 though.

(Also, be careful with your implementation of JSONP there, callbacks need to be ​validated. JSON_PRETTY_PRINT also isn't available on 5.2.x.)

[pento]

Replying to rmccue:

(Also, be careful with your implementation of JSONP there, callbacks need to be ​validated. JSON_PRETTY_PRINT also isn't available on 5.2.x.)

Thanks for pointing them out. Fixed. :)

I'd be happy with Activity Streams, since it seems like there's actual work behind it. We should definitely skip to the ​2.0 draft rather than 1.0 though.

I had a look at the 2.0 draft earlier, but I'm not wild about going with it. It's not yet finished, and they're currently discussing creating a W3C Activity Streams WG, which would delay and probably change the draft further. I'm all for implementing 2.0 once it's finished, but implementing a draft is just asking for trouble.

[pento]

​7B is starting to take shape. I've decided to make /feeds/json/ a generic endpoint that we can change in the future, kind of like how /feeds/ is currently rss2. With that in place, we can more easily upgrade to Activity Streams 2 in the future, for example. The various JSON implementations are now sub-endpoints of /feeds/json/. For example, Activity Streams 1.0 is /feeds/json/as1/.

For more some coding style questions, any suggestion for how much this needs to change to go into core? In particular:

• feed-as1.php relies on filters in a lot of places where other feeds use actions. This is primarily because I'm generating the entire JSON object before json_encode()-ing it, instead of printing the JSON as it's generated.
• There's no add_json_feed() equivalent of add_feed(). Instead, I created a json_feeds filter that a new feed provider can hook into.

[pento]

I added a basic implementation of rss.js to ​7B - I haven't used any of the extra namespaces our RSS2 feed uses, because the rss.js page doesn't define how namespacing should be done.

[pento]

attachment:25639.diff​​

Here's my first pass at a core patch that adds AS1 and rss.js feeds.

Functionally, there are two major changes from 7B.

• The addition of comment feeds.

• The feed endpoints are now /feed/as1/ and /feed/rssjs/, there's no /feed/json/. The primary reason for this is that JSON feeds don't have a header for identifying the type/version of the feed, in the way that XML-based feeds do. With that in mind, it seems a bit confusing to have a generic /feed/json/ endpoint, if the consumer can't easily identify the feed received.

Feedback welcome. :-)

[pento]

attachment:25639.2.diff​​

Adds the 'callback' and 'pretty' query vars.

[pfefferle]

The generator in the as1 version seems to be wrong.

'provider' => (object)array( 
   'url' => get_feed_link( 'url' ) 
)

The result is an URL like that "​http://devblog.local/feed/url/"

[rmccue]

Replying to pento:

Feedback welcome. :-)

Patches themselves aside, is there any reason these should both be in core? AS1 seems fairly standardised and something that we could add, but rss.js feels more like plugin territory to me. That said, even AS1 feels like it's wavering on the edge of plugin territory to me. I don't know that there's any clients for either AS1 or rss.js, so I'm not sure what benefit we get.

[pfefferle]

Replying to rmccue:

I don't know that there's any clients for either AS1 or rss.js, so I'm not sure what benefit we get.

It's kind of a Henn and Egg problem. If there are no AS or rss.js implementions around, noone would write clients. I think it is a good idea to provide a JSON-Feed besides the XML versions (to move with the times) and why not using well defined ones?

[pento]

Replying to rmccue:

is there any reason these should both be in core?

I've provided both as options, but I'd be happy to cut it down to one. I not convinced that the rss.js spec is mature enough for us to lock it into permanent use. The major downside of AS1 is that it's more verbose than rss.js, but I don't think overly so. It has a well defined spec, and some traction in the social network world.

Replying to pfefferle:

It's kind of a Henn and Egg problem. If there are no AS or rss.js implementions around, noone would write clients. I think it is a good idea to provide a JSON-Feed besides the XML versions (to move with the times) and why not using well defined ones?

Agreed - by providing either of these, it'll give a significant boost to adoption. JSON is easier to work with than XML, so I expect people will want to use it when it's available.

[rmccue]

Replying to pento:

I've provided both as options, but I'd be happy to cut it down to one. I not convinced that the rss.js spec is mature enough for us to lock it into permanent use. The major downside of AS1 is that it's more verbose than rss.js, but I don't think overly so. It has a well defined spec, and some traction in the social network world.

If we go for anything here, then it should be AS1, so... +0 on AS1, -1 on RSS.js.

[matt]

Atom! Haven't heard that one in a while. :) Regardless, let's try to keep personal swipes ("so-and-so person is hardly the best") out of Trac.

Whatever you think of RSS 2 as a standard, the way WP produces feeds is probably the most widely understood and tested feed format in the world. It's a "good standard" in that you can look at what's in our database, look at the code that produces the feed, and parse it in a deterministic way. The "problem" with RSS produced by lots of different and non-transparent code may be large, but for WP it's largely non-existent.

The main point of introducing a JSON style feed would be to make it easier for people to consume WP-generated content in a programatic way, hopefully leveraging code they've already written. Under that assumption it seems the lowest-friction thing to do for potential users of this feed would be to keep the content, the variables if you will, exactly the same as our RSS2 implementation, and just change the wrapper.

Imagine switching out the library you use for grabbing a feed from an expensive XML-based one to a lightweight JSON one, maybe changing a variable name or two for things that are namespaced (which doesn't make sense to try and duplicate, because there's no XML-style extensibility model we're trying to build in), and then the rest of your code runs exactly the same. With a callback you could even do it entirely client-side and cross-domain.

This is a green field thing, something we want to do because we think people will use it in interesting ways, not because there are existing implementations or demand. After launch if this picks up traction I could see us doing an iteration on the format adding a field or two to ease make it easier for people writing code using these feeds, maybe adding a "redundant" date field in a format easier to natively parse in pure JS. I could also see us adding in an Activity Streams JS feed, but personally would rather wait until the working group finishes 2.0.

[pento]

Replying to matt:

The main point of introducing a JSON style feed would be to make it easier for people to consume WP-generated content in a programatic way, hopefully leveraging code they've already written. Under that assumption it seems the lowest-friction thing to do for potential users of this feed would be to keep the content, the variables if you will, exactly the same as our RSS2 implementation, and just change the wrapper.

I don't think this is a good reason to stick with RSS. It wouldn't be exactly the same code to handle the data coming from the JSON feed - for example, JSON doesn't encode HTML like the RSS feed has to. I think this also overestimates the time commitment in learning a new standard, both from a personal point of view (it takes a very small amount of time to read the AS1 spec and understand it), and from a global point of view (there are very few WordPress users who will need to learn this, so it's only a minor inconvenience on a global scale).

With regards to namespacing, there are currently several different proposals in the ​rss.js discussion thread about how to handle this. Implementing a particular method before a decision is made seems to be premature, in the same way implementing AS2 before the spec is finished would be.

This is a green field thing, something we want to do because we think people will use it in interesting ways, not because there are existing implementations or demand. After launch if this picks up traction I could see us doing an iteration on the format adding a field or two to ease make it easier for people writing code using these feeds, maybe adding a "redundant" date field in a format easier to natively parse in pure JS. I could also see us adding in an Activity Streams JS feed, but personally would rather wait until the working group finishes 2.0.

If this is a green field thing, why restrict ourselves to RSS? Surely we should choose the best-defined option, to give the developers who use it the most deterministic outcome, especially if they want to reuse code on reading JSON feeds from other services.

[markjaquith]

Fix a copy/paste error in .2

[markjaquith]

25639.3.diff​ fixes a copy/paste error in 25639.2.diff​ that was routing atom comment feeds to rssjs.

[markjaquith]

My thoughts:

1. The standard hasn't gotten much traction, and there seem to be some technical issues that are unresolved.
2. BUT: this can be experimental and prospective, much like our adoption of AtomPub (which fizzled). Further, these feed engines generally don't require a lot of effort to maintain. If it doesn't go anywhere, fine. If it does, we can help guide that direction as the first major adopter.
3. If we do adopt it, I agree with /rssjs/ over /json/.
4. I do like the general idea behind RSSJS. RSS 2.0, for it's shortcomings, is a known quantity. Even if it isn't the gold standard, it's a good stepping stone to one.

[aramzs]

Some thoughts regarding this ticket as someone working with a lot of feeds internal and external to WordPress. I'm in the process of working with the Center for History and New Media at George Mason Univerity ​to build a WP plugin that parses, interprets and broadcasts RSS feeds and is getting set up to deal with other types of feeds.

I think there are some important considerations that make this a worthwhile project to move forward on sooner rather than later, especially for WordPress.

Right now the field for RSS is wide open. Google Reader dropped out of existence, but nothing has filled the gap completely. This means there is a big opportunity for the content providers to push the next generation of tools to use new and better formats. No one is better placed to do so than WordPress, but that window may only be open for so long.

Further, RSS as a spec is chaotic, there are a lot of namespaces out there and no place that lists them all effectively, nor any platform that implements all, or even the most important ones. There are things that RSS needs to be better, more modern, and more useful to anyone who wants to use it in any way beyond some really basic reading.

I've been doing a lot of work with interpreting and generating RSS and ​we've been collecting feedback from the authors, academics and readers using our plugin. There's an opportunity here to extend beyond the basics of RSS2.0 and make it better.

It's even more attractive because the available processes that handle RSS and process it, even SimplePie (used in WP itself), are way heavier, cumbersome and difficult to extend that the same type of process through JSON. Parsing any large number of feeds is a huge load on any system and the biggest challenge for RSS reader tools.

Imagine switching out the library you use for grabbing a feed from an expensive XML-based one to a lightweight JSON one, maybe changing a variable name or two for things that are namespaced (which doesn't make sense to try and duplicate, because there's no XML-style extensibility model we're trying to build in), and then the rest of your code runs exactly the same. With a callback you could even do it entirely client-side and cross-domain.

This is exactly the opportunity. If you build it, they will come. All these fledgling RSS services would love a significantly lighter tool in JSON parsing, they just don't have anyone to use it on. If implemented, this would be the push to develop these tools, I know I would.

Beyond all that, this is WordPress's opportunity to push for additional things in the standard that are needed by users, but not supplied. Things that are available in a rainbow of disconnected protocols.

I think WordPress has a golden opportunity to push this forward right now and we should grab it.

A short list of items that would make standard RSS better:

• per-item authors (because think of how many blogs have guest authors or multiple users)
• per-item copyright/creative commons statements
• per-item original/syndication source (​Google does it, and it is needed, because aggregation is now standard blog behavior)
• OpenGraph data, especially featured image, for readers like Feedly or aggregation tools like PressForward, which have to manually walk through feed items looking for images, not an easy or lightweight behavior.
• a separation between taxonomies (tags, categories, or custom taxonomies defined on object)
• sharing data like that described in Activity feed.
• Abandoning 'description' and calling it what it is used for, an 'excerpt'
• Standard use of 'content'

[dd32]

I'm yet to see a json "standard" that could actually be used to properly expose a WordPress post / archive.

The RSS.JS spec isn't exactly a great idea to me, it bundles RSS up into a JSON object sure, but it doesn't actually make RSS any more useful, it's still a severely limited spec designed to push formatted HTML in chunks for a human to read, which is a huge comparison to JSON's primary use being machine-machine communication of data.
(It's also worth noting that the RSS.JS implementation on this ticket supports less than our RSS2 feed, and doesn't expose enclosures)

The AS1 spec is interesting, although not actually in use by many at all, it's verbosity and separating everything into individual fields makes it better than RSS.JS.
However AS1 doesn't seem like it conveys all of WordPress's data that would be useful for a JSON-based front-end, leaving it severely hamstrung.

As much as I like standards, I'm not sure either of these unadopted standards are the right thing for WordPress to support. If they were in use by other major CMS's or sites it would be much easier to say yes.

I would much prefer to see a WordPress-specific JSON endpoint that exposes the WordPress public post data in such a way that it's usable by both aggregators, JSON front ends, future editors, and, being generic enough that someone else could implement it for their own application and have it just work.
One potential option here is that we look at the WP-API project could bring and instead implement a read-only feed-like endpoint from it. It'd give us a heads start on integrating it with WordPress, a v0.1 some would say, allowing us to implement a JSON structure which is minimal and to the point of what data modern CMS's have.

The other option is simply going with AS1 and adding WordPress extensions to it, such as tags/categories/post type/post format (which AS1 has as a objectType but is a different set than what WordPress uses), which would make it more usable to most.

One of the things I fear about AS1/RSS.JS adoption is that they seem great from the standpoint of "Lets add a JSON format!", but when you actually look at the standard and think about how someone would use it, it seems like it'll come up just short of what someone needs for it to be useful - Ultimately the format being completely ignored when we too realise that and pull WP-API into core or build extensions to the specification so we can expose the data people need.

It's one thing to say "Build it and the applications will come", but it's another to say "Build it, and the application developers won't run into shortcomings and report bugs like that they can't see what Category something is posted in".

tl;dr: I'd much prefer to see someone actually try to use either of these formats, with a theme or stand alone application before we adopted one, it really seems like we'd be throwing a dart over our shoulder and hoping it hit the board..

[mbijon]

While AS1 and RSS.JS are fairly new, I think the lack of implementations may indicate some of the structural issues noted above are problematic. I'm not sure if the best option for solving these is extending or creating an alternative, but I have experience implementing JSON (actually JSON-P) data-sharing in several past work projects.

Also, if we did have a supported JSON/JSON-P format, content-sharing from WP to other CMSes would be more common. Our current RSS formats make it tough. I've seen several implementations try to do content-sharing using RSS and it's usually fragile, contentious code. With IT disliking the need to make changes to code like that, it may be enforcing "lock in" to build blogs into pay/enterprise CMSes.

When doing content-sharing from WP to another main or marketing site, my preferred method is a quick, custom view via @dphiffer's excellent JSON API plugin. The one downside though is that plugin is designed almost like an MVC framework and requires some controller and view setup every time. Having our own feed format would speed up getting the data and further prevent fragility. What that format is I'm not sure yet, but I think it needs to be (a) either a significant extension of AS1 or completion of the WP API, and (b) support JSON-P for frontend-only (JS) cross-domain access.

---

Use Cases

The most-common use of a JSON feed seems to be displaying corporate blog content in a main or marketing site's sidebar. This might look something like our widgets on the front end and be in a sidebar area. My preferred method after building many of these is to stay frontend-only & pull the data via JSON-P. This avoids any duplicate storage of content that might happen if you use the other CMS's backend tools, spares learning a 2nd CMS paradigm (and negotiating with someone in IT about new tables vs existing tables), and fits the Backbone model of frontend views.

Another use case for exposing all post, category, and meta data via JSON is for Backbone-based themes. I considered one of these a while back as a learning experiment, but put it aside when I realized it would need the JSON API plugin and not be very portable. Devin and Zack discussed the same thing on Twitter just yesterday too, ​https://twitter.com/devinsays/status/402570447742459904. Their resolution was the JSON API plugin. If we had our own JSON format it would save them a lot of time and (IMO) make Backbone-based themes tenable.

---

TL;DR
Both RSS.JS & AS1 currently fall short of our needs, but there is a definite demand for JSON & JSON-P feeds -- for cross-site content widgets and Backbone-based themes. A core or 'official' format would reduce the extra work of using a JSON API plugin and help push adoption.

[mbijon]

I chatted with @rmccue on Twitter & WP API already supports JSON-P, it just isn't in the docs yet. He also has some plans to extend WP API that he hasn't had time to writeup yet.

If he's that far effort-wise then coming up with a JSON format that works for WP (extended AS1 or new) and letting Ryan catch up on WP API might keep code & duplicate efforts down.

[matt]

I think people are getting lots of different goals, many which are good but not trying to be solved right now, mixed up in this ticket.

The goal is to provide what we already do in RSS in a non-XML format.

If people want to add or enhance what's already in the feeds to be more useful, let's do that in *all* our feeds, not just a new one, and make a new ticket and thread for it.

If people want programatic access to all of WP beyond what feeds currently provide, that falls more under the JSON API plugin / project.

[aaroncampbell]

I really like the idea of JSON over XML for things that will be machine-consumed. However, in this case I feel like there's a pretty marginal benefit. To me, it seems like a JSON feed is best left to be part of a JSON API.

[bpetty]

The goal mentioned (exactly as stated) is one fully inclusive goal outlined for the REST API. @mbijon is just trying to avoid duplicated effort. I don't think there's mixed up goals here, just very different approaches to the same goal.

Considering there really isn't a viable, solid, and stable standard to build this out on, we're in the same territory as the REST API, which is also not currently restricted to implementation of a specific standard. The REST API is already trying to be designed in a way that is conducive to frontend JavaScript REST consuming libraries, and there are already many generic JS libraries out there for this purpose. When you think about it, it's actually more portable than creating a duplicate "RSS" (without actually being RSS) JSON endpoint with one specific purpose that the REST API is already providing in a more generic way that's widely supported.

The REST API has already accomplished the single technical goal of this ticket (providing JSON instead of XML). Even if this results in a new endpoint, it still makes sense for it to be provided through the REST API. It would cover things like request rate limiting, CORS or JSONP as already mentioned, caching, pagination and other features (even when provided by plugins) in the future without extra duplicated efforts.

[aramzs]

Replying to bpetty:

The REST API has already accomplished the single technical goal of this ticket (providing JSON instead of XML). Even if this results in a new endpoint, it still makes sense for it to be provided through the REST API. It would cover things like request rate limiting, CORS or JSONP as already mentioned, caching, pagination and other features (even when provided by plugins) in the future without extra duplicated efforts.

I think the issue at hand is more than just providing a JSON within a more complex setting like the REST API. The issue is that there are many of us using RSS readers (and some of us building them), the only use-case is not just displaying blog feeds on another site's front page. There is a heavy load involved in reading in any large set of RSS feeds.

In any large set of RSS feeds for a reader the most common source is likely to be WordPress. By providing a lighter alternative to RSS feeds, WordPress can push this spec forward. Why wait on some other CMS to adopt it, or a reader to adopt it? If an RSSJS feed was provided by all up-to-date WordPress sites that's enough of a reason for readers to start using it, because it would cut down significantly on their server requirements.

Further innovation can, and I'm sure will, come later. But this initial move to provide the same thing that RSS2.0 provides in a more lightweight package is very useful for those of us building tools for reading feeds.

[nacin]

In 26294:

Add an experimental rssjs feed based on the experimental rss.js spec.

This is simply a JSON representation of the RSS 2.0 feed, accessible at /feed/rssjs/ anywhere.

props pento.
see #25639.

[rmccue]

The goal of this ticket is not to provide an API; it's for a syndication format, so I see the need for one separate from the API project. However, syndication formats are only useful if they're a) interoperable, and b) strictly specified.

I've spent enough of my life maintaining a feed parsing library to know what it's like when either of these aren't met. RSS, and by extension rss.js, fail the second criteria, which is why SimplePie is ~10% of WordPress' codebase.

RSS has its place: in the history books. We've invented better formats since, and the only real argument for using RSS these days is because it's already supported. rss.js is not supported, and it's not particularly easy to just convert an existing RSS library to rss.js.

Although RSS might seem on the surface to be a "good" standard, it's really not. If you don't believe me, I have an issue tracker full of RSS-related issues that you're welcome to tackle.

I cannot overstate how much I am against this ticket. I honestly believe that introducing this is actively harmful to both WordPress and the web.

I'm done with discussing this ticket. It has been clear from that start that this patch was going in regardless of any (non-technical) objections, so I'm not sure why I wasted my breath honestly.

[mbijon]

Funny, I'm completely in support of a JSON-formatted feed, but against rss.js for the same reasons as @rmccue.

That's where I was going with my input (and why it may have been seen as sideways to the point) -- unless the feed is consumable *in a way that's better than RSS* then WP is only spreading a mediocre format that doesn't solve many problems.

@nacin, could you weigh-in on why rss.js? (please excuse if this is too direct) It's unusual for a ticket to see this many of the core team + several negative responses, but not see your opinion. I'm not looking to challenge that, just see the logic behind choosing rss.js.

[Otto42]

Replying to rmccue:

RSS has its place: in the history books. We've invented better formats since, and the only real argument for using RSS these days is because it's already supported. rss.js is not supported, and it's not particularly easy to just convert an existing RSS library to rss.js.

That's not really an argument against rss.js though. That's an argument against RSS alone. See, the point here is that you would not use rss.js in the same places.

If I need to read a bunch of posts from a bunch of different sources, then I already have SimplePie right now. I don't need a new format, and in fact I don't much care what the format is. Thanks for that, BTW.

But if I need a quick way to implement something in a browser, then I need it in a javascript format. Example off the top of my head: infinite scrolling. It is a few lines of code to read in data from a json endpoint and display it in a browser, or fiddle with it, or whatever.

And the really big thing is that right now, it actually doesn't make a whole heck of a lot of difference what the format of that data is, because *there is no standard*. You have nothing in place to even hold a comparison to, because every single time you need to get data from a json endpoint in WordPress, you have to implement that endpoint yourself, in PHP.

Nothing you implement as a general starting point will have everything, or fit everybody's needs, or be useful in every possible case. That's impossible.

But there are very few things as much of a de-facto standard on the web as WordPress is. RSS may be crap, but rss.js is not widespread. Whatever WordPress implements in this respect *is* the standard. WordPress's RSS implementation is not necessarily a standard, but it is a known quantity and a reasonable starting point. Okay, sure, I would have preferred Atom, but the bottom line is that either way, having a feed URL that returns JSON structured data, and which works with all our existing query-URL parameters, the same as the RSS feed does, is the game changer.

Start with something. Iterate. Experimental and not widespread means that we can change it as we go along to adapt to perceived problems and gaps in the format. Even gaps in RSS itself. Who cares that rss.js is a badly defined standard? Nobody really implements it anyway. We're free to control it and extend it as we see fit. Having 20% of the web gives you considerable leverage when implementing something new.

And if /feed/rssjs doesn't work out, we can always ditch it and switch up to /feed/something-else later. Experimental features can die, or revert to plugins.

[dd32]

Since the battle has been ‘won’ here’s a full list of issues with the implementation and RSS.JS in general that we need to address to keep this

RSS.JS Feeds:

1. Includes “docs: ​http://cyber.law.harvard.edu/rss/rss.html” ( RSS 0.92 includes a link to ​http://backend.userland.com/rss092 )
2. Includes “ttl: 15” (rss2 uses sy:updatePeriod for 1 hourly, also misses the rss_update_period & rss_update_frequency filters)
3. Includes “language: "en-US”” (our rss2 doesn’t have a language element) (Our RSS2 DOES have a language field)
4. Uses get_bloginfo for the title, RSS feeds use wp_title()
5. Includes “generator: "WordPress 3.8-alpha-26294-src”,” instead of “​http://wordpress.org/?v=3.8-alpha-26294-src” as RSS uses

RSS.JS skips:

1. All standard feed filters are skipped (wp-includes/feed.php) (Which are on the echo variety of functions, not the get_*() functions making it hard to add to RSS.JS). Plus most feed-related functions have different default filters to deal with RSS format requirements
2. Author Name
3. Categories (plus, RSS doesn’t include slugs, just the title, which makes it hard to use for anything other than text-only display purposes)
4. Comments link & comments feed links
5. the_content filters - raw post_content is included, with unconverted short codes, embeds, no texturize, and, \n, it may also contain sensitive data. Most machines will want the raw data and not the_content styled data though.
6. Enclosures - When a Audio file is attached to a post, an <enclosure> is included in RSS to link to the content for parsers to read appropriately
7. (RSS skips this too) Links to Author / Category archives
8. Excerpts - If a post includes a Excerpt RSS uses it for the description field, and puts the full content in the content field, RSS.JS skips the excerpt as it has no description vs content field.
9. Doesn’t respect “For each article in a feed, show: Summary” (Excerpts only), allows content scrapers to have full post content (separate, but related to #5 and #8)
10. Password Protected posts: RSS includes a “There is no excerpt because this is a protected post.” as the description. plus a login form in the content (Also related to #8/#9)
11. RSS.JS doesn’t display the entire post as it doesn’t set $more = 1 (will occur once #5 is fixed)
12. i18n of errors

Obviously #1, #5, and, #9 are the most important ones here, In the case of #1 it’ll require some backwards incompatible changes (or numerous skipped filters, or output buffers). #6 will require refactoring the enclosure support in core to have a get_rss_enclosure version (which we should have anyway)

A lot of the challenges related to permissions / formatting content / how much (un)processed data is what WP-API has been dealing with AFAIK (aside from appropriate format).

Due to the significant differences between RSS2.0 output and RSS.JS, I’d also suggest dropping the “rss” namespace and “version: 2.0”, and, “channel” fields, and simply returning the channel container as a “feed” container.
Yes, this moves away from the RSS.JS “specification”, but since existing parsers cannot be altered to support RSS.JS removing the extra wrappers that serve no purpose (and contain now invalid data) seems appropriate.

[kovshenin]

In 25639.4.diff​: add missing filters and *_rss functions for existing fields.

[SergeyBiryukov]

Replying to kovshenin:

In 25639.4.diff​: add missing filters and *_rss functions for existing fields.

We should probably pass rssjs as a second parameter to the_content_feed filter, like we do in get_the_content_feed()​. Can we just use get_the_content_feed() there?

[dd32]

Can we just use get_the_content_feed() there?

Due to the RSS CDATA hacks, probably best not to.

[nacin]

Given the number of issues outlined in comment:37, I am inclined to revert this for 3.8 unless someone steps forward with a patch to address these issues. With a lot of other loose ends for 3.8 that are higher priority, I will not be holding my breath.

[nacin]

This is solidly in fix-or-revert territory.

[johnny5]

I've attached a patch (of r26294), based on what dd32 listed. As this is turning into a hybrid feed type I've been somewhat liberal with structural and naming modifications.

• RSS update period & frequency replace TTL
• Author name and archive link included
• Categories included, with links to archives
• Comment link, feed, and count included
• The surrounding 'rss' and 'channel' namespace removed, flattening the hierarchy. Version 2 has been dropped
• description is now used for the excerpt, and content for the content. This naming is not compatible with RSSjs.org, but then the neither is the above hierarchy change, and instead keeps the names similar to RSS 2.
• The effects of full/excerpt feeds and password protected posts are followed

[matt]

I like the latest work here, but let's go ahead and pull out of core into a plugin and let it soak, have more vigorous discussion, and aim for the next release train.

[matt]

When we have the plugin going and linked in this ticket we can close this as WONTFIX and continue discussion on make/core.

[dd32]

In 26644:

Remove the experimental RSS.JS feed, and move it to a plugin for feature development. Unprops pento. See #25639

[Otto42]

Plugin created for this code:

​http://wordpress.org/plugins/rssjs/

[pento]

If there's continued interest in this, discussion can be based around ​the plugin, and on make/core.