Make storage implementation more flexible for plugin developers

[paulgibbs]

Merits aside, I don't like the fact that the current implementation forces the storage to be tied to comments (which are tied to post types). I know post types get "stuff for free", and that's okay, but since this is such a front-end facing feature, it's pretty lame if a 3rd party plugin has content types that are implemented using their own database tables, because it makes this entire feature useless -- those developers can't re-use any of the implementation.

When you approach feature plugin proposals, please try to remember to consider the implementation from the perspective of outside plugin developers who want to extend or re-use it as much as possible

This matters because it would be a really poor user experience if a WordPress post has this core implementation/design of reactions, but if non-CPT content had its own distinct design.

In this case, I'd suggest using a class to handle the "CRUD". You'd require an interface to be implemented for that class (I can't immediately think why this would benefit from using inheritance). A simple filter around the class name before the object is instantiated would be enough to let plugin developers switch out the storage layer as they need. And by making the feature flexible for developers, you'd go a long way to preventing each major plugin implementing its own slightly-different version of this.

[pento]

This is absolutely an issue we should explore further!

So we have some practical targets in mind, do you have particular uses cases that you'd like to have reactions available for?

[paulgibbs]

BuddyPress' Activity Stream, which you can see demo'd at https://buddypress.org/members/djpaul/ (if you are logged in you should see Favorite and Delete buttons below each item).

[pento]

:+1: