BuddyPress.org

Grosbouff-

You posted the same basic request in this thread 2 days ago and I answered it, giving you the same advice that Andy did above.

Please do not double post. Use the same thread.

I’m going to close this thread as your original post should do.

@Anointed Ha! I was doing the same thing! Trying to make Elgg look like BP. Funny. I worked on it for about a week before giving up. I couldn’t deal with the 100’s (okay, dozens) of CSS files (that are actually PHP files so you can’t use live CSS editing tools like Coda or CSSEdit for Mac… ARGH!). Plus I was finding I had to override a lot of core files to make it look and act the way I wanted… which didn’t sit well. I agree that Elgg is more advanced in terms of features… but I just didn’t want to deal with it. I also decided that although BP is newer and not as complete… it has a brighter future. My prediction. I could be wrong.

@David –

I couldn’t agree more with you on the theming issues. Elgg is more like drupal, anything is possible, but the learning curve is beyond steep and straight up hill imo. Of course in it’s current state bp isn’t much easier, though that is going to change bigtime with 1.1. As to the interface, well that can be changed as well, but it’s a huge amt of work. We actually got about 90% finished making an exact ‘clone’ of the theme used for bp on this site. I just got sidetracked on other projects so didn’t complete it yet.

@Jeff – I’m definitely not trying to start a platform war. The only reason I even brought up elgg was as an example of what can be accomplished and a system that I absolutely fell in love with when I found it. In the case that you had not seen the code from elgg, I was simply trying to give an example is all.

My foundation is and will remain wpmu. That is why I keep coming back every few days to check on bp progress. Your privacy plugin is going to make bp usable in many instances where without it bp would not even be an option. I applaud you for the work on this, and the devs behind bp itself. I agree it’s an amazing platform considering how young it is.

I think my request for granular object control has been made pretty clear. I just wanted to get my 2cents in whether it’s accepted or not.

peace

@Jeff. That’s cool. I can just use a simple plug-in to block out groups, etc. wholesale. Like that code Burt did… just using is_user_logged_in(). It’ll do for now.

The issue is, I want to use BP as a kind of simple, lightweight “Intranet”/communication tool for our local Search & Rescue group. We’ll mostly use groups and/or bbPress to discuss fundraising, training, recent searches… etc. As well as look up members in the directory. Etc. All that stuff should be just for members. Some of it can be sensitive info. But we still need a public face for news, events and static info (faq, about, photos, etc.)

Two sites (a WordPress site for the public and a BuddyPress site for members) might make sense… but there’s overlap. All that public stuff needs to be available to members as well (pages, posts, events). So having two sites would be kind of a nightmare.

But I digress!!! As I say… I’m sure I can hack something together. Since I’m just hiding entire classes wholesale… it should be simple enough with a bit of PHP. Not sure how events will work though.

Anyway… very much looking forward to the privacy component as designed. Even thought it’s not what I thought it would be… and won’t do what I had in mind… it sounds like it’s actually a lot more impressive than that.

Please post bugs in trac, not here where they may be missed:

https://trac.buddypress.org/newticket – same login as here

Thanks

Disable all of your plugins – move them from the /plugins/ directory. Upgrade WordPress MU to the latest.

Re-add your plugins to the /plugins/ directory, do not activate them. Upgrade BuddyPress and then re-active your plugins.

Please, please backup before you upgrade. I’m not saying this for my own health. If you have a site running that can’t afford to be down, this is critical.

Please check out the function

bp_core_new_subnav_item()

That will allow you to do what you are trying to do. The function you are using is deprecated in 1.1.

Replying to myself… I did a forum search and this should do the trick. A simple plugin to make BP components only visible to logged in users.

https://buddypress.org/forums/topic/plugin-to-show-components-to-registered-users-only#post-18381

Like wordpress fan… I also need a solution that shows different components to registered vs. non-registered users. I can’t launch without it. Unless we build to separate sites… but I really don’t want to do that. The “public” (non-members) should basically only see the main blog’s posts, pages and events. Everything else needs to be hidden until you log in. I guess a bit of PHP might fake it just by hiding navigation options. In fact, there is a thread on the forums about that. I was assuming that the new privacy module would make that information moot however.

