[buddypress-trac] [BuddyPress Trac] #3460: Support custom post types in activity stream
buddypress-trac
noreply at wordpress.org
Tue Mar 25 02:02:14 UTC 2014
#3460: Support custom post types in activity stream
-------------------------------------------------+-------------------------
Reporter: boonebgorges | Owner:
Type: enhancement | boonebgorges
Priority: low | Status: new
Component: Activity | Milestone: Future
Severity: normal | Release
Keywords: 2nd-opinion has-patch needs-testing | Version: 1.2.8
| Resolution:
-------------------------------------------------+-------------------------
Comment (by imath):
Replying to [comment:70 boonebgorges]:
> Thanks for the work here, imath. I've finally started to take a close
look at it.
You're welcome and thanks a lot for looking at it :)
> - If I understand correctly, settings for a given post type are shared
across sites. Say I'm running a plugin that registers post type 'foo' on a
couple of subsites. If I want to record 'foo' on one subsite but not on
another, then I'm out of luck, right? (aside from changing privacy
settings)
> - In the same vein, it appears that a post type (say, Pages) that is
marked as "tracked" in the global BP settings cannot be disabled on
subsites. If this is going to be the case, then it should be reflected in
the interface. However, I think it probably should *not* necessarily be
the case - it seems like a very common use case to want to track a post
type on the root blog but not the same post type on a secondary blogs.
If a plugin doesn't want to be tracked, he can choose to set his
show_in_nav_menu args to false.
Actually, each site Admin can choose what post type will be tracked. In
the example above. If site A want to track 'foo' and site B doesn't want,
he can choose to deactivate the tracking. Each site has the choice. If the
SuperAdmin wants to be the only one to control, he can disable the sub
site Site Tracking settings sub menu.
> - The interaction of privacy settings and trackability on subsites is a
bit confusing. As it stands, it looks like setting blog_public = 0 is
enough to disable all tracking for the site. But if this is the case, then
the interface should enforce it and/or provide documentation. So, eg, the
whole checkbox section should be disabled or hidden when the blog is not
public.
Well it's the case, if the blog is defining itself as not public, then,
the Site Tracking settings menu is no more available as anyway when the
blog record post function will run no post type from his blog will be
tracked. As soon as the admin will define his blog as public the Site
Tracking submenu will show again.
I haven't check for the root blog, but i have some doubt he would do that,
because it would be weird to activate the site tracking component in this
case :)
> - At the same time, if we're going to start allowing fine-grained, per-
post-type user settings for blog tracking, maybe we should be doing away
with the blog_public bit - or at least, we would only use blog_public = 0
to provide default tracking settings (unchecked)
Well it's still a good way to completely disable the blog tracking, but it
can be "done away" because as you said, each blog has the power to choose
what post type will be tracked.
> Again, I'm not 100% sure which way to go with any of these questions,
but all of them need some work and some discussion.
> As for the milestone, I think that we are too late to complete this
ticket, as currently conceived, for BP 2.0.
I agree, this still needs a lot of testing. I'd say let's do it all for
2.1 ;)
My concern is more about the drop down list to filter activities.. If the
network is tracking a lot of post types, this can be huge !!
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/3460#comment:71>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list