Disable Blade in favor of Timber?

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

3 Likes

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:

base.blade.php:

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

controllers.php:

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');

Thanks!

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.

Controller:

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' }}

:slight_smile:

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.

4 Likes

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.

4 Likes

Oh god I have so much to learn.

3 Likes

Hello,

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) {
    $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

mensch,

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.

With beta 3 (I think) I made the switch to Blade and haven’t looked back since. While it’s still true you miss out on a some Timber convenience methods, but soberwp’s Controller makes working with Blade a charm.

Same here, love using the controllers! Superclean separation between data and markup!

Excuse me for noobish questions, but isn’t this very much bleeding-edge coding?

The Sober Controller is essentially 1 guy, it’s less than a year old, and the entire documentation is one readme file. The install base must be tiny. If you are basing a theme around this, is it going to be supported and functional in 3-4 years? Can it be easily passed off to another developer or does it create long-term support headaches for the client?

Like with the Sage Wrapper, I’m seeing a lot of added complexity and marginal benefit so far. But then I’ve only invested a week into trying to understand Sage 9 and maybe that’s not enough time.