20 Comments

  1. Blair Jersyer
    · Reply

    I’m wondering why such interesting feature took that long to be implemented. Frameworks have that feature and can’t literally exist without that. Anyway it’s never too late.

    Report

    • Justin Tadlock
      · Reply

      Templating-related features have largely taken a backseat in WordPress for years. Even the addition of get_template_part(), one of the biggest features over the last several years, was just a wrapper function for existing functionality. Not much has changed, and theme authors have been left to their own devices.

      Often, tickets like this just need someone to champion them. Many of the people with the resources to make improvements to the templating system just stick to building things in-house. They see 8-year-old tickets like this and don’t think it’s worth their time trying to get in core. So, until someone comes along to really push something and get approval, it just sits there untouched.

      Report

  2. Mario Peshev
    · Reply

    I can’t believe this is so exciting – and yet, it’s awesome!

    One step closer to dropping another batch of global variables across the board.

    Report

    • Scott Kingsley Clark
      · Reply

      Yes! I’m so glad other people thought it was worth it too and kept it going. I stopped doing theme dev a few years back and totally gave up on the ticket. I’m thankful it was championed again and finally merged!

      Report

  3. Ionut Calara
    · Reply

    I think things like these are great for the community. While I had a function I always used, when its part of the core, it gets used more, leading to better code overall. It’s crazy it hasn’t been integrated sooner, it’s such a simple change and its a core feature for any templating system.

    Report

  4. Saumya Majumder
    · Reply

    Can’t wait for the documentation & example code. This ks really amazing, should have been added long time back. But it’s never late to have great features like these.

    Report

  5. Cameron Jones
    · Reply

    About damn time.

    Report

  6. Kirsten
    · Reply

    Sounds good, but what does this mean in real life?
    What are possible use cases for this feature?

    Don’t talk to me foo bar stuff. ( I get this part. Pass on data.)
    But I’m afraid that I don’t quite get the meaning yet.

    Report

    • Justin Tadlock
      · Reply

      One simple example I use in my themes is to pass along the sidebar ID. So, let’s say I have a sidebar.php template to handle multiple dynamic sidebars. Instead of creating a template for each of the sidebars, I can pass the sidebar ID to the template so that it outputs the correct sidebar widgets.

      So, when calling my footer sidebar, I can do something like and pass along the sidebar ID:

      <?php get_sidebar( 'footer', [ 'sidebar_id' => 'footer' ] ) ?>

      That will look for a sidebar-footer.php and fall back to sidebar.php. Let’s assume I don’t create a sidebar-footer.php. My main sidebar.php template could handle this footer sidebar (or any other) like so:

      <!-- open html -->
      
      <?php dynamic_sidebar( $args['sidebar_id'] ) ?>
      
      <!-- close html -->

      If all the sidebars have the same markup, there’s no need for individual templates. I can just pass the ID that I need.

      This is an overly simple example, but I hope it illustrates how this feature can be used. As you get into more complex setups, you’ll find that you could use this in more and more ways.

      Most templating systems for other PHP frameworks start with the notion that you’re passing data into templates. WordPress generally works based on a set of global variables and “template functions” (i.e., the_title(), the_content(), etc.). Other templating systems would usually pass that data along via a variable instead. Often, the idea is to separate the logic code from the template code. But, I’m starting to venture into a much larger discussion.

      Report

      • Kirsten
        · Reply

        Thank you, Justin!

        Let’s see if I got it now.

        The old way I had to build a template for every sidebar (sidebar-footer.php, sidebar-blog.php and so on). Which was indeed somewhat strange.
        Now, in the new era, I will build only one sidebar.php template where I call the IDs directly from the functions.php. I can call this sidebar (with ID) from every template/template-part.

        So the point is I can define something in functions.php and access this from inside any template part, right?

        I wonder if this new way of accessing data will have any impact on the theme colors conundrum. With that I mean that Gutenberg colors are defined inside functions.php but I cant’t really do something with these colors. They just sit there.
        I can output some inline CSS but that’s about it.

        I am constantly looking for a connection of my theme design system (build on SASS) and the Gutenberg color palette. There are workarounds with custom properties, but I haven’t found one yet that works for me.

        Report

    • Jermaine Holmes
      · Reply

      I can pass objects to template parts without needing to use set_query_var(). Makes programming WP a little bit easier.

      Report

  7. Santosh Kunwar
    · Reply

    For a login time I am using set_query_var(); and get_query_var().
    It is a very nice feature.

    Report

  8. Khoi Pro
    · Reply

    About passing variables to sub-template.

    Believe or not, I able to do the same thing long time ago. This movement is too slow.

    https://github.com/barrel/barrel-wordpress/blob/master/wp-content/themes/barrel-base/lib/helpers/modules.php#L21

    Shopify now moves to “render” which brings variables inside, but limited it there and don’t need to reset variables back.

    https://shopify.dev/changelog/deprecating-the-include-liquid-tag-and-introducing-the-render-tag

    Report

  9. Rob
    · Reply

    Or just use include rather than get_template_part

    Report

    • Justin Tadlock
      · Reply

      The downside of that is you lose the ability for child themes to override the template and cannot use any of the hooks associated with it. It also wouldn’t be allowed in the WordPress theme directory.

      You could include locate_template() to allow child theme overrides and pass theme review guidelines. You’d still lose the hooks associated with get_template_part() in that case.

      Report

  10. Rob
    · Reply

    Yeah, not good if you make commercial themes.
    If you are building g a custom one that won’t have a child theme though…

    I seem to remember something about being able to include get_template_part

    Report

  11. Shrinivas
    · Reply

    I skipped using get_template_part() function many times as we can’t pass the variable to that template part file, Finally it is possible with WordPress 5.5.

    But when we use the “passing variable” feature in our theme, it won’t work in the earlier versions of WordPress. So the minimum requirement to run our theme is WordPress 5.5.

    Report

Leave a Reply to Khoi Pro Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: