This is searchable archive of our old support forums, which operated from 2012 - 2016. To find out how to get support for your current theme, please visit our support page.

Jumpstart 2, Beta 3 – Questions regarding using WP custom_post_type

  • Creator
    Topic
  • #21452
    Ron
    Participant

    Hi Jason,

    I have several question regarding using Jumpstart with WP “custom_post_type”. I need to create several WP custom_post_types and register them using WP register_post_type to provide items on the WP Dashboard. These will also have custom fields, etc. (my client need to be able to enter fixed data types, repeating content types, etc.)

    In the purely WP sense, I would normally create a “single-custom_post_name.php” file to handle the display of the single posts, etc.

    I guess I’m not quite clear how (or if) I can do the same in the Jumpstart 2.x.

    In JS 1.x, I’ve created simple custom single posts from TB “content.php” and registered them with
    add_filter( ‘themeblvd_template_parts’, ‘my_template_parts’ );
    etc. without custom_post_type.

    But with the JS framework, the “content.php” code already sits inside the WP loop, so this doesn’t seem the right way to integrate for a WP custom_post_type.

    I guess my questions:

    1) Does JS 2.x support an integration of WP custom_post_types?
    2) to Custom Layout Builder (list, grids)?
    3) If so how?
    4) or, does JS recognize a “content-custom_post_name.php” automatically like WP?
    5) Or is it just better to to implement the standard WP way which allow me access to the loop in order to query with the custom_post_type I create?

    I suspect there might be several ways to approach this, but kind of want to hear your thoughts on the best way in JS 2.x

    Thanks in advance,
    Ron

Viewing 5 replies - 1 through 5 (of 5 total)
  • Author
    Replies
  • #21456
    Jason Bobich
    Keymaster

    Hi,

    Nothing has changed since v1 in this regard. Sure, as always, you could copy the entire single.php file, rename it, and use that; but as with any theme, this is probably going to make updates down the road harder. So, putting the filterable template part system in place is meant to give you a better alternative to doing that, which will make updating go more smoothly in the future.

    So, yup, your basic approach you’ve already outlined is how I’d say you want to go about it. However keep in mind (since v1.1, I believe) , there are two filters you can use for this.

    1. get_template_parts — plural, an array of all template parts, applied outside the loop
    2. get_template_part — singular, a single template part string, called within the loop

    So, if you’re trying to filter based on the post type, you’d want to do this within the loop, and so you’d want to use the filter on the individual template part called.

    function my_template_part( $part, $type ) {
    	
    	if ( $type == 'single' && get_post_type() != 'post' ) {
    		$part = get_post_type();
    	}
    
    	return $part;
    }
    add_filter('themeblvd_template_part', 'my_template_part', 10, 2);

    This would result in you creating files like content-{post_type}.php in your child theme.

    Let me know if this doesn’t work… I’m just writing it out off the top of my head.

    #21471
    Ron
    Participant

    So I must be missing something. I’ve successfully done the content-{template}.php in JS 1x.

    I tried both get_template_part and get_template_parts with the same result. Both the “Read More” post link and the “View Post” in the Post Editor take me to the Home page instead of to any single page. (Normal posts work okay.)

    The template parts code was added to the functions.php of my child theme (started from your JS child theme). The file I’m trying to target is “content-gwfa_board.php” (located in child theme’s root directory).

    I hard-wired the file name part name into this code to test, since I wasn’t sure that I hadn’t done something screwy with the custom_post_type (register_post_type function). The register_post_type seems okay though (and the post-type is coming back as ‘gwfa_board’). Note: I’ve implemented the custom_post_type in a plugin (I need to use several identical custom_post_types across several web sites in a WP Multsite install – each is using it’s own different JS 2.x child theme). The plugin seem to perform okay on the dashboard side.

    Here’s the code:

    Test 1

    function gwfa_set_custom_post_type_template_part ( $part, $type ) {	
    
    	if ( $type == 'single' && get_post_type() != 'post' ) {
    		$part = 'gwfa_board';   // hard-wired for test
    	}
    
    	return $part;
    }
    add_filter('themeblvd_template_part', 'gwfa_set_custom_post_type_template_part', 10, 2);

    or
    Test 2

    function gwfa_set_custom_post_type_template_parts ( $parts ) {
     
     	global $my_post_id;	
    															   						
    	$parts['single'] = 'gwfa_board';   // hard-wired for test
    			
        return $parts;
    }
    add_filter( 'themeblvd_template_parts', 'gwfa_set_custom_post_type_template_parts' )

    Am I missing something in JS 2.x? functions.php child file?

    Or is there possibly something I’ve done wrong in register_post_type that would block the display of single posts?

    Best,
    Ron

    #21473
    Jason Bobich
    Keymaster

    Both the “Read More” post link and the “View Post” in the Post Editor take me to the Home page instead of to any single page. (Normal posts work okay.)

    This tells me something is weird about how your post type is registered. I don’t see how this has anything to do with Jump Start (or any theme you’d be using).

    But I went ahead and just setup a test and tested it myself. I registered a custom post type with standard register_post_type() function and then applied the code I wrote for you above, created a content-example_type.php file … and everything worked. Maybe you can try this, as well, and not use your plugin (to troubleshoot).

    So, I’d maybe step back and look at how these custom post types are being registered before letting this stuff with Jump Start get too complex.

    #21553
    Ron
    Participant

    My bad. Nothing weird about anything you or I coded. Angela pointed out that you have to re-set the permalinks after adding a custom_post_type. Everything worked okay as a plugin, too. That’s one thing that constantly drives me crazy about WP. sigh.

    Thanks once again.
    Ron

    #21555
    Jason Bobich
    Keymaster

    Aw, yup, gotta flush those rewrite rules!

Viewing 5 replies - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.