smarty-php/smarty
1
0
Fork 0
mirror of https://github.com/smarty-php/smarty.git synced 2025-07-31 16:37:14 +02:00
Code Issues Packages Projects Releases Wiki Activity

Update README.md. Fix references to Smarty3. Get rid of old changelog-like files.

Browse Source
This commit is contained in:
Simon Wisselink
2021-10-13 22:49:43 +02:00
parent 64a6333d5d
commit ffb2fd923b
10 changed files with 18 additions and 1494 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
COMPOSER_RELEASE_NOTES.txt
View File

@@ -1,31 +0,0 @@
Starting with Smarty 3.1.21 Composer has been configured to load the packages from github.
*******************************************************************************
* *
* NOTE: Because of this change you must clear your local composer cache with *
* the "composer clearcache" command *
* *
*******************************************************************************
To get the latest stable version use
"require": {
"smarty/smarty": "~3.1"
}
in your composer.json file.
To get the trunk version use
"require": {
"smarty/smarty": "~3.1@dev"
}
The "smarty/smarty" package will start at libs/.... subfolder.
To retrieve the development and documentation folders add
"require-dev": {
"smarty/smarty-dev": "~3.1@dev"
}
If you are using (include) the composer generated autoloader.php which is located
in the /vendor folder it is no longer needed to require the Smarty.class.php file.

91
INHERITANCE_RELEASE_NOTES.txt
View File

@@ -1,91 +0,0 @@
3.1.3"
New tags for inheritance parent and chilD
{parent} == {$smarty.block.parent}
{child} == {$smarty.block.child}
Both tags support the assign attribute like
{child assign=foo}
3.1.31
New tags for inheritance parent and child
{block_parent} == {$smarty.block.parent}
{block_child} == {$smarty.block.child}
Since 3.1.28 you can mix inheritance by extends resource with the {extends} tag.
A template called by extends resource can extend a subtemplate or chain buy the {extends} tag.
Since 3.1.31 this feature can be turned off by setting the new Smarty property Smarty::$extends_recursion to false.
3.1.28
Starting with version 3.1.28 template inheritance is no longer a compile time process.
All {block} tag parent/child relations are resolved at run time.
This does resolve all known existing restrictions (see below).
The $smarty::$inheritance_merge_compiled_includes property has been removed.
Any access to it is ignored.
New features:
Any code outside root {block} tags in child templates is now executed but any output will be ignored.
{extends 'foo.tpl'}
{$bar = 'on'} // assigns variable $bar seen in parent templates
{block 'buh'}{/block}
{extends 'foo.tpl'}
{$bar} // the output of variable bar is ignored
{block 'buh'}{/block}
{block} tags can be dynamically en/disabled by conditions.
{block 'root'}
{if $foo}
{block 'v1'}
....
{/block}
{else}
{block 'v1'}
....
{/block}
{/if}
{/block}
{block} tags can have variable names.
{block $foo}
....
{/block}
Starting with 3.1.28 you can mix inheritance by extends resource with the {extends} tag.
A template called by extends resource can extend a subtemplate or chain buy the {extends} tag.
NOTE There is a BC break. If you used the extends resource {extends} tags have been ignored.
THE FOLLOWING RESTRICTIONS ARE NO LONGER EXISTING:
In Smarty 3.1 template inheritance is a compile time process. All the extending of {block} tags
is done at compile time and the parent and child templates are compiled in a single compiled template.
{include} subtemplate could also {block} tags. Such subtemplate could not compiled by it's own because
it could be used in other context where the {block} extended with a different result. For that reasion
the compiled code of {include} subtemplates gets also merged in compiled inheritance template.
Merging the code into a single compile template has some drawbacks.
1. You could not use variable file names in {include} Smarty would use the {include} of compilation time.
2. You could not use individual compile_id in {include}
3. Separate caching of subtemplate was not possible
4. Any change of the template directory structure between calls was not necessarily seen.
Starting with 3.1.15 some of the above conditions got checked and resulted in an exception. It turned out
that a couple of users did use some of above and now got exceptions.
To resolve this starting with 3.1.16 there is a new configuration parameter $inheritance_merge_compiled_includes.
For most backward compatibility its default setting is true.
With this setting all {include} subtemplate will be merge into the compiled inheritance template, but the above cases
could be rejected by exception.
If $smarty->inheritance_merge_compiled_includes = false; {include} subtemplate will not be merged.You must now manually merge all {include} subtemplate which do contain {block} tags. This is done by setting the "inline" option.
{include file='foo.bar' inline}
1. In case of a variable file name like {include file=$foo inline} you must use the variable in a compile_id $smarty->compile_id = $foo;
2. If you use individual compile_id in {include file='foo.tpl' compile_id=$bar inline} it must be used in the global compile_id as well $smarty->compile_id = $bar;
3. If call templates with different template_dir configurations and a parent could same named child template from different folders
you must make the folder name part of the compile_id.

291
NEW_FEATURES.txt
View File

