Date: 2016-05-09 15:08
Posted By: Robert Campbell (calguy1000)

the smarty {block} tag is not the same as a content block.  i.e: the block
argument on the {content}, {content_image} and {content_module} plugins.

CMSMS checks to make sure that no content block is defined multiple times as in
the past people would use {content} multiple times within a template and have
strange or confusing results.   or multiple edit areas.

CMSMS has no way of knowing during template processing if a block is being
overridden or if it is just a simple user error. Therefore it is better for the
users to force them to explicitly use assignment of the output of the plugin
than to try to intelligently guess what they are trying to do.

In your drived template you should be able to use {content_image block='bar2'} 
however you would still see the edit area for {content block='bar'} in the edit
content form, but it would not be displayed.
      

Date: 2016-05-09 17:35
Posted By: Ludger Merkens (lume)

I am well aware of the difference between {block} and {content
block='blockname'} I should have written my post a little more concise when
addressing the different concepts. And yes of course, you can add a differently
named content-block in a derived template.
If you use 
{block name='foo' append}
   {content_image block='bar2'}
{/block}
you can even use both content-blocks inside your template. 

So If I write 'block' in this post - I mean the smarty 3 construct {block},
where a content-block means something that holds data for a cmsms template. In
other words - something that can be defined via {content}, {content_image},
{content_module} etc. (Or something I can retrieve via the smarty plugin
{page_attr key='content-block-name'} or even
{$content_obj->GetPropertyValue('content-block-name')}

What I try to accomplish - and where the current template processing of cmsms
seems to run into some limits - is actually the redefenition of a content-block
in a derived template.
As a mere sidenote I give you my scenario where this redefinition would actualle
be a feature.

[sidenote]
I want to create a complex {Navigator} template, that can handle different ways
to embed a child page. (Accordingly to a commen content-block (a shared name for
all templates)) The value of this content-block indicates the way how to present
the node, the page template limits the possible values by providing template
specific dropdown selectors like

{content_module module='ECB2' field='dropdown' values='list of possible values'
assign='plonk'}
(I don't want the value to show in the output of the template at all)

Thats the part, where I want to exchange the content-block definition, because
not all presentation modes make sense for all page templates in the family of
templates. The navigator template would look something like:

{foreach $data as $node}
   {page_attr key='pmode' page=$node->alias}
   {if $pmode=='a'}<div>some html fragment here</div>
   {elseif $pmode=='b'}<div>some alternative implementation</div>
   {elseif $pmode=='c'}<div>and so on and so on</div>
   {/if}
{/foreach}

[sidenode end]

If conent-blocks would be handled like normal smarty code, there actually is no
guesswork left during template processing.
::: cms_template:base :::
Hello
{block name='foo'}
world
{/block}
... some more code especially a call to {content} ....

::: cms_template:derived :::
{extends file='cms_template:base'}
{block name='foo'}
my friend
{/block}

would render "Hello world" for the 'base' template, but "Hello my friend" for
the derived template. 'world' never appears in the second output. While I
applaud for the checking of duplicate content-blocks - in this scenario, there
actually should be no duplicate content-block involved.

I didn't check for the template processing details in 'backend-mode', but I
assume this will not be a trivial "fix". Perhaps a parameter overwrite=true
passed to the {content_xxx} plugins to indicate 'i know what I'm doing' to the
processor, is an easier fix.

thanks for reading this long comment
---Ludger

      

Date: 2016-05-09 18:49
Posted By: Robert Campbell (calguy1000)

We will investigate changing this behaviour for CMSMS 2.2.