Smarty 3 last minute changes

[Monte Ohrt]

There are some things changing in Smarty 3, big ones, and I want to get feedback from the developers, in case there are any questions/concerns.

1) {php}{/php} is being removed from the core distribution. I never liked that this was in Smarty 2, and now is our chance to get rid of it. If someone really needs this feature, a simple block function will suffice.

2) I'm strongly considering dropping the new "php" template option. As it has been thought about for some time now, PHP templates simply work against the fundamental design of Smarty. Smarty has always been about separation of business and presentation. Also, by design, it insulates the view from the business code with a tag-style template syntax. If we allow pure PHP templates, I believe this would stir up bigger messes than {php}{/php} have already caused in the past. Developers could too easily abuse the system and make a mess of php templates mixed with business logic. If you really want this, a 3rd party compiler could be created.

3) In Smarty 2, there is a $php_handling option, PASSTHRU, QUOTE, REMOVE, and ALLOW. I think I want to remove this option and just handle all PHP in the templates as PASSTHRU. That is, it just echoes as text. If you want PHP quoted, you could use an {escape}{/escape} block function around text you want html-escaped, or use a modifier, or prefilter, etc. If you want PHP removed, use a prefilter. If you want to allow PHP, use your own {php}{/php} block function.

Thoughts on these decisions? Please reply, even if it's just "agreed" :)

Monte

[Tom Fazakas]

100% agree! The main reason why we decided to replace the Zend
Framework's view with Smarty is because we would like to give out our
templates to the third party developers, disallow the php execution.
So we are happy for it.


2009/9/25 Monte Ohrt <mo...@ohrt.com>:

[Jason Morriss]

I never understood why there were "php" options within smarty templates anyway, so I agree that those options should be removed.

-- Jason

[Greg Fuller]

I agree. But perhaps keeping the capability would give some level of
comfort to the partially convinced.

Maybe it should be made optional, so it would be safe for "untrusted"
template editors if so configured.

[Monte Ohrt]

Smarty is certainly flexible enough to configure these things. I just
want to remove it from the distribution and send developers down the
right path. If someone really wants these things, if they really need
the BC of Smarty 2 in these respects, there will be plugins/snippits
available in other places, such as 3rd parties, or forum/wiki contributions.

[Rodney Rehm]

Hello Monte,

> 1) {php}{/php} is being removed from the core distribution.

agreed.

> 2) I'm strongly considering dropping the new "php" template option.

I disagree.

Websites are not strictly HTML nowadays. There's lots of JSON and XML
going around. Even PDF might be of interest. Smarty is a very powerful
template engine. But apparently only when it comes to HTML?!

I need to serve the same data in different formats. One requests the
data as a complete HTML page. The next request only wants the actual
data part (without header, footer, and stuff) to replace a part of the
current page. The next request requires the data in JSON or XML
because some neat javascript stuff is going to go down on it. It's
even possible that I need to serve the data as a PDF. JSON is easy,
XML all that easy (you want DOM!), PDF nearly impossible.

Now why on earth would I want to re-implement Smarty's caching system?
It (almost) perfectly suits my needs. Using CacheGroups i can flush
the cache for a specific data point for HTML, HTML-part, JSON, XML,
PDF at the same time. This is frakking cool!

As I'm currently using Smarty2, I introduced some function-plugins to
dump all currently assigned variables to JSON or XML. This far it's
working, but kind of ugly. I would like to separate the HTML / HTML-
part from JSON / XML. I would also like to introduce PDF. I would like
to keep the HTML templates clean, but still use all that Smarty power
for the other formats I have to "render".

I haven't tested Smarty3 thoroughly. I actually just kept reading this
mailing list. So I'm not sure if my plan is actually implementable.
But I was planning on using the PHP-templates to interface JSON and
XML utilities to get my HTML templates clean. And I was planning on
using Smarty3 to generate latex which would be piped through some
utilities to generate PDF. All that using Smarty. Just Smarty. With
all that easy caching stuff, with all those cool plugins.

If you remove the PHP templates all of the above might still be
possible. But from my point of view this would be a way bigger pain in
the ass.