@@ -1,291 +0,0 @@
This file contains a brief description of new features which have been added to Smarty 3.1
Smarty 3.1.33-dev
Variable capture name in Smarty special variable
================================================
{$smarty.capture.$foo} can now be used to access the content of a named
capture block
Smarty 3.1.32
New tags for inheritance parent and child
=========================================
{parent} == {$smarty.block.parent}
{child} == {$smarty.block.child}
Both tags support the assign attribute like
{child assign=foo}
Deprecate functions Smarty::muteExpectedErrors() and Smarty::unmuteExpectedErrors()
===================================================================================
These functions to start a special error handler are no longer needed as Smarty does
no longer use error suppression like @filemtime().
For backward compatibility the functions still can be called.
Using literals containing Smarty's left and right delimiter
===========================================================
New Methods
$smarty->setLiterals(array $literals)
$smarty->addLiterals(array $literals)
to define literals containing Smarty delimiter. This can avoid the need for extreme usage
of {literal} {/literal} tags.
A) Treat '{{' and '}}' as literal
If Smarty::$auto_literal is enabled
{{ foo }}
will be treated now as literal. (This does apply for any number of delimiter repeatations).
However {{foo}} is not an literal but will be interpreted as a recursive Smarty tag.
If you use
$smarty->setLiterals(array('{{','}}'));
{{foo}} is now a literal as well.
NOTE: In the last example nested Smarty tags starting with '{{' or ending with '}}' will not
work any longer, but this should be very very raw occouring restriction.
B) Example 2
Assume your delimiter are '<-' , '->' and '<--' , '-->' shall be literals
$smarty->setLiterals(array('<--','-->'));
The capture buffers can now be accessed as array
================================================
{capture name='foo'}
bah
{\capture}
{capture name='buh'}
blar
{\capture}
{foreach $smarty.capture as $name => $buffer}
....
{/foreach}
Smarty 3.1.31
New tags for inheritance parent and child
=========================================
{block_parent} == {$smarty.block.parent}
{block_child} == {$smarty.block.child}
Smarty 3.1.30
Loop optimization {foreach} and {section}
=========================================
Smarty does optimize the {foreach} and {section} loops by removing code for not needed loop
properties.
The compiler collects needed properties by scanning the current template for $item@property,
$smarty.foreach.name.property and $smarty.section.name.property.
The compiler does not know if additional properties will be needed outside the current template scope.
Additional properties can be generated by adding them with the property attribute.
Example:
index.tpl
{foreach $from as $item properties=[iteration, index]}
{include 'sub.tpl'}
{$item.total}
{/foreach}
sub.tpl
{$item.index} {$item.iteration} {$item.total}
In above example code for the 'total' property is automatically generated as $item.total is used in
index.tpl. Code for 'iteration' and 'index' must be added with properties=[iteration, index].
New tag {make_nocache}
======================
Syntax: {make_nocache $foo}
This tag makes a variable which does exists normally only while rendering the compiled template
available in the cached template for use in not cached expressions.
Expample:
{foreach from=$list item=item}
<li>{$item.name} {make_nocache $item}{if $current==$item.id} ACTIVE{/if}</li>
{/foreach}
The {foreach} loop is rendered while processing the compiled template, but $current is a nocache
variable. Normally the {if $current==$item.id} would fail as the $item variable is unknown in the cached template. {make_nocache $item} does make the current $item value known in thee cached template.
{make_nocache} is ignored when caching is disabled or the variable does exists as nocache variable.
NOTE: if the variable value does contain objects these must have the __set_state method implemented.
Scope Attributes
================
The scope handling has been updated to cover all cases of variable assignments in templates.
The tags {assign}, {append} direct assignments like {$foo = ...}, {$foo[...]= ...} support
the following optional scope attributes:
scope='parent' - the variable will be assigned in the current template and if the template
was included by {include} the calling template
scope='tpl_root' - the variable will be assigned in the outermost root template called by $smarty->display()
or $smarty->fetch() and is bubbled up all {include} sub-templates to the current template.
scope='smarty' - the variable will be assigned in the Smarty object and is bubbled up all {include} sub-templates
to the current template.
scope='global' - the variable will be assigned as Smarty object global variable and is bubbled up all {include}
sub-templates to the current template.
scope='root' - the variable will be assigned if a data object was used for variable definitions in the data
object or in the Smarty object otherwise and is bubbled up all {include} sub-templates to the
current template.
scope='local' - this scope has only a meaning if the tag is called within a template {function}.
The variable will be assigned in the local scope of the template function and the
template which did call the template function.
The {config_load} tag supports all of the above except the global scope.
The scope attribute can be used also with the {include} tag.
Supported scope are parent, tpl_root, smarty, global and root.
A scope used together with the {include} tag will cause that with some exceptions any variable
assignment within that sub-template will update/assign the variable in other scopes according
to the above rules. It does include also variables assigned by plugins, tags supporting the assign=foo attribute and direct assignments in {if} and {while} like {if $foo=$bar}.
Excluded are the key and value variables of {foreach}, {for} loop variables , variables passed by attributes
in {include} and direct increments/decrements like {$foo++}, {$foo--}
Note: The scopes should be used only to the extend really need. If a variable value assigned in an included
sub-template should be returned to the calling sub-template just use {$foo='bar' scope='parent'}.
Use scopes only with variables for which it's realy needed. Avoid general scope settings with the
{include} tag as it can have a performance impact.
The {assign}, {append}, {config_load} and {$foo...=...} tags have a new option flag 'noscope'.Thi
Example: {$foo='bar' noscope} This will assign $foo only in the current template and any scope settings
at {include} is ignored.
Caching
=======
Caching does now observe the template_dir setting and will create separate cache files if required
Compiled Templates
==================
The template_dir setting is now encoded in the uid of the file name.
The content of the compiled template may depend on the template_dir search order
{include .... inline} is used or $smarty->merge_compiled_includes is enabled
APC
===
If APC is enabled force an apc_compile_file() when compiled or cached template was updated
Smarty 3.1.28
OPCACHE
=======
Smarty does now invalidate automatically updated and cleared compiled or cached template files in OPCACHE.
Correct operation is no longer dependent on OPCACHE configuration settings.
Template inheritance
====================
Template inheritance is now processed in run time.
See the INHERITANCE_RELEASE_NOTES
Modifier regex_replace
======================
An optional limit parameter was added
fetch() and display()
=====================
The fetch() and display() methods of the template object accept now optionally the same parameter
as the corresponding Smarty methods to get the content of another template.
Example:
$template->display(); Does display template of template object
$template->display('foo.tpl'); Does display template 'foo.bar'
File: resource
==============
Multiple template_dir entries can now be selected by a comma separated list of indices.
The template_dir array is searched in the order of the indices. (Could be used to change the default search order)
Example:
$smarty->display('[1],[0]foo.bar');
Filter support
==============
Optional filter names
An optional filter name was added to $smarty->registerFilter(). It can be used to unregister a filter by name.
- $smarty->registerFilter('output', $callback, 'name');
$smarty->unregister('output', 'name');
Closures
$smarty->registerFilter() does now accept closures.
- $smarty->registerFilter('pre', function($source) {return $source;});
If no optional filter name was specified it gets the default name 'closure'.
If you register multiple closures register each with a unique filter name.
- $smarty->registerFilter('pre', function($source) {return $source;}, 'closure_1');
- $smarty->registerFilter('pre', function($source) {return $source;}, 'closure_2');
Smarty 3.1.22
Namespace support within templates
==================================
Within templates you can now use namespace specifications on:
- Constants like foo\bar\FOO
- Class names like foo\bar\Baz::FOO, foo\bar\Baz::$foo, foo\bar\Baz::foo()
- PHP function names like foo\bar\baz()
Security
========
- disable special $smarty variable -
The Smarty_Security class has the new property $disabled_special_smarty_vars.
It's an array which can be loaded with the $smarty special variable names like
'template_object', 'template', 'current_dir' and others which will be disabled.
Note: That this security check is performed at compile time.
- limit template nesting -
Property $max_template_nesting of Smarty_Security does set the maximum template nesting level.
The main template is level 1. The nesting level is checked at run time. When the maximum will be exceeded
an Exception will be thrown. The default setting is 0 which does disable this check.
- trusted static methods -
The Smarty_Security class has the new property $trusted_static_methods to restrict access to static methods.
It's an nested array of trusted class and method names.
Format:
array (
'class_1' => array('method_1', 'method_2'), // allowed methods
'class_2' => array(), // all methods of class allowed
)
To disable access for all methods of all classes set $trusted_static_methods = null;
The default value is an empty array() which does enables all methods of all classes, but for backward compatibility
the setting of $static_classes will be checked.
Note: That this security check is performed at compile time.
- trusted static properties -
The Smarty_Security class has the new property $trusted_static_properties to restrict access to static properties.
It's an nested array of trusted class and property names.
Format:
array (
'class_1' => array('prop_1', 'prop_2'), // allowed properties listed
'class_2' => array(), // all properties of class allowed
}
To disable access for all properties of all classes set $trusted_static_properties = null;
The default value is an empty array() which does enables all properties of all classes, but for backward compatibility
the setting of $static_classes will be checked.
Note: That this security check is performed at compile time.
- trusted constants .
The Smarty_Security class has the new property $trusted_constants to restrict access to constants.
It's an array of trusted constant names.
Format:
array (
'SMARTY_DIR' , // allowed constant
}
If the array is empty (default) the usage of constants can be controlled with the
Smarty_Security::$allow_constants property (default true)
Compiled Templates
==================
Smarty does now automatically detects a change of the $merge_compiled_includes and $escape_html
property and creates different compiled templates files depending on the setting.
Same applies to config files and the $config_overwrite, $config_booleanize and
$config_read_hidden properties.
Debugging
=========
The layout of the debug window has been changed for better readability
New class constants
Smarty::DEBUG_OFF
Smarty::DEBUG_ON
Smarty::DEBUG_INDIVIDUAL
have been introduced for setting the $debugging property.
Smarty::DEBUG_INDIVIDUAL will create for each display() and fetch() call an individual debug window.

