Smarty Forum Index Smarty
The discussions here are for Smarty, a template engine for the PHP programming language.
Modifiers not working same as in 3.0 RC3

 
Post new topic   Reply to topic    Smarty Forum Index -> Smarty 3
View previous topic :: View next topic  
Author Message
Michael White
Smarty Rookie


Joined: 08 Oct 2009
Posts: 20

PostPosted: Sun Dec 05, 2010 4:18 pm    Post subject: Modifiers not working same as in 3.0 RC3 Reply with quote

Hi,

I finally got a chance to try out Smarty 3.0.4 and 3.0.5 after having used RC3 since the day it was released.

It appears that modifiers no longer compile the way they did in RC3 and earlier releases.

In 3.0 RC3 and lower, if you had a line in the template like:

Code:

{$app->doSomething(500)|noprint}


it would result in a compiled line like:

Code:

<?php echo smarty_modifier_noprint($_smarty_tpl->getVariable('app')->value->doSomething(500));?>


In both 3.0.4 and 3.0.5, using the noprint modifier results in a compiled line like:

Code:

<?php echo '';?>


At least for us, this is a major break as our templates often use noprint in this way so we cannot upgrade our system to a stable release of Smarty 3 at this time. I do hope we can resolve this issue as it would be very nice to run on a stable release rather than a release candidate.
Back to top
View user's profile Send private message Visit poster's website
U.Tews
Administrator


Joined: 22 Nov 2006
Posts: 4671
Location: Hamburg / Germany

PostPosted: Sun Dec 05, 2010 4:52 pm    Post subject: Reply with quote

Some of the standard modifiers are now compiled into the template for better performance.

They are impelmented as ülugin type modifiercompiler.

You could remove in the plugins folder modifiercompiler.noprint.php and reülace it with the old modifier.noprint.php.
Back to top
View user's profile Send private message
Michael White
Smarty Rookie


Joined: 08 Oct 2009
Posts: 20

PostPosted: Wed Dec 08, 2010 11:38 pm    Post subject: Reply with quote

Thanks,

That worked well but definitely feels hackish since it involves modifying a file in a stable release of software.

Is there any way to set up the new modifiercompiler plugins to handle PHP function/method calls the way that the regular modifier plugins do?
Back to top
View user's profile Send private message Visit poster's website
U.Tews
Administrator


Joined: 22 Nov 2006
Posts: 4671
Location: Hamburg / Germany

PostPosted: Thu Dec 09, 2010 3:51 pm    Post subject: Reply with quote

Why do you need that modifiers are implemented (called) in a certain way?
Back to top
View user's profile Send private message
Michael White
Smarty Rookie


Joined: 08 Oct 2009
Posts: 20

PostPosted: Fri Dec 10, 2010 4:17 am    Post subject: Reply with quote

We often call functions and class methods directly from the templates. Many times those calls return a value such as true/false or an integer or some other value that we don't actually want to have rendered.

One specific example of this type of situation is our debugging statements. We might call something like:

Code:

{Debugger::debug('My debug message')}


The debugger might send that data somewhere like to FirePHP and return true if debugging is currently turned on and false if the debugger is turned off.

In that case we would need to prevent the output of the number "1" by using the noprint modifier like:

Code:

{Debugger::debug('My debug message')|noprint}



In RC3 the above line would still send the debug message to the debugger, but when the modifiercompiler.noprint version is used, the compiled template does not include the actual debug statement, but instead includes an empty string (as shown in the initial post).

Thus we would not be able to call functions that return a value without wrapping them in {capture} blocks to prevent the output, which is a bit awkward when you just want to write a simple debug statement.
Back to top
View user's profile Send private message Visit poster's website
Lemon Juice
Smarty Pro


Joined: 24 May 2006
Posts: 106

PostPosted: Tue Dec 21, 2010 4:56 pm    Post subject: Reply with quote

Michael White wrote:
Thus we would not be able to call functions that return a value without wrapping them in {capture} blocks to prevent the output, which is a bit awkward when you just want to write a simple debug statement.

You could create your own noprint modifier (e.g. my_noprint) and use it instead. Theoretically, you should also be able to overwrite the noprint modifier by simply registering your custom modifier with the same name and if smarty compiler is smart enough, it should not optimize your method calls to empty strings - it's worth checking out.
Back to top
View user's profile Send private message
Michael White
Smarty Rookie


Joined: 08 Oct 2009
Posts: 20

PostPosted: Wed Dec 22, 2010 4:45 am    Post subject: Reply with quote

Thanks,

I will probably try overriding the core modifier with my own... at the moment I just removed the modifier compiler version and replaced with with the RC3 version of the plugin.


I will post the results of the override attempt once I implement it.
Back to top
View user's profile Send private message Visit poster's website
Michael White
Smarty Rookie


Joined: 08 Oct 2009
Posts: 20

PostPosted: Tue Oct 08, 2013 5:47 pm    Post subject: Reply with quote

It's been a while but we ran into this again when a slightly older project showed a couple of bugs. We decided not to override the noprint modifier because we really expected that this would be fixed in core Smarty since it seemed to us to be a pretty significant regression.

In core Smarty the compiler should just render the command / call and not prefix that line with echo so that the result is not rendered in the output.

We are currently using Smarty 3.1.15
Back to top
View user's profile Send private message Visit poster's website
U.Tews
Administrator


Joined: 22 Nov 2006
Posts: 4671
Location: Hamburg / Germany

PostPosted: Wed Oct 09, 2013 6:10 pm    Post subject: Reply with quote

Hi Michael

For some reason this problem was not solved.
The current workaround is still to remove the modifier compiler version with a standard modifier plugin returning an empty string.

As modifiers are expected to return some sort of output the compiler will always generate an echo.

I will look into a general solution introducing a noprint option flag like

{something noprint}

in a future release.
Back to top
View user's profile Send private message
Michael White
Smarty Rookie


Joined: 08 Oct 2009
Posts: 20

PostPosted: Wed Oct 09, 2013 6:46 pm    Post subject: Reply with quote

We worked around it for now by using calls like {$_noPrint=functionCall()}

but I definitely think your flag idea is a more elegant solution Smile I will keep an eye out for when that makes it in.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Smarty Forum Index -> Smarty 3 All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP