I'm seriously considering introducing a compiling stage to Plates, with two main goals:

1. To finally allow proper auto-escaping
2. To cleanup the template code

I know what you're thinking: "What, a parsing stage for native PHP templates? Isn't that exactly what we're trying to avoid?" It's a fair question. But, I think a bigger question needs to be asked first: Why do developers prefer native PHP templates? I believe it's because they don't want to learn a new syntax. They are comfortable working with PHP, they know the functions available to them, and they can get the job done quick. The lack of compiling stage is just an added benefit, although given how compiled template engines handle caching, this is really a moot point.

Generally compiled template engines have a unique, custom syntax. But what if Plates templates remained 100% pure, native PHP, and the compiling stage simply helped make these templates safer (auto-escaping) and nicer to read? I think that could be pretty awesome!

Proposed compiling stage

• Automatically insert an escape function inside all PHP short tags:
  • <?=$name?> becomes <?php echo $this->escape($name) ?>
  • To output "raw" variables, simply use regular tags: <? echo $name ?>
  • Auto-escaping can be enabled/disabled
• Automatically add $this-> to all template functions:
  • <? layout('template') ?> becomes <?php $this->layout('template') ?>
  • Completely removes the need to ever use $this in templates
  • Still has all the benefits that an object-based template system provides
• Automatically convert short open tags to regular tags:
  • <? becomes <?php
  • Short open tags make templates cleaner/more legible, except they're often disabled
  • This allows them to be used all the time, even when they're disabled!
  • Again, no new syntax—these are documented tags

The result

• 100% native PHP templates
• Proper auto-escaping (only on outputted variables)
• No more $this pseudo-variable
• The ability to use short open tags

Example

A new Plates 3.0 template:

<? layout('template', ['title' => 'User Profile']) ?>

<h1>User Profile</h1>
<p>Hello, <?=$name?></p>

<? start('sidebar') ?>
     <ul>
         <li><a href="/link">Link</a></li>
         <li><a href="/link">Link</a></li>
         <li><a href="/link">Link</a></li>
     </ul>
<? stop() ?>

A compiled Plates 3.0 template:

<?php $this->layout('layouts/page', ['title' => 'User Profile']) ?>

<h1>User Profile</h1>
<p>Hello, <?php echo $this->escape($name); ?></p>

<?php $this->start('sidebar') ?>
     <ul>
         <li><a href="/link">Link</a></li>
         <li><a href="/link">Link</a></li>
         <li><a href="/link">Link</a></li>
     </ul>
<?php $this->stop() ?>

What do you think?

This request keeps coming up:

Can we access template variables without the $this pseudo-variable?

As discussed in #9, this is not possible with template functions, and therefore it seemed unwise to do this with template variables (as it would create inconsistency between how these two are accessed).

Further, prior to the changes made to nesting and layouts, accessing variables without $this wasn't even possible. However, because nested templates now have their own variable scope, this may actually be be possible...with some caveats to sections. Consider this example:

<?php $this->start('content') ?>

    <h1>Welcome!</h1>
    <p>Hello <?=$this->e($this->name)?></p>

<?php $this->end() ?>

The contents of this section will be placed into the variable <?=$this->content?>. Generally, sections are used with inheritance, in which case there shouldn't be an issue. The section variables can be extracted before the layout is rendered, making the content available in the layout's local scope ($content).

However, if you want to use this variable in the same template, this will not be possible. For example:

<?php $this->start('content') ?>

    <h1>Welcome!</h1>
    <p>Hello <?=$this->e($this->name)?></p>

<?php $this->end() ?>

<!-- This will not work: -->
<?=$content?>

There are two ways around this. You could access this variable the old way (<?=$this->content?>), but that now creates an odd and very inconsistent approach to accessing variables. Alternatively, section variables could be accessed using a new template function, such as: <?=$this->section('content')?>. I'd be inclined to say, for consistency's sake, that all section variables should be accessed using this new section() function. For example:

<html>
<head>
    <title><?=$this->title?></title>
</head>

<body>

<div id="content">
    <?=$this->section('content')?>
</div>

