Only thing I can see potentially limiting this is the provided user not having any published or privately published posts, given the WP core source code for count_user_posts.
Have you made sure something is published for the user, public or private?
Hi @tw2113 ,
Thanks for getting back.
I eventually made it working, but I had to register the post type manually calling it from functions.php file.
So I exported the post type code from the CPT backend, deleted the post type, and re-registered it manually via functions.php amending the last string to
add_action( 'init', 'cptui_register_my_cpts_magazine_pages', 1 );
Other than that, the user has public published post, which is now showing correctly.
But could you please take a look at it, run a few tests, see if it works for you?
I should probably also mentioned that I was using the count_user_posts function to add an additional Buddypress Profile Tab only for users that have a post from that particular post type.
I was using the code like this:
function buddypress_setup_bp_nav_magazine_pages() {
if ( bp_is_user() ) {
global $bp;
$user_id = bp_displayed_user_id();
$user = new WP_User( $user_id );
if ( $user->ID && count_user_posts( $user->ID, 'magazine_pages' ) > 0 ) {
$args = array(
'name' => __( 'Magazine Pages', 'buddypress' ),
'slug' => 'mags',
'default_subnav_slug' => 'mags',
'screen_function' => 'buddypress_bp_nav_tab_magazine_pages',
'item_css_id' => 'mags',
'position' => 80,
);
bp_core_new_nav_item( $args );
}
}
}
add_action( 'bp_setup_nav', 'buddypress_setup_bp_nav_magazine_pages' );
This seems to work perfectly fine on ay other post type registered by plugins, and it also works now after I re-registered the post type manually.
Thanks
hmm. Only real way I could see this new setup working any different is from the registering the post types at a higher priority. Kind of curious if the code above was being run before post types were being registered, and thus somehow WordPress was returning empty results.