Issues with legacy plugin directory page and wordpress Standard

[sbrajesh]

Hi,
Just came across this weird issue, though It's not a big deal. Posting here to make sure if someone else has the same trouble can get the solution.

It seems some load order has changed in bp 1.5 beta1 to bp 1.5 rc1.

Earlier, if you registered globals on "bp_init" action with priority 6(In fact I have been using 6 for many plugins), The bp_is_current_component used to return correct value on directory page.

In bp 1.5 Rc1, this works for wordpress multisite but not for wordpress standard. Just tested and it seems the function bp_core_set_uri_globals is unable to set(as It is called on bp_init with priority 2) the $current_component if you register it late. I could not understand why It worked for Multisite though.

Looking at the loading orders, I switched the registering of plugin globals to bp_loaded and it worked for both wordpress standard as well as wordpress multisite.

I haven't modeled any of my component based on the skeleton component, so I may be using the wrong loading order.

Any thoughts on why there is inconsistency in wp/wpms.

[boonebgorges]

Thanks very much for posting this here, sbrajesh.

I have no idea why there would be an inconsistency between WP and WPMS with respect to this. In WPMU, there are some additional hooks that fire in this sequence (like muplugins_loaded) but I don't see how it would affect anything in BP.

More importantly, it's very strange that this would have changed in BuddyPress between the first beta and now. r4977 did introduce a small load order change. But it's far too late to make a difference for plugins that register globals ('wp' comes after 'init', which is when 'bp_init' fires). So I doubt that it has anything to do with it.

It's possible that r5105 is part of the culprit. I found, while messing with the Skeleton Component, that this bp_is_active() check caused some problems - not so much because of the load order, but because of the additional check against $bp->active_components. This manifested itself on the directory pages, which makes me think it might be related. Maybe you could roll back this change locally and see if it makes a difference.

For what it's worth, BuddyPress internally (both in 1.2.x and in the new BP_Component class) registers its globals at the hook 'bp_setup_globals', which is fired at bp_init with priority 4. See ​https://buddypress.trac.wordpress.org/browser/trunk/bp-core/bp-core-hooks.php#L23. Perhaps you could try hooking here, instead of to bp_loaded, to see if it helps.

[sbrajesh]

Hi Boone,
Thank you for the thoughts on this.
I tried setting up with 'bp_setup_global' with 2-10 priority and all worked for wordpress multisite but not for standard wordpress.

Again I tried to use bp_init with priority 3-8, none worked for wordpress standard but worked for multisite. Finally, I hooked to bp_init with priority 0-2 and it worked for both the multisite as well as wordpress standard.

Onething I noted while debugging, In the cases when it does not work for wordpress standard, the bp->current_component were empty on directory page(Yes, I checked that even on bp_screens action/wp action).

The only thing I can understand is the code which sets the current_component some how skips it for lower priority.

[boonebgorges]

This is serious if true.

sbrajesh, can you share the plugin code where you're having the problem? I'd like to have a fuller picture of where and how you're doing the relevant checks.

[sbrajesh]

Hi Boone,
Just sent you the mail. I got your mail from Hans today. hope you don't mind that.

[boonebgorges]

Thanks, sbrajesh.

The problem is indeed related to r5105. Here's what's happening:

The bp_is_active() check introduced in r5105 checks against $bp->active_components. Core components are recorded in this array from an option in the wp_options table very early in the loading process. Third-party components, on the other hand, are responsible for registering themselves (like you do in bp-gallery - $bp->active_components[$bp->gallery->slug], etc.). Most plugins do this in their global setup routine, which should be hooked to bp_setup_globals. That means that bp_is_active( $component ) will work properly for third-party $component when fired *after* bp_setup_globals (because then the component will be in the active_components array) but not *before*. And since bp_core_set_uri_globals() runs before bp_setup_globals, it doesn't work.

I think the solution is to revert r5105 and find a better solution for the problem it was meant to solve. I'd like to have feedback from jjj on this before moving forward, as he was the one who initially made the change.

[johnjamesjacoby]

The issue is when you assign a BuddyPress component to a page and then deactivate the component. This becomes especially apparent with bbPress 2.0 because they both try to like in /forums.

If you had BuddyPress forums active, deactivate it, then activate bbPress 2.0, BuddyPress still sees the forums page in the array, and tries to load it. Having some kind of is_active check is necessary to prevent a bunch of load errors when accessing a page that BuddyPress thinks belongs to it.

[boonebgorges]

After beaucoup de discussion in Skype, I think the best tack right now is: revert the bp_is_active() check in bp_core_set_uri_globals(), and then mark this down as a known issue. If the problem arises for individual users, the recommendation will be to reenable the disabled component, de-associate the page at Dashboard > BP > Pages, and then deactivate again. We can revisit the underlying problems, which IMO trace to the way bp_is_active() works, in a future cycle.

[boonebgorges]

(In [5149]) Removes bp_is_active() checks from current_component routine in bp_core_set_uri_globals(). Fixes #3579