BuddyPress.org

Hello there,

I’m reviving this old thread cause I can’t wrap my head around the text domain.

I’ve read this thread, the codex and this example : https://gist.github.com/imath/dce8426f686da1727f82

It works for me, I understand how and the code but in case of adding buddypress-activity support to a post type created by another plugin (CBX Poll) I can’t figure out what text domain to use when I put this code in bp-custom.php

With a home made plugin I would add support at post type registration and use this custom plugin’s domain.

I guess I could use the functions.php of the theme and the theme’s domain but then it’s theme dependent.

If anyone can enlighten me…

@prashantvatsh thank you for this. My case is a little different. I want to a tab in the buddypress profile menu that shows all the site-wide forums where members can click and add topics or replies. They wont be able to create forum. Basically, I just need what I see in “homepage/forums” to be replicated in homepage/members/username/forums.

Thanks in advance

Email should work but much can go wrong including things connected to plugins, themes and functions.php or bp-custom.php files.

Presuming the email didn’t go into spam, and WordPress sent emails before installing BuddyPress, then one thing that can be tried is disabling all plugins except except buddypress and the ( un-customised ) bp-default theme.

If this is a localhost/dev site then php / server has to be correctly configured and/or upgraded for email. Alternatively WP Mail SMTP may be useful in this situation…

The main email address is set on the wordpress Settings > General page.
I would advise you check you have correct PTR record for your IP address, and also set a SPF record along with your MX records doing these two things can drastically affect how mail servers receive your mail or reject it if not happy these two items exist and check out as valid.
There may be other issues in some situations. For more info see: How to fix WordPress Not Sending Email issue

Email should work but much can go wrong including things connected to plugins, themes and functions.php or bp-custom.php files.

Presuming the email didn’t go into spam, and WordPress sent emails before installing BuddyPress, then one thing that can be tried is disabling all plugins except except buddypress and the ( un-customised ) bp-default theme.

If this is a localhost/dev site then php / server has to be correctly configured and/or upgraded for email. Alternatively WP Mail SMTP may be useful in this situation…

The main email address is set on the wordpress Settings > General page.
I would advise you check you have correct PTR record for your IP address, and also set a SPF record along with your MX records doing these two things can drastically affect how mail servers receive your mail or reject it if not happy these two items exist and check out as valid.
There may be other issues in some situations. For more info see: WordPress Not Sending Email – Mail SMTP Not Working

BuddyPress Moderator

I don’t there is anything that matches exactly what you are after but the above thread lists plugins for reporting if that is any use.

Thanks a lot for your interesting suggestions @coolhunt. I agree we need to talk about how we can improve BuddyPress documentation and about how to find help to start using/resolve issues.

We are currently working on the next major version of BuddyPress (5.0.0). As soon as it’s released, I’ll start a discussion about it from our Development news blog.

PS: really happy you like the work accomplished in Bowe Codes (although it would benefit from some improvements, but that’s another topic 😉 )

Hi @coolhunt

Everybody is welcome to contribute to BuddyPress, here are possible ways to do so https://codex.buddypress.org/participate-and-contribute/

Writing documentation, helping others in support forums or translating BuddyPress in other languages are examples of contributions which does not require development skills.

Hey, do you know what version of BuddyPress you upgraded from?
I think there used to be guides on steps required for really old versions

Hi @m4soN – The easiest place to add custom CSS is in the Customizer. See https://www.wpbeginner.com/plugins/how-to-easily-add-custom-css-to-your-wordpress-site/.

Once there, you’ll need to learn a bit about how CSS works to make the changes you want to change. Without knowing more about what “very ugly” means, it’s hard to give specific instructions. But let’s say you wanted to increase the field padding. You might introduce the following CSS:

.buddypress-wrap .bp-tables-user tr td {
  padding: 20px;
}

Here’s some more info about getting started with CSS: https://developer.mozilla.org/en-US/docs/Learn/CSS/Introduction_to_CSS

The function responsible for creating the notices is bp_nouveau_template_notices(). For example, if you override the buddypress/members/single/profile/edit.php template, you can insert <?php bp_nouveau_template_notices(); ?> just above the tabs, and the notices will show there. (They’ll also show in the original spot, which you could hide with some targeted CSS.)

To make a similar change without overriding the template, try the following:

add_action( 'bp_before_profile_field_content', 'bp_nouveau_template_notices' );

Hi @sibahmed, and thanks for the post!

