Forum Replies Created
It could be the fact that BP Privacy sends its request to BuddyPress core to check current login status before WP-FB-Autoconnect registers the fact that a user is logged in. But, I’m guessing it is more likely that WP-FB-Autoconnect does not properly hook into BuddyPress–at least that is what the second post in the thread I linked to indicates.
The firing sequence of WordPress and BuddyPress action and filter hooks is a little understood a greatly ignored area. See my other plugin group for more information on that topic: https://buddypress.org/community/groups/wordpress-hook-sniffer/forum/topic/wordpress-hook-sniffer-a-developers-plugin-updated-to-v0-15/
I’m not too sure how reliable the WP-FB-AutoConnect plugin is with BuddyPress in general. See this thread: https://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/creating-accounts-with-facebook-plugin-wp-fb-autoconnect/ Also, search for other threads like it on BP support forums.
Either way, this must be some issue with how that plugin interacts with BuddyPress as the coding in BP Privacy to check whether someone is logged in is a simple call to BuddyPress’ is_user_logged_in() function. See the coding on line 1093 of the bp_privacy_site_lockdown() function in the bp-authz-api.php file.
There is nothing else in BP Privacy that would or could prevent this from working. It has to be an issue with BuddyPress clashing with the WP-FB-AutoConnect plugin. The BuddyPress is_user_logged_in() function is not passing the proper information back to BP Privacy. This means that other 3rd-party plugins, as mentioned in the link above, will also have issues when people are using WP-FB-AutoConnect. It is not an issue caused by or endemic to BP Privacy. Plugin conflicts are the downside to open source systems.
As this appears to be an issue with how that plugin interacts with a very crucuial, core BuddyPress function, I suggest that if you cannot get this to work, contact the author of WP-FB-AutoConnect.
I have seen a few comments where I get the impression that people are using the special privacy template functions without actually having installed the special privacy templates. If you want to use these features, make sure the /privacy theme directory is properly installed. See the readme.txt file. It is reproduced on the group’s home page. Look for the ”Installing the Optional Special Privacy Template Files” section.
Note:This is an item that should be noted for future development. Site Admins should not be able to even see the privacy admin settings sections for the site lockdown options if the /privacy template folder has not been moved into the proper place.
So, you are talking about the admin setting screen? Yes, it may be that I forgot to internationalization that outputted text. Please ask another developer how to do it. It is not that hard, just look at how other outputted text lines are internationalized.
Of course, once you have added new internationalization lines, you will have to generate a new pot file and then create your new translation file.
It has been two weeks since I released BP Privacy to the community. As I have not yet seen any expressed interest on behalf of the community to adopt BP Privacy, I thought I would post a reminder, bumping this topic back into the forefront of the support threads.
I have invested considerable time crafting a detailed manual that should help any team of developers who wish to continue this project understand the BP Privacy codebase. Furthermore, there are extensive comments throughout the codebase that elucidate why something is done in a particular way. Finally, as mentioned in the above post, the future.txt file that ships with BP Privacy includes a long list of items that I felt a developer team should focus on in the next release cycle.
Please remember that BP Privacy is a release candidate and that it was developed to be compatible under WP 3.0.5 and BP 1.2.7. Therefore, if you are running it under WP 3.1 and BP 1.2.8 and find that it does not work (parts of it won’t) it is not that it is broken. Instead, it is that it is not compatible with those versions. Therefore, do not down vote this plugin if you are using it in an environment for which it was not designed. Instead, apply the fix offered in the link in my above post. If it still does not work, report back here. Only through sharing your experiences with BP Privacy will a development team be able to help troubleshoot future issues.
This plugin is currently the only full-service privacy plugin available. The longer the community waits to adopt it, the harder it will be to bring it into compliance in the future. There are major changes coming to BuddyPress in version 1.3. A team should be working with BP trunk and BP Privacy right now to refactor its codebase so that the plugin continues to be compatible going forward.
The community has been crying for 18 months for a Privacy Component. It now has one. If someone or some team does not adopt BP Privacy soon, then the community will be back at square one. I hope that BP Privacy either gets adopted (in full or in part) or that another team offers up their vision of a BuddyPress privacy component. Do not let this major resource rust into oblivion!
You have created a new thread in the wrong plugin group. This group is for BP Privacy, the plugin that offers privacy for 4 of BuddyPress’ 6 components. What you are discussing is BP Profile Privacy, the plugin that focuses solely on offering profile privacy.
Please continue your discussions on BP Profile Privacy’s Group forums.
Since I cannot move this thread into the proper group’s forum, I’m closing this thread.
With yesterday’s release of WordPress 3.1 and BuddyPress 1.2.8, I wanted to point you in the direction of at least once set of fixes that will be required to allow Site Admins to see and use the BP Privacy admin settings menu. Please read this post by @boonebgorges on the BP development blog.
Also, as is clearly stated in a number of places, BP Privacy requires PHP 5.2.x, WP 3.0.5, and BP 1.2.7. Therefore, if you are running BP Privacy under any other configuration, do not be surprised if it does not work. The above linked-to few changes may not be the only things that break BP Privacy.
As BP Privacy is in the hands of the community, if there is interest in seeing this plugin continued into the future, I suggest that someone make note of these changes and any future changes so as to keep BP Privacy updated as both WP and BP evolve.
Finally, as noted in the readme.txt file, I have included an large list of items to address in the future.txt file that ships with BP Privacy. The extensive BP Privacy Manual (which also ships with the plugin) is a great resource for any developer or team. It contains a wealth of information designed to help you learn the BP Privacy codebase.
I thought I would pop in for a few comments. First, thanks to all who have expressed their opinions in this thread. Second, there are only a very few people who seem to be having issues getting BP Privacy to work. It is clear that these people have not taken the time to read the manual.
So, if you are having issues, here are two pieces of advice. As stated on the very bottom of the first page of the first section of the BP Privacy Manual (Section A. BuddyPress Privacy Overview), if you are testing BP Privacy logged in as a Site Admin, then you will see all of your users’ data as Site Admins are exempt from the impacts of privacy filtering. So to see BP Privacy in action, filtering out a user’s items, you must test BP Privacy as a regular member, not as a Site Admin. Of course, you will also still see items if you are logged in as yourself and viewing your own items. As different browsers have different behaviors, just to be on the safe side, if you have recently logged in as Site Admin, it is advised that you clear your cache and cookies after logging out and before viewing as a non-logged-in user or logging back in as another user without admin privileges.
For those few people having issues getting BP Privacy to work in the first place, make sure that you are using at least PHP 5.2, WordPress 3.0.5, and BuddyPress 1.2.7 (as stated in the readme.txt file and a number of other places.). If that does not help, then read section xiv (Troubleshooting BP Privacy, pages 18 – 21) in the BP Privacy Manual as you may be having conflicts with a custom theme or with another 3rd-party plugin.
As far as those few who have complained about BP Privacy’s complexity, you are free to your own opinions. After extensive testing, this UI and UX was deemed sufficiently easy to comprehend by most people. It does not get much easier than selecting a single privacy setting for all your profile or activity stream items that gets applied globally. For those that want more fine-grained control, they have options as well. Site Admins also have the ability to limit the number of ACL settings that a user sees. So if you think there are too many filtering levels, you have the option to limit it to just a few options.
BP Privacy is also much more than just as simple privacy filter for profiles or a simple privacy filter for activity streams. If that is all you want, then you should use a privacy plugin that provides just that single service. But if you want to offer a suite of privacy filters to your users (profile, activity stream, friends, and messaging), then BP Privacy is currently the only option available.
BP Privacy was designed to offer flexibility, to offer a number of ways in which a Site Admin could configure it to meet the needs of their particular community, and to offer several levels of privacy filtering control to users. It is not a plugin that forces you and your site into one way of doing things. This is why BP Privacy is more complex under the hood. If you really are a PHP coder, take the time to understand how things are done. Explore the extensive codebase. If you are a designer, then you can alter the layout as you see fit as BP Privacy does not require it’s own templates and it has only a handful of CSS selectors used for UI (design) output.
If you have issues with BP Privacy, you are free to fork it, to bend it to your desires. It is in the hands of the community. You also have the freedom to create your own privacy plugin from scratch. Of course, that freedom was always available and only a handful of people chose to do just that. Remember, I have never been a member of the core development team nor was BP Privacy ever intended to be merged into core. Although some may have had that impression, that was never my goal. BP Privacy has always been a 3rd-party plugin project.
And just to be clear, as I’m sure that some people will have unfortunately failed to see one or more of the 10 or 12 places in which this is clearly stated, “This plugin is a release candidate version to be used only in a development sandbox and not in a production environment. Use at your own risk.”
I hope a team adopts BP Privacy and continues developing it or uses parts of it in a new privacy project.
Another nice catch. I’ll update next week sometime.
You have a good point. I’ll unlock your thread. I suggest that you place a link back to this thread (for reference) and explain why you’re creating a new thread so that some other moderator does not do what I did!
So, you’ve managed to output the tab but cannot get the link to work?
Have you looked at the Skeleton Component–in particular in bp-example-core.php at the function bp_example_load_template_filter() and the section below that entitled “Screen Functions”?
You’re welcome! I’m glad you are up and running with BP Group forums.
With respect to a forum control panel in WP’s back end, you are not missing anything. When using bbPress as a BP Groups forum component, there is no sitewide bbPress admin control. Instead, each BP group has the ability to have its own forum. To get the group forums to work, a group admin has to navigate to the given Groups “Admin > Group Settings” menu and click the “Enable discussion forum” checkbox.
Your issue should be easy to fix!
1. Before going through this process, double check to make sure that the bbpress directory exists under /plugins/buddypress/bp-forums/. It should be there as it comes with a clean install of BP.
2. Assuming that checks out, then the next step is to make sure you have a backup of your MySQL database.
3. Now delete, or in DB parlance, drop the unneeded bbPress tables from your database.
4. Finally, go back to your WP admin screen and navigate to “BuddyPress > Forums Setup” and follow the instructions.
There may be a meta record that tells BP that you’ve already installed bbPress. If BP thinks that a bbPress instance has already been installed, you’ll get some verbiage like the following:
“bbPress forum integration in BuddyPress has been set up correctly. If you are having problems you can re-install”
If that is the case, just click the “re-install” link.
A successful bbPress install will have two bb-config.php files. The primary one will live at the root level of your WP install. The second one will be located at /plugins/buddypress/bp-forums/ and is a single one line piece of code to stop unauthorized access to your forums. It should not be an issue to delete the version living at the root level of your WP install as the process of installing bbPress for BP Group forum use creates this file. Do not delete the second, lower-level version of this file.
Please see my first post in this thread as I may have been editing it as you were typing your response.
As for your immediate post question above, the table prefix is not necessarily an issue (but it could be). It really depends on how you are trying to use bbPress (as a standalone forum, or solely for BP Group forums).
But, to get to the heart of your issue, we need to clarify in what way you’re trying to use bbPress.
Are you trying to integrate an existing bbPress install with BP group’s? Or, is this a brand new bbPress install with no data?
If the latter, there is no reason to do a separate install of bbPress. BuddyPress comes with a barebones version of bbPress already. It allows BP Groups to each have their own forums. However, it does not allow for the creation of a sitewide forum.
If you have an existing bbPress forum that you’re trying to associate with BP, then the bbPress tables must be installed into the same database as your WordPress tables. Make sure that you have read this BP Codex article: https://codex.buddypress.org/buddypress-site-administration/using-an-existing-bbpress-installation/
Finally, if you’re trying to have a standalone, global bbPress forum on your site, and not just have BP Group forums, then read this: https://buddypress.org/community/groups/how-to-and-troubleshooting/forum/topic/how-do-i-create-a-non-group-specific-forum
That’s not possible with BuddyPress at this time. See this: https://codex.buddypress.org/getting-started/faqs/
In fact, I don’t see this ever being an option in BP–even when the new bbPress plugin becomes available. Both BP and the upcoming plugin version of bbP are software layers that sit on top of WordPress. So each is responsible for their own sets of data access functions. Even with BP Group-based forums, the bbP functions are being hijacked to work within BP but only barely.
To have a standalone install of bbPress functioning in WordPress (which is what would give you a site-wide forum) requires a process called deep integration. For more information on integrating bbPress with WordPress, search the WP or bbP forums. Or better yet, just wait until the pluginitized version of bbPress is available!
The way in which you check to make sure BuddyPress is installed and activated has changed over time. As @djpaul indicates, the proper way is to use a mypluginname_loader.php file and hook into the bp_include event: https://codex.buddypress.org/extending-buddypress/checking-buddypress-is-active/
The BuddyPress Skeleton Component is woefully out of date a this time. So you should use it as a general guide only. To get a clearly understanding of how things are done, I suggest studying a few of the more popular, major custom components that work with the latest version of BP.
Oops! Nice catch. It is next Monday, November 15 as detailed in my BP update here: https://buddypress.org/community/members/jeffsayre/activity/115287
Interesting write up, @peterkirn. Please suggested this topic as a possible agenda item for tomorrow’s BP dev meeting: http://bpdevel.wordpress.com/2010/10/30/the-next-dev-chat-will-be-on-wednesday-3/
Also, I assume that you’ve seen this older thread started by @foxly? https://buddypress.org/community/groups/requests-feedback/forum/topic/here-come-the-spammers/#post-52663
[blockquote]Jeff, yes, I like MAMP, but also wanted to avoid creating lots of copies of Apache and php et al – and I want to run on port 80 anyway…[/blockquote]
I have a single Apache/PHP install (the default MAMP version) and simply use Apache’s virtual host directive to host 9 different WordPress development sites locally. They all have their own test domain (they do not use “localhost”), and they use the default Apache port (80) and MySQL port (3306). It’s simple to set up and manage. This is done with MAMP not MAMP Pro. If you don’t know how to do this, then MAMP Pro will do it for you.
I gave up a long time ago rolling my own WordPress and BuddyPress installs directly on OS X. It was too much of a pain for very little benefit. I switched to using MAMP (the free version) and both install easily without issue.
“For BP 1.3, we’re going to add current_user_can checks throughout so if someone wanted to add a capability to a certain role or user, they could.”
Providing that flexibility is nice. However, with the exception of groups, there is no reason that the current BP core components need to offer the ability to assign roles. Why would a user want to grant someone the right to control their personal content? Facebook and Twitter don’t offer users that option.
Blogs, which live outside of BuddyPress, are different of course. It makes sense to allow blog owners the ability to add helpers to their blog, to allow others to add content as authors or editors, etcetera. In BuddyPress, this type of collaboration is also currently possible with the group component.
But for all other core components, assigning additional roles seems like a bad idea as the focus is on individual users creating their own content which they alone control.
With the limited exception of BP groups, BuddyPress offers only one role — that of user. The forums are controlled by bbPress code, integrated into BuddyPress, but it’s bbPress that is in control of offering additional roles. Even when bbPress is relaunched as a WordPress plugin, forum roles will still be controlled by bbPress.
BuddyPress is a social layer that sits on top of WordPress. As such, the notion of user and author are synonymous. What does all of this mean?
With the exception for BP groups mentioned above, BuddyPress is a user-centric platform where there are currently no-jointly owned or controlled subsets of data. Ignoring the overall Site Administrator, in BuddyPress, there is a one-to-one relationship between a given piece of datum and a single owner of that datum. The key is who owns data. That person is the one with ultimate control (ignoring the super admin). Even with groups, the original group creator is the owner of the group–at least until he or she adds another admin. Group mods do not own the group data, they just help to manage it. Now, if the original group admin leaves the group, the new admin becomes the sole owner.
So user roles are irrelevant to the operation of BuddyPress as it focuses on users and not user roles. It is a social networking layer after all and not a content authoring and management layer like WordPress.