[farmer paul]

I am now learning that this isn’t the only BuddyPress delete hook that is placed in this way. I’d also like to hook into `groups_remove_data_for_user()`, but same deal – the action is triggered only *after* the user’s group membership data has occurred (and that’s the data I need access to for Google Docs). I’m going to have to hook into WP’s user delete actions instead, specifying a higher priority than BP, since they are triggered immediately before deletion, when the data I need is still available.

A similar incident was noticed in WordPress core w.r.t. user deletion a few years ago, and I guess developers agreed to insert an additional hook: one prior to deletion – `delete_user`, and one following deletion – `deleted_user`. (Original bug reported here: https://core.trac.wordpress.org/ticket/2956)

Can the same additional delete hooks be added to BuddyPress?

[farmer paul]

Thanks for the quick reply, Paul. I did what you said, and the errors disappeared so long as BP was disabled. They came back as soon as I re-enabled it. But at least now I have super-admin access again. I had to disable all the plugins to get that to happen.

I did a mysqlcheck on the database – nothing needing repair.

Maybe one of the other developers modified BP core? Well, no worries for now. We have another instance of the site that we might try to mirror.

[farmer paul]

There’s no reason we should suddenly be exceeding 256 MB of memory on every wp-admin dashboard request. I think this must be related to the MySQL-Link errors.

[farmer paul]

Also noticed this error on the Dashboard under the QuickPress section:

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 64 bytes) in /home/wmaster/yexpress.net/wp-includes/wp-db.php on line 1315

[farmer paul]

No worries – we decided not to take this route after all. Instead we’ll add a new function “Request to close topic”, which will message the group admin/moderator, who does have the power to accomplish this.

[farmer paul]

Since I’m trying to meet a deadline I’m just going to leave this for now, and make do with accessing the page from the member domain (i.e., /members/[username]/groupdir).

But if anyone has any inkling as to why accessing /groupsdir as a root component is redirecting me to the home page, I’d be most appreciative! I find it really tricky trying to follow the exact flow of actions that happen when a BP page is accessed.

[farmer paul]

Thanks, @jeffsayre. I must have missed that page when I was browsing the Codex. I was following the Skeleton Component because my coworkers had recommended it to me. However, apparently none of them tried writing a BP plugin that provided a root component!

Now my problem isn’t that I’m getting a 404 error anymore. Instead, now when I go to “/groupsdir”, BuddyPress is redirecting me to the root “/”, without an explanation. Spent the last hour or so trying to figure out where this is happening. No luck so far, but I’ll keep looking.

@travel-junkie: You explained how root components were registered, and that `bp_core_new_nav_item` adds to the member’s menu, not to the root. But surely I still need to call `bp_core_new_nav_item` to tell BP which screen function to use when the “groupsdir” component is requested – right? So I’m still using `bp_core_new_nav_item` to provide that information – *in addition* to calling `bp_core_add_root_component` to state that “groupsdir” is also a root component. Is this correct?

[farmer paul]

Thanks, you two. This sort of info would be fantastic to include in the Codex and as revisions to the Skeleton Component so more of us don’t spend days scratching our heads.

[farmer paul]

Well I couldn’t resist investigating further, and it turns out that the code that BuddyPress runs to compare the URL to the `$bp->root_components` array happens during the `bp_loaded` action, which happens during the WP `plugins_loaded` action, which seems to happen *before* the `bp_init` action – which is the action I’m supposed to use to cause my plugin’s code to be loaded in the first place.

So basically it seems I’m screwed if I want to cleanly add a root component to BuddyPress from within my plugin. I’ll have to do a bit of fudging in my plugin’s `loader.php` file instead.

[farmer paul]

Tried changing the priority of `add_action( ‘wp’, ‘bp_gdatree_setup_root_component’ )` – still no difference. Can’t seem to scrap the 404 no matter what I try. I’m out of ideas.

[farmer paul]

Could it have to do with the order that `bp_gdatree_setup_globals`, `bp_gdatree_setup_nav`, and `bp_gdatree_setup_root_component` are run in…? I’m not sure what the correct order is.

[farmer paul]

(Oops – make that /members/[my username]/groupsdir)

[farmer paul]

Well, still no luck. I added this to my code:

`function bp_gdatree_setup_root_component() {
/* Register ‘groupsdir’ as a root component */
bp_core_add_root_component( BP_GDATREE_SLUG );
}
add_action( ‘wp’, ‘bp_gdatree_setup_root_component’ );
add_action( ‘admin_menu’, ‘bp_gdatree_setup_root_component’ );`

Again, I used an echo statement to verify that this function was in fact getting triggered. Despite this, I still get a 404 error when I visit /groupsdir.

Just occurred to me to try accessing the page from /members//groupsdir – and at least that works!

So any idea of what else to try?

[farmer paul]

Wow, well I had no idea. Where in the skeleton component do you see this mentioned? That’s exactly what I’ve been following to build my plugin. Then I started looking into the `messages` component to see if there was something I was missing, but didn’t make any headway. I guess I didn’t look at enough other components.

Thanks for the tip.