Skip to:

Opened 15 years ago

Closed 11 years ago

#1304 closed defect (bug) (wontfix)

Site Wide Activity Blogs Filter Button still exist after turn of Blogs

Reported by: svenl77's profile svenl77 Owned by: mrmaz's profile MrMaz
Milestone: Priority: major
Severity: normal Version:
Component: Activity Keywords:
Cc: MrMaz


I turned of Blogs in the wpmu admin settings and in the buddypress component setup I disabled tracks blogs.

But on the Site Wide Activity is still the Blogs Button.

Attachments (1)

1304.patch (6.7 KB) - added by MrMaz 15 years ago.

Download all attachments as: .zip

Change History (13)

#1 @MrMaz
15 years ago

  • Cc MrMaz added
  • Owner set to MrMaz
  • Status changed from new to accepted

15 years ago

#2 @MrMaz
15 years ago

  • Keywords has_patch activity filter disabled components added; blogs removed

Attached patch is for bp-activity-classes.php

This should definitely be tested well before committing.

#3 @MrMaz
15 years ago

  • Milestone set to 1.1.3

#4 @MrMaz
15 years ago

  • Keywords has-patch added; has_patch removed

#5 @erich73
15 years ago

  • Resolution set to worksforme
  • Status changed from accepted to closed

this is not a bug.
it is working fine.

#6 @MrMaz
15 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

If you disable blog tracking in the BuddyPress admin the activity still shows up in the sitewide activity widget. The same thing happens for groups and friends activity if you disable those components.

I spent a long time working on this patch, please do not close this again until a core developer has looked at it. Thank you!

#7 @MrMaz
15 years ago

  • Status changed from reopened to accepted

#8 @johnjamesjacoby
15 years ago

I like this patch a lot, but I may reverse the logic slightly for the core later.

Question: How does an external BuddyPress plugin (like bp-links) tell this function that it isn't activated? If the plugin isn't activated then its code isn't included so it can't apply the filter to say it isn't there.

I'm thinking if we reverse this to tell the query which components are activated, then we can build the activity based on which components are active.

Does that make sense? This way external components can add themselves to the BP array and say whether or not they're active. If active, then show activity.

#9 @MrMaz
15 years ago

  • Status changed from accepted to assigned

I agree that the activity component needs to be reworked so that somehow core components and plugins "register" themselves instead of just throwing data at it. This solves a lot of issues that are happening now, and bound to get worse in the future.

The big problem with fixing this is backwards compatibility. If all of the sudden the activity widget (or other activity code) are only listening to "registered" components, then every plugin that currently records activity will not work correctly.

So I think the backwards compatibility needs to be addressed before a final solution can be worked on. In the meantime my patch solves some of the problem, but is not a long term solution. It might even be a good idea to remove the filter so people don't start relying on it.

#10 @apeatling
15 years ago

  • Milestone changed from 1.1.3 to Future Release

#11 @DJPaul
14 years ago

  • Component set to Core
  • Keywords reporter-feedback added

MrMaz, would you look at this please sometime after 1.3?

#12 @DJPaul
11 years ago

  • Component changed from Core to Activity
  • Keywords has-patch activity filter disabled components reporter-feedback removed
  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Severity set to normal
  • Status changed from assigned to closed

wontfixing this as it's 3 years old and I'm not 100% sure what this ticket is referring to.

If it's still an issue in 1.7, please re-open with new details, and we'll review. Thanks.

Note: See TracTickets for help on using tickets.