only {content} tag support from v2.2.0?

[creopard]

Hello there,

in my templates, I've used logic like:

Code: Select all

{$content|replace:'<img ':'<img loading="lazy" '}

as

Code: Select all

{content|replace:'<img ':'<img loading="lazy" '}

would not work.

This works great so far.
However, after updating to CMSMS v2.2.0 the code with {$content} makes the whole (primary) content block dissapear when I try to edit a page in the "content manager" in the admin section.

When i replace {$content} by {content} in the template (design manager), the content block will again show up while editing content pages.

Any suggestion on how to (still) support the {$content} syntax?

[Jo Morg]

Do you have any errors or warnings in either PHP error log or even admin log of CMSMS?
There has been some reports of a different behavior of the {content ...} block with inherited templates and we are investigating the issue. It looks like a Smarty change but it may also be at the CMSMS parser level too. I haven't been able to consistently reproduce it yet.

[creopard]

Sorry, no error messages at all, the whole <div> content block (+textarea) in the default admin theme is just missing:

Code: Select all

<div class="pageoverflow">
<p class="pagetext">...
<p class="pageinput">...

when using {$content} instead of {content}

[Jo Morg]

If you have any possibility send me (via PM if you will) a test case. I'll try to reproduce it, thx.

[creopard]

I do have a test case, e.g. CMSMS "playground".
-> PM

[creopard]

While setting up a test environment for reproducing the issue, I accidentaly found a workaround:

My setup has a header template "html-head" starting with:

Code: Select all

{strip}{process_pagedata}
{$content = "{content}" scope=global} ...

to make the {$content} variable everywhere.

The main template includes this header like this:

Code: Select all

{include|strip file='cms_template:html-head'}{strip}

/*...here comes a lot of html ...*/

{$content|replace:'<img ':'<img loading="lazy" '}

using that approach, the {$content} will be displayed in the frontend, but as already stated the, content textblock is then completely missing in the Content Manager starting from CMSMS v2.2.0. (It was working flawlessly with v2.2.19)


Solution/Workaround:

When I shift the assignment of the {$content} Smarty variable from the header template "html-head" directly to the main template like this:

Code: Select all

{include|strip file='cms_template:html-head'}{strip}

/*...here comes a lot of html ...*/

{$content2 = "{content}" scope=global}
{$content2}

(I named the variable "$content2" on purpose, as I kept the original "$content" in the header template "html-head")

This way there is no issue at all and the content textblock gets displayed as usually in the Content Manager.

I guess there might be an issue with the "global" scope?
Also the permissive Smarty setting is in place:

Code: Select all

$config['permissive_smarty'] = true;

[Jo Morg]

I guess there might be an issue with the "global" scope?

Possibly, thanks for sharing! We'll dig a bit more in the meantime.
Thx again!

[creopard]

one more thing:

if you keep the Smarty assignment coding

Code: Select all

{$content = "{content}" scope=global}

in the template header also breaks the search results template (even if {$content} isn't used anywhere later on).

The search results will be completely empty (no PHP errors at all) unless you remove the coding line again.

[creopard]

Without the possibility to assign {content} to another Smarty variable anymore, solutions such as auto-metatags
https://cmscanbesimple.org/blog/base-cm ... d-metatags

also won't work anymore.

[creopard]

For making auto-metatags work again and keep the global search functional, I found a workaround:
(i.e. avoiding to access the {content} directly)

replace

Code: Select all

{$content = "{content}" scope=global}
{$page_description = $page_description|default:$content|strip_tags:false|strip|trim|truncate:300|default:'' scope=global}

with

Code: Select all

{$loc_page_desc = {page_attr key=content_en}}
{$page_description = $page_description|default:$loc_page_desc|strip_tags:false|strip|trim|truncate:300|default:'' scope=global}

It seems that messing/assigning around with {content} in the header section (aka "Area 1" section) in any way, it will break the global search functionality.