PHP 8 has deprecated for "@". But modifier "default" is not compatible.

plugins/modifiercompiler.default.php // $output = '(($tmp = @' . $output . ')===null||$tmp===\'\' ? ' . $param . ' : $tmp)'; $output = '(($tmp = ' . $output . ' ?? null)===null||$tmp===\'\' ? ' . $param . ' : $tmp)'; // edit by 2020.12.1 -- fixed PHP 8

I see that Smarty hasn't had any updates in 2019, is it dead?

If yes, then maybe someone could post an alternative php templating engine, so we can start migrating.

Thank you.

When we use

{include file="extendsall:template.html"}

in our template, extendsall is not supported at all in 3.1.28. File which defines extendsall resource type is original resource.extendsall.php file from tgz package (demos/plugins/resource_extendsall.php) and is placed in /path/to/application/plugins directory added to plugin dirs by the following code:

$smarty->addPluginsDir('/path/to/application/plugins');

In 3.1.27 workaround with prefilter replacing {include file="template.html"} by {include file="extendsall:template.html"} was a solution.

This is not the first time such question is raised, but until now it was more in the spirit of "if we raise Smarty, version, then…".

Now, I'd like to raise the reverse question. Should we actually KEEP supporting PHP5(for now), and for the future, which PHP versions we're supporting and how do we deal with version upgrades?

Personal opinion following

As I see it right now, this is no longer a question of "which of PHP5 versions we support?" We can't keep support for 5.6 if we plan to have consistent error handling.

Here's a list of features I see relevant for Smarty as a project:

For 7.0:

• \Throwable interface;
• parsing exception (handle plugin loading failures better);
• AST parsing changes may also be related for code generation;
• null coalescing operator, while not specifically relevant, may prove invaluable for writing cleaner code;
• spaceship operator is of the same quality of life change;
• generator delegation may help in resolving {foreach} behavior with different kinds of \Traversables.

For 7.1:

• ?nullable types, iterable pseudo-type and void return type;
• error exception on passing too few function arguments;
• assignment via string index access on an empty string may also be related as a major change in behavior.

For 7.4:

• allowed exceptions from __toString() is imperative, but 7.4 is too high of a target right now.

There's a few things in 7.2 and 7.3 that can be considered QoL at best, but nothing I can call a major improvements or life-changer.

Given an increasing pressure from supporting disparate syntactic constructs between different PHP versions, the list of relevant features and consulting the list of supported PHP versions, I think it would be reasonable to leave Smarty 3.1 targeting PHP=^5.3.6 || ^7.0 (which would be a version bump from current 5.2, but will still probably work with 5.1+) and start a new Smarty version branch (3.2?) targeting PHP=^7.1 || ^8.0 with maintained backward compatibility on template level.

The choice of version 5.3.6 is made because PHP up to this specific version received fixes to several facilities that I see important for consistent coding practices.

In addition, I think it may be worthwhile to start deprecation process for legacy Smarty2 constructs while we're still in compatibility mode.

Hello,

I assume the following scenario: I have many template directories, when each contains template.html file. Let's assume these directories have names: directory1, directory2, directory3. Then we add all these directories using Smarty::addTemplateDir() method in exact above order to template directories list. I'd like to be able to create templates as below:

1. template.html from directory3: {block name="contents"}This is {/block}
2. template.html from directory2: {extends file="template.html"} {block name="contents"}{$smarty.block.parent}the {/block}
3. template.html from directory1: {extends file="template.html"} {block name="contents"}{$smarty.block.parent}test.{/block}

I'd like to get as the result the following text: This is the test.

Now Smarty triggers error in such scenario, because of recursive template loading. It could detect that a given directory has been used as template directory for template.html file already and continue searching for template.html file from next template directory in directory chain. It would allow to create dynamically modified templates with simple usage from php code: $smarty->display('template.html'); This code could be used by something like application plugins.

Maybe you have another solution for described scenario?

Bests, Tomasz

The goal of this PR is to make smarty compatible with PHP 8.1.

The main issue was the use of the function strftime() which is deprecated in PHP 8.1. This problem is solve by the use of IntlDateFormatter after being sure that the intl extension is loaded.

Other deprecations have been removed too.

