[@jeffsayre Participant 16 years, 9 months ago]

Grosbouff-

I’m currently working on updating my BuddyPress Privacy Component to work with BP v1.2. I expect to have a new release in about two weeks. I will not release it before BP 1.2 is tagged. There are still a number of changes being made to the BP core codebase, so I need to wait until the dust has settled to see what additional modifications are required in my plugin.

I plan on providing better documentation–a users’ guide, an site admin guide, and some information on extending components to hook into the privacy filtering functions. So, if you wait a couple of weeks, this information should be available.

[@jeffsayre Participant 16 years, 9 months ago]

JJJ-

I agree with your argument about the dangers of paywalls to OS projects. But I just wanted to correct one issue. The GPL does not say anything about free as in cost. It is about freedoms of the end user.

http://www.gnu.org/philosophy/selling.html

Most people in vibrant OS communities like the WordPress ecosystem, are moving beyond the spirit of the GPL, to a more utopian, share and share alike vision. There’s nothing wrong with that if it happens. But the GPL has never been about free as in cost.

[@jeffsayre Participant 16 years, 9 months ago]

Haha, Bowe!

It looks like I was adding more details to my post as you where posting your response.

[@jeffsayre Participant 16 years, 9 months ago]

I agree with MrMaz’s assessment above. We should be thinking about extending the BuddyPress framework and not deprecating major components at this time.

The ability to assign more than one type of “friend” was something I proposed 10 months ago but was somehow deleted as a future enhancement by an anonymous person. That may have been an automatic “deletion” as it was around the time that the phrase “future enhancement” was replaced with “future release.” But, I would have thought that the ticket would have simply been switched to that new milestone indicator.

https://trac.buddypress.org/ticket/582

My suggestion in the link above is what jjj refers to in this comment on his Trac ticket linked to in this thread’s OP:

It would solve Jeff Sayre’s user relationship issue too…

The best solution to accomplish my suggestion is to extend the Friends Component and model the data in a one to many relationship. Simply relegating friends to another type of group does not accomplish the goal.

[@jeffsayre Participant 16 years, 10 months ago]

does the installation actually create “members”, “groups”, etc blogs

No, those are simply slugs that are appended to the URI.

To help us better troubleshoot your issue, please answer these questions.

[@jeffsayre Participant 16 years, 10 months ago]

@javicarrasco

Jeff I won’t try compression now because It could increase the CPU usage and this is our main problem.

That is not correct. It will increase CPU usage the first time a PHP page’s output is compressed. But, from that point forward, only the compressed data will be served. This can significantly decrease as server’s CPU usage. Now, when you clear the compressed cache, it will have to recompress all over.

[@jeffsayre Participant 16 years, 10 months ago]

http://macdougalmedia.com/2009/06/30/compress-php-output-and-save-on-bandwidth/

[@jeffsayre Participant 16 years, 10 months ago]

If you have not yet tested or commented on my BuddyPress Privacy Component, now is the time. I am holding back on some of the work as I wait to see where the coding dust settles for BP v1.2.

You can get the Beta component here: http://jeffsayre.com/2009/12/05/buddypress-privacy-component-released/

For those who want to know more about BuddyPress, Privacy, and the issue of hooking your community up to other social networks, I’ve posted a new article here:

http://jeffsayre.com/2009/12/21/oauth-buddypress-and-privacy/

[@jeffsayre Participant 16 years, 10 months ago]

Andy-

I agree. This discussion should be held in a developers area, away from the regular forum. Unfortunately, Trac and IRC are not great places to hold in-depth conversations, nor do either provide a mechanism with which to do so effectively.

In the past, there was a discussion about creating a developers’ resource section on BP.org–a place that would not only contain a library of code snippets, but provide an arena for the type of discussion that we’re having in this thread.

That discussion happened 8 months ago and lost steam. Read the entire thread as it starts out as a discussion about snippets and evolves from there:

https://buddypress.org/forums/topic/buddypressorg-needs-a-common-place-to-share-code-snippets#post-11852

[@jeffsayre Participant 16 years, 10 months ago]

I did see the version of WPMU and BP that you’re currently running. But the other questions in the link that I provided are asked because they help determine other possible issues with your setup. So, please answer those questions so that I, or someone else, does not have to reask them one at a time in this post.

[@jeffsayre Participant 16 years, 10 months ago]

Okay, as I was thinking about and writing a reply to Andy’s OP, there have been many posts. So, I will post what I have to say first before reading the rest of this thread. I’ll post again if I have anything to say with regards to other people’s comments

---

First of all, I want to say thank you for starting this thread. This type of discussion is not something that can been done effectively on IRC. Secondly, it’s clear that the trajectory of the referring thread has struck a nerve in you.

My comments were an attempt to start a healthy debate and not meant as a major criticism. Your work on the BuddyPress core is very commendable and much appreciated. So, let me reiterate, as I stated in my first post in that thread, I’m excited with the direction BuddyPress is headed. I believe that v1.2 will be a major, beneficial update to the platform.

The vision that you’ve outlined here helps frame the discussion going forward. Up until now, we, or at least I, did not have a clear idea about your vision. The roadmap is of course only a listing of features. It is not a statement of your design philosophy or design goals. All that the majority of us could discern about your vision (and here I particularly mean developers) was from what we saw in each changeset and a few morsels gleamed from IRC here and there.

