Notifications not working correctly in multisite

[KR155E]

Not sure if this is a bbPress or Buddypress issue.

bbPress notifications only work on the network site a reply was created on. On other sites, topic title and permalink are wrong or are not there at all.

Thing is, the site ID is seemingly not taken into consideration when the notification text is created. Instead, the system always looks for a topic with the given ID on the current site instead of the one the topic belongs to.

[netweb]

Moving to 2.7 to investigate further.

[boonebgorges]

May I bring this ticket back from the dead?

The problem is more significant than this: if BP is network activated, but bbPress is not network activated and is not active on the secondary site, then notifications in the toolbar dropdown are not formatted at all - they just read 'bbp_new_reply', etc.

This is fairly complex to solve for a number of reasons. Here's an idea: Have a small network:true plugin (potentially shipped in bbPress itself) intended for this sort of situation. It'd work by making REST API requests back to the BP_ROOT_BLOG to get forum title, etc. This way, you avoid having to load up half of bbPress on secondary sites (or dealing with the nightmare of plugin activation + switch_to_blog()) just to format notifications.

[r-a-y]

The problem is more significant than that. Already mentioned above :)

There is no way for sure to know if the orphaned 'bbp_new_reply' notification came from the BuddyPress site. (For Boone's use-case we can make that assumption though :) )

There is also the possibility for post ID collisions to occur if bbPress was active on the secondary site, as well as on the main BuddyPress site or whatever other network site that has bbPress active. (See bbp_buddypress_add_notification() where bbPress is saving the current site's topic (post) ID as the notification's item ID.)

One way to solve this is to save the sub-site's ID as BuddyPress notification meta and then referencing the sub-site's ID from switch_to_blog() or the WP REST API, etc.

[boonebgorges]

Here's a proof-of-concept for the secondary plugin idea. Because this is not merged into bbPress, I need two separate plugins: one that's activated alongside bbPress (which provides the API endpoint and does the formatting) and one that's network activated. ​https://gist.github.com/boonebgorges/5ac2a5479233c8bb39ccc56153782f7b

It's a bit more complicated than a mere proof-of-concept because I'm going to deploy to a production environment where (a) I need asynchronous caching, and (b) I need to mess with CORS headers to allow requests to different subdomains in the same WP network. It involves some hardcoded stuff, and it doesn't account for the issue of ambiguous site_id, as referenced by @r-a-y and @KR155E. But it gives a sense of what a solution might look like.

[r-a-y]

I definitely applaud the idea of using the WP REST API here, but how about saving the rendered notification URL string directly into BP notification meta at the time of adding the notification? Then, we reference the notification meta entry when we need to call a single bbp_new_reply notification on a sub-site that doesn't have bbPress activated.

This side-steps all the complexity of needing two plugins and a JS file, but it also solves the site ID issue and needing to use either switch_to_blog() or the WP REST API here. (We would still need one auxiliary plugin though.)

Potential problems with my idea is stale data such as if the topic title is edited or if the person who posted a reply has changed their display name. The other issue is perhaps, the over-reliance on notification meta.

[boonebgorges]

The main problem with storing the string literal - aside from stale data - is localization. Notifications have always been formatted dynamically for this reason; we used to use stored activity action strings, but switched to dynamically-generated ones for related reasons. (Having a cached value of the English notification string in notification meta may be better than nothing, though.)

[r-a-y]

If we're okay with the idea of stale data, we could also save the topic title and the topic author as an array into notification meta or just as separate meta entries.

Then, you could localize that way.