425: Proof of Concept for Blog List Remote Source Enhancement

[kadamwhite]

This PR was originally created by @alwaysblank in the old repository. Original PR description appears below.

---

This branch represents a Proof of Concept experiment as part of my research into #425.

It is meant to prove the feasibility of enhancing the Blog List block to pull data from remote WordPress sites via the REST API. My conclusion is that this is possible, with the following caveats.

Caveats / Limitations

• The remote site must (obviously) have support for the REST API enabled, and provide particular data regarding posts, categories, etc. This data is all basic stuff that should be in any implementation unless it has been manually disabled.
• In order to not hammer the remote site we need to take some precautions locally to only make requests when we need them. This implementation has some fairly naive transient-based caching to keep it from being egregious, but this could use additional investigation/tweaking.
• Currently there is little to no error handling, and no real feedback for users if things go wrong when pulling remote posts.
• Remote images are intended to just be served directly--i.e. "hotlinked"--which some remote hosts may frown on. We could potentially import them into the media library, but this introduces a lot of issues around management and invalidation that I didn't want to tackle in a PoC. Potentially we could avoid this concern by just passing remote URLs directly to an image manipulation service (i.e. Photon or Tachyon). In this branch, though, images are not optimized at all.
• This implementations makes some assumptions (which are hopefully safe) around the shape of the data it expects to find.

RSS

This implementation doesn't attempt to import items from RSS, but an RSS implementation would be conceptually similar, though probably a little more "static." If an RSS-based solution was desired, I'd advise building a separate block for RSS feeds rather than using the Blog List block. Certain elements of the Blog List (i.e. Author or Category-based filtering) would not work well in an RSS context.

Although RSS would theoretically allow us much more latitude in terms of CMS backing we could support, only the RSS spec is defined--not the data it might deliver. We would likely still need to develop specific "adapters" for each site we wanted to support--feasible if a small number of sites, but time-consuming if we want to support a large range of divergent sites. Using the WP REST API, on the other hand, allows us to quickly and easily connect to just about any modern or semi-modern WordPress site.

Conclusion

I think that this approach (enhancing the Blog List block to support remote data sources) is a reasonably robust one, and potentially very useful as it could enable syndication of content from a vast range of sites--so long as they are WordPress sites. If the ultimate goal is to be able to syndicate content from sites regardless of CMS, then the RSS approach would be more reasonable, but require dropping other features, i.e. filter by category. These two approaches could co-exist, though: There's no reason not to have the Blog List block and an RSS Feed block, if necessary.

[kadamwhite]

Original comments:

@smccafferty:

Nice work! Extremely through and well thought out so would be a good base.

@varnent:

I like this approach and think it makes a lot of sense. Thank you!

[varnent]

Original comments:

@smccafferty:

Nice work! Extremely through and well thought out so would be a good base.

@varnent:

I like this approach and think it makes a lot of sense. Thank you!

@kadamwhite - Is this ready for deployment or still at concept/development stage?