> 3) In Smarty 2, there is a $php_handling option, PASSTHRU, QUOTE, REMOVE,
> and ALLOW. I think I want to remove this option and just handle all PHP in
> the templates as PASSTHRU.

agreed.

Regards,
Rod

[Jason]

I agree with all 3 changes :)

[Monte Ohrt]

Hi Rodney,

I don't think you'll be held back at all. Smarty can directly support
all of your text-based needs such as HTML/XML/JSON. You can generate
this stuff directly in template, or with a combination of template
plugins/resources, or you can make a PHP stream for it with Smarty 3. As
for PDF, I suppose you could make a plugin/resource for it, but I've
never tried to run that through Smarty, you are better off leaving that
to a PHP library fitted to that purpose. Maybe with a custom resource or
stream, you could do $smarty->display('pdf:index.tpl'); and retain the
use of the Smarty cache. Anything you want to do in a template with PHP
you can better handle in a custom plugin/resource.

Monte

[Snor]

Okay, here's my partially anecdotal take on things...

Although I try to keep PHP out of my templates at all times, I've been
forced to do it for the sake of simplicity and functionality many
times with Smarty 2. With Smarty 3, which I've used for 2 projects
(one of which is in production) so far, I've not had the need for any
PHP inside templates. Partially this is due to Smarty 3 being way more
powerful but also possibly because I've not done anything particularly
complex with it yet.

While I hope I never want to put PHP in a template again, I can
imagine there will come a time when I wish I could. If it was up to me
I'd say <?php ... ?> should be left completely untouched, and then
have a template option eg. allow_php = true/false (have it false by
default?) - but maybe you have some technical reason for not wanting
to do this? I don't think the fact that people *may* abuse this is a
particularly good reason to not have the feature, and using PHP in a
template does not necessarily mean that people are mixing up business
and template logic, it can be that they just have some complex
template logic that they want/need to write in pure PHP.

- Leo

[Rodney Rehm]

Hello Monte,

On 25 Sep., 18:32, Monte Ohrt <mo...@ohrt.com> wrote:
> [...] Anything you want to do in a template with PHP

> you can better handle in a custom plugin/resource.

Maybe I misunderstood your second issue.
I thought you meant dropping the php resource type.

Regards,
Rod

[U.Tews]

Hi Rodney

The ideas was to drop both the PHP tags and the PHP resource type.

[Steve Eriksen]

> 1) {php}{/php} is being removed from the core distribution. I never liked
> that this was in Smarty 2, and now is our chance to get rid of it. If
> someone really needs this feature, a simple block function will suffice.

To me, the power of Smarty is its flexibility. By all means, turn of
features from being turned on by default, but removing this facility
would make it more difficult to achieve some goals. Example:
CMSMadeSimple is an excellent CMS built on Smarty, and a PHP tag
allows me/the client to use PHP code if needed directly within the
content page editor, and there is definitely a need to do this from
time to time. If a function has to be created then it becomes a lot
more complex, especially for the client who would also need access to
more of the "inner workings" of the application and could truly mess
things up. Yes, absolutely, creating a function can achieve everything
and replace the tag completely, and is the "purist" way to go, but
sometimes flexibility is more important. So my vote is: turn it off by
default, but leave it in for those who really want it (like me).

> 2) I'm strongly considering dropping the new "php" template option. As it
> has been thought about for some time now, PHP templates simply work against
> the fundamental design of Smarty. Smarty has always been about separation of
> business and presentation. Also, by design, it insulates the view from the
> business code with a tag-style template syntax. If we allow pure PHP
> templates, I believe this would stir up bigger messes than {php}{/php} have
> already caused in the past. Developers could too easily abuse the system and
> make a mess of php templates mixed with business logic. If you really want
> this, a 3rd party compiler could be created.

Same as above, although I would agree more with this one. Doesn't
quite make sense to have a php template in this fashion although it
COULD help with transition from straight PHP to a new Smarty based
system?

> 3) In Smarty 2, there is a $php_handling option, PASSTHRU, QUOTE, REMOVE,
> and ALLOW. I think I want to remove this option and just handle all PHP in
> the templates as PASSTHRU. That is, it just echoes as text. If you want PHP
> quoted, you could use an {escape}{/escape} block function around text you
> want html-escaped, or use a modifier, or prefilter, etc. If you want PHP
> removed, use a prefilter. If you want to allow PHP, use your own {php}{/php}
> block function.

