How to utilize custom layouts (from the builder) globally for custom post types?

[Israel Curtis]

So the layout builder has become a very powerful tool, and I love how much time it saves me from coding elaborate html page templates. And I know there’s the “layout to posts” plugin which provides the ability to apply any custom layout to post types other than pages (including my own declared custom post types) — but it’s only available as a metabox selector for each individual post object, meaning you have to go and manually choose a template for every new post you create. There’s no way to say “use this custom template *every time* we’re displaying “mycustomposttype” posts.

From an end-user standpoint, having to choose the template every time you create a new CMS entry for say “movies”, so that those “movie” post types are displayed with “mymovielayout” is an extra step that seems unnecessary (create a new “movie” post, then go and tell wordpress that it needs the “movie” layout :P), and opens the possibility that they could forget to select the layout or pick the wrong one. It’s far more effective to restrict the data entry of the end-user to only certain content elements so they can’t mess up the layout, which you, the site builder, have carefully crafted.

I’d be perfectly happy with a purely code solution, some filter hook that I could include (with all my custom post type declarations) that simply tells jumpstart to connect a particular layout ID with a particular custom post type slug. Maybe could even have two hooks for “single” vs. “archive” views of that custom post type. No more need for handmade template files

single-{post_type}.php

archive-{post_type}.php

in the child theme.

If you were going to support this usage in the themeblvd options UI, I would think it would work to display a list of all the declared post types in a column, and then alongside have a dropdown selector for each one, populated with the currently defined custom templates from the builder.

Another route would be to have an option in the template editor (maybe in that Template Information metabox) to assign that particular layout to be the default template for a particular post type. Then the individual post editor metabox (if shown) would provide the option to override for exceptions, but wouldn’t be required every time.

Basically, there needs to be a more global method of applying these incredibly powerful templates. Right now you can only use them one by one, “per post”, via the post editor metabox.

In doing this, you’d really be unleashing the power of the layout builder to be the main tool for site builders to design their dynamic page layouts, replacing much of the need for hardcoded Template Files.

Topic

[Jason Bobich]

To answer your question of how to utilize layouts globally, it’s actually not all that complicated if we’re talking about a singular item.

You need to:

1. Filter into the framework’s global config, and set the custom layout ID (layout slug and layout post ID).

function my_frontend_config( $config ) {

	// To activate builder for this page load, you need 
	// the two parameters of $config set:

	// $config['builder'] = 'layout-slug';
	// $config['builder_post_id'] = themeblvd_post_id_by_name( 'layout-slug', 'tb_layout' );

	return $config;
}
add_filter( 'themeblvd_frontend_config', 'my_frontend_config' );

2. Redirect to the template_builder.php page template.

function my_builder_redirect() {
	if ( themeblvd_config('builder') ) {
		include_once( locate_template( 'template_builder.php' ) );
		exit;
	}
}
add_action( 'template_redirect', 'my_builder_redirect' );

[Jason Bobich]

Let’s look at a practical example of apply custom “templates” from the admin to all single posts of various custom post types. In your admin, let’s say any template we want applied to a custom post type we’ll name in the format type-{post_type}.

So, for example, we have a custom post type called “portfolio-item” and we want to target all of these posts with a template. We create a template in the admin called “type-portfolio-item”.

Now, we can setup a dynamic system to check for these:

<?php
/**
 * Look for existing template from admin Layout
 * Builder to redirect to for single posts.
 */
function my_frontend_config( $config ) {

	if ( is_single() ) {

		$template = 'type-'.get_post_type();

		if ( $template_id = themeblvd_post_id_by_name( $template, 'tb_layout' ) ) {
			$config['builder'] = $template;
			$config['builder_post_id'] = $template_id;
		}

	}

	return $config;
}
add_filter( 'themeblvd_frontend_config', 'my_frontend_config' );

/**
 * If this is a single post, and we've set the global config
 * builder, redirect WordPress to the builder template file.
 */
function my_builder_redirect() {
	if ( is_single() && themeblvd_config('builder') ) {
		include_once( locate_template( 'template_builder.php' ) );
		exit;
	}
}
add_action( 'template_redirect', 'my_builder_redirect' );

Note: This is all untested. Just off the top of my head. But that should give you enough to get started.

[Israel Curtis]

So I started digging in the Layout to Posts plugin to see how you’re applying layouts locally (per post). Found this filter hook for the primary config array:

add_filter( 'themeblvd_frontend_config', 'themeblvd_ltp_frontend_config' );

and then the triggering of the layout builder in case a layout has been selected

add_action( 'template_redirect', 'themeblvd_ltp_redirect' );

So I guess what explains the current “non-global” system for applying layouts is that you’re storing the selection of a layout in the individual post meta. Thus, every post that is to be displayed with a custom layout must have the post meta included.

$layout_name = get_post_meta( $post->ID, '_tb_custom_layout', true );

So my plan to implement a more global usage of layouts was to copy the functionality of themeblvd_ltp_frontend_config() but instead of checking for post meta, I would provide the custom layout name manually depending on the custom post type involved (and then later I’ll build some kind of theme options UI to assign layouts for each post type).

Now technically all I need to replace is this:

$layout_name = get_post_meta( $post->ID, '_tb_custom_layout', true );

and the rest of themeblvd_ltp_frontend_config() would be identical, where it grabs the id, featured, below, sidebars, etc. This would work, but I’d rather not be recreating all that very themeblvd-specific code, which might break with future updates to themeblvd framework. Maybe that could exist within the framework and I could just be filtering the retrieval of the layout name — to allow for cases other than post meta storage.

I’m also wondering why

add_action( 'template_redirect', 'themeblvd_ltp_redirect' );

exists in this external “Layout to Posts” plugin — don’t you need to be checking for custom layouts normally and redirecting even without this plugin? If I’m filtering the primary config array to add a layout, I would think the framework would automatically notice the builder layout in the config and fire this redirect automatically.

[Israel Curtis]

… and of course you answer while I’m respond to my own question 😛 Sorry it looks like I’m not listening …

[Jason Bobich]

Yeah see my actual example here. It’s much more simple than you’re making out to be. The plugin is complex because (1) it has a meta box and (2) it works also with older themes.

[Jason Bobich]

don’t you need to be checking for custom layouts normally and redirecting even without this plugin?

In a normal circumstance with a page, you’re setting the page template through the standard WordPress option. And thus, WordPress already knows to use correct template file. This whole system was originally built around pages and using the standard WordPress page template system, linking up template_builder.php in the theme.

But when you start dealing with posts, WordPress is obviously going to pull the theme file hierarchy associated with single posts, which doesn’t include page templates. So we have to force the redirect to our page template file.

[Israel Curtis]

Perfect. Pretty much exactly what I learned from scanning the Layout to Posts plugin. Though I am happy to see that I don’t have to include all the other code from themeblvd_ltp_frontend_config(). So just setting these two keys is enough:

$config['builder'] = $template;
	$config['builder_post_id'] = $template_id;

Based upon this potential use scenario, I’m guessing you might want to include your example my_builder_redirect() function in the framework itself, to respond to any case in which someone sets the global config builder? Any reason you wouldn’t want this always checking by default?

[Jason Bobich]

Because the whole system is designed around pages and setting up individual landing pages or homepage. For now, these kinds of uses are not what the Builder is meant for.

[Jason Bobich]

By the way, if you didn’t get notified, I figured out this odd one you were talking about before:

http://support.themeblvd.com/forums/topic/post-grid-or-list-when-query-returns-pages-displays-0-for-excerpts/#post-20393

[Israel Curtis]

once again you squeeze out two posts in the time it takes me to respond once 😛

I can understand your focus on pages. Just hoping that given the immense popularity of using wordpress as a more universal CMS, and the value of creating custom post types to better create and organize content (especially on the back-end), I can keep pushing for broader applications of your great framework features…

[Jason Bobich]

Right now these sorts of things you’re wanting to do are not by design of the Builder, and there’s nothing wrong with that. But the problem comes in when trying to make these actually default, marketable end-user features.

When you do this, all of a sudden, there are all of these new issues that come to light, showing that the Builder is not meant to do these various things. — If you can create templates for single posts, why not category archives, for example? (This is something many people have asked me) Well, then there has to be new builder elements like a post list that pulls from the actual current primary loop, and a way to insert the title/description of the category. And then you go down this road of all these possible things you could do, with one thing leading to another, creating a whole system where you’re building a theme from your WP admin?

So, these things have to be more carefully planned out in the future, with the big picture in mind, and not just thrown in there bit-by-bit. And right now, the big picture is that the Builder is a tool to create those special landing pages. And with 2.0, we’ve only just started to get into this idea of “re-usable” templates for pages.

In the future (like Builder 3.0), I see the Builder not really going in the direction of replacing theme files all over the place, but more towards the idea of more visual ways of building these pages, like through the Customizer.

[Author]

Replies