bp_core -> bp_members has erased a bunch of hooks

[boonebgorges]

I was poking through the new bp-members files today, and noted that a bunch of hooks of the form bp_core_ (like bp_core_signup_user) have been changed to bp_members_signup_user. This will break many plugins and customizations, including some that I have written.

IMO, we should include both the old style hooks and the new hooks, with an inline note that the new hooks are to be preferred.

[boonebgorges]

jjj, I'd like your view on this, as you made the changes. Was it just a case of overgenerous search-and-replace?

[boonebgorges]

As I think about this, I have similar issues with the changed function names themselves. Can we consider changing them back to bp_core_ (which was, I thought, the original plan)? I see that there are wrapper functions in the deprecated file for 1.3, but this has the potential to overload error logs, and to what end?

[DJPaul]

Sort of similar to #3100

[johnjamesjacoby]

Overzealous search/replace. I'd rather not rename the function names back to bp_core_ since the goal is to get them out of the bp-core component completely.

The deprecated notices should only happen when WP_DEBUG is set which shouldn't be in a live environment anyhow.

The action and filter names, that's a casualty I/we will need to manage. Can we hook the old actions/filters into the new ones, and pass the variables through it. We can incept them. You be Leonardo Decaprio, Paul will be Joseph Gordon-Levitt, and I will be Ken Watanabe since I'm the bad guy in this instance. :)

[boonebgorges]

I don't feel all that strongly about the function names, though in the future I would prefer to avoid changing more function names unless really necessary. Backpat is more important than internal consistency with something as meaningless as function names.

As for the actions/filters, I would think that it will maximize readability to just stack the old ones on top of the new ones right in the core code.

I have not seen Inception, but I see how it would make sense for me to be DiCaprio, since both he and I are very handsome.

Going to bump the issue up in priority because it really must be done for release.

[modemlooper]

I'm a spinning top. :D

[r-a-y]

Is Ken Watanabe (JJJ) really the bad guy? He does force Leo (Boone) into the job though ;)

Yes this analogy works on both fronts!

[boonebgorges]

See also #3100

[DennisSmolek]

Patch of the ones I could find

[johnjamesjacoby]

(In [4605]) First pass at reverting members/core function & filter refactor. See #3158.

[johnjamesjacoby]

(In [4606]) Second pass at reverting members/core function & filter refactor. See #3158.

[boonebgorges]

I'm going to mark this as fixed, as I've not seen any problems after r4605 and r4606. If you find specific issues related to these function/hook names, please open a ticket.

[hnla]

Just updated 1.3 checkout and these reversion to func names appear to have broken:

bp_members_get_notifications_for_user() - undefined function

had been using this since approx 1.2.6 or thereabouts

However just checked and changing to:

bp_core_get_notifications_for_user()

is working ok

[boonebgorges]

I'm quite sure you're incorrect that bp_members_get_notifications_for_user() was in use in 1.2.x. Would you mind looking through some previous tags and pointing to where it was defined? ​https://buddypress.trac.wordpress.org/browser/tags

FWIW, this function was defined in the BP trunk for a month or two recently. But never in a stable tagged version.

[hnla]

Yes sorry I was trying to impart that. I was wrong bp_members_get... wasn't in 1.2, I had lost track of the fact I had had to change it to 'member' from 'core'( or thought I had to?) for 1.3. if I had thought to first look back at an older test install to see what function was used it would have become clearer.

Tis a little confusing though chaps :)

[johnjamesjacoby]

Hopefully the worst of that is behind us now. :)