I would stick with the current behaviour - after all, there is
something to be said for Backwards Compatibility!

Steve

[Monte Ohrt]

No decisions have been made, but I like the discussion, keep it coming.
The needs of the developers will ultimately drive the result. So, I'm
going to give some more of my thoughts :)

Let's back up a bit and look at the bigger picture. A fundamental design
aspect of Smarty is to insulate the view (templates) from the business
code, and this is by way of a simplified tag-based syntax. It should be
a safe assumption that when you are in a template, you are not in a PHP
script. A template is static text interspersed with {tags}. The {tags}
are designed to process dynamic presentational content, nothing else.
You should be able to put any text outside of {tags} and rest assured it
will be treated as such. If we process <?php ?> tags in the templates,
you have just broken that insulation.

If you follow this insulation design, the organization of your
application should fall right into place. There should be no need to
inject PHP into a template, as all presentation items should be assigned
there. Anything you want to process at-run-time from within a template
should be handled with a proper plugin that returns the presentational
content back to the view, and we maintain our insulation and tag-based
syntax. If you are injecting PHP in the template, I'm going to guess
that 99.9% of the time you really are mixing business logic into the
view, because there would be no reason to include php that just echo's
static content. Also, wrapping your code in Smarty plugins will ensure
that the features (or future features) of Smarty can apply to any
logic/content that is processed in the templates.

With that said, even if you feel that somehow injecting PHP in the
template is a good/easier thing to do, then there are several ways to go
about it, even if Smarty drops direct support. That is, create a
plugin/resource for it (preferred, keep it separate), or create a block
function or filter and inject it directly (bad design.)

So the decision is, enforce the good habits by dropping support for
things that create bad habits, or leave them in and let the developers
decide. I'm going off of the history of the {php}{/php} tags, and the
havoc they have created over the years. It's amazing to me, how many
first-timers using Smarty don't care to learn how to use it properly,
and instead dive straight for the {php}{/php} crutch once they find that
in the manual.

Monte

[Monte Ohrt]

Good point about the CMS. It may be better to disable things by default,
but keep the option available for some cases.

[Monte Ohrt]

Can you give me an explicit example where PHP in the template is
necessary for CMSMS?

[Rodrigo Machado]

totally agree

[Monte Ohrt]

To sum up the consensus so far:

1) {php}{/php} tags
Will be deprecated/remove, but available as separate plugin for BC.

2) php resource type, or php-only templates
drop completely, this creates too much confusion. *maybe* available
later as a separate resource option.

3) php_handler
leave exactly as Smarty 2, with option to process php tags, but PASSTHRU
by default.

Monte

[Mark Perkins]

For what it's worth, this sounds like an well balanced and workable solution to me.

Cheers,

Mark

[Steve Eriksen]

On Sep 25, 8:26 pm, Monte Ohrt <mo...@ohrt.com> wrote:
> Can you give me an explicit example where PHP in the template is
> necessary for CMSMS?
>

Well, yes and no. I am not saying that having PHP in the template is
NECESSARY. I am saying that it can make life easier in the right
circumstances.

One specific example is a CMS for an estate agent. I created a system
with a number of different functions (called "tags" in CMSMS) which I
as a developer didn't want the customer to have access to.

They then wanted to extract information from a live MySQL table. They
already had the code, didn't want to pay me to create a new function
and test it, and I didn't want to give them access to the code behind
the tags I had created (they were paying monthly, not a one-off fee
for development). So the solution was simple - give them access to
{php}{/php} and told them I would charge support fees if they messed
it up. They didn't, so they were happy and continued to take the
service from me until they went bankrupt!

They also added more code to their pages, although I wasn't involved
in it so I don't know what they achieved. It didn't matter to me
though - my code was protected.

Of course, I could have taken my code out of the "tags" system in
CMSMS and inserted it as individual files on the server, however then
their system wouldn't be contained in the MySQL database anymore and I
would have to arrange special backup for their site only, plus the
additional time to move all the code across.