@Anointed: It’s not that the core is “flawed”… it’s that BuddyPress is simply a plugin that sits “on top” of WordPress MU while Elgg is an integrated solution. Personally, I still prefer BuddyPress. The theming process in Elgg caused me great pain and I find the Elgg interface suffers from inconsistencies and poor usability.

@markpea I am using 1.6.1 so I am not sure what was in or out of previous versions.

My understanding of the permissions system is it has both ‘general’ privacy settings on a per component basis, with the ability for granular override of any given object. Pretty much the best of both worlds. I can set my ‘overall preferences on an object set, and decide to override an individual object should I have the need to.

I can’t think of a single downside to having both systems in place with elgg. Complete privacy control is given to the user for every object, and since it’s in the core, any plugin can hook directly to the permission system to it’s extensible.

Your right, the system for elgg is absolutely brilliant and lightyears ahead of bp in this area. I found that on my network, once I showed everyone the power of granular permission control, that almost everyone started using it instantly. (I did a demo showing how my pages are completely different depending upon the viewers permissions and people loved it).

I would estimate that at least 80-85% of my members are using granular control in one fashion or another.

@Jeff

My understanding of bp is nowhere near my level of understanding of how elgg operates, so I use that as a base for my comments. I’m guessing bp is similar in it’s approach.

In elgg, it makes no difference if ‘album objects, or any other object’ is part of the core or not when it comes to privacy. All objects have to pass through the authentication system before they are added to the given page. In fact I’m not even certain a plugin would function properly without passing through the authentication system first, never tried that.

I guess I just don’t understand why this type of system would not work in bp. Is the core really that flawed?

Still I’m glad to see that your tackling the permission system for bp. Imo bp is pretty much useless fodder without permissions.

I noticed tonight that the description in Themes for bp-default says

The template files are located in /themes/bp-sn-parent/messages. The stylesheet files are located in /themes/bp-default.

Why would WPMu be looking for template files in a directory under bp-sn-parent/, rather than in that directory?

That is very strange. There have been two other reports of something similar–except one listed /blogs the other listed /groups.

• https://buddypress.org/forums/topic/child-themes-working#post-23669
• https://buddypress.org/forums/topic/upgrading-to-1111-beta#post-23646

Please file a ticket so that we remember this issue. Perhaps with a little more information, we might be abel to find out why some people have seen this behavior.

There are so many causes of time-settings problems that you really have to dig into the threads and see if you can find what’s causing your particular issue.

Here are a few to start:

https://buddypress.org/forums/topic/time-offset-is-incorrect#post-22818

https://buddypress.org/forums/topic/the-tale-of-the-time#post-14726

https://buddypress.org/forums/topic/timezone-problem#post-11955

@Anointed

I take it that you are using Elgg 0.9 or at least a pre-1.0 version of Elgg. The granularity of Elgg’s ACL system is brilliant but in my experience of running an Elgg system for two years (https://els.earlham.edu) is that most users do not grasp the power of this system and/or forget to use it when posting to their blog for example. In addition, it seems like most if not all of the access control system has been jettisoned with versions 1.0 although I notice that 1.6 has brought something similar back. But my conclusion is that from the user’s perspective the granularity of access control that elgg provides is over the top — much more comprehensible to have all postings to a group blog be only accessible by the group for example than to have to set access for each individual post. Does this make sense?

Thus it seems to me that Jeff’s conclusion “Offering privacy control on BuddyPress’ core component objects is more than sufficient.” would actually address 99% of what I might need for a college social networking system. Also I want to say that this development is very exciting and definitely encouraging me to move over to BuddyPress. Well done Jeff!

readme.txt says,

Move “/wp-content/plugins/buddypress/bp-themes/bp-sn-parent” and

“/wp-content/plugins/buddypress/bp-themes/bp-default” to “/wp-content/themes/”

But when bp-themes does not exist, alert box with message below appears on General Settings page.

Please move the default BuddyPress themes to their correct location (move /var/www/html/test/wp-content/plugins/buddypress/bp-themes/ to /var/www/html/test/wp-content/bp-themes/) and reload this page.

Which is correct?