[jeff-sayre]

Dace:

According to jjj, a privacy component is currently being developed and should be released as part of version 1.1. Read John’s post in this thread for more details: https://buddypress.org/forums/topic.php?id=1590#post-8019.

So, what you are asking will be possible in the near future. When will version 1.1 be released? Well, since BuddyPress version 1.0 has not yet even been officially released, I cannot answer that question.

[jeff-sayre]

westpointer-

Just is case…

In your first post you listed your add_action code as:

add_action( 'groups_new_form_topic_post', 'my_notification_new_post' );

If that is the actual code you’re using, then you have a typo. You need to change the word “form” to “forum” to match the do_action line. Of course, you need to include the proper parameters as nicola pointed out.

I hope it’s as simple as that little typo!

[jeff-sayre]

Hey kennibc-

I’m glad jjj got you down the path.

I assume you’re placing this code in the header.php file. The reason that you need to set $bp as global is that without it, a call to the $bp object is out of scope–it has no way to reference the object’s fields.

Here’s another way to accomplish your clickable image links. This way pulls in the user’s name and not the user’s id.

<?php global $bp; ?>

<a href="<?php echo bp_core_get_userurl($bp->loggedin_user->id); ?>blogs/create-a-blog" title="hi" ><img src="<?php bloginfo('template_url'); ?>/images/createblog.png" alt="Create a Blog" /></a>

Two final notes:

First, I removed the hspace=”4″ align=”right” attributes from the image tag. You don’t need them. Instead, position the images using CSS.

Second, I included the title tag within the anchor tag. Replace the text with whatever you want it to say. Although it is a matter of choice among coders, in my opinion it is wise to make a practice of using the title tag. It is an accessibility aid on links and it allows browsers to pop up a nice tooltip when a user positions their browser over an image.

[jeff-sayre]

Thanks, donnacha!

Last night I added an enhancement request to trac for what I’m calling a Relationship Mapping feature.

Hopefully, we will see BP’s abilities and flexibility rapidly evolve because that is going to be, surely, it’s strength.

I have no doubt that BP will become a more flexible, sophisticated platform–and quicker than we expect. It is already quite a piece of work for a version one release candidate. Andy and the other developers have done quite a job!

[jeff-sayre]

@donnacha

The fans functionality, as you detail above, is a viable idea. Imagine a BP network of emerging artists. As you mentioned, it may not be appropriate to ask a favorite artist to add you as a friend but it would be easy enough for you to tell that artist, “I love what you do, keep it up!”

I see this idea as part of a larger necessity–mainly being able to provide members with a way to more accurately describe their relationships. Whether a true friend, a fan, a business partner, an intimate partner, a work colleague, a student, a professor, and many others, the ability to describe the type of relationship would add more power to the BP platform.

After all, I have many friends on the testbp.org site but I’ve never met them, I don’t know what most of them look like, and have never talked to them before. Are all of these really my friends? Whether or not they become actual friends in the future is not the issue. The issue is, what is the nature of our relationship at this point in time.

[jeff-sayre]

donnacha-

I’ve been following the other thread you mention in your first post. So as not to double post, you can read my recent thoughts on this issue here: https://buddypress.org/forums/topic.php?id=1485#post-8136

[jeff-sayre]

devweb, sorry about the little thread jacking

There is a plugin on WPMU Dev ( http://wpmudev.org/project/default-user-role ) that allows admins to set the default user role on signup. There’s also this plugin ( http://agapetry.net/news/introducing-role-scoper/ ) that seems to offer significant role customization in WP. However, I cannot find this particular plugin in the WP repositry so beware.

You may also get some useful ideas from this thread on the Mu forums: https://mu.wordpress.org/forums/topic.php?id=8217

Granted, these are all WPMU-specific ideas, not BuddyPress. But Mu is the platform on which BP sits, so this may be of some use if you’re planning to code your own solution.

[jeff-sayre]

Yes, by using the Extended Profile fields this idea can already be implemented. But perhaps I’m missing something. Whereas multiple href tags are placed within single posts everyday in the blogosphere, it is a lot harder to extract (parse) that data–each individual link–for other purposes.

In this particular instance, placing a member’s outbound homepage links, each in their own individual record, makes it a lot more useful. In other words, a 1:N relationship between a member and his or her chosen online homesites. They could add as many as they like and each would appear in a nicely formatted table, one row for each link, each record. This would provide a more flexible and easy to manipulate subset of profile data for plugin developers to utilize.

However, such relational design in this case may be over engineering the data schema and might be of limited use for the vast majority of developers. It could also make the management of the profile fields more complex–from a coding standpoint.

But, this general concept of offering a way for plugin developers or site admins to place multi-record fields (model 1:N type data) within profiles would be very powerful. Currently, most social network platforms do not provide that type of relational complexity within their users’ profiles. True 1:N relationships are simply listed within a single field. For instance, members of a musicians network list their albums or songs within each album in a list within a large text field.

You get the idea. Maybe this is not too useful for most. But I think providing the option could help BP become an even more sophisticated platform.

[jeff-sayre]

Thanks for the detailed response, jjj!

I knew the official BP privacy solution would be (much) more advanced than mine. In the meantime while v1.1 is incubating, I’ll finish my basic profile privacy plugin. It will help me learning about coding BP components.

[jeff-sayre]

An additional thought. Whereas it would be possible to use a text field to allow members to add links to whatever external blog(s) or website(s) they consider their primary online home(s), it would be preferable to do so through a 1:N relationship and not within a single field.

[jeff-sayre]

The need being addressed here is not to pad the user profiles and activity streams with content generated elsewhere but, rather, to make the profiles more useful, having the humility to accept the fact that the most important information about someone may not be located on their profile page within our BuddyPress network but elsewhere, and allowing that user to indicate wherever it is he considers to be his online “home”

I agree with donnacha’s sentiment. When it comes to creating a new social network, it’s not only possible, but probable that many members will already have a website url they consider their primary domain. BP needs to have a away for members to place one or more clickable links within their profile.

[jeff-sayre]

Hi John:

Is the permissions plugin the same thing as the privacy component Andy mentions in this thread (post #4)? https://buddypress.org/forums/topic.php?id=39#post-158

I literally just started (i.e. this morning) coding a bare-bones privacy plugin for BP that in essence controls privacy at the profile subgroup level.

A simple radio button array appears in each subgroup’s title bar with options to grant or deny viewing access. It offers the following granular subgroup level of control:

• allow/deny anyone (i.e. globally public or private)
• allow/deny only logged in users
• allow/deny only friends

It’s not much of a privacy filter, but it is a start.

If it is the case that V1.1 will have the first generation of the privacy component, then perhaps I should simply wait. I’m sure the core developers will provide a more powerful (and better) solution than I could.

Jeff