<?php if ($this->section('sidebar')): ?>
    <div id="sidebar">
        <?=$this->section('sidebar')?>
    </div>
<?php endif ?>

</body>
</html>

With the sections issue out of the way, does it now make sense to encourage (force) everyone to access variables without the $this pseudo-variable? We could theoretically allow both approaches, and developers can choose which one they prefer. Personally, think that is a bad idea since it creates inconsistency in the templates. I'd prefer to simply choose which approach is better, and force that. This would clearly be a breaking change, meaning a version bump (3.0).

So, is everyone okay with having template functions accessed differently than template variables?

<h1>Hello, <?=$this->e($name)?></h1>

So, as I'm looking through the docs I don't see way to set a global layout. Is there? What I mean: setting a layout in the main controller that all other controllers use and/or extend then each template would use that layout instead of defining it in each and every template explicitly.

Changing the layout of a particular set of templates I'd have to go through and edit all of those files. This doesn't seem ideal. Or even just passing a side bar data for a particular layout has to be done by passing the side bar data to each template and from each template to the layout. This seems very redundant. Or am I missing something?

The Plates documentation has a section on making the template object available to extensions. The methods of that object used to escape output would be useful to extensions, but are presently protected, preventing them from being accessible in that scope. Not sure that it matters, but this happens under Plates 3.1.1 and PHP 5.6.10.

// template.php
<?php echo $this->foo(); ?>

// Extension.php
class Extension implements \League\Plates\Extension\ExtensionInterface
{
    public $template;

    public function register(\League\Plates\Engine $engine)
    {
        $engine->registerFunction('foo', [$this, 'foo']);
    }

    public function foo()
    {
        return $this->template->e('foo');
    }
}

// test.php
$engine = new \League\Plates\Engine;
$engine->addFolder('foo', __DIR__);
$engine->loadExtension(new Extension);
echo $engine->render('foo::template');

/*
Output:
PHP Fatal error:  Uncaught exception 'LogicException' with message 
'The template function "e" was not found.' in 
vendor/league/plates/src/Template/Functions.php:63
Stack trace:
#0 vendor/league/plates/src/Engine.php(196):
  League\Plates\Template\Functions->get('e')
#1 vendor/league/plates/src/Template/Template.php(70):
  League\Plates\Engine->getFunction('e')
#2 test.php(16):
  League\Plates\Template\Template->__call('e', Array)
#3 test.php(16):
  League\Plates\Template\Template->e('foo')
#4 [internal function]: Extension->foo()
#5 vendor/league/plates/src/Template/Func.php(105):
  call_user_func_array(Array, Array)
#6 vendor/league/plates/src/Template/Template.php(70):
  League\Plates\Template\Func->call(Object(League\Plates\Template\Template), Array)
#7 . in vendor/league/plates/src/Template/Functions.php on line 63
*/

Hope this makes since, first time posting. Using Plates 4 alpha. Please excuse bad coding, Im working on it. Ok so in the main template.php file I load initial sections through a include file like so:

<?=$view->insert('page-section')?>

Inside page-section.php has all the default content for each section I want to load in template.php. So in the header section of template.php I have:

<?=$view->section('header_codetop')?>

The problem is farther down the template.php I have some code to load side modules, like so:

foreach($side_modules AS $curr_module):
                
$view->insert('modules/' .$curr_module['modfile']);

endforeach;

In some of the module files I want to push data like needed JS or CSS code/includes to the header_codetop section, for example modules/site-links.php:

<?php $view->push('header_codetop') ?>
<script src="/test.js"></script>
<?php $view->stop() ?>

//HTML content goes here

But it doesnt work. It only works if the push happens before:

<?=$view->section('header_codetop')?>

So if I want to push content to a section in the footer, which is below the foreach loop, it works just fine. Is there a way to make the push happen later down the process so I can push data to a section at anytime on the page? Or maybe, hopefully, Im doing something wrong?

EDIT: Also I understand that when Im doing this:

<?=$view->section('header_codetop')?>

Its echoing out the value for section header_codetop. However I was hoping there was a different way of not echoing it right away, instead it can wait until everything is rendering and echo it all out at the end. Or maybe Im using plates all wrong and there is a better way of doing what Im trying to do?

