Passing scoped variables and doing partial page caching with get_template_part

[sc0ttkclark]

I've recently developed an interesting class that provides an advanced get_template_part() experience.

This class has some stuff baked in for the project it was for, but it really provides a great proof of concept for a big addition to get_template_part().

I am suggesting we add three new arguments to get_template_part():

function get_template_part ( $slug, $name = null, $data = null, $expires = null, $cache_mode = null ) {

$slug and $name are great and all, but they lack the ability to reference currently scoped variables like a normal include/require does. One way around this is to pass $data into get_template_part(), like so:

<?php get_template_part( 'twitter', 'feed', compact( array_keys( get_defined_vars() ) ) ); ?>

This at least gives get_template_part() access to the currently scoped variables or any others you would like to pass in for context of a specific get_template_part() call. $data would then be passed to load_template() just above the $wp_query extract:

if ( !empty( $_data ) && is_array( $_data ) )
	extract( $_data, EXTR_SKIP );

The last two variables are centered around caching. $expires functions as you'd expect, it's a integer of seconds, where 0 is to not expire. $cache_mode would accept one of three values: cache | transient | site-transient

Caching get_template_part() can be very handy, especially for content that won't change often, and especially for cases where you have logged in users but no ability to offer full page caching (not recommended, as you've come to know).

Partial page caching is where it's at, this would be a big step up for theming within WordPress. I'm also not opposed to splitting this ticket up into two, one to pass $data into get_template_part(), and one to create a new function that hooks into get_template_part() using output buffering, something to be named like get_template_cached().

You can see my proof of concept as it currently exists in Pods 2.0 core, just ignore the parts that aren't exactly like get_template_part() :)

​https://github.com/pods-framework/pods/blob/2.0/classes/PodsView.php

pods_view( 'location/of/file.php', compact( array_keys( get_defined_vars() ) ), ( 60 * 60 * 24 ), 'site-transient' );

[sc0ttkclark]

Discussing with @nacin, it seems like a viable option for the $data is to not do the extract, just allow $data to be whatever, and let the user to extract on their side within their template, the $_data variable.

As for caching, @nacin feels it is not something core should be doing, but instead, allow for filtering to do that. I disagree, but hopefully there are more who can chime in to give their pro/con of caching's inclusion within get_template_part or an additional function like get_template_cached()

[sc0ttkclark]

I've broken off the $data variable portion of this ticket into it's own, I will break off caching into it's own as well, this was too big to implement, especially since $data on it's own seems to be more realistic for inclusion.

[mikeschinkel]

Replying to sc0ttkclark:

Just a general comment about function parameter architecture. Rather than added 3 more parameters to make it 5 total parameters, like so:

function get_template_part ( $slug, $name = null, $data = null, $expires = null, $cache_mode = null ) {
   ...
}

I'd highly recommend just adding one (what I call an) $args parameter and then allow the other two to be passed in via the $args array

function get_template_part ( $slug, $name = null, $data = array() ) {
   $args = wp_parse_args( $args, array(
      'expires' => null, 
      'cache_mode' => null, 
   ));
   ...
}

This is a pattern I've found to work extremely well and is very resilient to evolutionary changes in code over time. It also make it easier to:

• Remember function signatures include parameter order, and
• Be also to pass the $args array to functions the called function wants to delegate to, and
• It's also easier to read without having to scroll horizontally. :-)

Just something to consider maybe?

[sc0ttkclark]

Yeah I totally agree, I always prefer the $args approach for functions, so much more future-proof.

[iandunn]

The ticket sc0ttkclark mentioned for passing vars to get_template_part is #21676.