SeoGreenPea

>I’m a little confused as to how this is relating to CMB2.

All I can share with you, at least from my limited experience with functionality failing, is that I only use a few plugins (cmb2 being one of them) and after deactivating your plugin, the functionality of adding and saving “tags” to my custom post types works just fine. Upon activating your plugin, adding or saving tags to my custom post types no longer works.

I don’t understand the question…>Is this a custom setup/configuration you have that uses CMB2 for its metaboxes and whatnot?

I am using the ‘object_types’ => array( ‘event’, ), // Post type

I also copied the example functions to use as a platform to test and learn from.

Here’s my custom post type and taxonomy code as requested.

//*Code for event custom post type and taxonomy
//* Create Event Type custom taxonomy
add_action( 'init', 'custom_event_type_taxonomy' );
function custom_event_type_taxonomy() {

	register_taxonomy( 'event-type', 'themeprefix',
		array(
			'labels' => array(
				'name'          => _x( 'Event Types', 'taxonomy general name', 'themeprefix' ),
				'singular_name' => 'Event Type',
				'search_items'  => 'Search Event Types',
				'edit_item'     => 'Edit Event Type',
				'add_new_item'  => __( 'Add New Event Type', 'themeprefix' ),
				'new_item_name' => __( 'New Event Type', 'themeprefix' ),
			),
			'exclude_from_search' => true,
			'has_archive'         => true,
			'hierarchical'        => true,
			'query_var'    => true,
			'rewrite'             => array( 'slug' => 'event%eventtype%', 'with_front' => false ),
			'show_ui'             => true,
			'show_tagcloud'       => false,
		)
	);

}

//* Create event custom post type
add_action( 'init', 'custom_event_post_type' );
function custom_event_post_type() {

	add_rewrite_tag('%eventtype%','(.+)');

	register_post_type( 'event',
		array(
			'labels' => array(
				'name'          => __( 'Events', 'themeprefix' ),
				'singular_name' => __( 'Event', 'themeprefix' ),
			),
			'has_archive'  => 'event',
			'hierarchical' => true,
			'menu_icon'    => '',
			'public'       => true,
			'rewrite'      => array( 'slug' => 'event/%eventtype%', 'with_front' => false ),
			'supports'     => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'trackbacks', 'custom-fields', 'revisions', 'page-attributes', ),
			'taxonomies'   => array( 'event-type', 'post_tag' ),

		)
	);
	
}

I hope that gives you a bigger picture.

Thanks for the help!

Recreating the rule by choosing “Page” then “Post Type” is fine, but unfortunately that does not allow me to specifically select the “Single Post” of post type or the “Archive Page” of post type in which that case, my widget doesn’t display where I need it to.

After reviewing my other test sites, which I use widget visibility on, it doesn’t matter which rule I was originally using. No matter the rules set, all original (visual) visibility settings that I originally had selected have disappeared, but still remain in tact on the front end. Additionally, after viewing jetpack 4.6 visibility options (on my non-updated test sites) I have determined which visibility rules I specifically would have selected for my original issues, they are as follows…

Show if…

Post Type – Single Post: Job
Post Type – Archive Page: Archive of Jobs
Taxonomy – Sales Jobs

Note: Out of the above setting options, the only available existing setting option in version 4.7 is the “Taxonomy” option. The other options, “Post Type – Single Post” & “Post Type – Archive Page“, are no longer able to be selected within the widget visibility settings. These above mentioned settings are being used on custom post types I created.