Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#21673 closed feature request (invalid)

Passing scoped variables and doing partial page caching with get_template_part

Reported by: sc0ttkclark's profile sc0ttkclark Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.4.1
Component: Template Keywords:
Focuses: Cc:


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() :)

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

Change History (7)

#1 follow-up: @sc0ttkclark
12 years ago

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()

#2 @sc0ttkclark
12 years ago

  • Resolution set to invalid
  • Status changed from new to closed

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.

#3 @SergeyBiryukov
12 years ago

  • Milestone Awaiting Review deleted

#4 in reply to: ↑ 1 @mikeschinkel
12 years ago

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?

#5 @mikeschinkel
12 years ago

  • Cc mikeschinkel@… added

#6 @sc0ttkclark
12 years ago

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

#7 @iandunn
11 years ago

  • Cc ian_dunn@… added

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

Note: See TracTickets for help on using tickets.