Native PHP template system

Overview

Plates

Maintainer Source Code Latest Version Software License Build Status Coverage Status Quality Score Total Downloads

Plates is a native PHP template system that's fast, easy to use and easy to extend. It's inspired by the excellent Twig template engine and strives to bring modern template language functionality to native PHP templates. Plates is designed for developers who prefer to use native PHP templates over compiled template languages, such as Twig or Smarty.

Highlights

  • Native PHP templates, no new syntax to learn
  • Plates is a template system, not a template language
  • Plates encourages the use of existing PHP functions
  • Increase code reuse with template layouts and inheritance
  • Template folders for grouping templates into namespaces
  • Data sharing across templates
  • Preassign data to specific templates
  • Built-in escaping helpers
  • Easy to extend using functions and extensions
  • Framework-agnostic, will work with any project
  • Decoupled design makes templates easy to test
  • Composer ready and PSR-2 compliant

Installation

Plates is available via Composer:

composer require league/plates

Documentation

Full documentation can be found at platesphp.com.

Testing

composer test

Contributing

Please see CONTRIBUTING for details.

Security

If you discover any security related issues, please email [email protected] instead of using the issue tracker.

Credits

License

The MIT License (MIT). Please see License File for more information.

Comments
  • Cleaner templates via new compiling stage

    Cleaner templates via new compiling stage

    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?

    enhancement 
    opened by reinink 50
  • Accessing template variables without $this

    Accessing template variables without $this

    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>
    
    enhancement 
    opened by reinink 21
  • Setting Layout Once Per Controller

    Setting Layout Once Per Controller

    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?

    question discussion 
    opened by KnightYoshi 20
  • Make template escape methods public

    Make template escape methods public

    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
    */
    
    opened by elazar 20
  • Section push not showing after section start

    Section push not showing after section start

    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?

    opened by brightboxtech 14
  • 'Translation' functionality

    'Translation' functionality

    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.
    opened by DaGhostman 14
  • Escape multiple variables by reference

    Escape multiple variables by reference

    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?

    opened by cdCorey 13
  • Fatal error: Class 'League\Plates\Template\Directory' not found in <folders>/template/Engine.php on line 57

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

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

    opened by dirkplatts 13
  • V4 Roadmap

    V4 Roadmap

    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
    opened by ragboyjr 12
  • Nested templates with their own variables

    Nested templates with their own variables

    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

    enhancement 
    opened by Leimi 12
  • Discussion around Future Direction of Plates (Original Title: Plates abandoned?)

    Discussion around Future Direction of Plates (Original Title: Plates abandoned?)

    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?

    opened by asvvvad1 11
  • league/plates v4.0.0-alpha to v3.4.0 create error

    league/plates v4.0.0-alpha to v3.4.0 create error

    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>";
        }
    }
    
    opened by tiagocaus 3
  • 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 cloned a php project from git. The project is using platesphp. But i am not able to run my branch in localhost.

    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.

    opened by LijoDavid16 1
  • Data documentation outdated

    Data documentation outdated

    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

    opened by truefusion 0
  • Any hope of documented Themes functionality being release? If not, recommended workaround?

    Any hope of documented Themes functionality being release? If not, recommended workaround?

    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.

    opened by cdCorey 3
  • Website blocked in India

    Website blocked in India

    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 log
    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

    opened by captn3m0 1
