Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Unexpected "$smarty.block.parent"" in default modifier. #393

Closed
AnrDaemon opened this issue Oct 9, 2017 · 5 comments
Closed

"Unexpected "$smarty.block.parent"" in default modifier. #393

AnrDaemon opened this issue Oct 9, 2017 · 5 comments

Comments

@AnrDaemon
Copy link
Contributor

{block "content"}{$content|default:$smarty.block.parent}{/block}

emits

PHP Fatal error:  Uncaught  --> Smarty Compiler: Syntax error in template "file:legacy-page.tpl"  on line 10
"{block "content"}{$content|default:$smarty.block.parent}{/block}"  - Unexpected "$smarty.block.parent" <-- 
  thrown in …/sysplugins/smarty_internal_templatecompilerbase.php on line 10

There's a simple workaround, however

{block "content"}{$content|default:{$smarty.block.parent}}{/block}

but I'm not sure the original behavior is desired.

@uwetews
Copy link
Contributor

uwetews commented Oct 9, 2017

Never considered that $smarty.block.parent could be used as |default: value.
I will change hat ASAP

@AnrDaemon
Copy link
Contributor Author

Shouldn't any variable reference be acceptable as parameter value?
I've seen similar behavior with cache_id parameters of '{include}' blocks.

@AnrDaemon
Copy link
Contributor Author

And to clarify the original use case, I have the following structure:

parent.tpl

{block "content"}<div>error message</div>{/block}

child.tpl

{block "content"}{$content|default:$smarty.block.parent}{/block}

uwetews added a commit to smarty-php/smarty-phpunit that referenced this issue Oct 12, 2017
uwetews added a commit that referenced this issue Oct 12, 2017
@uwetews
Copy link
Contributor

uwetews commented Oct 12, 2017

This is now fixed in the master branch.

Can you explain the behavior with cache_id parameters of '{include}' blocks you have mentioned.

@AnrDaemon
Copy link
Contributor Author

First time I started to port my current project forward, I've tried to dynamically assign cache ids to various includes (mainly various menu blocks), but failed because it would crash on anything but a plain variable.
I'm unable to reproduce it now, and it was so long ago that it may have been fixed already.
If it would resurface anywhere, I will file a new issue.

@uwetews uwetews closed this as completed Oct 12, 2017
wisskid pushed a commit that referenced this issue Apr 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants