BuddyPress.org

https://wordpress.org/support/topic/need-a-cheap-reliable-hosting-for-my-buddypress-network?replies=2
https://buddypress.org/community/groups/buddypress-hosting/forum/
“Cheap” is relative.

The weird thing is that the BP Activity component link is working while the Members and Groups component links are not working.
Do you have any membership plugin turned on which requires Is_user_logged in?
If you change theme to bp-default theme are the links to Members and Groups working?

https://wordpress.org/extend/plugins/buddypress-badge/

I would add it as a sub domain then. You could do a different install all together or put your WP install into multisite mode and use the instructions in the link below.

https://codex.buddypress.org/getting-started/install-buddypress-on-a-secondary-blog/

https://codex.buddypress.org/extending-buddypress/changing-internal-configuration-settings/
`define ( ‘BP_ACTIVITY_SLUG’, ‘wall’ );`

for the rest: https://codex.buddypress.org/extending-buddypress/customizing-labels-messages-and-urls/

You can use the code from plugins/buddypress/bp-themes/activity/post-form.php to cobble a post form on other areas of a site.

I would be interested to hear more about the project. I already run 123flashchat software, and absolutely love it. It is not currently integrated into bp, but it could be. I run a flash comm cluster in order to use the video chat and live video broadcasting. I would warn people first, that bandwidth is a huge issue with video.

Hi @BuddyPresser,

I would like to add to Javier’s @arques post above. His method does work but it’s missing the initial sign-up screen where gravatar is being pulled. I also rewrote his path a bit. This should do the trick for killing all Gravatar calls. If someone has more time than I it would be great to have this in plugin form. Here is the code:

`
function bp_remove_gravatar ($image, $params, $item_id, $avatar_dir, $css_id, $html_width, $html_height, $avatar_folder_url, $avatar_folder_dir) {

$default = get_stylesheet_directory_uri() .’/_inc/images/bp_default_avatar.jpg’;

if( $image && strpos( $image, “gravatar.com” ) ){

return ‘‘;
} else {
return $image;

}

}
add_filter(‘bp_core_fetch_avatar’, ‘bp_remove_gravatar’, 1, 9 );

function remove_gravatar ($avatar, $id_or_email, $size, $default, $alt) {

$default = get_stylesheet_directory_uri() .’/_inc/images/bp_default_avatar.jpg’;
return ““;
}

add_filter(‘get_avatar’, ‘remove_gravatar’, 1, 5);

function bp_remove_signup_gravatar ($image) {

$default = get_stylesheet_directory_uri() .’/_inc/images/bp_default_avatar.jpg’;

if( $image && strpos( $image, “gravatar.com” ) ){

return ‘‘;
} else {
return $image;
}

}
add_filter(‘bp_get_signup_avatar’, ‘bp_remove_signup_gravatar’, 1, 1 );
`

The image that I am referencing doesn’t have to be a JPG. The size is 150×150. You may have to adjust the file name and/or path to your liking.

Thanks @arques for the initial code!

Team up with a host that can do it. like make a deal with them where they will host your plugin user then your plugin user pay for the hosting. How much would it cost if there just hosting the video and thats it. Im looking for a video chat.

One approach might be to configure php.ini to use the smpt localhost and port lines (i.e uncomment) and set an explicit sendmail_from address or simply configure sendmail,

I’ve never had an issue with sending email reg confirmations from a test environment but then I scrabbled around and worked out how to configure ‘fake sendmail’ which essentially amounted to stating a true smtp server to use e.g my main email account.

This is one of those issues that is not really application based necessarilly but more server OS oriented and finding a solution may be quicker focusing on these aspects rather than WP/BP and perhaps trying in a WAMP forum? or XAMPP? for a solution?

Nice of you to congratulate yourself for solving the problem. However, these posts show up on search results so it would be good protocol for you to explain your solution. Cheers!

I also have found myself torn about using pages for BP directories. In the end, though, I think it’s a compromise that works out for the better in the short- to medium-run, and does not have awful long-term consequences.

