Serendipity Forums

Posted: **Sun Jan 09, 2011 8:02 pm**

I am afraid this is true. It should look something like

class mySmarty extends Smarty {
  function __constructor {
     parent::__constructor();
     // local settings go here
  }
}

Else we could ask smarty devs to reorder the parameters of their funktion to be compatible with Smarty2.

Ian

Posted: **Sun Jan 09, 2011 9:42 pm**

Hi!

Maybe your suggestion is the best. Would you like to try to contact the smarty devs?

Regards,
Garvin

Posted: **Mon Jan 10, 2011 1:51 pm**

Yes sure, I already did so.... waiting for a response......

Ian

Posted: **Mon Jan 10, 2011 8:15 pm**

The answer is:

It was not intended that the $display parameter is used by user applications.
It is an internal flag when fetch() gets called from display().

For that reason it was in Smarty2 an undocumented last parameter.

As we have in Smarty3 a new additional public parameter $parent the hidden $display moved by one position.

We will not change Smarty3 parameter ordering. You could implement a wrapper by extending the Smarty class for example like this:

Code:
Code: Select all
MySmarty extends Smarty {
   public function fetch($resource_name, $cache_id = null, $compile_id = null, $display = false) {
      parent::fetch($resource_name, $cache_id, $compile_id, null,  $display);
   }
}

So this has to be our way going into future

Anything to talk back?

Ian

Posted: **Mon Jan 10, 2011 8:53 pm**

Hi!

This reasoning sounds a bit odd to me; if it's in the API, it surely gets used. Anyhow, their statement sounds final, so I think we'll need to go the wrapper way they described. Would you like to prepare a code change for that? Seems like you got a good grip on this...

Regards,
Garvin

Posted: **Tue Jan 11, 2011 1:23 pm**

Not really, to be honest! (You have a PM).
We still have enough time though, since Smarty 3.1 will have some major develop- and enhancements we should really wait for.

Ian

Posted: **Tue Jan 11, 2011 11:15 pm**

Good news! All engines running. Liftoff! We have a Liftoff!

in function serendipity_smarty_init()

Code: Select all

            // Default Smarty Engine will be used
            @define('SMARTY_DIR', S9Y_PEAR_PATH . 'Smarty/libs/');
            if (!class_exists('Smarty')) {
                include SMARTY_DIR . 'Smarty.class.php';
            }

            if (!class_exists('Smarty')) {
                return false;
            }

            class serendipity_smarty extends Smarty 
            {
                // reorder parameters in smarty(3) fetch method to be smarty(2) compat
                public function fetch($resource_name, $cache_id = null, $compile_id = null, $display = false)
                {
                    return parent::fetch($resource_name, $cache_id, $compile_id, null, $display);
                }
                public function display($resource_name, $cache_id = null, $compile_id = null, $parent = null) 
                {
                    return parent::fetch($resource_name, $cache_id, $compile_id, $parent,  true);
                }
                public function __construct() 
                {
                    // Class Constructor.
                    // These automatically get set with each new instance.
                    parent::__construct();
                }
            }

            $serendipity['smarty'] = new serendipity_smarty;

and the function &serendipity_smarty_fetch() can be changed back to old behaviour, but also works with the switch and our new class.

Ian

Posted: **Wed Jan 12, 2011 12:03 pm**

Hi!

This is great news, and great work from you. Once 3.1 is out the door, we should try to put it into SVN for the first time.

Regards,
Garvin

Posted: **Sun Jan 23, 2011 10:42 am**

The admins of smarty write:

Some major performance improvements have been implemented since 3.0.6, mostly memory management. There are still more improvements to come before 3.1, but it my be worth a test.
Starting with the upcomming version 3.1 Smarty will use the cache_id for distributing the cache files into sub_dirs.

This is a feature [the cache itself] I cannot figure out how we use it in s9y in detail.
Is it a smarty2 only deciding to cache anything in templates_c?

If they improve the caching features in Smarty3, which should improve perfomance a lot, we should learn how to use it in generally and for every single file in s9y, which is possible by now.

Ian

Posted: **Sun Feb 06, 2011 11:58 am**