So it's much less about what necessary or possible in terms of
programming, but much more about the commercial realities sometimes of
the best way to implement it - it saved time, hassle and the client's
money.

Steve

[Monte Ohrt]

Yeah this an example of directly injecting business logic, but I see the
logistical implications.

[Jason]

I can see how people can see this as useful, but I only see it as a
security risk.

-- Scenario --
My design team works with our FTP, the only directory they have access
to is the /styles/ folder for editing templates.

There are a couple of imposed security risks with the {php} tag here:

1) If the FTP directory gets compromised, the {php} tag gives the
intruder full access to our working directory since the full leverage
of PHP is at their fingertips.
2) The designers could inject {php} into our designs that could impose
security risks themselves, be unethical, or they could try to snoop
around by reading files and listing directories.

Even if I trust my designers, I don't want to have the thought of them
using the {php} tag in the back of my head (IE: "what if..").

Taking out {php} is both good and bad at the same time. I can think of
a dozen scenarios where {php} could be helpful, however I cannot stop
thinking about the security risk that it imposes. And while there are
situations where {php} is viable, there is most likely another viable
alternative that doesn't involve using {php}.

-J

[Monte Ohrt]

With security enabled, {php} tags are disabled, that is true even with
Smarty 2. If someone compromises your FTP folder, they can probably just
create php files anyways.

With no security enabled, {php} is not the only vulnerable place for
php. You can execute arbitrary php funcs in the template as:

modifiers (Smarty 2/3):
{$foo|somefunc}

if statement (Smarty 2/3):
{if somefunc()}

direct functions (Smarty 3):

{somefunc()}

[Steve Eriksen]

The beauty of it is that you have the power to disable the {php} tag,
whilst others might find a good reason to turn it on.

For me, the service is hosted on a public server with another 30 or so
websites, and all of them have direct ftp access to their root
directory as they upload their own code. So giving a client {php}
access like that isn't a big deal.

Now, of course, they had the ability to go and find the code
themselves so for me it was a balance of "security through obscurity"
but as I knew the capability of the client I knew that was enough.

[Tom Fazakas]

How can you disable {php} tag if your template already requires it if
the previous developer made a bad design?


2009/9/25 Steve Eriksen <st...@effectivemarketingtenerife.com>:

[Monte Ohrt]

You mean how to replace {php} with a plugin, or how to disable the plugin?

[Monte Ohrt]

To disable {php} in smarty 2 you need to turn on security. Smarty 3,
{php} will be a block plugin that is disabled by default.

[Tom Fazakas]

I just replied to Steve who wrote that you have the power to turn the
{php} support off if you don't like it. So I cannot disable if someone
made a bad design in the beginning of the project and their code
requires the template {php} block. That's why I think this {php}
shouldn't be a part of the Smarty option. If you need to use {php} in
your template then you have a bad design, even if it's faster or
easier.



2009/9/25 Monte Ohrt <mo...@ohrt.com>:

[Steve Eriksen]

Hi Tom,

It all down to context, business rules etc.

If there's developer making the wrong choices at the start of a
project, I'm sure using {php} tags will just be one in a long list of
bad decisions, so I would look for great developers in the first
place, or giving them explicit instructions such as "due to security
issues Smarty must be used in its default configuration or locked down
even more; no features can be enabled without explicit instructions".

When using external developers I have become accustomed to giving
extremely specific instructions to ensure design guidelines are
adhered to. If they don't have the skills in the first place then
there's very little you can do to control them, unfortunately.

My point is simply this - once in a blue moon there is a good reason
to enable it, although in 99% of the cases there isn't. For me, it was
spending hours doing unpaid work to change an existing project to save
the client a little bit of money, or doing that work and several other
small bits of work for free. Everything I did was using the correct
structures and no php code at all.

But when the project was completed and I had no financial incentives
to spend hours on the project, then yes, commercial reality meant it
was better to enable it than spending hours or losing the customer.

On Sep 25, 9:42 pm, Tom Fazakas <fto...@gmail.com> wrote:
> How can you  disable {php} tag if your template already requires it if
> the previous developer made a bad design?
>
> 2009/9/25 Steve Eriksen <st...@effectivemarketingtenerife.com>:

