I am pretty sure this is fixed in trunk for 2.6, but it’s a bug that’s come back a few different times, so I try to keep an eye out for it.
Sorry for the trouble!
Thanks for the frequent updates to this. It’s really cool to see the iterations!
It looks like a conflict is causing the WPML language parameter to be added before bbPress adds its /edit/ endpoint.
I suppose it’s possible inside bbPress to try and handle that differently, but I’m reluctant to make it too fancy since it might break something else.
Without really looking, my guess is that WPML should filter the permalink at a later priority (as late as possible) so that all other filters have a chance to hook in normally first.
You may want to start with the bbPress 2.6 release candidate instead. It comes with numerous improvements to the forum converter that will help speed up your migration.
You can download RC 5 here: https://wordpress.org/plugins/bbpress/advanced/
Changes coming in bbPress 2.6 will make this easier for BuddyPress to keep a tab on.
Sounds related to caching. What (if any) caching plugins are you using?
I’ve made the following change, and it will be part of the 2.6 release.
https://bbpress.trac.wordpress.org/changeset/6728
Until then, I’m afraid you’re a bit out of luck. There really isn’t a great place to filter that exact value other than the place I just added.
@websmyth Also fixed a bug I just found with it in r6727.
Thanks for the reply!
I’ve made another tweak to the way subscription emails are sent, hoping to make this work a little bit more efficiently.
See: https://bbpress.trac.wordpress.org/changeset/6725
We could probably improve this a bit more still, by letting plugins like Mailgun replace the email sending process completely with their own. Sending emails en-masse is neither easy nor super fast, so however we can make this better in bbPress, we should be!
You’ll want to contact the author of the post views plugin that you’re using for help.
This won’t be super easy, unfortunately. Users would need to opt-in or opt-out of being anonymous (either in their profiles, or in their individual posts) and then there are a bunch of places the user account would need to be overloaded with some anonymous’esque object with hardcoded values.
So, 3 things are necessary:
* Profile integration
* Topic/Reply integration
* Per-post User override
It’s possible, but will take a few development hours to achieve.
:/ bummer. Sorry about that.
If you or the fine folks over at WPE can drop a hint at what’s timing out where, we can probably tune it a bit more.
We’ve changed the email address gathering & sending methods in bbPress 2.6 to try and accommodate bigger sets of users. You could try upgrading your forums to the latest 2.6 release candidate, and see if it makes a difference.
https://core.trac.wordpress.org/ticket/41134 seems relevant here.
@fabian If you wanted to take a stab at sprucing bbPress up with its own polyfill for autoload support, I’m happy to help test and implement.
We should probably open a ticket on our Trac as well.
Believe it or not, this type of layout is not built into the default templates, mostly because I don’t really like them very much, and also because we plan on changing the way forums & categories work in a future version, and I did not want to commit to that type of design only to need to force users to rename their template files.
Check the source of those pages for JavaScript errors. Something isn’t being enqueued, or is being blocked on those pages.
Could be caching, a bug, a plugin conflict, or something else.
BuddyPress and bbPress both have their own version of mentions, and it sounds like they are working as they are currently designed to. Meaning, BuddyPress activity mentions always win, and bbPress mentions do not create BuddyPress notifications on their own.
Also, is it not possible to write one query that deletes content from two tables (wp_posts and postmeta)?
Correct; it is not possible. Each deletion from each table needs its own query. It’s not possible to know which meta-data IDs to delete without SELECTing which post IDs before deleting them.
You won’t be able to do this with just 1 query, because you’ll also want to delete the associated meta-data; that will take at least another query with the post IDs of the topics you’re trying to delete. If you’re using any type of caching, those caches should be purged also, which usually requires PHP or a cache-key reset.
There are a few alternatives.
* Admin > Tools > Forums > Reset will let you erase all bbPress content completely. It may timeout depending on your server configuration, but it will eventually get through it.
* Use WP-CLI: http://wp-cli.org
* Export the DB, do the data delete on a more capable server (or locally) then re-import it back in. This obviously is the more technical solution, but works really well in a pinch.
I understand the need for this, but this is coming from bbPress so there is only so much we can do. bbPress has no way to to blanket unsubscribe someone from all of their forums/thread email subscriptions. If bbpress had a way to unsubscribe globally, then we could look into it but going topic by topic, which is how they have it setup does not work. Simply put bbPress doesn’t have the utilities to make it reasonably possible
The bbp_topic_subscription_user_ids filter can be used to remove users from the array of users to be notified about new replies to topics.
The bbp_forum_subscription_user_ids filter can be used to remove users from the array of users to be notified about new topics in a forum.
On the Memberpress side, or in a separate add-on, they can filter those arrays, remove “inactive” members from those emails, and problem solved.
I’d also argue that you actually don’t want to blanket unsubscribe anyone from anything, because if they ever re-subscribe, they’ll want to get all of their previous history back; right? If you purged all those subscriptions when their membership expires, that would kinda stink for them.
The problem of conditionally loading the PHP files will go away when we can start to officially support autoloading for versions of PHP greater than 5.2.
With BuddyPress, we did move to supporting autoloading when it’s available. bbPress has fewer files, and is a simpler piece of software, so my preference would be to keep it a bit more pristine and not include the same conditional support until it’s a general requirement for running WordPress.
Anything we can do to make bbPress more performant is definitely encouraged, so I appreciate you noticing, and taking the time to start the discussion here.
> You can then delete the bbpress plugin directory and re-install bbpress from the front end
This is my suggestion. If that file is missing, it’s hard to trust that other files haven’t been compromised in other ways.
This is a PHP 7.0/7.1 issue with anything in the 2.5 range.
We need to port some changes from the 2.6 branch backwards to make it work.
Hi @sourfew, sorry to hear you’re having trouble. It’s really important to us that incoming users have a great experience, so I’d like to try and tackle this right away.
Curious how many topics & replies you converted? Also, it’s usually most helpful to have access to or see your conversion data, which is totally based on your comfort level.
I don’t think we’ve made any changes to this repair routine, and it isn’t “critical” to your forums working, but it is nice to do.
Something in your theme must be forcing the width of those fields. They are naturally responsive by using percentage based widths by default.
