Feature request. Able to run multiple versions

[welrachid]

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..

[Fri Jul 12 15:45:08.749652 2024] [php7:notice] [pid 26783] [client 192.168.56.1:53865] PHP Notice:  Undefined index: sdksajdsk in /home/devbox/code/smarty3/templates_c/c265de37450a7e5e1510eedcab9e9ac5bd4126d1_0.file.test.tpl.php on line 26
[Fri Jul 12 15:45:08.749871 2024] [php7:notice] [pid 26783] [client 192.168.56.1:53865] PHP Notice:  Trying to get property 'value' of non-object in /home/devbox/code/smarty3/templates_c/c265de37450a7e5e1510eedcab9e9ac5bd4126d1_0.file.test.tpl.php on line 26
[Fri Jul 12 15:45:08.749886 2024] [php7:notice] [pid 26783] [client 192.168.56.1:53865] PHP Notice:  Undefined index: test in /home/devbox/code/smarty3/templates_c/c265de37450a7e5e1510eedcab9e9ac5bd4126d1_0.file.test.tpl.php on line 29

Here is the compiled version tpl file.

<?php
/* Smarty version 3.1.48, created on 2024-07-12 15:45:01
  from '/home/devbox/code/smarty3/test.tpl' */

/* @var Smarty_Internal_Template $_smarty_tpl */
if ($_smarty_tpl->_decodeProperties($_smarty_tpl, array (
  'version' => '3.1.48',
  'unifunc' => 'content_6691335dd649a5_42630450',
  'has_nocache_code' => false,
  'file_dependency' => 
  array (
    'c265de37450a7e5e1510eedcab9e9ac5bd4126d1' => 
    array (
      0 => '/home/devbox/code/smarty3/test.tpl',
      1 => 1720791901,
      2 => 'file',
    ),
  ),
  'includes' => 
  array (
  ),
),false)) {
function content_6691335dd649a5_42630450 (Smarty_Internal_Template $_smarty_tpl) {
?>This is a testfile

* just a unassigned variable: <?php echo $_smarty_tpl->tpl_vars['sdksajdsk']->value;?>

* test in query: <?php echo $_GET['test'];
}
}

The not-compiled file tpl file

This is a testfile

* just a unassigned variable: {$sdksajdsk}

* test in query: {$smarty.get.test}

and the php file:

<?php

require('libs/Smarty.class.php');
$smarty = new Smarty();

$smarty->display('test.tpl');

Thanks

[Mart007King]

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:

1. 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 } ?>

   • Alias Approach: If you're unable to refactor the whole codebase to use namespaces, consider using class aliases: <?php class_alias('Smarty', 'Smarty3'); ?>
   • Versioning in Class Names: It seems like you're already following this approach by renaming classes from Smarty_ to Smarty3_. Ensure that this convention is consistently followed throughout the entire codebase.

2. 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'}

3. 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

[wisskid]

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.

[Mart007King]

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

[welrachid]

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.