Can mimic the functionality of translating the static (and dynamic?) content inside a template. It takes a 1 dimensional array containing key => value.

Pros:

• Separates static from dynamic content. - Links texts, meta content and etc.
• Can help in generating language specific URLs. - The value is set during instantiation, see: https://support.google.com/webmasters/answer/182192?hl=en#1
• Language changing. - All data for a language changing plugin are presented
• Makes templates syntax prettier. (depends on implementation)

Cons:

• Is not extendable
• Does not support anything but PHP arrays. (Yet)
• Doesn't do much.

I understand that auto-escaping isn't feasible, but I believe we could still improve things in this area by simply offering a method to mass-escape multiple variables at once. For example, we could then have this at the top of a template:

$this->escapeMultiple($foo, $bar, $baz);

And that would allow the actual template code to be much cleaner:

<h1><?=$foo?></h1>
<div><?=$bar?></div>
<div><?=$baz?></div>

This way the template author still has to think about escaping, but they only have to do it once at the top. If they've escaped some variables and not others, this is nicely self-documenting, as they can glance back up to the top if they need to check whether a particular variable has been escaped already. It's not quite as slick as full-blown auto-escaping, but this feels like it would be a middle ground that's better than the current requirement of manually escaping every single time, without running into the problems associated with auto-escaping.

I tried to write an extension to add this (which was going to support both strings and arrays of strings), but discovered it seems to be impossible to add as an extension given the current architecture, because template functions cannot receive data by reference.

Any chance of this being added as an official feature? If not, any chance of making it possible for template functions to get data by reference, so I can at least finish my extension?

Fatal error: Class 'League\Plates\Template\Directory' not found in /template/Engine.php on line 57

I keep on receiving this error. No matter if I use absolute or relative path:

$templates = new League\Plates\Engine('/mypath/template');

This going to be a list of features/changes I want to make for version 4.0.

• [x] Naming strategies
• [x] Revisit Extensions
• [x] Revisit Template Data
• [x] Re-architect sections
• [x] Slim feature set, Focus on extensions to provide features
• [x] Peridot for Tests (maybe)
• [x] Components (similar to laravel blade components)
  • Pass output buffered content as variable into sub template.
• [ ] come up with any more features...
• [ ] BC
• [ ] Integration Tests
• [ ] Unit Tests

Architecture Goals

• Every component should be able to replaced with a custom one
• Plates should do the simple case well, everything extra should be an extension.
• Keep the core as simple as possible, yet flexible to handle any abstraction
• Template files should be BC with 3.x. The Engine should also be BC for 3.x as much as possible. It might contain methods that are deprecated and only exist for BC reasons, we can remove in 4.1

Hey,

Wouldn't it be great if we could have nested templates with their own variables, not shared with the parent template?

I quickly hacked something that works for my case but I'm not sure it's okay so I didn't go much further:

class Template
{
    public function insert($name, Array $data = null)
    {
        //save current template data
        $templateData = $this->getPublicVars();

        //show the nested template with its own data
        $this->data($data);
        include $this->_internal['engine']->resolvePath($name);

        //delete nested template data not existing in the parent template
        $toDelete = array_diff(array_keys($data), array_keys($templateData));
        foreach ($toDelete as $name) {
            unset($this->$name);
        }

        //put back parent template data for the rest of the page
        $this->data($templateData);
    }

    public function getPublicVars() {
        return call_user_func('get_object_vars', $this);
    }

What do you think? :)

Cheers, Leimi

There haven't been any activity or response to the issues specially v4.0 in a while I wonder if this has been abandoned.. I really love this it's straightforward and does what you need without any new language however recently i started using the v4.0 branch since I remember it started development a couple years ago and thought it's not so unstable now but I was surprised nothing changed.. I get v3.0 is stable and works but did the development stop?

Hello, I'm downgrading league/plates from v4.0.0-alpha to v3.4.0, because this version supports PHP 8.

When making this change I'm having a problem with this create:

IMG: https://i.imgur.com/fnsrTGz.png

