Currently the only way the extend SSTemplateParser is to define a class
extension of it and then tell the injector component to use your new
custom class. This new change allows a user to define new "open blocks"
and "closed blocks" for SSTemplateParser to use without needing to
recompile the real SSTemplateParser class.
The following example shows how the functionality can be used
to add a new <% minify %>…<% end_minify %> syntax to the template parser
In a config.yml file, define the new minify closed block to call the
static function "Minifier::minify"
```
Injector:
SSTemplateParser:
properties:
closedBlocks:
minify: "Minifier::minify"
```
Define a new class with the minify static method that returns the new
template code when regenerating templates:
```
class Minifier {
public static function minify(&$res) {
return <<<PHP
{$res['Template']['php']}
\$val = zz\Html\HTMLMinify::minify(\$val, array('optimizationLevel' => zz\Html\HTMLMinify::OPTIMIZATION_ADVANCED));
PHP;
}
}
```
The motivation for this was to allow module developers to change what parser is used to parse SilverStripe templates.
This change enables people to compile their own version of the SilverStripe template parser and use it without modifying core files.
The parser could sometimes generate invalid code if the
source-file-comments were enabled, this moves the comments outside the
html-tag to circumvent these problems, update test as well.
The template-parser files were not in sync, there were some lines added
in SSTemplateParser.php from 3334eafcb1
and 0a9f3b75a9 , I readded those parts
into the SSTemplateParser-include-file and recreated the
SSTemplateParser.php to get to a synced state...
The entire framework repo (with the exception of system-generated files) has been amended to respect the 120c line-length limit. This is in preparation for the enforcement of this rule with PHP_CodeSniffer.
