Add a templating engine like Twig

[discobot]

In the current state templating is plain spaghetti code. PHP interwoven with HTML. Readability is difficult at best. With a solution like Twig things would get dramatically improved. For WordPress already exists a plugin: GitHub - timber/timber: Create WordPress themes with beautiful OOP code and the Twig Template Engine . With its help you get a separation of concerns. You have PHP files responsible for the logic and control and twig files for the presentation. Way easier to read any maintain, improved security through Twig by default, way easier loop construction and in case you ever need to work with time and unix timestamps in WordPress the Twig functionality is nothing but bliss. And the best it is backward compatible. Themes could run built in the old fashioned way without using Twig functionality at all, you could update certain templates adapting to Twig or migrate or write themes from the ground up for Twig.

---

Read-only archive: Issues · ClassicPress/ClassicPress · GitHub

Author: rkoller

Vote count: 11

Status: open

Tags:

• difficulty-hard
• cp-research-plugin
• request-add-feature

---

Comments

Apart from the fact that I’m not a fan of Twig, I also don’t think that adding this into the equation would be a good thing. People have yet to learn something new, basically for no reason at all. There are other proposals that tackle decoupling and are far superior in both method and outcome.

~ posted by Pieter Bos

@Pieter: how would you recommend decoupling HTML structure from dynamic content?

I like template engines personally. For many projects in JavaScript, I’ve used a very similar library: GitHub - node-swig/swig-templates: Take a swig of the best template engine for JavaScript.

If you would like to use Twig in a WordPress/ClassicPress theme, by all means, feel free. Much like SCSS/SASS, you’ll need to make it part of your development workflow, and distribute the final, compiled PHP files produced by Twig as part of the theme package.

However, there are a couple of things that make the inclusion of a template engine not so great for ClassicPress core.

---

First, the core code does not even try to separate concerns - it’s all just PHP, filters, HTML, CSS, and some inline JavaScript mixed together however someone thought it was a good idea at the time. This means introducing a template engine to the core software would be a major re-organization of basically any code structure that outputs HTML.

For ClassicPress itself, we don’t have the resources to complete this task right now. Also, we are trying to keep ClassicPress compatible with WordPress, but rearranging the order of filters and HTML output would break a decent number of plugins.

---

Second, using Twig creates a bunch of generated PHP code. I understand why, but this is more code that needs to be reviewed and kept up to date. In the best-case scenario this adds a new build step, which is probably going to be required to develop against ClassicPress.

I am very interested in keeping ClassicPress easy to develop against. Ideally this means that build steps should only add “optional” value like minifying CSS and JS, but no build steps should be necessary to run and modify the core software.

~ posted by James Nylen

i’d suggest blade Blade Templates - Laravel - The PHP Framework For Web Artisans

~ posted by Paolo Falomo

I’d also suggest Blade over Twig. It’s actually already been done by the team over at Roots. Sage | WordPress Starter Theme with Tailwind CSS & Blade | Roots

Their starter theme allows for anyone to use Blade instead of regular PHP.

@James Nylen this creates a bunch of generated PHP code also, but it does not do so as a build step. It does it like how Laravel does it and just generates it and stores it in a cache directory as the page is first loaded.

However, seeing as this is completely possible to do just by installing a theme, I’m not sure it’s anything even needed in ClassicPress core.

It might be a cool idea to maybe work with the folks over at Roots on some sort of good tight integration. WP includes some awful default themes, CP could include Sage as an awesome, but optional, default theme.

Could also be cool to get them to offer a Bedrock version of CP.

~ posted by Xan

Generated PHP code makes me a bit nervous because it is an attack vector that is very difficult to detect and prevent.

Still, I think this is a good candidate for an experimental theme under ClassicPress Research · GitHub. This way it will at least be available as an option for people who want it.

~ posted by James Nylen

Repo created: GitHub - ClassicPress-research/blade-starter-theme: ClassicPress EXPERIMENTAL theme: Starter theme using Laravel Blade templates.

~ posted by James Nylen

Rather than force a specific templating engine upon users, why not implement a real templating system that just comes with a PHP engine by default? Let plugins provide other engines and let the user decide what they want to use.

~ posted by Wells

I agree no Twig. Why introduce a complete new structure. I inherited a twig site and I hate working with it.

~ posted by Guy Phillips

Twig is awesome. I made a tiny theme with twig a long while ago ( GitHub - petermolnar/petermolnar.eu ), it was way faster, than using the normal WP functions.

Also, Twig is near drop-in compatible with some other language templating systems, eg. jinja2, which could benefit porting projects.

~ posted by Peter Molnar

[anon66243189]

@discobot

You have PHP files responsible for the logic and control and twig files for the presentation

And then why does twig have a for loop?
It’s just a layer (bloat, really) to do the same like php does already

Way easier to read any maintain

It’s not. How is

<?php echo $var ?>

More difficult to understand (even to a non coder) than

{{ var }}

?

The latter is totally out of context. The word echo instead, even means something, it’s not just a statement in code.

Security is also not improved
If you don’t trust your developer don’t solve the issue by adding bloat but by working with a dev who can be trusted and use code reviews, security measures and so on.

Twig uses eval, a function often disabled and not suggested to be used at all.

I think this petition should be closed as “won’t do”.
Mainly because it adds unnecessary bloat, but for many more reasons (some of which shown above, but the list is quite endless)

[james]

Agree, I don’t see a workable path for this to be included in CP core in a way that is secure and not bloated. Setting this to close in a week. Exploring as a plugin is definitely still an option regardless.