Unknown: Function strftime() is deprecated in file /Smarty_Compiler.class.php line 395
Unknown: preg_match_all(): Passing null to parameter #2 ($subject) of type string is deprecated in file /Smarty_Compiler.class.php line 1531

https://github.com/php/php-src/blob/php-8.0.0beta1/UPGRADING

For example, this patch causes a fatal error

diff --git a/demo/templates/index.tpl b/demo/templates/index.tpl
index 1fbb6d3..291c3fa 100644
--- a/demo/templates/index.tpl
+++ b/demo/templates/index.tpl
@@ -1,6 +1,10 @@
 {config_load file="test.conf" section="setup"}
 {include file="header.tpl" title=foo}
 
+
+{if $smarty.const.TEST}
+{$smarty.const.TEST}
+{/if}
 <PRE>
 
 {* bold and title are read from the config file *}

Fatal error: Uncaught Error: Undefined constant "TEST" in public_html/smarty/demo/templates_c/234d0264d74c0efb651cf2c28d8975810c02182d_0.file.index.tpl.cache.php:35

Stack trace:
#0 public_html/smarty/demo/templates_c/234d0264d74c0efb651cf2c28d8975810c02182d_0.file.index.tpl.cache.php(35): constant('TEST')
#1 public_html/smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_5f32594c42fb41_62206325(Object(Smarty_Internal_Template))
#2 public_html/smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode(Object(Smarty_Internal_Template))
#3 public_html/smarty/libs/sysplugins/smarty_internal_runtime_updatecache.php(38): Smarty_Template_Compiled->render(Object(Smarty_Internal_Template))
#4 public_html/smarty/libs/sysplugins/smarty_template_cached.php(143): Smarty_Internal_Runtime_UpdateCache->updateCache(Object(Smarty_Template_Cached), Object(Smarty_Internal_Template), f#5 public_html/smarty/libs/sysplugins/smarty_internal_template.php(211): Smarty_Template_Cached->render(Object(Smarty_Internal_Template), false)
#6 public_html/smarty/libs/sysplugins/smarty_internal_templatebase.php(232): Smarty_Internal_Template->render(false, 1)
#7 public_html/smarty/libs/sysplugins/smarty_internal_templatebase.php(134): Smarty_Internal_TemplateBase->_execute(Object(Smarty_Internal_Template), NULL, NULL, NULL, 1)
#8 public_html/smarty/demo/index.php(36): Smarty_Internal_TemplateBase->display('index.tpl')
#9 {main}

due to https://github.com/php/php-src/blob/php-8.0.0beta1/UPGRADING

The code like this should not be used

<?php if (@constant('TEST')) {
echo @constant('TEST');?>

<?php }?>

I think there is a bug in smarty_internal_runtime_updatecache.php on

if (!$no_output_filter && !$_template->compiled->has_nocache_code &&
            (isset($_template->smarty->autoload_filters['output']) ||
                isset($_template->smarty->registered_filters['output']))
        ) {
            $content = $_template->smarty->ext->_filterHandler->runFilter('output', $content, $_template);
}

If the template contains {nocache} code, the results of the output filters are not going to be cached and that is IMHO useless because it leads to loss of the result of probably expensive output filters.

It's fixed by removing the condition

if (!$no_output_filter &&
            (isset($_template->smarty->autoload_filters['output']) ||
                isset($_template->smarty->registered_filters['output']))
        ) {
            $content = $_template->smarty->ext->_filterHandler->runFilter('output', $content, $_template);
}

Hi,

After upgrade from Smarty 3.1.27 to 3.1.29 i am receiving this error:

Smarty property 'sub_template' does not exist

It is throwred by the file smarty_internal_extension_handler.php at the line 92.

Someone knows how can i solve this?

Thanks!

smarty v.3.1.24

Stack trace:

