Disable Blade in favor of Timber?

Hi there,

Although I like the new Blade templating options in Sage alpha 4, I still prefer using Timber instead. I like the fact that I can use my php templates purely for retrieving data for that specific template and pass that on the my twig views. That way I can really use my views for purely html markup.

This off course is a personal taste, but with the latest alpha 4 release I found it hard to figure out how deeply woven Blade is into the new Assets pipeline in the new Sage setup, helpers & filters files.

I would still like to use the benefits of the latest Sage release, but without Blade. I guess I can still use a page.php file instead of page.blade.php, but I was wondering if this doesn’t add unnecessary overhead to my project?

Do you have any intentions to enable Blade as an option in the future? And if not, is it ‘safe’ to just keep using regular php templates or will that potentially break stuff in the future?



Yes, you may rename your files to .php and use those instead. Blade will run them through its PhpEngine, which basically does nothing.

class PhpEngine implements EngineInterface
    // ...

    protected function evaluatePath($__path, $__data)
        $obLevel = ob_get_level();


        extract($__data, EXTR_SKIP);

        include $__path;
        /** Note it actually does a little exception handling here, but 
           I've removed it for the sake of clarity. **/

        return ltrim(ob_get_clean());
    // ...

Good to know Timber can still be used without much effort in Sage 9. I’m a heavy user of the combination of Sage 8 and Timber.

I was under the impression that the new release would rely heavily on Yeoman in order to facilitate different versions of Sage 9 (e.g. Sage+Foundation, Sage+Semantic UI, Sage+Blade, Sage+Timber, etc.). Is this still the intention or have things shifted towards a default Sage+Blade solution?

Thanks, good to know indeed!

No, not at this time.

Just saw the beta announcement and I can’t wait to develop something with it. Yeoman always seemed like a nice extra, but certainly not essential to my particular needs.

This is ideally how you would use Blade templates as well. You can pass data with this filter


Good to know that we can still use twig templates with Sage 9.

I’m working on a Patternlab -> Sage integration which relies on twig/timber.

I would use blade if only Patternlab supported it.

Ah cool, that DOES look very interesting!

I was wundering how you can declare global data (such as menu’s etc), regardless of the body class?

Can you use some kind of wildcard or are you supposed to add a global body class and then use the filter on that? Something like this:


<body @php(body_class('global'))>