How to fix it?

Code v4.0.0-alpha:

<?php

namespace App\Controllers;

use League\Plates\Engine;

class Panel
{
    private $view;
    public function __construct()
    {
        $this->view = Engine::create(__DIR__ . "/../Views/", "php");
    }

    public function login(): void
    {
        echo $this->view->render("login", [
            "title" => "Login"
        ]);
    }

    public function error(array $data): void
    {
        echo "<h1>Error {$data["errcode"]}</h1>";
    }
}

I have cloned a php project from git. The project is using platesphp. But i am not able to run my branch in localhost. I have installed composer leage plates. But not running in localhost. Kindly help me regarding this.

Data page contains information that doesn't match the source code.

https://github.com/thephpleague/plates/blob/v3/doc/content/templates/data.md?plain=1#L23

https://github.com/thephpleague/plates/blob/v3/src/Engine.php#L288

I selected Plates for a recent project partly based on the Themes functionality that is documented on the website, with no indication that it is not available yet. (Yes, it's flagged "3.5," but you have to dig around to learn that 3.5 doesn't exist yet.) Is there any chance of this functionality being released in the near future? (If not, it might be best to consider removing the documentation, or at least very clearly marking it as a planned feature that hasn't been released yet.)

So I hacked together a template hierarchy system using the folders functionality instead, but what I have right now feels a bit kludgey (a wrapper object that adds its own logic before calling render). Is there any recommendation of how to best implement a template hierarchy using the released version of Plates? Is that something that could be done with an extension, or is that beyond the scope of extensions? Or would making an Engine-variant subclass be a cleaner option than a wrapper object?

The ideal scenario would obviously be to just call render() or insert() normally and have the magic happen behind the scenes to find the correct template, but I realize that may not be possible without Themes functionality built-in. Any advice here would certainly be appreciated. Thank you.

First reported on Reddit

CloudFlare servers in India get MITMd by the network provider (Airtel) if the upstream is GitHub Pages and configured without end-to-end TLS.

Here is a curl log as proof that this happens even over HTTPS.

curl -vvv https://platesphp.com/
*   Trying 172.67.147.246...
* TCP_NODELAY set
* Connected to platesphp.com (172.67.147.246) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Client hello (1):
* TLSv1.3 (OUT), TLS Unknown, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=sni.cloudflaressl.com
*  start date: Jul  4 00:00:00 2021 GMT
*  expire date: Jul  3 23:59:59 2022 GMT
*  subjectAltName: host "platesphp.com" matched cert's "platesphp.com"
*  issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
* Using Stream ID: 1 (easy handle 0x556e4d012600)
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
> GET / HTTP/2
> Host: platesphp.com
> User-Agent: curl/7.58.0
> Accept: */*
>
* TLSv1.3 (IN), TLS Unknown, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
* TLSv1.3 (OUT), TLS Unknown, Unknown (23):
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
< HTTP/2 200
< date: Fri, 07 Jan 2022 13:57:35 GMT
< content-type: text/html
< pragma: no-cache
< cache-control: no-cache
< cf-cache-status: DYNAMIC
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=yNTsYU5MJc0ZELL2ztaW8egU1HroWVV9fqrUSmUPGms9Rd7CGCo0XQmC3ucspUSxifcmBxdUIqcbl5Q100MfZGE7zvtw3h1KeX12CqO7c1309o7eEf8VncwAhuVcf6QL"}],"group":"cf-nel","max_age":604800}
< nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
< server: cloudflare
< cf-ray: 6c9db2309cd626bd-BLR
< alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400, h3-28=":443"; ma=86400, h3-27=":443"; ma=86400
<
* TLSv1.3 (IN), TLS Unknown, Unknown (23):
* Connection #0 to host platesphp.com left intact

CloudFlare has known about this issue for years (actively hostile ISPs) and they don't seem to be doing anything about it. The two fixes here are:

1. Switch from CloudFlare to direct GitHub Pages, which supports TLS now.
2. Enable HTTPS on GitHub pages, and switch the upstream on CloudFlare to get strict SSL instead of flexible.

You can see this thread on twitter for more details