Releases(v3.4.0)
  • v3.4.0(Dec 25, 2020)

    Added

    • Added new unshift method in templates to support prepending content to sections (thanks @kozubsky)
    • Added support for PHP8 (thanks @roxblnfk)

    Changed

    • Dropped explicit support for php 5. PHP 7/8 is allowed in composer, and only php 7.3-8.0 are tested in CI pipeline.

    Internal Changes

    • Minor modifications to repo workflow for CI with GitHub Actions instead of Travis
    • Migrated docs from Jekyll to Hugo
    Source code(tar.gz)
    Source code(zip)
  • v4.0.0-alpha(Feb 6, 2018)

    EDIT (12/24/2020): This release has been abandoned. Some of this work will be merged into the v3 branch, but most of it has been scrapped. This tag will still be available, but a version 4 will not be based off of this alpha release.

    v4 has been a complete rewrite in the plates system. It's fairly backwards compatible, but a lot of the internals have changed, and we still have a decent amount of features and work to do for v4.

    Significant Changes

    • Templates are Immutable VO's
    • Rendering is handled via RenderTemplate interfaces
    • Extensions are first class citizens
    • The Engine is now a small wrapper for an IoC Container

    New Features

    • RenderContext API for defining composable functions and more
    • Components
    • Powerful and customizable naming strategies for dynamic base paths
    • Multi folder fallbacks
    • Relative and Absolute Path templates
    • Better Error Handling
    • Default Layouts
    • Deep Sections #169
    • Template Composers
    • Static File Rendering
    • Image/Base64Encoding Rendering
    • And probably a few more ;p

    Documentation is lacking for many of these features. Contributions are welcome! The best way to learn about the features it to look at the tests and examples.

    Source code(tar.gz)
    Source code(zip)
  • 3.3.0(Dec 28, 2016)

  • 3.2.0(Dec 27, 2016)

    • Fixed an issue where template functions were not accessible from extensions.
    • Fixed an issued with the URI extension throwing errors when it shouldn't.
    • Added the ability to get all template data by calling $template->data().
    • Added the ability to render a template via the toString() magic method.
    • Added the ability to run the tests using composer test.
    • Improvements to error handling when rendering templates.
    • Various coding style, CI and documentation improvements.
    Source code(tar.gz)
    Source code(zip)
  • 3.1.1(Jul 9, 2015)

  • 3.1.0(Oct 21, 2014)

  • 3.0.3(Oct 20, 2014)

    • Added ability to define the default content of a section.
    • Various code improvements (cleanup DocBlocks, class simplification, add Composer keywords, etc).
    Source code(tar.gz)
    Source code(zip)
  • 3.0.2(Sep 30, 2014)

    • Added all missing tests.
    • Improved custom function name validation.
    • Fixed bug with fallback folders, where the file extension wasn't being applied.
    • Improved error handling in Template class.
    Source code(tar.gz)
    Source code(zip)
  • 3.0.1(Sep 28, 2014)

  • 3.0.0(Sep 27, 2014)

    • Added ability to share data across templates.
    • Added ability to preassign data to specific templates.
    • Added ability to create one-off template functions, without using an extension.
    • Added new folder "fall backs", where missing folder templates will fall back to the default folder.
    • Added new render() method to Engine class, improving the use of the Engine as the primary API.
    • Templates variables are now accessed without the $this pseudo-variable.
    • Total overhaul to how extensions are registered. Replaced getFunctions() method with new register() method.
    • Section content is no longer assigned to template variables. Use the the section() function instead.
    • Renamed section end() function to stop(). This fits more appropriately with the start() function.
    • Renamed get() function to fetch().
    • Renamed pathExists() method in the Engine class to exists().
    • Renamed getTemplatePath() method in the Engine class to path().
    • Renamed makeTemplate() method in the Engine class to make().
    • Removed the ability to assign template data directly to the Template class. For example: $this->name = 'Jonathan'. This applies both within and outside of templates. Use the data() method instead.
    • Removed getEngine() method from the Template class. There's no reason to need this anymore.
    • Removed addFolders() method from the Engine() class.
    • Removed unloadExtension() and unloadExtensionFunction() methods from the Engine() class.
    Source code(tar.gz)
    Source code(zip)
  • 2.1.0(Apr 2, 2014)

    • Improved DocBlocks throughout the library.
    • The insert() functionality has been moved to a new extension, called Nest.
    • A new get() function was also added with this extension, which offers an alternative syntax for nesting templates.
    • Improved error messages.
    • A new error check which prevents the calling of the render() function from within templates themselves. If this functionally is required, use the nesting functions instead.
    • Added a clearer error message to the content() function when calling it from a non layout template.
    • Added a clearer error message to the batch() extension function when a provided function does not exist.
    • Fixed a bug in the engine where it was possible to overwrite a default extension when loading extensions.
    Source code(tar.gz)
    Source code(zip)
  • 2.0.0(Mar 31, 2014)

    • Added stacked layouts, allowing even further simplification and organization of templates.
    • Added new unloadExtension() and unloadExtensionFunction() methods to the Engine() class.
    • Added getEngine() method to the Template class.
    • Added addFolders() and loadExtensions() methods to the Engine() class.
    • Nested templates are now self-contained objects, with their own variables and layouts.
    Source code(tar.gz)
    Source code(zip)
  • 1.2.1(Feb 20, 2014)

  • 1.1.0(Jan 31, 2014)

  • 1.0.11(Feb 20, 2014)

  • 1.0.10(Feb 20, 2014)

  • 1.0.9(Feb 20, 2014)

  • 1.0.8(Feb 20, 2014)

Owner
The League of Extraordinary Packages
A group of developers who have banded together to build solid, well tested PHP packages using modern coding standards.
The League of Extraordinary Packages
Foil brings all the flexibility and power of modern template engines to native PHP templates

Foil brings all the flexibility and power of modern template engines to native PHP templates. Write simple, clean and concise templates with nothing more than PHP.

Foil PHP 167 Dec 3, 2022
PHP Template Attribute Language — template engine for XSS-proof well-formed XHTML and HTML5 pages

PHPTAL - Template Attribute Language for PHP Requirements If you want to use the builtin internationalisation system (I18N), the php-gettext extension

PHPTAL 175 Dec 13, 2022
A template abstraction prototype for PHP template engines

Schranz Templating A template abstraction prototype for PHP template engines. This project should help to find a way for a general Template Render Int

Schranz Templating 16 Dec 7, 2022
The Templating component provides all the tools needed to build any kind of template system.

Templating Component The Templating component provides all the tools needed to build any kind of template system. It provides an infrastructure to loa

Symfony 999 Dec 25, 2022
A PHP project template with PHP 8.1, Laminas Framework and Doctrine

A PHP project template with PHP 8.1, Laminas Framework and Doctrine

Henrik Thesing 3 Mar 8, 2022
Twig, the flexible, fast, and secure template language for PHP

Twig, the flexible, fast, and secure template language for PHP Twig is a template language for PHP, released under the new BSD license (code and docum

Twig 7.7k Jan 1, 2023
Smarty is a template engine for PHP, facilitating the separation of presentation (HTML/CSS) from application logic.

Smarty 3 template engine smarty.net Documentation For documentation see www.smarty.net/docs/en/ Requirements Smarty can be run with PHP 5.2 to PHP 7.4

Smarty PHP Template Engine 2.1k Jan 1, 2023
☕ Latte: the intuitive and fast template engine for those who want the most secure PHP sites.

Latte: amazing template engine for PHP Introduction Latte is a template engine for PHP which eases your work and ensures the output is protected again

Nette Foundation 898 Dec 25, 2022
View template engine of PHP extracted from Laravel

Blade 【简体中文】 This is a view templating engine which is extracted from Laravel. It's independent without relying on Laravel's Container or any others.

刘小乐 143 Dec 13, 2022
A complete and fully-functional implementation of the Jade template language for PHP

Tale Jade for PHP Finally a fully-functional, complete and clean port of the Jade language to PHP — Abraham Lincoln The Tale Jade Template Engine brin

Talesoft 91 Dec 27, 2022
A ready-to-use Model View Controller template in PHP

PHP-MVC-Template A ready-to-use Model View Controller template in PHP Use this repo as a template! (Or clone it) Start to configure your MVC file Afte

Loule | Louis 20 Dec 26, 2022
Provides a GitHub repository template for a PHP package, using GitHub actions.

php-package-template Installation ?? This is a great place for showing how to install the package, see below: Run $ composer require ergebnis/php-pack

null 280 Dec 27, 2022
The free-to-use template for your Imagehost-website made with PHP, HTML and CSS!

The free-to-use template for your Imagehost-website made with PHP, HTML and CSS! Some information before we start This repo is only code related, to a

Ilian 6 Jul 22, 2022
The free-to-use template for your Imagehost-website made with PHP, HTML and CSS!

The free-to-use template for your Imagehost-website made with PHP, HTML and CSS! Some information before we start This repo is only code related, to a

Ilian 6 Jul 22, 2022
⚡️ Simple and fastly template engine for PHP

EasyTpl ⚡️ Simple and fastly template engine for PHP Features It's simple, lightweight and fastly. No learning costs, syntax like PHP template It is s

PHPPkg 19 Dec 9, 2022
Twig Template Engine to Phalcon PHP

Twig Template Engine to Phalcon PHP

Vinicius 4 Oct 7, 2022
Liquid template engine for PHP

Liquid is a PHP port of the Liquid template engine for Ruby, which was written by Tobias Lutke. Although there are many other templating engines for PHP, including Smarty (from which Liquid was partially inspired)

Harald Hanek 230 Aug 18, 2022
FyreView is a free, open-source template rendering library for PHP.

FyreView FyreView is a free, template rendering library for PHP. Table Of Contents Installation Methods Layouts Paths Helper Registry Helpers CSP Form

Elusive 1 Jul 30, 2022
A lightweight template parser used by PyroCMS.

Lex Lex is a lightweight template parser. Lex is released under the MIT License and is Copyrighted 2011 - 2014 PyroCMS Team. Change Log 2.3.2 Convert

PyroCMS 102 Dec 21, 2022