Create An Activity Lookup Table (better to call it a reference table)

[jeffsayre]

There are a few instances where BuddyPress stores data that are not easy for a developer to utilize in specific, meaningful ways. One such case is that of activity groups and their associated actions. These get stored in memory in the $bp->activity object array (the $bp->activity->actions subelement for action items). These crucial data are not stored in the database. It could be viewed as phantom data that is internally hardcoded into the core code.

Instead of using lookup tables, key/value pairs are used to store activity datasets in object arrays that are rebuffered into memory each time a page is loaded. Hardcoding data like this can make it very difficult, if not impossible, for 3rd-party plugins to interact consistently with and store meaningful data based on this internal data.

Why is this an issue? If activity data is changed in the future -- via a change in the hardcoded activity group names or activity action names -- any stored data (in a 3rd-party plugin’s table) that counts on a particular activity item to have a particular name could lose integrity.

For instance, the “New friendship created” activity item (action) which was internally coded as the action “friendship_accepted” in an older of version of BP, was renamed to “friendship_created” in Changeset 1749. This single change could have caused data instability in any 3rd-party plugin that utilized the older activity items in their custom tables.

This method of storing activity data in memory (arrays) was implemented in this ​BP Trac ticket. It was an attempt to offer a mechanism with which to manage activity privacy. But after much testing and trial and error, this solution did not present any easily-accessible, stable method to manage activity privacy on a user-by-user basis. To make this method work for my component BP Privacy, I would have had to either add a special column to the privacy table just for this single piece of datum or create an entirely separate table solely for activity privacy. Even then, the data stored in that table could not be counted on remaining accurate (as detailed above).

On a side note: It is interesting to note that all activity actions, except the single one coded for the friends component, are used in the the activity stream table. However for the friends component, the stored activity action of “friends_register_activity_action” is not used. Instead “friendship_created”, an action that is not officially registered with the $bp->activity->actions array, is used. This should be changed.

It is crucial to offer unique identifiers for all core pieces of datum. With a unique identifier for activity data -- based off of the proposed activity lookup table’s auto-incremented ID field -- it would be more unlikely that any activity data stored via 3rd-party plugins could become orphaned in the future by changes made to BP core’s values.

As an example, the Xprofile component offers unique field group IDs and field IDs by virtue of the auto-incremented ID field in their respective database tables. The Group component does so as well. But BP’s activity component does not offer unique numeric identifiers for activity groups nor activity actions. Instead, each activity item is stored in volatile memory. This makes it difficult for a developer to count on activity item data to never change.

Currently, a developer wishing to offer customized activity filtering based on BP core’s activity names or activity actions must create their own way to uniquely identify and index activity items. Since activities and their associated actions are not stored in a table in the database, there is no safe and stable way to assure that a particular piece of activity datum will not change in the future.

Instead of storing activity groups and their associated activity actions in volatile memory, I propose that BP switches to using an activity lookup table. See the attached image for an example.

[jeffsayre]

Proposed Activity Lookup Table

[cnorris23]

So you're suggesting something similar to WP's category/tag/taxonomy schema?

[jeffsayre]

Replying to cnorris23:

So you're suggesting something similar to WP's category/tag/taxonomy schema?

You could look at my suggestion in that way. However, folksonomies are created by the users of the site, not the developers.

Within BP, activity data (activity group names and activity actions) is not technically data as it is not stored in a database. Instead it is hardcoded in BP's core and any 3rd-party's plugin codebase. As such, it is at best phantom data as I state above.

The idea of a lookup table is nothing new, of course. Developers have been using them ever since RDBMses came into vogue. I suppose what I'm suggesting might better be called a reference table as the term "lookup table" is often used more accurately for in-memory data storage. In this case, data in an in-memory lookup table would be pulled into the array via querying the reference table. Thus the data is not created on the fly via the codebase. Instead, it is loaded into an array from the database -- which is where data belongs.

Currently, the activity array is recreated and rebuffered into memory on each page load. This is an unnecessary use of resources. It should be queried once from the activity reference table and then used in memory. But, the in-memory array would include an unique index value for each activity action.

The basic idea is to allow for key data that does not change very often and is not added to too often, to be stored in an easily accessible and referenceable place. Let's use the term activity reference table instead of activity lookup table.

[DJPaul]

By happy coincidence, I addressed the "friends_register_activity_action" thing in r5437

[jeffsayre]

Replying to DJPaul:

By happy coincidence, I addressed the "friends_register_activity_action" thing in r5437

Nice!

BTW, my suggested enhancement is of course just that, a suggestion. Whereas developers can access and manipulate activity data in the current versions of BP, I do think that creating an activity reference table would make storing activity references for custom services more manageable and stable -- and therefore more dependable.

[johnjamesjacoby]

Valid points. Would happily review a patch that turns these bits into a legit API.

Less words next time. :) So much to read makes the issue difficult to assess.

[boonebgorges]

Good idea, Jeff. Managing these things with custom components has been a perpetual thorn in the plugin dev's side.

Could this be mapped into a custom post type? Schema:
activity_action maps to post_title
description maps to post_content
For the component_id, we could hijack something like post_content_filtered (otherwise unused)

Then, either
(1) we write API functions that are wrappers for WP_Query instances, or
(2) we do a single WP_Query at runtime and stash the results in the $bp->activities global object, and write API functions that refer to it

This seems more economical than creating (and maintaining) a custom table that will never have more than a few dozen entries.

[jeffsayre]

Replying to johnjamesjacoby:

Valid points. Would happily review a patch that turns these bits into a legit API.

Less words next time. :) So much to read makes the issue difficult to assess.

Ha ha! Fewer words from me? You should have seen the first two drafts. I did try to describe the suggestion to DJPaul via twitter in 140 chars, but that failed.

But, I get your point and will try to economize in the future. :)

[jeffsayre]

Replying to boonebgorges:

Could this be mapped into a custom post type? Schema:
activity_action maps to post_title
description maps to post_content
For the component_id, we could hijack something like post_content_filtered (otherwise unused)

Then, either
(1) we write API functions that are wrappers for WP_Query instances, or
(2) we do a single WP_Query at runtime and stash the results in the $bp->activities global object, and write API functions that refer to it

This seems more economical than creating (and maintaining) a custom table that will never have more than a few dozen entries.

That is possible. The only purpose here is to obtain a unique identifier for activity groups and actions that can always be counted on by a 3rd-party plugin. It would be best for that ID to be numeric as it would fit well with other unique IDs for key WP and BP data -- like userID, profile group ID, and profile ID.

I agree that querying a record in some table to extract activity data upon BP startup and then populating the $bp->activities global object would be the way to go.

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/