Since I discovered problems with the entries preview having the switch and the new serendipity_smarty class, we have to remember to remove the switch from nightlies trunk.
http://svn.berlios.de/viewvc/serendipit ... 22&r2=2725

Instead we have to think about including some sort of exception or error handler to the new class wrapper functions.

Ian

Posted: **Sat Oct 08, 2011 1:56 pm**

Reporting status 10/2011

I still have an eye on upgrading to Smarty3.x, which is now by v.3.1.3 and looks pretty finalizing...

When starting developing S9y 1.7 on Git, I 'll try and upload a smarty3 version, if everybody is willing, which makes us modify a lot of smarty behaviour things in the S9y framework. One thing I am on, is this:
Our plugins use the smarty fetch security_settings by its default setting, I presume.

Code: Select all

            $inclusion = $serendipity['smarty']->security_settings[INCLUDE_ANY];
            $serendipity['smarty']->security_settings[INCLUDE_ANY] = true;
            $content = $serendipity['smarty']->fetch('file:'. $tfile);
            $serendipity['smarty']->security_settings[INCLUDE_ANY] = $inclusion;

The only plugin with a slight difference is serendipity_event_picasa adding a modifier

Code: Select all

	Line 492:             $serendipity['smarty']->security_settings['MODIFIER_FUNCS'][] = "rand"; // necessary tweak before 0.8 final

which could be outlined or erased by now, as all S9y versions >0.8 allow the php modifier "rand" by default.

As the Smarty >3.1 versions do not use the Smarty::$security_settings property any more and we have to think of something else instead, we could even now reduce this bunch of overhead to just use

Code: Select all

            $content = $serendipity['smarty']->fetch('file:'. $tfile);

as no smartified plugin is using a different setting. I know this bunch was there to have the possibility to tweak the default security settings if necessary, but no one ever used it and all of them should work same without, shouldn't they?

Whats is your opinion about this, Garvin?

Posted: **Tue Oct 11, 2011 7:13 pm**

Hi!

Yes, I agree on this how you proposed.

INCLUDE:ANY was earlier required to allow including other files; does that mean that smarty now allows any template file to access any file path? That's a shame, it would mean that previously you could force people only to edit template files without being able to use raw PHP code and access random files and now it means they can?

Regards,
Garvin

Posted: **Tue Oct 11, 2011 7:48 pm**

garvinhicking wrote:Yes, I agree on this how you proposed.

Them we should start a "Großreinemachen"...!

garvinhicking wrote:does that mean that smarty now allows any template file to access any file path? That's a shame, it would mean that previously you could force people only to edit template files without being able to use raw PHP code and access random files and now it means they can?

NO certainly not! They just changed the property::security_setting to something being more precise, which is being set in the global smarty config enviroment. But we definitely dont need this bunch set overall any more.

Posted: **Mon Oct 17, 2011 6:24 pm**

Timbalu wrote:
garvinhicking wrote:Yes, I agree on this how you proposed.
Then we should start a "Großreinemachen"...!

This is just a reminder for the upcoming 1.6 release.

Plugins INCLUDE_ANY inclusions are a useless relict, based to some early 2.6.x smarty versions (~s9y1.1?). It should be good to remove them all, and add at least '2.6.18' to

Code: Select all

        $propbag->add('requirements',  array(
            'serendipity' => '1.2',
            'smarty'      => '2.6.18',
            'php'         => '4.1.0'
        ));

... and how about increasing the PHP version to ~5.x

Backward compatibility is very nice to have, but we all know these cases where old PHP versions started making trouble. This might be a good starting point to increase the standard level slowly!

EDIT:
Please make your own tests disabling these INCLUDE_ANY calls, since I just found this still as a security_setting in Smarty 2.6.26 too (is it really used?). But in my case I found disabling these INCLUDE_ANY plugin settings had no visual negativ effects by now...

Posted: **Tue Nov 01, 2011 8:58 pm**

I just helped Rodney Rehm set up a s9y blog. Rodney is a Smarty core developer. He probably won't have time to join us as a s9y developer, but has offered consultation in terms of migrating to Smarty 3.

So if you think this could be helpful, feel free to contact him via Twitter or email.

YL

Serendipity Forums

[2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3

Re: [2.0] Smarty3