FormeView Engines
In order to use one of the supported templating systems, you need to edit app/Core/View in your plugin or theme project and extend the relevant base class. The code for each of the options is below.
This is done for you automatically when you select a view engine using forme codegen to generate your initial boilerplate - we're outlining the code below if you need to do this manually.
Legacy Plates 4.
// app/Core/View.php
<?php
declare(strict_types=1);
namespace VendorName\NameSpace\Core;
use Forme\Framework\View\LegacyPlatesView;
final class View extends LegacyPlatesView
{
}This one is Forme's default, even though Plates 4 Alpha has actually been abandoned. The maintainer's development is currently focussed on Plates 3 below.
Why is this the default? This is partly a historical choice - we use it ourselves for most client projects and will therefore continue to support it - we find its slightly terser syntax is a marked improvement over v3.
We've forked Plates 4 Alpha and included it in Forme's core, so it won't be going away any time soon. We're not currently planning on adding any major new features, but will fix any critical bugs that crop up.
We've added some template error exceptions to enforce proper template syntax style, specifically:
- No one line if statements
- No multi-line php statements
- No more than one statement per line
- No use of echo
- No variable assignment
- Short/alternative syntax only for control structures
These are quite useful to ensure old school WordPress patterns don't creep in, but YMMV.
We will also be looking at porting over the Plates 4 documentation in due course.
Plates
// app/Core/View.php
<?php
declare(strict_types=1);
namespace VendorName\NameSpace\Core;
use Forme\Framework\View\PlatesView;
final class View extends PlatesView
{
}This is the currently maintained version. The main advantage of Plates over other options is that it's essentially just php, so there is no syntax as such to learn, although there are helper methods. It's more about following a set of conventions.
Blade
// app/Core/View.php
<?php
declare(strict_types=1);
namespace VendorName\NameSpace\Core;
use Forme\Framework\View\BladeView;
final class View extends BladeView
{
}This is of course Laravel's view engine, which is in fact originally based on .net's Razor.
Forme uses jenssegers/blade under the hood.
Caching
You will find the cache folder at FORME_PRIVATE_ROOT/view-cache in case you need to purge/delete it. We'll be adding a codegen command for this at some point, but you can rm -r it for now.
Directives
All the directives from Sage Directives are available in Blade templates. We haven't tested all of them - but they should mostly work so long as they don't use any Sage specific functionality. You can call arbitrary php functions within blade in any case, so these are mostly for convenience/syntactic sugar.
We'll look at providing a way of adding custom blade directives from within forme projects in a future release.
Twig
// app/Core/View.php
<?php
declare(strict_types=1);
namespace VendorName\NameSpace\Core;
use Forme\Framework\View\TwigView;
final class View extends TwigView
{
}Twig is Symfony's view engine. It's a little more verbose than the other options, and doesn't allow any arbitrary php.
Caching
The cache will be on if WP_ENV is production, off if it's development. You can find the cache folder at FORME_PRIVATE_ROOT/view-cache in case you need to purge/delete it.
Functions
In Twig you can't call arbitrary php functions like you can in Blade or Plates files. Forme allows this capability by wrapping them in function or the shortcut fn.
{# single.twig #}
<html>
<head>
<!-- Add whatever you need in the head, and then...-->
{{ function('wp_head') }}
</head>
<!-- etc... -->
<footer>
Copyright © {{ "now"|date('Y') }}
</footer>
{{ fn('wp_footer') }}
</body>
</html>You can also pass arguments into the function as follows.
{# single.twig #}
<div class="admin-tools">
{{ function('edit_post_link', 'Edit', '<span class="edit-link">', '</span>') }}
</div>