Scope of bbPress plugin and associated issues
Tagged: bbpress
- This topic has 7 replies, 3 voices, and was last updated 10 years, 7 months ago by Jonathan.
-
AuthorPosts
-
May 1, 2014 at 11:16 am #4676JonathanParticipant
We run CBOX on a multi-site wordpress install. On our CBOX install, we noticed that enabling bbPress network-wide caused each child site to have forums enabled in their dashboards, which we don’t want to do. Our solution was to disable bbPress network-wide, and just enable it for our main site. This was working fairly well, but recently we’ve seen some strange behavior from bbPress as a result of this configuration. If bbPress is not enabled network-wide, there is a discrepancy in capabilities between instances of WP_User–a new instance shows the user’s normal capabilities, while the instance in the global variable $current_user (and thus the one called by wp_get_current_user()) only has a subset of that user’s bbpress capabilities. This makes it so that some users (for some reason it’s about half of our users) don’t have the publish_topics capability that allows them to create new topics in forums, despite the fact that they’re members of the groups. So a user will join a group, and then discover that he or she still doesn’t have the permission to post topics to that group. I had a discussion with @jjj about this in #bbpress, yesterday and the day before. We couldn’t really find any good solutions.
I saw that in admin/plugins-loader.php, line 207, there’s a todo comment about this, expressing a desire to add the ability to limit the scope of bbPress. Furthermore, line 217 shows that network-settings is set to ‘root-blog-only” which would seem to limit bbPress to the root blog, but doesn’t really do that. My questions are:
- Are there plans among core CBOX developers to add the ability to limit the scope of bbPress so that it can be enabled on our BP root blog but not on child blogs?
- If not, is there some hack out there that would allow me to disable bbPress on child blogs?
- If not, how would I go about writing something that could limit the scope of bbPress?
- If that’s too difficult, is there a way to fix the issue with divergent WP_User instances so that users don’t run into this capabilities problem?
Thanks so much for any help anyone is able to provide!
May 1, 2014 at 3:22 pm #4678Boone GorgesKeymasterHi Jonathan –
My understanding of the roles system in bbPress is limited at best. (If you search through bbPress Trac, you’ll see I’ve opened a number of head-scratching tickets along these lines.) That said:
> Are there plans among core CBOX developers to add the ability to limit the scope of bbPress so that it can be enabled on our BP root blog but not on child blogs?
Yes. Maybe @r-a-y can say more about this, but I think that a logical next feature for the core Commons In A Box plugin loader would be to allow for this kind of selective activation (bbPress being the prime candidate)
> If not, is there some hack out there that would allow me to disable bbPress on child blogs?
You can drop
define( 'CBOX_OVERRIDE_PLUGINS', true );
into your wp-config.php. That’ll unhide our plugins from the Plugins panels (both locally and networkwide). You can then change the config however you’d like. Future updates to Commons In A Box should not touch these manual changes.> If that’s too difficult, is there a way to fix the issue with divergent WP_User instances so that users don’t run into this capabilities problem?
If JJJ doesn’t know how to solve this problem, I don’t either 🙂 Maybe a sanity check for group membership and publish_posts when viewing a group forum?
May 1, 2014 at 4:18 pm #4679JonathanParticipantThanks very much for all the input. Using
define( 'CBOX_OVERRIDE_PLUGINS', true );
, I’m able to disable bbpress on the network and enable it on the root buddypress blog, but that unfortunately causes the issue where users lose capabilities. Instead, it looks like I’ll need to keep bbpress enabled network-wide, yet disable it for all child sites except for the root site. Do you know if there’s a way to do that, say, by hooking into CBOX’s plugin management in some way?May 1, 2014 at 9:39 pm #4680Christian WachParticipantThis works on a test install here: first add
define( 'BBPRESS_LATE_LOAD', 9 );
in ‘wp-config.php’. This will cause bbPress to use the ‘plugins_loaded’ hook with a priority of 9 to initialise itself. I get recursive errors if bbPress is late loaded with a priority of 10 or more, but not with 9. Then add the following to a custom plugin:/** * Unhook bbPress init from sites other than the main site */ function bbpress_only_on_main_site_please() { if ( is_multisite() AND ! is_main_site() ) { remove_action( 'plugins_loaded', 'bbpress', 9 ); } } // hooked in with a lower priority so it runs before the bbPress action is fired add_action( 'plugins_loaded', 'bbpress_only_on_main_site_please', 8 );
Edit: I haven’t tested caps with this method. If you could report your findings back I’d be grateful as I’d also like to implement this. Thanks.
Cheers, Christian
- This reply was modified 10 years, 7 months ago by Christian Wach.
- This reply was modified 10 years, 7 months ago by Christian Wach.
- This reply was modified 10 years, 7 months ago by Christian Wach.
May 1, 2014 at 10:36 pm #4684Christian WachParticipantDamn, didn’t check the front end of a sub-site, just the dashboard to see if the bbPress CPTs were present. I get “Fatal error: Call to undefined function
bbp_get_version()
in/path/to/httpdocs/wp-content/plugins/commons-in-a-box/includes/frontend-bbpress.php
on line 69″ when I visit a sub-site homepage.There doesn’t seem to be a workaround for this, but changing the offending line to
if ( function_exists( 'bbp_get_version' ) AND version_compare( bbp_get_version(), '2.3' ) < 0 ) {
sorts it out. There may be more issues I’ve missed, but at least the front-end loads. I’ll create a pull request for this.May 2, 2014 at 12:41 pm #4685JonathanParticipantThanks, Christian. I wasn’t able to get that code to work, but I did finally get it to work with this, however:
function mla_remove_forums_from_child_sites($plugins) { global $current_blog; if( $current_blog->blog_id != 1 ) { unset($plugins['bbpress/bbpress.php']); } return $plugins; } add_filter('site_option_active_sitewide_plugins', 'mla_remove_forums_from_child_sites');
I’m sure this is probably not the most best-practices solution, but I hope it’ll work as a stopgap measure until there’s better plugin activation scope ability in CBOX. If you have any suggestions for how to improve this, definitely let me know.
- This reply was modified 10 years, 7 months ago by Jonathan.
May 2, 2014 at 1:49 pm #4687Christian WachParticipantOut of interest, what were the stumbling blocks to implementing the code I shared? At what point (or points) did it fail for you?
Cheers, Christian
May 2, 2014 at 4:32 pm #4688JonathanParticipantYour code didn’t seem to disable forums on child sites in my install at least. Maybe something somewhere wasn’t taking. I didn’t see any relevant error messages in the debug.log, and I didn’t get the fatal error about the undefined function, so it’s a mystery to me.
But I really like
if ( is_multisite() AND ! is_main_site() ) {
so I went with that in my final version. -
AuthorPosts
- You must be logged in to reply to this topic.