In my view, it is a gross overstatement to say that this move ‘ruins’ BP. However, there are a few things about it that are unappealing:
1) It forces the creation of what are, essentially, dummy pages – whatever content you might add to the page through the normal WP editor is totally ignored
2) Related – It uses part of the WP page infrastructure (URLs) without using others (in particular, WP page templates)

Problem (1) is unappealing, but it is mitigated by a couple of points. First, the current system is not a whole lot better. Instead of having ‘dummy’ pages that you can see in the admin (like BP trunk has), the current version of BP has ‘phantom’ pages, so that when BP detects a URL like example.com/groups, it essentially hijacks the page load in order to do its own stuff. This is a bit jarring, and not at all transparent. So there is a trade-off, but it’s not all bad. Second, while the idea that ‘Pages in WordPress are supposed to be static content’ seems right to me in broad strokes, it doesn’t seem to me to be a hard-and-fast rule. Many plugins (gallery plugins, ecommerce plugins, etc) display their content by means of a shortcode that is manually inserted on a page or post, with pages being used for their pretty URLs.

On the other hand, there are some real benefits to directories-as-pages:
A) Easier URLs (as @driz has noted)
Integration into WP 3.0-type menus (this is the big one IMO)

How important are things like (A) and (? For sites maintained by folks with some PHP chops (and organizations with money to pay people with PHP chops), they could be fairly easily accomplished with BP_GROUPS_SLUG, etc, and with some other finagling. But – and this is just a guess – this profile does not match most of the users of BP. Nor should it, necessarily. To the extent that BP can be easy to use and install for people with little technical knowledge, without at the same time making it less flexible from a developer’s point of view, it should be. This change is good for end users, and is no more difficult for developers than the current technique, so it seems like a net win.

Another more theoretical argument for the directories-as-pages move (especially as compared to the new admin panel @driz suggests for changing slugs) is that BP shouldn’t reproduce functionality that WP could provide, unless there is a convincing reason for doing so. Using WP pages for BP directories is a step toward greater BP-WP integration. It’s not perfect (see my problem (2) above) but it is a start.

As for custom post types: It’s likely that at least some of BP’s components will be refactored to use custom post types in the future. When that happens, part of the upgrade script will probably involve removing the dummy pages at issue here. So from the user’s point of view, the transition will be seamless.

I should say that I am in agreement with a lot of the sentiment in this thread about making BP a bit more lightweight, framework-y, and disjointed than the sometimes hulking behemoth it is now. However, that kind of transition can and probably should be gradual (at least more gradual than the 1.3 release).

Thanks @r-a-y , I’ll give it a go.

@r-a-y

I am a big fan of Justin’s and have read that particular post several times in the past. I mostly agree with his arguments, but my view is even a bit more extreme, since even when you remove the term “framework” they still box you into an API that is impossible to break out of, which is not developer friendly in the long run.

There are a lot of themes that I think do this on purpose, because it fits their business model

@bgrun80 I’ve added you as an Editor on the codex. (The script that is supposed to handle this setup automatically has been acting buggy lately.)

When you load a URL that matches a pattern that BP is looking for (eg /members/boonebgorges), BP first finds the corresponding data in the database (in this example, the profile data for a member matching the name ‘boonebgorges’) and then loads the theme file designated for this kind of data (members/single/home). In broad strokes, it’s not that different from how a standard WP post query works.

The relationship between core files is conventional. For something like the groups component:
– bp-groups/bp-groups-templatetags.php contains all function that are called from theme templates, along with the loop builder classes
– bp-groups/bp-groups-filters.php contains the functions that modify the output of the groups component via apply_filters(), plus the application of any WP-native filters like kses
– bp-groups/bp-groups-classes.php contains the database classes (for the most part, the -classes.php files should be the only place where SQL statements appear) as well as any other miscellaneous classes (like the BP_Group_Extension class, in the case of groups)
– bp-groups/bp-groups-notifications.php contains the functions that format and send email notifications related to the group
– bp-groups.php contains some setup functions for the component (like groups_setup_globals() and the functions that set up navigation), as well as any other functions that don’t have a natural home in any of the other files listed above.