Using WordPress as an application framework -- Draft podcast • Post Status

I’d like to follow up on Twig templating, and Timber’s extensions/adapters for WordPress.

We’ve been using Twig for a large multi-site (not Multisite™) client project at XWP. Having a templating language was a key requirement for the client. One big reason was that they needed to be able to empower their frontend developers to be able make template changes. Twig facilitates this not only because straight PHP logic is not allowed (both good architecturally for separation-of-concerns, but also security-wise so they can’t accidentally do something bad) but also with autoescape they can output variables safely by default without having to do the echo esc_html(…) dance over and over again. This can greatly reduce the amount of code review needed for frontend developer work since Twig will force them to do the right thing (usually). Additionally, the sites we’re developing are running on WordPress.com VIP and so it is especially important that frontend developers who are unaware of all the WordPress best practices and PHP security considerations to be able to hack on templates without their code getting rejected during review, and thus delay a deployment.

Also, Twig is not just some syntactic sugar that can translate 1-to-1 into PHP equivalents. You can’t do the same in WordPress templates with get_template_part() as you can do in Twig with its model of template embedding and extending. The way I think of it, WordPress templates require you to do a top-down template include pattern, whereas Twig allows you to build templates from the bottom-up.

Since Twig is not just some syntactic sugar but a full templating engine, the concern raised about coming up against a roadblock when wanting to do something the Twig language doesn’t support isn’t really valid. Twig is extensible and new language features can be added. So if it isn’t in Twig it can be added in Timber, if not in Timber then you can add another extension. Not only can new functions and filters be added, but entirely new language constructs can be introduced in Twig as it allows you to hook into the compiler.

By the way, we’re not using Timber at all. Given the constraints of VIP, we can up with our own wrapper plugin called VIP Twig which facilitates using Twig in that environment (we have more work to do there, however). There is a lot of code in Timber, and so it’s too heavy for our purposes and for the purpose of getting reviewed for VIP; we have a client-internal plugin called “Twig Integration” that implements any custom functions or filters that the frontend developers need to use Twig in WordPress effectively.

One thing holds me back from fully getting excited about Twig is that it is a PHP-specific framework. There is a JS implementation, but it is far from complete. I’d really want to be able to render templates on the server as well as the client, but Twig isn’t really there yet.

Anyway, all of this to say that Twig can be a great choice for large projects that have complicated templates and many contributing frontend developers maintaining them.

4 thoughts on “Using WordPress as an application framework — Draft podcast”

RPWD

October 28, 2015 at 12:34 pm

Partway through this podcast, I could hear both of you roll your eyes when referring to Advanced Custom Fields usage. Any chance you guys could elaborate and/or point us to more information on why you feel this way? ACF is something that I use on every site I build and I’d love to hear more about your thoughts/opinions on this topic. 🙂 Thanks!
- Austin
  
  November 5, 2015 at 8:06 am
  
  I think their point was that ACF stuffs everything in the post meta table and that information might be better served in a more organized way in terms of being in the database and it’s ability to be queried.
Weston Ruter

November 1, 2015 at 2:18 pm

I’d like to follow up on Twig templating, and Timber’s extensions/adapters for WordPress.

We’ve been using Twig for a large multi-site (not Multisite™) client project at XWP. Having a templating language was a key requirement for the client. One big reason was that they needed to be able to empower their frontend developers to be able make template changes. Twig facilitates this not only because straight PHP logic is not allowed (both good architecturally for separation-of-concerns, but also security-wise so they can’t accidentally do something bad) but also with autoescape they can output variables safely by default without having to do the echo esc_html(…) dance over and over again. This can greatly reduce the amount of code review needed for frontend developer work since Twig will force them to do the right thing (usually). Additionally, the sites we’re developing are running on WordPress.com VIP and so it is especially important that frontend developers who are unaware of all the WordPress best practices and PHP security considerations to be able to hack on templates without their code getting rejected during review, and thus delay a deployment.

Also, Twig is not just some syntactic sugar that can translate 1-to-1 into PHP equivalents. You can’t do the same in WordPress templates with get_template_part() as you can do in Twig with its model of template embedding and extending. The way I think of it, WordPress templates require you to do a top-down template include pattern, whereas Twig allows you to build templates from the bottom-up.

Since Twig is not just some syntactic sugar but a full templating engine, the concern raised about coming up against a roadblock when wanting to do something the Twig language doesn’t support isn’t really valid. Twig is extensible and new language features can be added. So if it isn’t in Twig it can be added in Timber, if not in Timber then you can add another extension. Not only can new functions and filters be added, but entirely new language constructs can be introduced in Twig as it allows you to hook into the compiler.

By the way, we’re not using Timber at all. Given the constraints of VIP, we can up with our own wrapper plugin called VIP Twig which facilitates using Twig in that environment (we have more work to do there, however). There is a lot of code in Timber, and so it’s too heavy for our purposes and for the purpose of getting reviewed for VIP; we have a client-internal plugin called “Twig Integration” that implements any custom functions or filters that the frontend developers need to use Twig in WordPress effectively.

One thing holds me back from fully getting excited about Twig is that it is a PHP-specific framework. There is a JS implementation, but it is far from complete. I’d really want to be able to render templates on the server as well as the client, but Twig isn’t really there yet.

Anyway, all of this to say that Twig can be a great choice for large projects that have complicated templates and many contributing frontend developers maintaining them.
Steven Jones

November 2, 2015 at 9:26 am

I was already thinking about the lack of support themes usually have for editor styles when listening to the podcast but I came up with an automated way to produce them with no maintenance.

I think because you can use the editor without extra styling them often become optional but if you want to make a good experience for your user then it should actually be quite high on the list.

Anyway – here’s the approach I take: http://stomptheweb.co.uk/2015/10/automatically-generate-editor-styles-in-wordpress/