BuddyPress.org

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?

Me too! An privacy option is very important. This http://devbox.computec.de/2009/06/buddypress-xprofile-privacy-plugin/ does not work with 1.1

Edit: it does work! But user must select before. But privacy fields like birthday etc. should never be visible for guest. Maybe with an click to activate, but at the moment thats not good.

@sschablow

The auto upgrade usually does its job. But you are using a version of WPMU (2.7.1) that is 5 months old. Also, you were attempting to upgrade from a version of BP that was at least that old as well.

Whenever that many months have elapsed between your updating software versions, it is wise to check the readme.txt files and make sure that the versions you are using are compatible with each other. Had you done so, you would see at the top of BuddyPress’ v1.0.3 readme.txt file that you need at least WPMU 2.8.1.

=== Plugin Name ===

Contributors: apeatling

Tags: wpmu, buddypress, social, networking, profiles, messaging, friends, groups, forums, activity

Requires at least: WordPress MU 2.8.1

Tested up to: 2.8.1

Stable tag: 1.0.3

During those five months, many updates have been made to both platforms. In fact, it is recommended that you upgrade WPMU to 2.8.4a for security reasons. Here’s some information that might help in upgrading WPMU.

As for your comment here:

Crash occured after fatal error during BP upgrade (If it’s not possible to upgrade automatically you REALLY SHOULD REMOVE THAT S***[edited for content] FROM THE OPTIONS. DAYUMN. )

That is an issue. I’m not sure that it has been reported, but as you are the first to report such a bug in the BuddyPress forums, you should check in WPMU Trac and see if it has been reported. If not, add a new ticket.

Before activating BuddyPress, did you delete the /bp-themes/ directory? If you do not, and then activate BP and choose the new theme framework, BP can have issues resolving which theme system–the old or the new–your wanting to use.

Next version is a minor release to work with BP 1.1 but yeah I’d like to do that.

The achievements plugin is pure awesome. A truly great way to incentivize participation, all with a nice sense of humour. I’d love to a builder-type tool to allow admins to create new achievements without writing code..

Report it as a bug on https://trac.buddypress.org/ – use the same username and password that you do for these forums.

@sschablow : Please try by renaming plugins folder to tmp_plugins or something.

I have deleted it and now it shows this error message

‘You do not have any BuddyPress themes installed.

Please move “/wp-content/plugins/buddypress/bp-themes/” to “/wp-content/bp-themes/” and refresh this page. You can download more themes here.’

are u sure deleting is correct?

Jeff, where do I sign up for the alpha tests? I’ve been contemplating the “Members Only” plugin limiting access to registered users. Aside from the question of how it would work with BuddyPress (any experiences with MO?) there is the granularity which your component seems to offer. I want some of my membership site open to the general public, but the core information – profile data – I want to provide access to premium subscribers.