Skip to:

New 1.2 SWA and Blog/Forum syncing: Feedback Needed

  • Mike Pratt


    Bringing up a Topic I thinks needs serious discussion as Andy dives headfirst into issues raised by the new SWA model.

    If you have played around with the bleeding edge trunk or the new, then you can see this issue in action.

    Current State: the new in-line commenting system (awesome) allows for all members to chime in and add to conversations taking place throughout your BP site. These comments are ajax’d, threaded and are a boon to activity. CAVEAT: comments made in-line do NOT post back into the originating thread (this goes for forum postings and blog post comments). The obvious problem here is that 2 separate discussions will most certainly evolve from one originating posting, potentially occurring multiple times even within the same topic!

    Question #1: Does Andy “sync” these postings. After chatting, I think the answer is some form of “yes”

    BUT: This will force a possible re-thinking of the concept of Groups and Blog roles and membership e.g. is it necessary for a user to be a member of a group before in-line commenting? Are they warned (in-line) that they cannot comment if they are not a group member? Are they auto-joined in-line like they are now in the actual Group itself? What about Groups that require permission to join but whose forum postings show up in the SWA?

    We have a possible solution on our site but realize it will not universally apply. We think of Groups as logical aggregations of topical activity and association. Our site is pretty gated as a whole but not once you’re in. We DON’T want people auto joining a group JUST because they made a comment (in the new in-line model) For ex. we have graduating class groups going back to 1940 and imagine a busy commenter realizing he is now a member of 18 class groups when all he did was comment on the SWA. To us, the reason you JOIN a class is to 1. be associated and found and 2. be kept up on all that goes on within the group. We want everyone to comment and engage but we know that for many it may be a one off thing that doesn’t deserve an auto-join.

    There are many sides to this coin. I just threw out one of them. We need to hash it out here for Andy’s benefit…..and, therefore, OURS.


