Block tag not working in template

[Timberline]

Running version 1.11.10, I have (among others) a trivially defined block tag that works as expected when inserted into a content page.

When I try to put the simplest possible invocation of it into a layout template, the editor reports a compile error ending with "unexpected closing tag."

Is this an intended behavior, a known bug, or something I'm doing wrong or failing to grasp?

The invocation is {zz2Echo}abcde{/zz2Echo}, which normally outputs "(++ abcde ++)".

The function is:

Code: Select all

<?php
function smarty_block_zz2Echo($params, $content, &$smarty, &$repeat)
{
  if(!$repeat):
  	return "(++ $content ++)";
  endif;
}
?>

in file block.zz2Echo.php in the plugins directory.

[Jo Morg]

I just tested on 1.11.11 and works for me:
I created a new file called block.zz2Echo.php in the plugins directory, and pasted the code on your post; pasted {zz2Echo}abcde{/zz2Echo} on a page, and it resulted in (++ abcde ++) being rendered...
So something else may be interfering. Try clearing CMSMS cache.
HTH

[Timberline]

You pasted directly to a content page or you put it in the layout template used by that page? I only have trouble putting it in the layout template.

I'll also try upgrading 1.11.10 to 1.11.11 as there seems to be a diff download for that.

[Jo Morg]

I only have trouble putting it in the layout template.

Mmm... ok, I could reproduce that.
Confirmed in 1.11.11.
I'll do some more tests, and get back to this thread asap.

[Timberline]

Thanks so much. I'll watch this thread for developments.

Obviously it's a powerful and useful feature. Being smarty-based and especially the versatility of smarty's open-close tagging paradigm were decisive in persuading me to migrate my project to CMSMS.

[calguy1000]

It appears to be a smarty issue with the actual name of the block plugin.
renaming the block plugin to something that does not start with zz2 works just fine.

[Timberline]

It appears to be a smarty issue with the actual name of the block plugin.
renaming the block plugin to something that does not start with zz2 works just fine.

What name are you using? When I change it to "abcqrs" I still get the same behavior as long as the block actually exists: it works in page content but not in a layout template -- not even a new and trivial layout template like:

Code: Select all

{abcqrs}abcde{/abcqrs}
{content}

However, the template editor happily accepts a non-existent block tag. Change "abcqrs" to "asdfdas" without creating the plugin to support it, and you can save the template without error.

In fact, I can trick the layout template editor into accepting the tag by deleting the tag from the plugins directory, clearing the cache, saving the template, restoring the tag to the plugins directory, and running the page as a user. The page displays correctly, although with warnings and notices to the error log.

But then, as you might suspect, saving (or trying to edit?) a page using that template gives a white-screen error.

I've tried returning nothing, TRUE, FALSE, empty-string, and 'a' from the opening tag, all without success.

That's all after upgrading to 1.11.11 now.

Are we really running identical systems or is it possible you have a newer version of of Smarty in your 1.11.11 testbed? My smarty.version shows Smarty-3.1.16

But if it's only a Smarty bug, it seems a bit odd for it to be context-dependent within CMSMS. Yet none of the CMSMS-provided tags are of block type; could it really be possible that nobody has tried to use a block tag in a layout template until now? That also seems improbable.

[Jo Morg]

could it really be possible that nobody has tried to use a block tag in a layout template until now?

No, I use them in more than a few occasions and even have some block plugins of my own. Renaming didn't work for me either (tried myEco) for instance, and failed when saving the template, although for some reason it seemed to work once... It seems to have something to do with template parsing just before saving, but didn't have time to test any further yet.
I'm not sure why it seems to work on calguy1000's tests though...