10  87.0320 22877960    Smarty->fetch( string(17), null, null, null, bool, bool, bool ) .../ViewRenderer.php:84
11  87.0320 22882448    Smarty_Internal_Template->render( bool, bool, bool )    .../Smarty.class.php:824
12  87.0380 22909816    Smarty_Template_Compiled->render( object(Smarty_Internal_Template)[1804] )  .../smarty_internal_template.php:246
13  87.0380 22910424    Smarty_Template_Compiled->process( object(Smarty_Internal_Template)[1804] ) .../smarty_template_compiled.php:199
14  87.0380 22910768    Smarty_Template_Compiled->compileTemplateSource( object(Smarty_Internal_Template)[1804] )   .../smarty_template_compiled.php:152
15  87.0415 22958584    Smarty_Internal_TemplateCompilerBase->compileTemplate( object(Smarty_Internal_Template)[1804], ???, ??? )   .../smarty_template_compiled.php:226
16  87.0434 22966104    Smarty_Internal_SmartyTemplateCompiler->doCompile( string(4272), bool ) .../smarty_internal_templatecompilerbase.php:396
17  87.0689 24537000    Smarty_Internal_Templateparser->doParse( long, string(1) )  .../smarty_internal_smartytemplatecompiler.php:114
18  87.0689 24537584    Smarty_Internal_Templateparser->yy_reduce( long )   .../smarty_internal_templateparser.php:2398
19  87.0689 24537792    Smarty_Internal_Templateparser->yy_r57( )   .../smarty_internal_templateparser.php:2303
20  87.0689 24538008    Smarty_Internal_TemplateCompilerBase->compileTag( string(10), array(0), ??? )   .../smarty_internal_templateparser.php:1585
21  87.0690 24538368    Smarty_Internal_TemplateCompilerBase->compileTag2( string(10), array(0), array(0) ) .../smarty_internal_templatecompilerbase.php:462
22  87.0690 24538416    Smarty_Internal_TemplateCompilerBase->callTagCompiler( string(10), array(0), array(0), ???, ??? )   .../smarty_internal_templatecompilerbase.php:495
23  87.0690 24541352    Smarty_Internal_Compile_Blockclose->compile( array(0), object(Smarty_Internal_SmartyTemplateCompiler)[1814], array(0), null, null ) .../smarty_internal_templatecompilerbase.php:761

In doc-comments like

   /**
     * saved cache lifetime in seconds
     *
     * @var integer
     */
    public $cache_lifetime = 0;

vscode complains Use of unknown class: 'integer' I suppose it should be int instead.

I currently have 257 errors in my project; I'd like to only have my own errors/warnings to worry about. ;-)

If the error handler allow properties are true (default), Smarty catches ALL notices (in short) for ALL code that STARTS in a Smarty template. That's a bit too much. This notice should be caught like now:

{{$nonExistingVar}}

That throws an Undefined array key from 24555ff3ba201974a27652ea2c61a898c2df0cb8_0.file.bla.tpl and we want to catch that. That's good.

But this one should NOT be caught by the Smarty error handler:

{{$existingObject->existingMethod()}}

function existingMethod() {
    return $this->existingArray['nonExistingKey'];
}

That also throws an Undefined array key, but NOT from compiled template code. But Smarty catches and suppresses it anyway. I don't think that's what we want.

Can Smarty_Internal_ErrorHandler::handleError() check for the source of the error? If it's not a smarty compiled template file, let it through.

For some reason, I am receiving Fatal Errors like the following:

Fatal error: Uncaught ErrorException: Using php-function "md5" as a modifier is deprecated and will be removed in a future release. Use Smarty::registerPlugin to explicitly register a custom modifier. in /home/patrick/github.com/getbooka/booka/vendor/smarty/smarty/libs/sysplugins/smarty_internal_compile_private_modifier.php on line 114

While I understand that and why this "feature" is deprecated, I don't understand why it has to be a fatal error. The wording is "will be removed in a future release," which means it is not removed now. So why is it throwing an error/exception? It should be a warning of some kind? Maybe I am doing something wrong that sets notices to fatal errors in my system, but I am not aware of this.

Can you confirm that it's currently an exception with the wording above?

PS: I know how to add my modifiers and work through this; the issue is about the error level of the deprecation notice, not the change itself.

If set to TRUE, Smarty will use only compiled templates, also ignoring the (in)existence of base templates. Compiled filenames will be constant and relative to the template basename. Useful to use pre-compiled templates and distribute them already compiled on production websites. Overrides and disables $merge_compiled_includes

I noticed that if one is calling |truncate on null, it triggers E_DEPRECATED: mb_strlen(): Passing null to parameter #1 ($string) of type string is deprecated on PHP 8.1.

This is expected, but given the modifier accepts null we may as well return an empty string before calling the function.