Viewing 14 replies - 26 through 39 (of 39 total)

  • Jeff Sayre


    BP1.2 is shaping up to be a major, beneficial update to the platform. But I do have a small issue with this thread’s topic.

    As Mike said several posts above, the current threaded commenting feature of the SWA stream offers nothing more than a “comment about a comment.” I understand what jjj is proposing, but why should we want members to be able to comment about blog comments and forum posts?

    Should we later then create a feature that allows members to comment about comments about comments? This is just a rhetorical question, of course.

    The SWA table is reporting on activity sitewide. IMO, it should not be a place where new activity is created and stored. If you look at the new table, that is exactly what is happening. There is a new component_action called “activity_comment.” It exists only in the activity table. It is not a reflection of activity that has occurred elsewhere. It is a self-referential, disjointed piece of activity—activity for activity’s sake in essence.

    What is the solution?

    Well, as Andy has pointed out above, there is limited time before v1.2 comes out. So, at this point, I believe we need to discuss viable and desirable solutions for a future release. Here’s one thought going forward.

    I am not a fan of the way that content data is duplicated in the xx_bp_activity_user_activity_cached table. The data already exists in other tables. It is not a good practice to copy it into this table. Yes, I know that that’s what a cache is all about. But a cache is supposed to take place in memory or temporarily on the HD. It is considered temporary storage. It is not written to a physical, permanent table.

    Why is this important? Well, since this thread is about the bifurcating of commenting activity, if we ensure that all commenting activity takes place in the original containers—this means in the backend, not in any particular user interface—then we could do away with this table.

    This would mean that to obtain the wonderful threaded commenting feature that Andy has implemented for the SWA stream would require that the data be written back to the appropriate tables and properly associated with the original piece of comment datum. The SWA stream would be auto-created from a query, storing the results in an array instead of pulling it from a permanent “cache” table. The array would be updated as needed.

    To clarify, be stating that the system would ensure that all commenting activity takes place in the original containers it does not mean that all commenting activity would be forced to occur in the blog or forums screens. With the proper underlying functionality, the system would write the data back to the appropriate table; commenting could occur within any user interface area (like the SWA stream). This is a behind-the-scenes issue, not a user interface issue.

    John James Jacoby


    And if I could reply to only Jeff right now, I would say T_PAAMAYIM_NEKUDOTAYIM!

    But since I can’t I just forked this conversation in a totally new direction! :D How’s that for activity.

    I think Jeff is right, but it isn’t feasible since the queries it would take to pull that off would be astronomical. The reason this is an activity cache table is because it is where activity is stored in an easier to gather fashion. Maybe cache is the wrong word, but it’s doing what it says by being an easier way to combine other queries into one easy to get, light on its feet query of site wide activity.

    The only other solution would be to branch activity comments off into a separate table, but that would require a query for each group of comments, instead of just grabbing all of what’s relevant and dumping it out.

    Back to the original topic I suppose, but I think the talking back and forth between the components isn’t really the job of the core to do. The activity stream is a functional component of BuddyPress, and BuddyPress can exist without blogs, comments, and forums. In that scenario activity commenting doesn’t matter because there’s nothing to sync with. If someone needs to sync that data, they can make a plugin to do it, just like someone made a plugin to sync bbPress replies to blog posts and vice versa.

    Jeff Sayre


    And if I could reply to only Jeff right now, I would say T_PAAMAYIM_NEKUDOTAYIM

    That is why I make sure I have sufficient fiber for breakfast!

    Digging up obscure PHP error messages means you just have to fix them John ;)

    Jeff Sayre


    … it isn’t feasible since the queries it would take to pull that off would be astronomical.

    If the data can be written to a table to begin with, and the structure of the written data makes sense, then in theory a query can be designed to accomplish the same outcome without having to write it to a table.

    But in practice, since WP uses a sharded DB and not a normalized DB schema, this could be an issue.

    … but I think the talking back and forth between the components isn’t really the job of the core to do

    Okay, I think I just saw a ghost. That was a scary comment, jjj!

    Whereas I agree that it may not be the responsibility of the core to ensure that non-core components successfully talk back and forth with each other or with other core components, it is absolutely the responsibility of the core to ensure that each core component effectively and properly communicates with one another when activated. Every component we have discussed here is a core component.

    What you basically just said is the right hand does not need to know what the left hand is doing. In actuality, your right hand may not always need to know what your left hand is doing, but sometimes it is an absolute necessity. The brain takes care of this for us, of course.

    BuddyPress’ core needs to take care of monitoring, negotiating, and policing the actions of its core components. As users and developers, we are entirely dependent on the core development team to make sure that happens.

    John James Jacoby


    The data is written to a table, the activity_cache table. :)

    John James Jacoby


    Agreed on all counts. But I see the activity stream as a separate, isolated module of discussion that doesn’t belong in blog comments or post replies. Since that’s my view, the topic of sync’ing them together doesn’t appeal to me. Nevermind the fact that bbPress doesn’t support threaded topics and post replies out of the box in the first place.

    Maybe I should just leave this topic and never look back. :D



    I think atleast 10% of my brain just melted by trying to follow this conversation. When JJJ started about Skynet I was doubting if someone put acid in my coffee and by the end of the discussion I still had no clue about what had just happened.

    *closes browser and lays down on the ground in fetus position*

    Mike Pratt


    @jjj Yes, you see it that way but I will put forth that you are in the minority. Everyone I come across who classifies themselves as a regular user type thinks that SWA entries are actually the entries themselves. They have no idea that when the comment was originally posted it was also written to the activity cache (the reason for which I totally understand – views and on the fly queries are very computationally expensive)

    So that is the issue – given they think that what is being represented in the SWA is the comment itself, they naturally think they are replying TO that comment. But in BP they are not. I know Facebook is not a fair comparison but it’s what are users already know and when they comment in-line on FB they ARE commenting on the original stream… so at a minimum, we’ll have to unlearn that behavior to avoid the “Oh, I didn’t realize remarks”

    Jeff Sayre



    I understand your befuddlement and I’m sure it’s not caused by esoteric developer speak. It most certainly is due to the fact that obscure T3 references where made by a J3 unit.

    Jeff Sayre


    … views and on the fly queries are very computationally expensive

    Once the initial activity array has been built via query, the array can be appended to with each new reportable activity—as the data is being written to the appropriate table. The only time the system would need to be queried again is during a site reset, or for periodic purposes of clearing the cache. The time interval between cache clearing could be configurable via a Site Admin option.

    With fewer writes required—records are written to the component table(s) and not to an activity table as well— performance could actually improve.



    After reading the entire thread, I am going to have to say that Jeff has nailed this one. All of the solutions being offered are trying to work around a design flaw, instead of correct the flaw.

    To fix this issue, or rather to re-design the threaded activity comment feature so that it will be extensible, there has to be a serious change to the thought process of how this component, and eventually how all components are designed in general.

    WP seems to be built around this “buckets of data” concept, where you just kind of create a container for data, label it, and go get it later. All of these buckets of data are sometimes associated with lookup tables, and sometimes associated with meta data entries acting as a lookup key, and sometimes not even associated at all; they are COPIED. This type of design is also prevalent in BP.

    It is such a bad idea to copy data, and then begin associating other records with the copy, I can’t hardly stop myself from smashing my monitor to bits over the thought of it.

    At the point you begin to do this, you might as well stop using an RDBMS and go back to text files, because that is how it is being used, as a directory of files, not for normalized relational data.

    I understand there is short time here, but the problem must be solved with a clever design to associate all of the records in the proper way so there is a strong foundation to build on. I’m sure it will still be necessary to cache the data WHEN QUERIED, and there is nothing wrong with caching data (or careful de-normalization) for optimizing. It is a huge mistake, however, to pre-cache associations and treat those “virtual” associations as a new record.

    Think about it this way. If you are afraid to delete records from a cache table because it will cause permanent data loss, then you really messed up somewhere.

    I am willing to help out with this, if there is a willingness to do the right thing, and not what is needed to git’r done yesterday.



    I’ll say this from a user’s perspective. Not programmer.

    I want everything as a stream on one page. It’s great if things are categorised as forums, groups, wire and all. But still, I just want to write something in a box in a simple way. This either goes in reply to something or not. I want to encourage my users to engage. I’ve found this to be true with “activity streaming” but not so much with forums or blogs.

    I’ve got a small community. Like it will max out at 1000 members. And about 10-20% active ones. To us it will be useful with one stream and to use that mostly. You guys with 10.000 members will probably not have an efficient activity stream.

    Let’s make it moddable. It is not a one size fits all.

    I’m closing this thread since the conversation has moved on. Please continue over here:

Viewing 14 replies - 26 through 39 (of 39 total)
  • The topic ‘New 1.2 SWA and Blog/Forum syncing: Feedback Needed’ is closed to new replies.
Skip to toolbar