Unfortunately, BuddyPress doesn’t have these kinds of fields built in. They’re called “nested” or “conditional” fields, and they’ve been requested in the past – see https://buddypress.trac.wordpress.org/ticket/579. It’s a large job to build it as a feature for BuddyPress, though it’d be easier to build a custom tool for yourself that does this.

If you’ve got the technical experience, you could a custom BP_XProfile_Field_Type, whose edit logic would contain the markup and JavaScript to enable these sorts of fields. I did some quick searching, and it looks like someone was writing this at some point – see https://rimonhabib.com/coming-up-next-buddypress-nested-conditional-fields/. Maybe worth following up there?

@boonebgorges I hope BuddyPress continues to grow and improve. We based our whole business around BuddyPress for many years for a reason. I know it has taken a tremendous amount of work to get the plugin as far as it’s come, and we are grateful considering you guys have done all of this voluntarily. I can tell you from experience that even when you are paying a support team, it is still very difficult to stay on top of all the support requests, so to do it for free at any capacity should be appreciated.

Hi @cassel – Thanks for the post!

I’ve just installed All In One SEO to try to reproduce. Looks like the line numbers have changed – I’m seeing 5711 now, instead of 4735! – but the error is still there.

Looking into the all-in-one-seo-pack code, it appears that this error only occurs if you haven’t yet saved the options for this plugin. Once you’ve done so, the error ought to go away.

For the record, I was able to trigger this notice even without BuddyPress.

I’ve opened a ticket with the All In One folks to let them know about the bug on their end, so stay tuned at https://github.com/semperfiwebdesign/all-in-one-seo-pack/issues/2805 ! In the meantime, you might consider forcing errors not to be displayed on your production site – always a good idea. See https://www.wpbeginner.com/wp-tutorials/how-to-turn-off-php-errors-in-wordpress/

BuddyPress is not approaching EOL. As @sbrajesh noted above, BP is coming up on a 5.0 release that’ll include, among other improvements, REST API endpoints for our major content types. The development team believes this is going to be an important step in making BuddyPress more powerful as a foundation for community development.

I acknowledge that the amount of activity on the project has not been consistent over the last year or two. The BuddyPress project – the development of the plugin itself as well as the manning of these support forums – is 100% volunteer driven. BuddyPress is not a business, and as such, no one is paid by BP to work on BP. The central group of volunteers who work on BP development and support is pretty small, which means it’s quite sensitive to fluctuation in activity; if just one or two active members get busy with other work for a while, it can have a significant effect on the pace of the project. In contrast, Michael and Brajesh are both correct when they note that businesses with paid employees are able to devote a much more concentrated and consistent amount of effort to their products.

While it’s disappointing that the BuddyBoss team’s improvements haven’t been integrated into BP, I completely understand the reasons why their team has opted to fork rather than contribute. Personnel issues aside, the pace of development of a widely-used open source project, developed in a decentralized way with loose management, is necessarily going to be slower and more conservative than a private product. And it makes sense that a business owner would want 100% control over the direction of their core products. I respect the BuddyBoss folks and wish them the best of luck with their platform.

All this being said, I continue to believe that BuddyPress is the best community solution of its type, particularly for those users who need maximum flexibility and customizability. My limited experience with BP’s direct competitors in the WP market is that they work nicely for their central use case, but it’s extremely difficult to modify the default behavior.

As someone who’s been involved in BP for a long time and cares a great deal about the project, I must extend thanks to the folks in this thread who are here, demonstrating their concern for the well-being of BuddyPress 🙂

Hi Michael,
Thank you for sharing the insight and the goals. It helped.

I agree with your business objectives and the fork makes sense for your customer.

I am sure looking forward to see how your team speeds up BuddyPress. It should be easy for the community to port that to BuddyPress core.

I have been an admirer of your designs. Wish you and your team all the best!

@coolhunt,
I agree with you on the issues with BuddyPress. I hope that things will change in future.
Please do note that number of plugins is not an issue(even if it is 50 or 100). It is a misconception propagated by few. It is the quality of the plugins. Number of plugins don’t have much effect on speed. Keeping it to the minimum helps you remain secure( low number means lower chance of having an insecure plugin) and easy management of the plugins.

Regards
Brajesh

WP community ALWAYS preaches to have as little plugins as possible – but get getting buddypress to be usable takes at least a dozen

That’s one of our primary goals, to fix this. We want our platform to have every feature you could need in a social network out of the box, in a unified experience both frontend and backend, and all optimized to work together. That’s the direction we are moving towards.