Posts are only parsed and returned if they contain a message property

[hughbris]

When being parsed, posts returned by the API must have a message property. Is there a good reason for this?

I have noticed when I bypass this condition using

if (empty(trim($tags_string)) || (property_exists($val, 'message') && $this->tagsExist($tags_string, $val->message))) {

that I end up with different kinds of posts (video, photo) that require a lot of tweaking to make them render the way users would expect on FB. Is this the reason? (complexity)

Anyway, I have a local fork of the plugin where the config count parameter is passed in the API call, all posts types are parsed, and extra fields are retrieved to make sense of it all at the front end! I will make a pull request when I finish it properly, but please let me know if this PR is a waste of time.

[hughbris]

The other problems with retrieving the default number of posts and then slicing them in the template are:

• if the results contain mostly posts without message properties, most of the posts will be eliminated and users may be served less posts than the count setting. For example, if the FB API returns 25 posts, count is set to 15, and 13 posts are discarded because they have no message property, users will only see 12 posts rather than 15, even though more are available. This is a bug.
• more posts are retrieved from the API than required.

So this is a good change in my opinion, even though handling/rendering the different post types is more complex than we'd like. However, it would be a somewhat "breaking" change without accommodating each post type properly in default templates etc.