Conditions and custom post types

@mrcarllister – Haven’t had any reports of this type of thing, first thing I would check is that you don’t have a JS error on those pages preventing it from working correctly. Check your browser console for JS errors on a fantasy package that is targeted by the popup.

Hope that helps.

@danieliser thanks for getting back to me. No JS errors. The popup just isn’t loading.

I’ve tried it with a post and it works. So there’s something about my custom post types which aren’t triggering the condition to return true.

I’ve tried individual single.php and single-post_type.php but from what I tell from the plugin is that you only check if it is a single post page that matches post type.

Is there anything else you could think of trying?

Thanks again

@mrcarllister – You can see exactly how we process all post types here, including pages & posts. We made it as simple as we could so that we wouldn’t have to deal with unreliability.

If its working for pages & should be working for other post types as well.

https://github.com/PopupMaker/Popup-Maker/blob/master/includes/class-pum-condition-callbacks.php#L14

I am having the same issue as well. It worked before but since I updated it – the popups aren’t working on my custom post types. None of the code has changed – and it was initially working about three months ago. Any solution?

@aoassist – Hmm, as I said before the only thing that can be occurring here is that your CPT is doing this in a non standard way.

How did you add your CPTs?

I’ve been having the same issue too. Looking at the function you posted above @danieliser it looks like mine is breaking due to the custom post type being named as ‘blog_post’. What’s then being stored in $post_type is actually ‘blog’ and not ‘blog_post’.

Also when I select ‘Blog Archives’ as one of the conditions for my popup the $modifier variable is set to ‘index’ but looking at the switch statement in that function that doesn’t exist?

@chrisarnoldco – Will try some custom post types with your naming. Question though, why would you add a blog_post post type rather than use the existing post post type. Seems counter productive, though gives me a good starting point to work out what is going wrong.

Can you give me the code used to register your post type exactly so I can try to duplicate it?

The site has 7 custom post types and the post post type is being used for News and Events. They then asked for a blog to be added to the site so we created a new post type and named it blog_post.

The code I used for to register the post type is below…

function ns_blog_posttype() {
	register_post_type( 'blog_posts',
		array(
			'labels' => array(
				'name' => __( 'Blog' ),
				'singular_name' => __( 'Blog' ),
				'add_new' => __( 'Add New Blog' ),
				'add_new_item' => __( 'Add New Blog' ),
				'edit_item' => __( 'Edit Blog' ),
				'new_item' => __( 'Add New Blog' ),
				'view_item' => __( 'View Blog' ),
				'all_items' => __( 'All Blog' ),
				'search_items' => __( 'Search Blog' ),
				'not_found' => __( 'No Blogs found' ),
				'not_found_in_trash' => __( 'No Blogs found in trash' )
			),
			'public' => true,
			'supports' => array( 'title', 'editor', 'excerpt', 'thumbnail' ),
			'rewrite' => array("slug" => "blog", "with_front" => false), // Permalinks format
			'menu_icon' => 'dashicons-admin-page',
			'menu_position' => 30,
			'has_archive' => true
			)
	);
}
add_action( 'init', 'ns_blog_posttype' );

@chrisarnoldco – Hmm, semantically wouldn’t just using categories be a better idea? IE News, Events, Content Category 1 etc?

None of my business, just my 2 cents haha.

Ok perfect, I will try that later tonight and see if I can duplicate it.

Thanks for the code.

No that’s cool. Each post type has it’s own custom fields and taxonomies, trying to keep them all under the post post type would just get too unwieldy. Plus when the client logs in it’s much clearer for them to see where they need to add their content, having them all under Posts will mean they’ll need to remember to select the category, add data to the correct fields etc etc.

Okay great, let me know if you need anything else.

@chrisarnoldco – Testing this now, but just a tip, your post type should be singular. IE page, post, blog_post. Yours is currently blog_posts. Don’t think that has anything to do with it but WP assumes that its a singular by design.

Consider this

A singular post $post->post_type = blog_posts currently. That doesn’t quite sound right :).

@chrisarnoldco – Got it. The issue was we were splitting based on _ and taking the first & last values. Unfortunately that didn’t account for post types with a _ in them like yours. So it didn’t come out as blog_posts but as blog.

Now its a bit simpler & more refined like so:

// Everything prior to the last _ should represent the post_type.
		$post_type = implode( '_', explode( '_', $settings['target'], - 1 ) );
		// Modifier should be only one string after last _
		$modifier = array_pop( explode( '_', $settings['target'] ) );

Marking this resolved. Will be out in v1.4.16 come Monday.

@mrcarllister, @aoassist, @chrisarnoldco – Please take a moment to click that it Works and to rate and review the plugin or support.

@danieliser I’ve downloaded and tested the changes and my custom post type is now working so thank you!

However the popup is still not showing on the Archive page… the modifier is being set to index but the switch statement within the post_type function doesn’t contain a case 'index': so it’s always returning false.

Thanks for the tip re. post types being singular by the way ??

@chrisarnoldco – Hmm, not sure how that has gone un-noticed this long. v1.4 (those types of conditions) has been out for nearly 5-6 months and nobody has reported it. Such a blatant issue, very surprised. Will get a patch out.