575
README
View File

@@ -1,575 +0,0 @@
Smarty 3.x
Author: Monte Ohrt <monte at ohrt dot com >
Author: Uwe Tews
AN INTRODUCTION TO SMARTY 3
NOTICE FOR 3.1 release:
Please see the SMARTY_3.1_NOTES.txt file that comes with the distribution.
NOTICE for 3.0.5 release:
Smarty now follows the PHP error_reporting level by default. If PHP does not mask E_NOTICE and you try to access an unset template variable, you will now get an E_NOTICE warning. To revert to the old behavior:
$smarty->error_reporting = E_ALL & ~E_NOTICE;
NOTICE for 3.0 release:
IMPORTANT: Some API adjustments have been made between the RC4 and 3.0 release.
We felt it is better to make these now instead of after a 3.0 release, then have to
immediately deprecate APIs in 3.1. Online documentation has been updated
to reflect these changes. Specifically:
---- API CHANGES RC4 -> 3.0 ----
$smarty->register->*
$smarty->unregister->*
$smarty->utility->*
$samrty->cache->*
Have all been changed to local method calls such as:
$smarty->clearAllCache()
$smarty->registerFoo()
$smarty->unregisterFoo()
$smarty->testInstall()
etc.
Registration of function, block, compiler, and modifier plugins have been
consolidated under two API calls:
$smarty->registerPlugin(...)
$smarty->unregisterPlugin(...)
Registration of pre, post, output and variable filters have been
consolidated under two API calls:
$smarty->registerFilter(...)
$smarty->unregisterFilter(...)
Please refer to the online documentation for all specific changes:
https://www.smarty.net/documentation
----
The Smarty 3 API has been refactored to a syntax geared
for consistency and modularity. The Smarty 2 API syntax is still supported, but
will throw a deprecation notice. You can disable the notices, but it is highly
recommended to adjust your syntax to Smarty 3, as the Smarty 2 syntax must run
through an extra rerouting wrapper.
Basically, all Smarty methods now follow the "fooBarBaz" camel case syntax. Also,
all Smarty properties now have getters and setters. So for example, the property
$smarty->cache_dir can be set with $smarty->setCacheDir('foo/') and can be
retrieved with $smarty->getCacheDir().
Some of the Smarty 3 APIs have been revoked such as the "is*" methods that were
just duplicate functions of the now available "get*" methods.
Here is a rundown of the Smarty 3 API:
$smarty->fetch($template, $cache_id = null, $compile_id = null, $parent = null)
$smarty->display($template, $cache_id = null, $compile_id = null, $parent = null)
$smarty->isCached($template, $cache_id = null, $compile_id = null)
$smarty->createData($parent = null)
$smarty->createTemplate($template, $cache_id = null, $compile_id = null, $parent = null)
$smarty->enableSecurity()
$smarty->disableSecurity()
$smarty->setTemplateDir($template_dir)
$smarty->addTemplateDir($template_dir)
$smarty->templateExists($resource_name)
$smarty->loadPlugin($plugin_name, $check = true)
$smarty->loadFilter($type, $name)
$smarty->setExceptionHandler($handler)
$smarty->addPluginsDir($plugins_dir)
$smarty->getGlobal($varname = null)
$smarty->getRegisteredObject($name)
$smarty->getDebugTemplate()
$smarty->setDebugTemplate($tpl_name)
$smarty->assign($tpl_var, $value = null, $nocache = false)
$smarty->assignGlobal($varname, $value = null, $nocache = false)
$smarty->assignByRef($tpl_var, &$value, $nocache = false)
$smarty->append($tpl_var, $value = null, $merge = false, $nocache = false)
$smarty->appendByRef($tpl_var, &$value, $merge = false)
$smarty->clearAssign($tpl_var)
$smarty->clearAllAssign()
$smarty->configLoad($config_file, $sections = null)
$smarty->getVariable($variable, $_ptr = null, $search_parents = true, $error_enable = true)
$smarty->getConfigVariable($variable)
$smarty->getStreamVariable($variable)
$smarty->getConfigVars($varname = null)
$smarty->clearConfig($varname = null)
$smarty->getTemplateVars($varname = null, $_ptr = null, $search_parents = true)
$smarty->clearAllCache($exp_time = null, $type = null)
$smarty->clearCache($template_name, $cache_id = null, $compile_id = null, $exp_time = null, $type = null)
$smarty->registerPlugin($type, $tag, $callback, $cacheable = true, $cache_attr = array())
$smarty->registerObject($object_name, $object_impl, $allowed = array(), $smarty_args = true, $block_methods = array())
$smarty->registerFilter($type, $function_name)
$smarty->registerResource($resource_type, $function_names)
$smarty->registerDefaultPluginHandler($function_name)
$smarty->registerDefaultTemplateHandler($function_name)
$smarty->unregisterPlugin($type, $tag)
$smarty->unregisterObject($object_name)
$smarty->unregisterFilter($type, $function_name)
$smarty->unregisterResource($resource_type)
$smarty->compileAllTemplates($extension = '.tpl', $force_compile = false, $time_limit = 0, $max_errors = null)
$smarty->clearCompiledTemplate($resource_name = null, $compile_id = null, $exp_time = null)
$smarty->testInstall()
// then all the getters/setters, available for all properties. Here are a few:
$caching = $smarty->getCaching(); // get $smarty->caching
$smarty->setCaching(true); // set $smarty->caching
$smarty->setDeprecationNotices(false); // set $smarty->deprecation_notices
$smarty->setCacheId($id); // set $smarty->cache_id
$debugging = $smarty->getDebugging(); // get $smarty->debugging
FILE STRUCTURE
The Smarty 3 file structure is similar to Smarty 2:
/libs/
Smarty.class.php
/libs/sysplugins/
internal.*
/libs/plugins/
function.mailto.php
modifier.escape.php
...
A lot of Smarty 3 core functionality lies in the sysplugins directory; you do
not need to change any files here. The /libs/plugins/ folder is where Smarty
plugins are located. You can add your own here, or create a separate plugin
directory, just the same as Smarty 2. You will still need to create your own
/cache/, /templates/, /templates_c/, /configs/ folders. Be sure /cache/ and
/templates_c/ are writable.
The typical way to use Smarty 3 should also look familiar:
require('Smarty.class.php');
$smarty = new Smarty;
$smarty->assign('foo','bar');
$smarty->display('index.tpl');
However, Smarty 3 works completely different on the inside. Smarty 3 is mostly
backward compatible with Smarty 2, except for the following items:
*) Smarty 3 is PHP 5 only. It will not work with PHP 4.
*) The {php} tag is disabled by default. Enable with $smarty->allow_php_tag=true.
*) Delimiters surrounded by whitespace are no longer treated as Smarty tags.
Therefore, { foo } will not compile as a tag, you must use {foo}. This change
Makes Javascript/CSS easier to work with, eliminating the need for {literal}.
This can be disabled by setting $smarty->auto_literal = false;
*) The Smarty 3 API is a bit different. Many Smarty 2 API calls are deprecated
but still work. You will want to update your calls to Smarty 3 for maximum
efficiency.
There are many things that are new to Smarty 3. Here are the notable items:
LEXER/PARSER
============
Smarty 3 now uses a lexing tokenizer for its parser/compiler. Basically, this
means Smarty has some syntax additions that make life easier such as in-template
math, shorter/intuitive function parameter options, infinite function recursion,
more accurate error handling, etc.
WHAT IS NEW IN SMARTY TEMPLATE SYNTAX
=====================================
Smarty 3 allows expressions almost anywhere. Expressions can include PHP
functions as long as they are not disabled by the security policy, object
methods and properties, etc. The {math} plugin is no longer necessary but
is still supported for BC.
Examples:
{$x+$y} will output the sum of x and y.
{$foo = strlen($bar)} function in assignment
{assign var=foo value= $x+$y} in attributes
{$foo = myfunct( ($x+$y)*3 )} as function parameter
{$foo[$x+3]} as array index
Smarty tags can be used as values within other tags.
Example: {$foo={counter}+3}
Smarty tags can also be used inside double quoted strings.
Example: {$foo="this is message {counter}"}
You can define arrays within templates.
Examples:
{assign var=foo value=[1,2,3]}
{assign var=foo value=['y'=>'yellow','b'=>'blue']}
Arrays can be nested.
{assign var=foo value=[1,[9,8],3]}
There is a new short syntax supported for assigning variables.
Example: {$foo=$bar+2}
You can assign a value to a specific array element. If the variable exists but
is not an array, it is converted to an array before the new values are assigned.
Examples:
{$foo['bar']=1}
{$foo['bar']['blar']=1}
You can append values to an array. If the variable exists but is not an array,
it is converted to an array before the new values are assigned.
Example: {$foo[]=1}
You can use a PHP-like syntax for accessing array elements, as well as the
original "dot" notation.
Examples:
{$foo[1]} normal access
{$foo['bar']}
{$foo['bar'][1]}
{$foo[$x+$x]} index may contain any expression
{$foo[$bar[1]]} nested index
{$foo[section_name]} smarty section access, not array access!
The original "dot" notation stays, and with improvements.
Examples:
{$foo.a.b.c} => $foo['a']['b']['c']
{$foo.a.$b.c} => $foo['a'][$b]['c'] with variable index
{$foo.a.{$b+4}.c} => $foo['a'][$b+4]['c'] with expression as index
{$foo.a.{$b.c}} => $foo['a'][$b['c']] with nested index
note that { and } are used to address ambiguties when nesting the dot syntax.
Variable names themselves can be variable and contain expressions.
Examples:
$foo normal variable
$foo_{$bar} variable name containing other variable
$foo_{$x+$y} variable name containing expressions
$foo_{$bar}_buh_{$blar} variable name with multiple segments
{$foo_{$x}} will output the variable $foo_1 if $x has a value of 1.
Object method chaining is implemented.
Example: {$object->method1($x)->method2($y)}
{for} tag added for looping (replacement for {section} tag):
{for $x=0, $y=count($foo); $x<$y; $x++} .... {/for}
Any number of statements can be used separated by comma as the first
initial expression at {for}.
{for $x = $start to $end step $step} ... {/for}is in the SVN now .
You can use also
{for $x = $start to $end} ... {/for}
In this case the step value will be automatically 1 or -1 depending on the start and end values.
Instead of $start and $end you can use any valid expression.
Inside the loop the following special vars can be accessed:
$x@iteration = number of iteration
$x@total = total number of iterations
$x@first = true on first iteration
$x@last = true on last iteration
The Smarty 2 {section} syntax is still supported.
New shorter {foreach} syntax to loop over an array.
Example: {foreach $myarray as $var}...{/foreach}
Within the foreach loop, properties are access via:
$var@key foreach $var array key
$var@iteration foreach current iteration count (1,2,3...)
$var@index foreach current index count (0,1,2...)
$var@total foreach $var array total
$var@first true on first iteration
$var@last true on last iteration
The Smarty 2 {foreach} tag syntax is still supported.
NOTE: {$bar[foo]} still indicates a variable inside of a {section} named foo.
If you want to access an array element with index foo, you must use quotes
such as {$bar['foo']}, or use the dot syntax {$bar.foo}.
while block tag is now implemented:
{while $foo}...{/while}
{while $x lt 10}...{/while}
Direct access to PHP functions:
Just as you can use PHP functions as modifiers directly, you can now access
PHP functions directly, provided they are permitted by security settings:
{time()}
There is a new {function}...{/function} block tag to implement a template function.
This enables reuse of code sequences like a plugin function. It can call itself recursively.
Template function must be called with the new {call name=foo...} tag.
Example:
Template file:
{function name=menu level=0}
<ul class="level{$level}">
{foreach $data as $entry}
{if is_array($entry)}
<li>{$entry@key}</li>
{call name=menu data=$entry level=$level+1}
{else}
<li>{$entry}</li>
{/if}
{/foreach}
</ul>
{/function}
{$menu = ['item1','item2','item3' => ['item3-1','item3-2','item3-3' =>
['item3-3-1','item3-3-2']],'item4']}
{call name=menu data=$menu}
Generated output:
* item1
* item2
* item3
o item3-1
o item3-2
o item3-3
+ item3-3-1
+ item3-3-2
* item4
The function tag itself must have the "name" attribute. This name is the tag
name when calling the function. The function tag may have any number of
additional attributes. These will be default settings for local variables.
New {nocache} block function:
{nocache}...{/nocache} will declare a section of the template to be non-cached
when template caching is enabled.
New nocache attribute:
You can declare variable/function output as non-cached with the nocache attribute.
Examples:
{$foo nocache=true}
{$foo nocache} /* same */
{foo bar="baz" nocache=true}
{foo bar="baz" nocache} /* same */
{time() nocache=true}
{time() nocache} /* same */
Or you can also assign the variable in your script as nocache:
$smarty->assign('foo',$something,true); // third param is nocache setting
{$foo} /* non-cached */
$smarty.current_dir returns the directory name of the current template.
You can use strings directly as templates with the "string" resource type.
Examples:
$smarty->display('string:This is my template, {$foo}!'); // php
{include file="string:This is my template, {$foo}!"} // template
VARIABLE SCOPE / VARIABLE STORAGE
=================================
In Smarty 2, all assigned variables were stored within the Smarty object.
Therefore, all variables assigned in PHP were accessible by all subsequent
fetch and display template calls.
In Smarty 3, we have the choice to assign variables to the main Smarty object,
to user-created data objects, and to user-created template objects.
These objects can be chained. The object at the end of a chain can access all
variables belonging to that template and all variables within the parent objects.
The Smarty object can only be the root of a chain, but a chain can be isolated
from the Smarty object.
All known Smarty assignment interfaces will work on the data and template objects.
Besides the above mentioned objects, there is also a special storage area for
global variables.
A Smarty data object can be created as follows:
$data = $smarty->createData(); // create root data object
$data->assign('foo','bar'); // assign variables as usual
$data->config_load('my.conf'); // load config file
$data= $smarty->createData($smarty); // create data object having a parent link to
the Smarty object
$data2= $smarty->createData($data); // create data object having a parent link to
the $data data object
A template object can be created by using the createTemplate method. It has the
same parameter assignments as the fetch() or display() method.
Function definition:
function createTemplate($template, $cache_id = null, $compile_id = null, $parent = null)
The first parameter can be a template name, a smarty object or a data object.
Examples:
$tpl = $smarty->createTemplate('mytpl.tpl'); // create template object not linked to any parent
$tpl->assign('foo','bar'); // directly assign variables
$tpl->config_load('my.conf'); // load config file
$tpl = $smarty->createTemplate('mytpl.tpl',$smarty); // create template having a parent link to the Smarty object
$tpl = $smarty->createTemplate('mytpl.tpl',$data); // create template having a parent link to the $data object
The standard fetch() and display() methods will implicitly create a template object.
If the $parent parameter is not specified in these method calls, the template object
is will link back to the Smarty object as it's parent.
If a template is called by an {include...} tag from another template, the
subtemplate links back to the calling template as it's parent.
All variables assigned locally or from a parent template are accessible. If the
template creates or modifies a variable by using the {assign var=foo...} or
{$foo=...} tags, these new values are only known locally (local scope). When the
template exits, none of the new variables or modifications can be seen in the
parent template(s). This is same behavior as in Smarty 2.
With Smarty 3, we can assign variables with a scope attribute which allows the
availablility of these new variables or modifications globally (ie in the parent
templates.)
Possible scopes are local, parent, root and global.
Examples:
{assign var=foo value='bar'} // no scope is specified, the default 'local'
{$foo='bar'} // same, local scope
{assign var=foo value='bar' scope='local'} // same, local scope
{assign var=foo value='bar' scope='parent'} // Values will be available to the parent object
{$foo='bar' scope='parent'} // (normally the calling template)
{assign var=foo value='bar' scope='root'} // Values will be exported up to the root object, so they can
{$foo='bar' scope='root'} // be seen from all templates using the same root.
{assign var=foo value='bar' scope='global'} // Values will be exported to global variable storage,
{$foo='bar' scope='global'} // they are available to any and all templates.
The scope attribute can also be attached to the {include...} tag. In this case,
the specified scope will be the default scope for all assignments within the
included template.
PLUGINS
=======
Smarty 3 plugins follow the same coding rules as in Smarty 2.
The main difference is that the template object is now passed in place of the smarty object.
The smarty object can be still be accessed through $template->smarty.
smarty_plugintype_name (array $params, Smarty_Internal_Template $template)
The Smarty 2 plugins are still compatible as long as they do not make use of specific Smarty 2 internals.
TEMPLATE INHERITANCE:
=====================
With template inheritance you can define blocks, which are areas that can be
overridden by child templates, so your templates could look like this:
parent.tpl:
<html>
<head>
<title>{block name='title'}My site name{/block}</title>
</head>
<body>
<h1>{block name='page-title'}Default page title{/block}</h1>
<div id="content">
{block name='content'}
Default content
{/block}
</div>
</body>
</html>
child.tpl:
{extends file='parent.tpl'}
{block name='title'}
Child title
{/block}
grandchild.tpl:
{extends file='child.tpl'}
{block name='title'}Home - {$smarty.block.parent}{/block}
{block name='page-title'}My home{/block}
{block name='content'}
{foreach $images as $img}
<img src="{$img.url}" alt="{$img.description}" />
{/foreach}
{/block}
We redefined all the blocks here, however in the title block we used {$smarty.block.parent},
which tells Smarty to insert the default content from the parent template in its place.
The content block was overridden to display the image files, and page-title has also be
overridden to display a completely different title.
If we render grandchild.tpl we will get this:
<html>
<head>
<title>Home - Child title</title>
</head>
<body>
<h1>My home</h1>
<div id="content">
<img src="/example.jpg" alt="image" />
<img src="/example2.jpg" alt="image" />
<img src="/example3.jpg" alt="image" />
</div>
</body>
</html>
NOTE: In the child templates everything outside the {extends} or {block} tag sections
is ignored.
The inheritance tree can be as big as you want (meaning you can extend a file that
extends another one that extends another one and so on..), but be aware that all files
have to be checked for modifications at runtime so the more inheritance the more overhead you add.
Instead of defining the parent/child relationships with the {extends} tag in the child template you
can use the resource as follow:
$smarty->display('extends:parent.tpl|child.tpl|grandchild.tpl');
Child {block} tags may optionally have a append or prepend attribute. In this case the parent block content
is appended or prepended to the child block content.
{block name='title' append} My title {/block}
PHP STREAMS:
============
(see online documentation)
VARIBLE FILTERS:
================
(see online documentation)
STATIC CLASS ACCESS AND NAMESPACE SUPPORT
=========================================
You can register a class with optional namespace for the use in the template like:
$smarty->register->templateClass('foo','name\name2\myclass');
In the template you can use it like this:
{foo::method()} etc.
=======================
Please look through it and send any questions/suggestions/etc to the forums.
http://www.phpinsider.com/smarty-forum/viewtopic.php?t=14168
Monte and Uwe