<snip>

[Tom Fazakas]

Hi Steve,

So you think this {php} tag issue should work like the
register_globals on/off situation and keep it off by default.
This is a funny thing because if the php guys doesn't implement this
register_globals, nobody wants to miss this feature in their old
applications. Same as this {php} tag.
I think it's a neverending discussion and I'm sure the code cannot be
"stupid safe" but I think we should try to do.

Nice coding,
Tom




2009/9/25 Steve Eriksen <st...@effectivemarketingtenerife.com>:

[Steve Eriksen]

Hi Tom,

Completely agree, a never ending discussion. Yep, I think it should be
off by default. And I do agree, if it never had been there we wouldn't
miss it. However, it was there, and it was very useful for me to have,
so therefore I would like to have the ability in the future ;-)

Steve

[U.Tews]

Monte and I made the following decissions:

A) The {PHP} tag will be handled by a block plugin. It has an
internal enable flag. By default this is off and the tag will throw an
exception. If you need it you have to edit the plugin and set the
enable flag true.

B) The PHP resource type for PHP templates will be removed.

This is a sort of compromise.

Uwe


On Sep 26, 12:17 am, Steve Eriksen

[Steve Eriksen]

Cool, thanks, very happy with that!

Steve

[Snor]

Sorry, I think I misunderstood initially.

If you're saying that all php will be disabled by default, but by
changing php_handler to ALLOW would enable using <?php ... ?> inside a
template, then I agree 100% - That is exactly as it should be in my
opinion.

[zaenal m.]

Agree 100%. No need PHP in template.

@zaenal

[mitchenall]

Agreed!

[Monte Ohrt]

I think we are going to tie {php} handling to <?php ?> tag handling. That is, if you try to use {php} tags and smarty php tag handling is set to PASSTHRU, it will throw an exception. This will be Smarty 3's way of deprecating the {php} tag. Anyone have a problem with that?

[mitchenall]

Sounds fine to me.

My only slight worry might be that it would've perhaps been nicer to
deprecate the feature earlier, allowing some people perhaps more time
before switching off this feature completely. e.g. Perhaps include a
block plug-in in v3 to provide for {php} tags that at least raises
'deprecated' warnings, then throw exceptions in v3.1.

Just an idea. It doesn't affect me either way.

Cheers
Mark

[Snor]

Sounds like the best idea if it's to be kept at all. Just out of
curiosity will there still be a flag to set to enable {php} or will it
just require php handling to be set to ALLOW now?

On Sep 28, 5:45 pm, Monte Ohrt <mo...@ohrt.com> wrote:

[Monte Ohrt]

Just the handling. If you want to force {php} on in PASSTHRU mode, you'd
have to hack the plugin.

[Mark Wu]

Uwe:

> A)  The {PHP} tag will be handled by a block plugin. It has an
> internal enable flag. By default this is off and the tag will throw an
> exception. If you need it you have to edit the plugin and set the
> enable flag true.

Cool, I agree this one. I never like {php} before. :)

> B) The PHP resource type for PHP templates will be removed.

I am confused about this one, I just read all reply in this thread ...
is this mean no more "pure php" template in smarty3?

I really like smarty3 becasue it allow me to use php as template
language, it can save a lot of compilation time.

Mark

[Monte Ohrt]

Then begs the question... if you want pure php templates, what is your purpose of using Smarty at all? I suppose you can still leverage the caching and use the plugins, but you lose a whole lot of the insulation Smarty is meant to provide. I'd be interested in hearing some real use cases.

[Mark Wu]

Hi Monte:

I am the developer of LifeType, an open source blogging platform for
multi-user and multi-site. We use smarty for a long long time from
this project beginning. Smarty2 used in every page like blog pages,
summary pages and admin pages.

Since this platform is build for large BSP, so anything can reduce the
request time, we will use it. We use all cache technique as possible
as we can. For example , we use cache_lite/memcached for data cache.
we use smarty2 compile cache(for blog, summary, admin page) , page
cache(for blog and summary page) and a modified nocache plugin for
dynamic content that can not be cached in page cache.

