While investigating supporting different plugin types it turned up that the 'compatibility' functionality of FeedAPI is a really tricky problem. Unfortunately the solution for this is to build the functionality in at the type plugin level. This is fine but its also a problem because it's probably going to require a good bit of work to the plugin API's to support this.

Rather than rewriting most of the plugin interface /again/ I'm just going to postpone this as a lesson learned and let it happen after there's a stable release.

The side effect is this is that to support #549526: Extend to support non XML feeds eparser is going to become even ruder.(see #401122: feedapi_eparser_type_plugin overwrite namespace plugins data in $item->options elements) Basically, EParser needs to be the primary parser for node types /and/ no other parsers will work with it on that node type. Sucks but I think we'll be able to full fill the goal of being a flexible enough parser that it won't be a problem.

Hopefully this can be part of v2.

Comments

neclimdul’s picture

Status: Postponed (maintainer needs more info) » Postponed