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.
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.
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_class filter passes an array of class filters. I’d just filter it, and find and unset the no-js class you don’t want.
@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.
If bp_email_use_wp_mail return false, then it creates a BP_Email_Delivery object, 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).
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_warning in 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).
@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).
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.
Viewing 25 replies - 1 through 25 (of 6,157 total)
