WordPress client enhancements
Closed this issue · 5 comments
(Genesis from Issue #38)
The WordPress client needs to have functionality implemented for the post_include_media and post_include_content client options.
Implementation of post_include_media should be pretty straightforward, as documented at https://python-wordpress-xmlrpc.readthedocs.io/en/latest/examples/media.html.
The post_include_content option is not as simple, however. Upon further investigation into the WPClient code, I found that it is not actually posting based on RSS/Atom feed item contents, but rather on the contents of the link references from those entries. All other clients limit themselves to the feed item contents, not the content from the referenced link. I think this modified functionality in this client should be under the control of a new option (proposed post_link_contents), and the basic functionality should be changed to post only from feed item data. This approach also resolves what should be involved with the post_include_content option as well. I will wait for confirmation of this idea from @aurelg before proceeding with this implementation plan.
I do agree with your suggestion. This client was implemented with a very specific use case in mind. It would be much better to have a default behavior similar to the other clients, and this optional post_link_contents would be great!
I thought about it a little more, and unfortunately, if we implement it the way I describe, the user base will be forced to make a change in order to retain the existing functionality. So maybe it would be better to leave the default functionality alone and instead implement a post_use_feed_data option instead (which would only work with the feed data, of course). Or do we not need to be concerned about backwards compatibility (how many users are expecting the existing functionality)?
Also, if you could provide an Atom/RSS feed that has that specific use case, that would make a good test source for my development efforts.
Since feedspora is not even available on http://pypi.org/ yet, it's probably safe to assume that the current user base is quite tech savvy. It's probably OK to break backward compatibility for the sake of consistency, as long as it's mentioned in the git commit.
I'm not sure I understand your request regarding to an Atom/RSS feed, since the WPClient is not feed specific?
OK, based on your input I'll implement it as a WordPress client-specific post_link_content (instead of post_use_feed_data) option. I agree that the default behavior should be more uniform across the clients, but was concerned about compatibility issues, as I mentioned. Since that's not a factor, we can opt for the more uniform implementation!
As far as the feed URL request, it's true that none of the clients are (or should be) feed-specific, but it's also true that certain feeds have influenced some of the client behavior. I was just asking for the one(s) that influenced the WordPress client's operation (just to make sure none of my changes are messing that up), but it's certainly not critical.