Allow plugins to format profile-related notifications.

[dcavins]

The XProfile component doesn't create any notifications of its own. However, a plugin may want to create profile-related notifications. For instance, if you already have 50,000 users and you add a question to the "Base" profile group, wouldn't it be great to create a notification asking your members to update that profile group?

My patch adds the skeleton of a notification callback for the Profile component which allows plugins to hook uncaught actions much like recent changes to groups_format_notifications().

There's one weird bit, and that's that the xprofile component's key in the $bp array is profile. I'm not sure of the best way to handle that, so those cases are clunkily handled via special rules in bp-notifications/bp-notifications-functions.php

Thanks for your feedback.

[dcavins]

Allow plugins to format profile-related notifications.

[r-a-y]

dcavins - Are you recording xprofile notifications with the component_name set to xprofile? If so, why not record notifications with the component_name set to profile?

That would probably solve the issue in bp-notification-functions.php.

Edit - Looks like we do the profile / xprofile dance in a few other spots:

• bp_get_nav_menu_items()
• bp_attachments_cover_image_is_edit()
• bp_is_current_component()
• bp_is_active()
• bp_set_theme_compat_feature()

Based on the above, the patch looks okay! :)

[dcavins]

Hi @r-a-y-

Using profile for the component_name in the notification _would_ avoid the first issue at about line 200 (and a note in the format callback would help devs know what to use). The second piece at about line 600 comes from the keys in $bp->active_components. (It's weird that the active_components uses profile for its key, but $bp doesn't, ha ha.)

Thanks for your input!

[boonebgorges]

The approach in the patch looks fine to me.

A little background on the xprofile vs profile thing. xprofile is an optional component, and when it's disabled, BuddyPress uses some information from the WordPress user profile to fill in stuff like "display name". So I think profile was chosen as the top-level component name in order to account for these cases, so that you could grab something from $bp->profile without knowing whether xprofile was active. In retrospect, it probably doesn't make much sense for xprofile to share a key with WP profile info #blamepeatling but here we are. In general, I'd say you should be using xprofile to refer to things that are dependent on bp-xprofile, and only use profile when you need compatibility with the global key (or in certain cases, the activity component).

[dcavins]

Thanks for your feedback, @r-a-y and @boonebgorges. I'll hold off another day in case John wants to weigh in.

Boone, when you say this:

In general, I'd say you should be using xprofile to refer to things that are dependent on bp-xprofile, and only use profile when >you need compatibility with the global key (or in certain cases, the activity component).

should I take that to mean that you'd prefer that we expect xprofile to be the component_name in a notification record (requiring the first sleight-of-hand/switcheroo in bp-notifications-functions.php)? I'll add a NB to developers in the new hook documentation either way.

Thanks again for chiming in. I appreciate that you both took the time to read over a minor patch this late in the game. :)

[boonebgorges]

should I take that to mean that you'd prefer that we expect xprofile to be the component_name in a notification record (requiring the first sleight-of-hand/switcheroo in bp-notifications-functions.php)?

Yes.

[dcavins]

Better notes; Yoda logic.

[dcavins]

In 10284:

Allow plugins to format xprofile-related notifications.

Adds a hook so that plugins may generate
xprofile-related notifications (with the
component_name of xprofile) and
format those notification using a
dynamic filter based on the name
of the component_action.

Fixes #6663.