Everything works fine if all pages or data cached. But, you know, it's
quite terrible when first run before anything cached.

So, when I saw smarty3 support pure php template, I am quite happy
with it. Because I can use pure php template for admin and summary
page to reduce the compilation time in first run, even only reduce 10
ms.

But, I will keep blog page still use the original smarty syntax.
Becasue we allow user to modified the template, and we don't want them
to use and php function to abuse system.

That's the place I want/plan to use pure php cache. If pure php
template can exist as a plugin can replace the compile engine, I am
also quite happy with it.

BTW, I treat php as a kind of template syntax in Smarty, I still keep
my logic(action), data(model) and presentation(view) separate.

Therefore, I don't think it will mess up my code :)

PS. I suppose I still can use page cache, nocache in pure php
templates...

Regards, Mark

On 9月30日, 上午12時50分, Monte Ohrt <mo...@ohrt.com> wrote:
> Then begs the question... if you want pure php templates, what is your
> purpose of using Smarty at all? I suppose you can still leverage the caching
> and use the plugins, but you lose a whole lot of the insulation Smarty is
> meant to provide. I'd be interested in hearing some real use cases.
>

[Monte Ohrt]

Thanks for the info Mark, although it's a pretty far reach to completely rewrite the templates in PHP just to save a 10ms once at the (single) compile step.

[U.Tews]

After lots of discussion the status of the latest SVN is as follow:

A) {php} tag
The {php} is disabled by default and throws an exception.
$smarty->allow_php_tag = true; does enable it

B) <?php ... ?> tags
<?php .... ?> insde Smarty templates are controlled by $smarty-
>php_handling as in Smarty2.
The default is SMARTY_PHP_PASSTHRU

C) PHP resource type
The PHP resource type is back in the package to handle simple PHP
templates.
They are disabled by default and throw an exception.
$smarty->allow_php_templates = true; does enable them
Security features like restricting PHP function calls are not active.

Regards Uwe

On Sep 30, 10:05 pm, Monte Ohrt <mo...@ohrt.com> wrote:
> Thanks for the info Mark, although it's a pretty far reach to completely
> rewrite the templates in PHP just to save a 10ms once at the (single)
> compile step.
>

[Mark Wu]

Hi Monte & Uwe:

I do really appreciate to see this feature keep in Smarty3, thanks for
your kindly consideration and effort of this project.

Regards, Mark

[Cliff Chaney]

Though I've done quite a bit of Smarty development over the last
couple of years, I still consider myself to be at the "Beginner to
Intermediate" level. So please forgive me if I've overlooked
something obvious...

I see this rationale and similar complaint quite frequently.
Specifically, everyone "hates" the performance hit of the initial
compile time; but we all put up with it because it's a one-time cost
and we get it back in spades later. Mark Wu's response goes so far as
to say that he uses (or will use) true PHP templates just to avoid
that initial hit. This isn't a big deal in my situation, mind you;
and probably not in most. But under the right circumstances - as in
Mark Wu's case - it's a pretty big deal.

So then, has any thought been given to making the Smarty 3 compiler
more easily, independantly accessible (i.e. callable from a make file)
so that developers could install pre-compiled templates whenever
updates are rolled to production? I know that you could make this
happen manually - but for many large sites, that's a non-solution.

Even as I type this, it seems likely that this is probably pretty easy
to do and may require little more than specific documentation on how
to do it.

Thoughts?

[Mark Wu]

Hi Cliff:

To pre-compile the smarty templates to pure php files, it sounds a
good idea. I like it.

Mmm ... take my case for example:

1. For each blog has it's own template set ( a set of *.tpl files) , I
have to go through each blog and compile all templates. For small
amount of blogs, I think it should be okay. For large amout of blogs,
it will take a very long time to generate compiled php code.

2. For admin and summary page, I think it should be okay to adapt this
idea.

* I think I can write a crawler to digg every blog and let the smarty
compile all templates for all blogs before I open the site for outside
user.

Regards, Mark

[Monte Ohrt]

How often do the templates need to (re)compile? Just when you setup a new blog, or more often? It would seem that the only time you need to recompile is if a template changes, or you install a new blog, and the occasional smarty codebase update.