post_type_support - ajax changes the activity entry action

[shanebp]

WordPress 4.1.1 running any WP included theme.

In the activity stream, the item action is being changed to the generic 'wrote a new item' if a Show filter is used OR any tab is clicked.

When first loading an activity page, site-wide or personal, the entry shows the same action that is in that row in the database:

After I use _any filter OR click any tab, the entry changes to this:

The only way to return to showing the entry action as stored in the database is to reload the page.

I create a cpt:

register_post_type( 'event', ...
"supports"	=> array("title", "editor", "thumbnail", "author", "comments", "trackbacks", "buddypress-activity")

I edit the activity attributes:

function event_tracking_args_activity() {

    if ( ! bp_is_active( 'activity' ) )
        return;

    bp_activity_set_post_type_tracking_args( 'event', array(
        'action_id'                => 'new_event',
        'bp_activity_admin_filter' => __( 'Events', 'custom-domain' ),
        'bp_activity_front_filter' => __( 'Events', 'custom-domain' ),
        'contexts'                 => array( 'activity', 'member' ),
        'activity_comment'         => true,
        'bp_activity_new_post'     => __( '%1$s created a new <a href="%2$s">Event</a>', 'custom-domain' ),
        'bp_activity_new_post_ms'  => __( '%1$s created a new <a href="%2$s">Event</a>, on the site %3$s', 'custom-domain' ),
        'position'                 => 100,
    ) );
}
add_action( 'bp_init', 'event_tracking_args_activity' );

[shanebp]

I'm not creating a component.
But instead of defaulting to 'activity', setting component_id to be the same as the filter name seems to fix the problem. Ajax no longer switches the displayed activity action to the generic one.

    bp_activity_set_post_type_tracking_args( 'event', array(
        'component_id'             => 'events', 
    ...

[imath]

Thanks for your feedback looking at it asap.

[imath]

@shanebp could you check this ​https://buddypress.org/support/topic/custom-post-type-support-for-activity/#post-233980
I think it's a priority issue.

Why not defining the 'bp_activity' parameter directly in your register_post_type()

[shanebp]

Setting priority to 1000 and letting 'component_id' default to 'activity' results in the issue described in the opening of this ticket. iow. ajax replaces the activity action with the generic string. So a late priority is not a solution.

Why not defining the 'bp_activity' parameter directly in your register_post_type()

So I need to do that AND set up bp_activity_set_post_type_tracking_args ?

Also - this page is confusing:
​https://codex.buddypress.org/plugindev/post-types-activities/

Re contexts: I think the codex page needs an explanation of the difference between
'member_groups' and 'group'

And you start by saying:
"If you activate the Blogs component from the BuddyPress component’s Administration screen..."

Where do you see the option to activate the Blogs component?
I don't see it. And never have.

[imath]

First my sincere apologizes for my bad english. I try to do my best.

If the codex page is confusing, feel free to edit it. I thought in the introduction this part "Here are the different options" was clearly saying "OR". Moreover options are separated in sections.

Section 1 is talking about the post post type and the comments about posts : activate the blogs component
Section 2 is about post type you don't control the registration e.g.: the page post type
Section 3 is about the post type you control the registration.

So I need to do that AND set up bp_activity_set_post_type_tracking_args ?

No. As you are the one registering the post type simply use the ​bp_activity parameter.

Re contexts: I think the codex page needs an explanation of the difference between

'member_groups' and 'group'
​https://codex.buddypress.org/developer/function-examples/bp_activity_set_action/ read the $context section

Where do you see the option to activate the Blogs component?
I don't see it. And never have.

In WP Administration / Settings / BuddyPress ​https://codex.buddypress.org/getting-started/configure-components/
Site Tracking checkbox.

[shanebp]

First my sincere apologizes for my bad english. I try to do my best.

Your English is fine, mon petit chou chou.

Re activating the Blogs component - most people don't know that means selecting 'Site Tracking'.
I've tweaked the codex page.
In all my testing, Site Tracking has _always been enabled.

Thanks for the pointer to info re contexts.

So I need to do that AND set up bp_activity_set_post_type_tracking_args ?

No. As you are the one registering the post type simply use the bp_activity parameter.

Unless I want to customize the 'bp_activity_new_post' field, correct?

I appreciate you taking the time to explain things.
Meanwhile, the reason for this ticket still remains.
Unless ​https://buddypress.trac.wordpress.org/ticket/6312#comment:1 is a proper solution.

[imath]

Replying to shanebp:

mon petit chou chou.

I'll take this as being nice. FYI: in my country this is ironic & not being nice.

Unless I want to customize the 'bp_activity_new_post' field, correct?

Actually, this will need to go in labels

'labels'   => array(
	'name'                     => __( 'Artikel', 'your-plugin-textdomain' ),
	'singular_name'            => __( 'Artikel', 'sozialdynamik' ),
	'bp_activity_admin_filter' => __( 'Neuer Artikel veröffentlicht', 'sozialdynamik' ),
	'bp_activity_front_filter' => __( 'Artikel', 'sozialdynamik' ),
 	'bp_activity_new_post'     => __( '%1$s hat den neuen <a href="%2$s">Artikel</a>', 'sozialdynamik' ),
 	'bp_activity_new_post_ms'  => __( '%1$s hat den neuen <a href="%2$s">Artikel</a>, on the site %3$s', 'sozialdynamik' ),
),

Meanwhile, the reason for this ticket still remains.

If the problem remains once the labels 'bp_activity_new_post' and 'bp_activity_new_post_ms' are set during the register_post_type() step: yes. Do you confirm it's the case ?

[shanebp]

Adding the labels in register_post_type works.

Adding this in register_post_type works.

 'bp_activity' => array(
         'component_id'          => buddypress()->activity->id,
         'action_id'             => 'new_cpt',
          'contexts'             => array( 'activity', 'member', 'groups', 'member-groups' ),
          'position'             => 40,
  ),

The only issue now, and this may be particular to a personal plugin...

if a cpt post is assigned to a group, I create a custom activity entry using groups_record_activity()
It works fine in terms of creation and where it appears.
But in the Show filter dropdowns on a profile page > Groups and on the group home page, the Show filter does not include the label > 'bp_activity_front_filter' value. It does appear on SWA > My Groups.

Is there a better way to approach this?

[imath]

The component_id for groups_record_activity() is 'groups' and the component you've set in the 'bp_activity' parameter of your cpt is 'activity', maybe it might be more consistent to use the same component :

'bp_activity' => array(
         'component_id' => buddypress()->groups->id,
....

On the other hand, you'll need to add a ui so that it's possible to add the group id when saving a cpt from the WordPress administration.

Then, make sure your templates are up to date :
See: ​https://codex.buddypress.org/themes/activity-dropdown-filters-in-templates/#use-bp_activity_show_filters-within-your-bp-default-child-theme

the group's activity template should use <?php bp_activity_show_filters( 'group' ); ?> instead of the hardcoded options.

Thanks for your feedback about the fact using the labels is fixing your ajax issue. I'll run some other tests tomorrow for the page post type && bp_activity_set_post_type_tracking_args().

[imath]

Hi,

Did some tests today. I think the whole issue you shared is specific to your plugin. I've tested this ​option and it's working fine using AJAX requests.

I advise you to check your [table_prefix]bp_activity table and make sure the component field is consistent with the component you're using when registering your post type.

In the function bp_activity_generate_action_string() we are using the component saved in database to dynamically build the action string.
If for some reason you registered 'activity' in the 'bp_activity' parameter when using the register_post_type() function and the component in DB is set to 'groups', then as the action strings is linked to the 'activity' component, it doesn't find it for the 'groups' component (which is a regular behavior).

closing this as worksforme feel free to reopen it.

[shanebp]

The component_id for groups_record_activity() is 'groups' and the component you've set in the 'bp_activity' parameter of your cpt is 'activity', maybe it might be more consistent to use the same component :

This distributed plugin allows the user the Option to assign a cpt post to a group.
If they do , then I use groups_record_activity() to create an entry for that group, using component = groups and set the action, item_id and site-wide fields appropriately.

If they don't assign the post to a group, then the activity entry will use the component stated when registering the post type, in this case buddypress()->activity->id.

I advise you to check your [table_prefix]bp_activity table and make sure the component field is consistent with the component you're using when registering your post type.

So the point is that the component being used will change depending on what the user decides to do.
It sounds like there is no way to get show_filters to account for that possible change.

I appreciate your explanations. I'm a lot clearer now about post_type_support.

I hope ​https://buddypress.trac.wordpress.org/ticket/6294 can be addressed soon.
Clients get upset when their posts are handled inconsistently.

[imath]

Can we agree that i've replied to :

In the activity stream, the item action is being changed to the generic 'wrote a new item' if a Show filter is used OR any tab is clicked.

If there's a problem with what you called "show_filters", don't you think it's another problem and could be worked in a new ticket ?