Make WordPress Core

Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#42688 closed feature request (wontfix)

Option to make get_template_part return instead of require

Reported by: mclaurent's profile mclaurent Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.9
Component: Themes Keywords: 2nd-opinion close
Focuses: template Cc:

Description

Having the ability to have a template returned instead of required would be extremely helpful for building shortcodes using get_template_part to load reusable sections of code in the theme. Current work-arounds include output buffering and using locate_template, both of which have their own downsides.

<?php
function get_product_template($atts) {

    // the last boolean attribute would toggle between $echo = true or false.
    // Shortcodes should return output instead of outputting it directly.
    return get_template_part( 'product', $atts['type'], false );
}
add_shortcode('products', 'get_product_template');

The current work-around with output buffering looks something like this but it feels heavy for what it is meant to do.

<?php
function get_product_template($atts) {

    ob_start();  

    get_template_part( 'product', $atts['type'], false );

    $ret = ob_get_contents();  
    ob_end_clean();  
    return $ret;   
}
add_shortcode('products', 'get_product_template');

The alternative work-around is using locate_template however this does not check for fallback templates nor does it evaluate any PHP inside the template.

<?php
function get_product_template($atts) {

    $attribute = $atts[ 'type' ];
    return file_get_contents(locate_template( "product-{$atts}.php" ) ); 

}
add_shortcode('products', 'get_product_template');

Change History (6)

#1 in reply to: ↑ description @dd32
7 years ago

  • Keywords 2nd-opinion added
  • Type changed from enhancement to feature request

Replying to mclaurent:

<?php
function get_product_template($atts) {

    ob_start();  

    get_template_part( 'product', $atts['type'], false );

    $ret = ob_get_contents();  
    ob_end_clean();  
    return $ret;   
}
add_shortcode('products', 'get_product_template');

That can be shortened to just:

<?php
function get_product_template($atts) {
    ob_start();

    get_template_part( 'product', $atts['type'] );

    return ob_get_clean();
}
add_shortcode( 'products', 'get_product_template' );

I don't see this as being too complex for a plugin to handle itself, and is exactly what would happen under the hood in core if we were to add the functionality. It's not heavy-handed at all.

Overall, it seems that the extra two lines of code here is acceptable, given most plugins/themes should hopefully have a lot more sanitisation placed upon the data being passed into the template anyway.

#2 @mclaurent
7 years ago

Thanks @dd32 that makes sense. I agree that it isn't much extra work work at all to use the get_template_part within a shortcode. I guess that I feel the function name to be misleading as it begins with "get_" and implies that something is returned rather than echoed.
Would you consider a patch for a new function get_template_part_shortcode( $slug, $name = null ) or an updated function get_template_part( $slug, $name = null, $echo = true ) ?

#3 @dd32
7 years ago

I don't think either are needed myself, but I'll leave it open to other committers to see if anyone feels strongly.

A wrapper with shortcode in the method name doesn't seem useful, and like I said, given it's only two lines, I don't see the real need for core to support adding an $echo parameter to get_template_part() as I really dislike all the various $echo = ? functions.

#4 @dd32
7 years ago

  • Keywords close added

I am going to mark this as 2nd-opinion close for future trac cleanup purposes, if no-one else comes along and decides to run with it.

#5 @johnbillion
6 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Thanks for the suggestion @mclaurent , but I'm closing this as wontfix as per dd32's comments above. Cheers!

#6 @mclaurent
6 years ago

Thanks all for reviewing the ticket, the comment from @dd32 works for now as I appreciate the current work that is happening in the project, but hopefully this slight improvement can be reconsidered in the future.

Note: See TracTickets for help on using tickets.