Skip to:
Content

bbPress.org

Opened 5 years ago

Last modified 3 years ago

#2706 new defect

Notifications not working correctly in multisite

Reported by: KR155E Owned by:
Milestone: 2.7 Priority: normal
Severity: normal Version:
Component: Extend - BuddyPress Keywords:
Cc:

Description

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.

Change History (7)

#1 @netweb
5 years ago

  • Milestone changed from Awaiting Review to 2.7

Moving to 2.7 to investigate further.

#2 @boonebgorges
3 years ago

  • Component changed from General - Integration to Extend - BuddyPress

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.

#3 @r-a-y
3 years ago

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.

Last edited 3 years ago by r-a-y (previous) (diff)

#4 @boonebgorges
3 years ago

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.

#5 @r-a-y
3 years ago

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.

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.

Version 0, edited 3 years ago by r-a-y (next)

#6 @boonebgorges
3 years ago

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.)

#7 @r-a-y
3 years ago

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.

Note: See TracTickets for help on using tickets.