Closed welrachid closed 1 month ago
Hi there,
I understand the issues you're facing with class name clashes and undefined variables in your Smarty templates. Here are some suggestions to address these problems:
Class Name Clashes:
Namespace Approach: Instead of simply renaming classes, consider using namespaces. This can help in organizing the code better and avoiding name clashes. For example, you can put all Smarty3 related classes under a Smarty3
namespace:
<?php
namespace Smarty3;
class Smarty { // Class code here } ?>
Smarty_
to Smarty3_
. Ensure that this convention is consistently followed throughout the entire codebase.Undefined Variables and Error Handling:
Suppress Notices: While not recommended as a permanent solution, you can suppress notices in your development environment to avoid cluttering the error log: <?php error_reporting(E_ALL & ~E_NOTICE); ?>
Check for Existence: Always check if a variable is set before trying to access it:
<?php if (isset($_smarty_tpl->tpl_vars['sdksajdsk'])): ?> <?php echo $_smarty_tpl->tpl_vars['sdksajdsk']->value; ?> <?php else: ?> Variable not set <?php endif; ?>
Smarty Configuration: Set error_unassigned
to false
in your Smarty configuration to prevent it from raising errors for unassigned variables:
<?php
$smarty->error_unassigned = false;
?>
Default Values: Provide default values in your templates to handle undefined variables gracefully:
{$sdksajdsk|default:'Default Value'}
Specific Errors in test.tpl
:
The errors you shared suggest that certain variables (sdksajdsk
and test
) are not set before they are accessed. Ensure these variables are assigned properly in your PHP code:
<?php
$smarty->assign('sdksajdsk', 'Some value');
$smarty->assign('test', 'Another value');
?>
Alternatively, handle undefined variables in your templates:
just a unassigned variable: {$sdksajdsk|default:'Not assigned'}
test in query: {$smarty.get.test|default:'Not assigned'}
By following these suggestions, you should be able to mitigate class name clashes and handle undefined variables more gracefully in your Smarty templates. Feel free to ask if you need further assistance or clarification on any of these points.
Best regards
My question is whether it would make sense to make the major versions internally refer to themselves with a version number so that they would work regardless if there is another version on the same installation.
We won't be doing that, it would break everything for everybody else.
If you really need this, you could fork Smarty several times and rename everything in your forks.
Regarding your question on whether it makes sense to have major versions internally refer to themselves with a version number to ensure they work regardless of other versions being installed. Yes, it does make sense. Implementing internal version references can help manage multiple versions of the same library or framework on the same system without conflicts
My question is whether it would make sense to make the major versions internally refer to themselves with a version number so that they would work regardless if there is another version on the same installation.
We won't be doing that, it would break everything for everybody else.
If you really need this, you could fork Smarty several times and rename everything in your forks.
Thank you for your reply. i think i will do that then.
just to clarify. The $smarty = new Smarty(); would be the only thing changing to new Smarty3() instead. everyone would still use $smarty. only if you made any modifiers (which i have) would be need a small refactor.
anyway thanks for your time.
Hi guys
i'm trying to upgrade a lot of old systems running smarty2 and have managed to rewrite the entire smarty3 to have different classnames used so i can easily switch between the two versions.
My question is whether it would make sense to make the major versions internally refer to themselves with a version number so that they would work regardless if there is another version on the same installation. i ran into having different classes clashing and it complaining about i think it was the exception class already being defined.
my rewrite was mainly turning everything to be named Smarty_ -> Smarty3 with small exceptions. The place that actually looks in the tpl. files for $smarty. special variable
One of the things i am running into is that is an error with Smarty::error_unassigned which instead of giving an undefined variable is letting the error be raised in the error log.. (i tried both php7.4 and 8.0)
if you want me to make another issue with only the error i can do it np..
Here is the compiled version tpl file.
The not-compiled file tpl file
and the php file:
Thanks