With that said, I think this is the most crucial statement:

What I don’t want is for BuddyPress to be limited to high end servers with beautiful caching solutions. In reality, I want this thing to run on cheap hosts where someone can just throw it up there and it doesn’t take the server down.

This is a lofty but worthy goal! In my mind, I look at WPMU and BuddyPress as platforms best utilized on more robust setups. To that end, my ideas, my suggested approaches, have been geared toward a higher-end user. But now that this particular goal of yours has been stated, I have a very clear idea of what guides your BuddyPress design decisions.

Your ideas about the activity stream are interesting.

Rather than creating multiple new tables for each content type, why not just use the activity table but be able to denote different types of content using identifiers or types?

This will require some thought if blog posts, forum posts, and other content types are to be successfully integrated into this vision. I guess for purposes of backend discussion, it might be best to refer to this envisioned table, or set of related tables, as content tables instead of activity tables.

Activity of any type would be recorded in the appropriate content table and thought of as primary content and secondary content. Primary content is the object of the activity—a post (in a blog or forum), a picture (any piece of media), an accepted friendship, etcetera. Secondary content would be any response to the primary content—comments, retweets, etcetera.

As far as proposed schema changes, that all depends on how this vision is charted out. So, perhaps it’s best to figure that out before debating, or even professionally arguing, about DB design.

[@jeffsayre Participant 16 years, 10 months ago]

You probably were marked, or at least your post was marked, as spam, as coming from a bozo. This is not an insult. It is the actual term that bbPress applies to suspected spammers. This has happened to me twice in the past.

If this happens again, or seems permanent, you should contact Andy or jjj as whenever I log into bbPress admin, it does not show me the “bozo” members. So, I have no way of changing the status.

But, since you are obviously posting right now, the issue was more than likely the system marking that particular post as probable spam. This is just a hunch.

[@jeffsayre Participant 16 years, 10 months ago]

Yes, it is possible. You can create a function that adds a filter to this key, value pair in the groups_record_activity array in bp-groups.php (line 2059 as of BP v1.1.3):

'content' => apply_filters( 'groups_activity_new_wire_post', $activity_content ),

Your filter function would alter the value stored in $activity_content.

[@jeffsayre Participant 16 years, 10 months ago]

It seems that you are more than likely using an older theme, one that is not compatible with the version of BP that you’re running.

Please answer these questions so that we can better understand your setup:

https://buddypress.org/forums/topic/when-asking-for-support

[@jeffsayre Participant 16 years, 10 months ago]

… 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.

[@jeffsayre Participant 16 years, 10 months ago]

@Bowe

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.

[@jeffsayre Participant 16 years, 10 months ago]

… 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.

[@jeffsayre Participant 16 years, 10 months ago]

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!

[@jeffsayre Participant 16 years, 10 months ago]

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.

[@jeffsayre Participant 16 years, 10 months ago]

There are a few older posts talking about the dangers of using one-click install scripts to install WPMU and/or BuddyPress. IMO, if you are going to create a community site, you should take the time to carefully set it up. Toward that end, I place manually installing WPMU and BP as an important first step. You have more control over the process and gain a much better understanding of how your site is configured.

@KevinHeath

I’m glad that you’re up and running now after a clean, manual reinstall.

[@jeffsayre Participant 16 years, 10 months ago]

@Harry

Yes, my Privacy Component works just as I described. It is an advanced beta available for testing. See this thread for more details: https://buddypress.org/forums/topic/buddypress-privacy-component-an-update/page/3#post-30574

@David

I wouldn’t give users the option to set it to friends only. Or at least… I would like the site admin to have the ability to disable that option.

In my Privacy Component, the site admin can choose to disable this feature.

But, to get back on topic, I agree that the best solution is the one that requires the brunt of the filtering to be accomplished through invisible, behind-the-scenes techniques. Requiring users to prove that they are members and not bots should not be the first line of defense. I think it is okay, even necessary for registration purposes. But that is a one time occurrence. After that, the system should do more of the policing.

Concerning your second link above, perhaps we could create a new CAPTCHA that could harness the collective intelligence of site members to solve the Unified Field theory.

[@jeffsayre Participant 16 years, 10 months ago]

Here’s all you need to know about updating a theme to make it work with the BP 1.1.x theming architecture:

https://codex.buddypress.org/how-to-guides/upgrading-a-buddypress-1-0-theme-for-buddypress-1-1/

[@jeffsayre Participant 16 years, 10 months ago]

@Harry (a.k.a. stripedsquirrel)

I think a very good start is that you can only message your friends. Thought that this would be already ths case, that is why I wondered how we could get spammed?

See this discussion: https://buddypress.org/forums/topic/compose-message-send-to-username

Basically, the autocomplete message recipient list only autofills from your friends list. However, anyone can message any other individual via the “Send Message” button on user’s profile screen. All that is needed for a user to send a PM is that they have a member account and that they are logged in to the system.

On a related note, my Privacy Component does have an option to filter out the “Send Message” button, making it only visible to those you choose.

[@jeffsayre Participant 16 years, 10 months ago]

Do you have any plugins other the BuddyPress installed? I ask because that is not at all the default .htaccess file configuration.

[@jeffsayre Participant 16 years, 10 months ago]

It is a known problem. Hopefully, it will be corrected soon.

https://buddypress.org/forums/topic/httpcodexbuddypressorg-is-dead