Forum Replies Created
Has the project decided what to do about the product?
The problem with asking contributors who put so much time into a project in its early days, is that those people often have rose-tinted glasses and inaccurate memories of what worked well and what didn’t, and what they wished they could have done differently. 🤩
BuddyPress at the start was “Facebook in a box”, and broadly remains the same today. Facebook, on the other hand, has changed dramatically.
If it were down to me, I am not sure if I would replace BuddyPress’ systems while building new things and break backwards compatibility on purpose, or decide to keep legacy BuddyPress secure, and have current generation contributors start on a new plugin.
Very few websites stay up as long as BuddyPress is old, so I think in reality, the impact of starting from a clean slate is all about attracting new users, rather than worrying about trying to get old sites to migrate (any old site isn’t going to change dramatically). You’d still have the same challenge – attracting new users! (You could build a migration script in due course).
I believe the actual question is, what does a self-hosted social network look like *today* (and what kind?), and where might it go in the future? Build toward that aggressively, and be bold and remove things that aren’t in that vision.
For me, my next would focus around concepts from Discord, Slack, TikTok, Instagram.
Don’t resurrect old threads please. A new discussion would have been fine.
Have you tried example.com/me/friends ? I think it only works like that.
Unfortunately, it’s unlikely that file permissions are related to any change we made in the 4.0 release. I don’t know how they might have been set incorrectly, though if you’ve used any plugin installer or tool to add a plugin or update your site in the past, that might have been the cause.
You or someone who manages your server needs to go into the bp-core/classes/ folder, view the file permissions, and change those of the phpmailer file to match the other files which are (presumably) correct.
It’s not really the place to try to sell your plugin on our support forums, please; it’s rude.
WP Mail SMTP seems to be a well-written plugin. I’ve taken a quick look at its code, and how it affects what WordPress does, and it looks like BuddyPress – in theory – should work with it. However, if you say it doesn’t, I don’t know why – you’d have to spend time debugging what is going on.
If you know some PHP and basic WordPress development, I can give you some pointers (e.g. start looking at the phpmailer_init hooks and how both plugins add to it).
No need to try to un-hook where BuddyPress adds it. The
body_classfilter passes an array of class filters. I’d just filter it, and find and unset the no-js class you don’t want.
Nope. Try it and if you find an issue with BuddyPress after doing so, then start a discussion.
@whoweez This old code sample does nothing much at all. I’m not sure what the intent was, this is basically debugging. To answer your specific question:
I thought “__return_false” on “bp_email_use_wp_mail” should prohibit any BP emails from being sent in the first place as the new class should handle the email sending process…?
If that filter returns true, then BuddyPress generates a plain text version of the email, and calls WordPress’
wp_mail()function. By default, this is false, but it returns true if
wp_mail_content_type()has been configured for HTML, or if
wp_mail()has been redeclared (it’s a pluggable function).
That last bit is key. A lot of email plugins for WordPress re-declare
wp_mail(), so for BuddyPress to use those plugins, the default behaviour is to send that plain text version of that email.
bp_email_use_wp_mailreturn false, then it creates a
BP_Email_Deliveryobject, which is what that second filter is changing, which delivery class BuddyPress uses. Inside that class’
bp_email()method is where you would create a custom integration with your Sendmail plugin (or however you approach that integration).
This is a false positive. It’s a custom function. See https://github.com/buddypress/wp-cli-buddypress/blob/master/features/bootstrap/utils.php#L426
There’s no planned overlap. BuddyPress doesn’t provide any Gutenberg blocks.
If you’re referring to some of the extended profile field types that allow HTML, I expect those will stay as TinyMCE for now.
Have you checked the resolution of the image? Maybe it’s just too low.
The log in widget, and the activity stream comment bugs, will be fixed in v3.1.0, which will come out before the end of next week.
It’s likely that any new features will be added to Nouveau, and not Legacy.
It’s up to you which you want to support or build from.
Yep, you’ll want to use a survey plugin for this, and probably code some sort of integration yourself.
I don’t know about “simple”. The function in BP is bp_update_user_last_activity() and that calls WordPress’ user meta functions. I am positive there are filters within that stack you could use to override the value or prevent the writes, but you’ll need to look into that code yourself.
@boonebgorges Do you think we can stop this mirroring yet? And keep
_bp_get_user_meta_last_activity_warningin place. Basically, preventing DB writes.
It’d been helpful if you’d linked to it, @venuitius 😉
I’ve just tried searching myself and couldn’t find it.
At any rate, this is not a BuddyPress problem — it’s an out of date and unsupported plugin.
We are looking at trying to introduce some of these field types into the main BuddyPress plugin for future versions (it will happen, just a matter of number of contributors and time).
Our position is that we want BuddyPress to provide tools that help site owners comply with privacy legislation.
Our 4.0 release, about a month away, will be our first pass at this. Read the latter comments in https://buddypress.trac.wordpress.org/ticket/7698 for linked/related tickets, as well as https://buddypress.trac.wordpress.org/query?status=reopened&status=assigned&status=reviewing&status=new&status=accepted&group=status&milestone=4.0 to see all issues assigned to 4.0 (7855, 7856, 7866, 7867, etc).
I can’t see any code change in 3.0 that might have affected this. This filter is called in three places, and each place we pass eight parameters.
If you can debug this, perhaps with
wp_debug_backtrace()and find a code execution path, that would be handy.
We have this fixed for our next release, v3.1. This will be released next week (Wednesday) at the latest. The bug was addressed at https://buddypress.trac.wordpress.org/ticket/7869
@alpokoskiniva “Repair email” deletes the emails from the “Emails” menu, then re-adds them. You don’t need to do this unless you’ve added a translation to your site after installing BuddyPress, and want the translated emails, or if you’ve made a code change to the email language in the BuddyPress files, which is what @filipponeri20 has done. We strongly recommend that no-one ever changes a core file of BuddyPress, because it will be overwritten when you update.
You need to talk to whoever runs your server. It’s possible the PHP error logging configuration is different on each.
Furthermore, you can see the problem comes from the folder
/plugins/buddypress-links, which is not BuddyPress itself.
I haven’t seen BuddyPress Links in a long time — I’m assuming it’s not compatible, and that your PHP configuration is indeed different (you were probably suppressing the error before).
We can’t help more.
Imagine a BuddyPress Template Pack as something analogous to a WordPress theme. You can’t have a child theme compatible with multiple parent themes.
And you can’t have a template pack compatible with multiple themes. I don’t think there is anything in the template hierarchy – like the named folders that you suggest – that would let you do this. I suppose we could add something but I do not think this would be a good thing for the project at the moment.
We have discussed a concept of multiple small template packs being active at the same time and we might want to support this sort of folder structure then. But not now.