81
README.md
View File

@@ -1,75 +1,28 @@
# Smarty 3 template engine # Smarty template engine
[smarty.net](https://www.smarty.net/) Smarty is a template engine for PHP, facilitating the separation of presentation (HTML/CSS) from application logic.
![CI](https://github.com/smarty-php/smarty/workflows/CI/badge.svg) ![CI](https://github.com/smarty-php/smarty/workflows/CI/badge.svg)
## Documentation ## Documentation
Read the [documentation](https://www.smarty.net/docs/en/) to find out how to use it.
For documentation see
[www.smarty.net/docs/en/](https://www.smarty.net/docs/en/)
## Requirements ## Requirements
Smarty can be run with PHP 7.1 to PHP 8.0. Smarty can be run with PHP 7.1 to PHP 8.0.
## Distribution repository ## Installation
Smarty versions 3.1.11 or later can be installed with [Composer](https://getcomposer.org/).
> Smarty 3.1.28 introduces run time template inheritance To get the latest stable version of Smarty use:
```bash
composer require smarty/smarty
````
> Read the NEW_FEATURES and INHERITANCE_RELEASE_NOTES file for recent extensions to Smarty 3.1 functionality To get the latest, unreleased version, use:
```bash
composer require smarty/smarty:dev-master
````
Smarty versions 3.1.11 or later are now on GitHub and can be installed with Composer. To get the previous stable version of Smarty, Smarty 3, use:
```bash
composer require smarty/smarty:^3
The "smarty/smarty" package will start at libs/.... subfolder. ````
To get the latest stable version of Smarty 3.1 use:
```json
"require": {
"smarty/smarty": "~3.1"
}
```
in your composer.json file.
To get the trunk version use:
```json
"require": {
"smarty/smarty": "~3.1@dev"
}
```
For a specific version use something like:
```json
"require": {
"smarty/smarty": "3.1.19"
}
```
PHPUnit test can be installed by corresponding composer entries like:
```json
"require": {
"smarty/smarty-phpunit": "3.1.19"
}
```
Similar applies for the lexer/parser generator.
```json
"require": {
"smarty/smarty-lexer": "3.1.19"
}
```
Or you could use:
```json
"require": {
"smarty/smarty-dev": "3.1.19"
}
```
Which is a wrapper to install all 3 packages.

109
SMARTY_2_BC_NOTES.txt
View File

@@ -1,109 +0,0 @@
= Known incompatibilities with Smarty 2 =
== Syntax ==
Smarty 3 API has a new syntax. Much of the Smarty 2 syntax is supported
by a wrapper but deprecated. See the README that comes with Smarty 3 for more
information.
The {$array|@mod} syntax has always been a bit confusing, where an "@" is required
to apply a modifier to an array instead of the individual elements. Normally you
always want the modifier to apply to the variable regardless of its type. In Smarty 3,
{$array|mod} and {$array|@mod} behave identical. It is safe to drop the "@" and the
modifier will still apply to the array. If you really want the modifier to apply to
each array element, you must loop the array in-template, or use a custom modifier that
supports array iteration. Most smarty functions already escape values where necessary
such as {html_options}
== PHP Version ==
Smarty 3 is PHP 5 only. It will not work with PHP 4.
== {php} Tag ==
The {php} tag is disabled by default. The use of {php} tags is
deprecated. It can be enabled with $smarty->allow_php_tag=true.
But if you scatter PHP code which belongs together into several
{php} tags it may not work any longer.
== Delimiters and whitespace ==
Delimiters surrounded by whitespace are no longer treated as Smarty tags.
Therefore, { foo } will not compile as a tag, you must use {foo}. This change
Makes Javascript/CSS easier to work with, eliminating the need for {literal}.
This can be disabled by setting $smarty->auto_literal = false;
== Unquoted Strings ==
Smarty 2 was a bit more forgiving (and ambiguous) when it comes to unquoted strings
in parameters. Smarty3 is more restrictive. You can still pass strings without quotes
so long as they contain no special characters. (anything outside of A-Za-z0-9_)
For example filename strings must be quoted
<source lang="smarty">
{include file='path/foo.tpl'}
</source>
== Extending the Smarty class ==
Smarty 3 makes use of the __construct method for initialization. If you are extending
the Smarty class, its constructor is not called implicitly if the your child class defines
its own constructor. In order to run Smarty's constructor, a call to parent::__construct()
within your child constructor is required.
<source lang="php">
class MySmarty extends Smarty {
function __construct() {
parent::__construct();
// your initialization code goes here
}
}
</source>
== Autoloader ==
Smarty 3 does register its own autoloader with spl_autoload_register. If your code has
an existing __autoload function then this function must be explicitly registered on
the __autoload stack. See http://us3.php.net/manual/en/function.spl-autoload-register.php
for further details.
== Plugin Filenames ==
Smarty 3 optionally supports the PHP spl_autoloader. The autoloader requires filenames
to be lower case. Because of this, Smarty plugin file names must also be lowercase.
In Smarty 2, mixed case file names did work.
== Scope of Special Smarty Variables ==
In Smarty 2 the special Smarty variables $smarty.section... and $smarty.foreach...
had global scope. If you had loops with the same name in subtemplates you could accidentally
overwrite values of parent template.
In Smarty 3 these special Smarty variable have only local scope in the template which
is defining the loop. If you need their value in a subtemplate you have to pass them
as parameter.
<source lang="smarty">
{include file='path/foo.tpl' index=$smarty.section.foo.index}
</source>
== SMARTY_RESOURCE_CHAR_SET ==
Smarty 3 sets the constant SMARTY_RESOURCE_CHAR_SET to utf-8 as default template charset.
This is now used also on modifiers like escape as default charset. If your templates use
other charsets make sure that you define the constant accordingly. Otherwise you may not
get any output.
== newline at {if} tags ==
A \n was added to the compiled code of the {if},{else},{elseif},{/if} tags to get output of newlines as expected by the template source.
If one of the {if} tags is at the line end you will now get a newline in the HTML output.
== trigger_error() ==
The API function trigger_error() has been removed because it did just map to PHP trigger_error.
However it's still included in the Smarty2 API wrapper.
== Smarty constants ==
The constants
SMARTY_PHP_PASSTHRU
SMARTY_PHP_QUOTE
SMARTY_PHP_REMOVE
SMARTY_PHP_ALLOW
have been replaced with class constants
Smarty::PHP_PASSTHRU
Smarty::PHP_QUOTE
Smarty::PHP_REMOVE
Smarty::PHP_ALLOW

24
SMARTY_3.0_BC_NOTES.txt
View File

@@ -1,24 +0,0 @@
== Smarty2 backward compatibility ==
All Smarty2 specific API functions and deprecated functionality has been moved
to the SmartyBC class.
== {php} Tag ==
The {php} tag is no longer available in the standard Smarty calls.
The use of {php} tags is deprecated and only available in the SmartyBC class.
== {include_php} Tag ==
The {include_php} tag is no longer available in the standard Smarty calls.
The use of {include_php} tags is deprecated and only available in the SmartyBC class.
== php template resource ==
The support of the php template resource is removed.
== $cache_dir, $compile_dir, $config_dir, $template_dir access ==
The mentioned properties can't be accessed directly any longer. You must use
corresponding getter/setters like addConfigDir(), setConfigDir(), getConfigDir()
== obsolete Smarty class properties ==
The following no longer used properties are removed:
$allow_php_tag
$allow_php_template
$deprecation_notices

306
SMARTY_3.1_NOTES.txt
View File

@@ -1,306 +0,0 @@
Smarty 3.1 Notes
================
Smarty 3.1 is a departure from 2.0 compatibility. Most notably, all
backward compatibility has been moved to a separate class file named
SmartyBC.class.php. If you require compatibility with 2.0, you will
need to use this class.
Some differences from 3.0 are also present. 3.1 begins the journey of
requiring setters/getters for property access. So far this is only
implemented on the five directory properties: template_dir,
plugins_dir, configs_dir, compile_dir and cache_dir. These properties
are now protected, it is required to use the setters/getters instead.
That said, direct property access will still work, however slightly
slower since they will now fall through __set() and __get() and in
turn passed through the setter/getter methods. 3.2 will exhibit a full
list of setter/getter methods for all (currently) public properties,
so code-completion in your IDE will work as expected.
There is absolutely no PHP allowed in templates any more. All
deprecated features of Smarty 2.0 are gone. Again, use the SmartyBC
class if you need any backward compatibility.
Internal Changes
Full UTF-8 Compatibility
The plugins shipped with Smarty 3.1 have been rewritten to fully
support UTF-8 strings if Multibyte String is available. Without
MBString UTF-8 cannot be handled properly. For those rare cases where
templates themselves have to juggle encodings, the new modifiers
to_charset and from_charset may come in handy.
Plugin API and Performance
All Plugins (modifiers, functions, blocks, resources,
default_template_handlers, etc) are now receiving the
Smarty_Internal_Template instance, where they were supplied with the
Smarty instance in Smarty 3.0. *. As The Smarty_Internal_Template
mimics the behavior of Smarty, this API simplification should not
require any changes to custom plugins.
The plugins shipped with Smarty 3.1 have been rewritten for better
performance. Most notably {html_select_date} and {html_select_time}
have been improved vastly. Performance aside, plugins have also been
reviewed and generalized in their API. {html_select_date} and
{html_select_time} now share almost all available options.
The escape modifier now knows the $double_encode option, which will
prevent entities from being encoded again.
The capitalize modifier now know the $lc_rest option, which makes sure
all letters following a capital letter are lower-cased.
The count_sentences modifier now accepts (.?!) as
legitimate endings of a sentence - previously only (.) was
accepted
The new unescape modifier is there to reverse the effects of the
escape modifier. This applies to the escape formats html, htmlall and
entity.
default_template_handler_func
The invocation of $smarty->$default_template_handler_func had to be
altered. Instead of a Smarty_Internal_Template, the fifth argument is
now provided with the Smarty instance. New footprint:
/**
* Default Template Handler
*
* called when Smarty's file: resource is unable to load a requested file
*
* @param string $type resource type (e.g. "file", "string", "eval", "resource")
* @param string $name resource name (e.g. "foo/bar.tpl")
* @param string &$content template's content
* @param integer &$modified template's modification time
* @param Smarty $smarty Smarty instance
* @return string|boolean path to file or boolean true if $content and $modified
* have been filled, boolean false if no default template
* could be loaded
*/
function default_template_handler_func($type, $name, &$content, &$modified, Smarty $smarty) {
if (false) {
// return corrected filepath
return "/tmp/some/foobar.tpl";
} elseif (false) {
// return a template directly
$content = "the template source";
$modified = time();
return true;
} else {
// tell smarty that we failed
return false;
}
}
Stuff done to the compiler
Many performance improvements have happened internally. One notable
improvement is that all compiled templates are now handled as PHP
functions. This speeds up repeated templates tremendously, as each one
calls an (in-memory) PHP function instead of performing another file
include/scan.
New Features
Template syntax
{block}..{/block}
The {block} tag has a new hide option flag. It does suppress the block
content if no corresponding child block exists.
EXAMPLE:
parent.tpl
{block name=body hide} child content "{$smarty.block.child}" was
inserted {block}
In the above example the whole block will be suppressed if no child
block "body" is existing.
{setfilter}..{/setfilter}
The new {setfilter} block tag allows the definition of filters which
run on variable output.
SYNTAX:
{setfilter filter1|filter2|filter3....}
Smarty3 will lookup up matching filters in the following search order:
1. variable filter plugin in plugins_dir.
2. a valid modifier. A modifier specification will also accept
additional parameter like filter2:'foo'
3. a PHP function
{/setfilter} will turn previous filter setting off again.
{setfilter} tags can be nested.
EXAMPLE:
{setfilter filter1}
{$foo}
{setfilter filter2}
{$bar}
{/setfilter}
{$buh}
{/setfilter}
{$blar}
In the above example filter1 will run on the output of $foo, filter2
on $bar, filter1 again on $buh and no filter on $blar.
NOTES:
- {$foo nofilter} will suppress the filters
- These filters will run in addition to filters defined by
registerFilter('variable',...), autoLoadFilter('variable',...) and
defined default modifier.
- {setfilter} will effect only the current template, not included
subtemplates.
Resource API
Smarty 3.1 features a new approach to resource management. The
Smarty_Resource API allows simple, yet powerful integration of custom
resources for templates and configuration files. It offers simple
functions for loading data from a custom resource (e.g. database) as
well as define new template types adhering to the special
non-compiling (e,g, plain php) and non-compile-caching (e.g. eval:
resource type) resources.
See demo/plugins/resource.mysql.php for an example custom database
resource.
Note that old-fashioned registration of callbacks for resource
management has been deprecated but is still possible with SmartyBC.
CacheResource API
In line with the Resource API, the CacheResource API offers a more
comfortable handling of output-cache data. With the
Smarty_CacheResource_Custom accessing databases is made simple. With
the introduction of Smarty_CacheResource_KeyValueStore the
implementation of resources like memcache or APC became a no-brainer;
simple hash-based storage systems are now supporting hierarchical
output-caches.
See demo/plugins/cacheresource.mysql.php for an example custom
database CacheResource.
See demo/plugins/cacheresource.memcache.php for an example custom
memcache CacheResource using the KeyValueStore helper.
Note that old-fashioned registration of $cache_handler is not possible
anymore. As the functionality had not been ported to Smarty 3.0.x
properly, it has been dropped from 3.1 completely.
Locking facilities have been implemented to avoid concurrent cache
generation. Enable cache locking by setting
$smarty->cache_locking = true;
Relative Paths in Templates (File-Resource)
As of Smarty 3.1 {include file="../foo.tpl"} and {include
file="./foo.tpl"} will resolve relative to the template they're in.
Relative paths are available with {include file="..."} and
{extends file="..."}. As $smarty->fetch('../foo.tpl') and
$smarty->fetch('./foo.tpl') cannot be relative to a template, an
exception is thrown.
Addressing a specific $template_dir
Smarty 3.1 introduces the $template_dir index notation.
$smarty->fetch('[foo]bar.tpl') and {include file="[foo]bar.tpl"}
require the template bar.tpl to be loaded from $template_dir['foo'];
Smarty::setTemplateDir() and Smarty::addTemplateDir() offer ways to
define indexes along with the actual directories.
Mixing Resources in extends-Resource
Taking the php extends: template resource one step further, it is now
possible to mix resources within an extends: call like
$smarty->fetch("extends:file:foo.tpl|db:bar.tpl");
To make eval: and string: resources available to the inheritance
chain, eval:base64:TPL_STRING and eval:urlencode:TPL_STRING have been
introduced. Supplying the base64 or urlencode flags will trigger
decoding the TPL_STRING in with either base64_decode() or urldecode().
extends-Resource in template inheritance
Template based inheritance may now inherit from php's extends:
resource like {extends file="extends:foo.tpl|db:bar.tpl"}.
New Smarty property escape_html
$smarty->escape_html = true will autoescape all template variable
output by calling htmlspecialchars({$output}, ENT_QUOTES,
SMARTY_RESOURCE_CHAR_SET).
NOTE:
This is a compile time option. If you change the setting you must make
sure that the templates get recompiled.
New option at Smarty property compile_check
The automatic recompilation of modified templates can now be
controlled by the following settings:
$smarty->compile_check = COMPILECHECK_OFF (false) - template files
will not be checked
$smarty->compile_check = COMPILECHECK_ON (true) - template files will
always be checked
$smarty->compile_check = COMPILECHECK_CACHEMISS - template files will
be checked if caching is enabled and there is no existing cache file
or it has expired
Automatic recompilation on Smarty version change
Templates will now be automatically recompiled on Smarty version
changes to avoide incompatibillities in the compiled code. Compiled
template checked against the current setting of the SMARTY_VERSION
constant.
default_config_handler_func()
Analogous to the default_template_handler_func()
default_config_handler_func() has been introduced.
default_plugin_handler_func()
An optional default_plugin_handler_func() can be defined which gets called
by the compiler on tags which can't be resolved internally or by plugins.
The default_plugin_handler() can map tags to plugins on the fly.
New getters/setters
The following setters/getters will be part of the official
documentation, and will be strongly recommended. Direct property
access will still work for the foreseeable future... it will be
transparently routed through the setters/getters, and consequently a
bit slower.
array|string getTemplateDir( [string $index] )
replaces $smarty->template_dir; and $smarty->template_dir[$index];
Smarty setTemplateDir( array|string $path )
replaces $smarty->template_dir = "foo"; and $smarty->template_dir =
array("foo", "bar");
Smarty addTemplateDir( array|string $path, [string $index])
replaces $smarty->template_dir[] = "bar"; and
$smarty->template_dir[$index] = "bar";
array|string getConfigDir( [string $index] )
replaces $smarty->config_dir; and $smarty->config_dir[$index];
Smarty setConfigDir( array|string $path )
replaces $smarty->config_dir = "foo"; and $smarty->config_dir =
array("foo", "bar");
Smarty addConfigDir( array|string $path, [string $index])
replaces $smarty->config_dir[] = "bar"; and
$smarty->config_dir[$index] = "bar";
array getPluginsDir()
replaces $smarty->plugins_dir;
Smarty setPluginsDir( array|string $path )
replaces $smarty->plugins_dir = "foo";
Smarty addPluginsDir( array|string $path )
replaces $smarty->plugins_dir[] = "bar";
string getCompileDir()
replaces $smarty->compile_dir;
Smarty setCompileDir( string $path )
replaces $smarty->compile_dir = "foo";
string getCacheDir()
replaces $smarty->cache_dir;
Smarty setCacheDir( string $path )
replaces $smarty->cache_dir;

2
TODO.md
View File

@@ -1,2 +0,0 @@
# Pre-release Todos

2
libs/sysplugins/smarty_internal_compile_for.php
View File

@@ -18,7 +18,7 @@ class Smarty_Internal_Compile_For extends Smarty_Internal_CompileBase
{ {
/** /**
* Compiles code for the {for} tag * Compiles code for the {for} tag
* Smarty 3 does implement two different syntax's: * Smarty supports two different syntax's:
* - {for $var in $array} * - {for $var in $array}
* For looping over arrays or iterators * For looping over arrays or iterators
* - {for $x=0; $x<$y; $x++} * - {for $x=0; $x<$y; $x++}