function globalData() {
	$main_menu = wp_get_nav_menu_items('Primary Navigation');
	if ($main_menu) {
		$data['main_menu'] = $main_menu;
	return $data;
add_filter('sage/template/global/data', 'App\\globalData');


EDIT: This is not working unfortunately, it doesn’t pick up my added body class global, it only recognizes the body classes added by the sage filter.

Try adding your body class with a filter:

add_filter( 'body_class', function ( $classes ) {
    $classes[] = 'global';

    return $classes;
} );

That can go in src/filters or in your own functions file. I’m not sure if it’s the best approach, this is still new to me, but I just tried it and was able to pass data.


function globalData( $data ) {

    $data['my_global'] = 'Hi';
        return $data;

add_filter( 'sage/template/global/data', 'App\\globalData' );

Then in a template:

{{ $my_global or 'Nope' }}


1 Like

Yeah I tried that in the meantime and that does work!

If only there was an equivalent to Timber’s TimberMenu function in Blade, then I was sold already. I hate using that dreadful wp_nav_menu with it’s Walkers…

1 Like

Oh cool! I bet there’s something that can be done, like a custom directive or something? It’d probably be a pain write it, but it only has to be written once.

i have used sage / bedrock / trellis for several years now. I have integrated the timber plugin with sage to take advantage of the enhanced workflow offered by templating engines. now sage 9 is in beta and its using blade. great, but the way it has been implemented is at odds with what I thought were the reasons for seperating html views from php code.

i have developers and designers in the team and I have always tried to seperate the the php/wp api functions from the views so designers don’t have to look at php code and wp functions, but sage9 templates wrap php wp functions in the blade format and it seems counter intuitive to the efforts I have made to make this seperation for our team dev workflow.

I don’t get why sage9 works in this way. am I missing something? my designers just want to use html with {{variables}} that the developers make available for them . designers don’t want to see code like @php(the_post()), @if (!have_posts()), or {!! get_the_posts_navigation() !!}. they might as well go back to using php files and trying to do their design work and try not mess up the php

My guess is that it’s just early days, and you’ll likely see the implementation evolve as time goes on.

I’m a little confused about this criticism. Sage always used the normal PHP files as templates like any normal theme.

I’m sure you’d agree that Blade is a step in the right direction? It’s obviously better than nothing

I guess you’d prefer us to use Timber if we’re switching to a templating system? Sage tries to have a balance of pushing better practices without going too far. Timber just isn’t something we’re interested in adopting by default. It’s a step too far in our opinion (in the context of a default for a popular starter theme that never had it).

So while you are correct that keeping PHP code out of views/template is generally a good thing, Sage never did it anyway.

And this doesn’t stop you from using Timber with Sage 9. I guess there’s a little more work for you now which might be a little frustrating, but we’re trying to make things a little better for most people.


I believe his criticism was using WP’s functions in the templates. Which I can agree to an extent, if you want to use a templating engine, then the ideal scenario is gathering all your data and doing nothing but loops and echoing out data.

However, as what Scott basically said, the hard part of integrating Blade into the theme is done, restructuring the few base templates is the easy part. @jajouka, if you want to restructure the templates and use your own version of controllers to set up data so your designers don’t have to use WP/PHP functions, then obviously you’re still free to do that. It’s not like you’re any worse off from before, you actually now have the choice between using Blade or switching to Timber, just as before.

As has been mentioned quite a few times in the Blade discussions, we wanted to integrate Blade, but we don’t want Sage to become a framework rather than what it always has been - a starter theme. So we’ve added the basis for setting up controllers and having a more modern approach to your themes, and I would agree to us less WP functions in your template and start setting up data and then passing it to the templates - but setting controllers and routes and other things we strongly believe is out of the scope of a starter theme.


Oh god I have so much to learn.



Could you please tell me how can I use together Timber and Sage 9.
Actually I would like to replace Blade Template in favour of Twig.

Will be really appreciate for any information.

Thanks in advance.

In my custom Sage 9 setup I have removed all of the Blade stuff from setup.php (line 134 to 152) and added the following to my functions.php:

 * Check if Timber is loaded
if ( ! class_exists( 'Timber' ) ) {
	add_action( 'admin_notices', function() {
		echo '<div class="error"><p>Timber not activated. Make sure you activate the plugin in <a href="' . esc_url( admin_url( 'plugins.php#timber' ) ) . '">' . esc_url( admin_url( 'plugins.php') ) . '</a></p></div>';

  add_filter('template_include', function($template) use ($sage_error) {
        __('Make sure you activate the Timber plugin in the WordPress admin area.', 'sage'),
        __('Timber not activated', 'sage')
} else {
  Timber::$dirname = ['resources/templates'];

Templates reside in resources/templates. In my setup the controlling PHP files (header.php, footer.php, index.php, page.php, etc.) are all at the root level of the theme. This still bothers me, as the current state of Sage has all the PHP neatly tucked away inside the app directory.

I’m probably forgetting a lot of stuff and I’ve always found it more enlightening to look at code myself. This is the repository of my Sage 9 + Timber setup.

I’m still on the fence about Blade (mainly because I know Timber and its convenience methods are quite helpful) but that feeling is dwindling with every beta release of Sage 9. When it’s released I might just drop Timber altogether.

1 Like


With 9 beta 4 out, are you still using Timber over Blade?

I’m moving to Sage from a JointsWP + Timber configuration, really deeply enjoy templating in Timber/Twig, and wondering if it’s worth the effort to learn Blade.