Skip to:
Content

Opened 16 months ago

Last modified 2 months ago

#2151 new defect

BuddyPress: Disabling search engines from indexing blocks activity items from recording

Reported by: r-a-y Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 2.2
Component: Forums Keywords: dev-feedback has-patch
Cc: will@…

Description

The bbp_is_site_public() function is used in the BBP_BuddyPress_Activity class to determine if an activity item should be recorded into BuddyPress.

The problem with this is if a site owner chooses to hide their site by disabling search engines from indexing (under "Reading Settings" in the WP dashboard), no forum-related activity content will be recorded.

Note: This was tested on a single site install.

I chose not to submit a patch because I wasn't sure what the original intention behind this was. Let me know!

Attachments (1)

2151.01.patch (770 bytes) - added by r-a-y 2 months ago.

Download all attachments as: .zip

Change History (7)

comment:1 will_c16 months ago

  • Cc will@… added
  • Version changed from 2.2 to trunk

I came here to report this same behavior. We have chosen to discourage search engines from indexing our site using the Settings->Reading setting. While this is checked we don't get any activity feed integration with BuddyPress. I realize it's a bit of an edge case, but we don't want our site indexed and we definitely want activity feed integration. I'm also curious to know what the original intention behind this check was. It would be great if activity feed integration could work without public visibility.

My setup is a clean install of WordPress 3.5, BuddyPress 1.7 (as of 1/8/13), bbPress 2.2.3 and bp-default theme.

Thanks!

comment:2 johnjamesjacoby16 months ago

  • Component changed from BuddyPress to Forums
  • Milestone changed from Awaiting Review to Future Release

Filter 'bbp_is_site_public' and override it. It was a carry-over from the way bbPress 1.x worked, and the way blog posts work in the blogs component. We can revisit this later, but for now the filter is there to be used for this exact reason.

comment:3 r-a-y16 months ago

  • Version changed from trunk to 2.2

Thanks for the rationale behind this, JJJ.

comment:4 r-a-y2 months ago

Okay, just an update on this ticket.

Some plugins like "More Privacy Options" set the blog_public value to a negative integer like -1.

Currently, bbp_is_site_public() explicitly casts the blog_public value as a boolean. This has the unintended effect of bbp_is_site_public() returning true for a negative integer.

I've attached a patch that fixes this, while keeping into consideration the carry-over from bbPress 1.x as mentioned in comment:2.

r-a-y2 months ago

comment:5 r-a-y2 months ago

  • Keywords has-patch added

comment:6 johnjamesjacoby2 months ago

Perhaps incorrectly, I'm okay with returning true for a negative number. WordPress core assumes sites are public, unless the value is '0' in which case it's considered private. It's hard to special-case code for individual plugins that hardcode their own conventions.

I almost wonder if we should deprecate bbp_is_site_public() for bbp_is_site_private() and explicitly check for an empty value back instead. Reversing the logic doesn't change the way the code works, but might make it more clear what the intentions are?

Note: See TracTickets for help on using tickets.