In PHP 5.6
Volt:
partial("email/tag_open", {'type': 'p'}) - $type is local var
{{ type }} - not set
partial("email/tag_open", {}) - $type inside - not set
In PHP 7
Volt:
partial("email/tag_open", {'type': 'p'}) - $type is global var
{{ type }} - last state set
partial("email/tag_open", {}) - $type inside - last state set
PHP 5 allowed us to create intermediate symbol tables per render, in php7 that is not possible, we have to research more about it.
I would like to suggest this fixing ASAP, as this is braking all the partial system in the views. (quite important thing)
This happens only on php7, as @andresgutierrez described, thought - php5 (with phalcon 3) is all good.
Also it is happening with .phtml, not only with Volt.
It's also driving the loop context crazy :
{% for d in data %}
{{ dump(loop.first) }} // true
// there is a {% for t in tags %} inside it
{% include "header" with ['active': loop.first, 'tags': d.tags] %}
{{ dump(active) }} // true
{{ dump(loop.first) }} // false
{% endfor %}
some news about it? someone knows when it will be fixed? what branch ? or date? i've identified this problem in phalcon 3.0.0, but now i'm migrating to phalcon 3.0.3!
Im guessing if someone would know then he would do PR with fix. We have to wait until @andresgutierrez will do something about this.
Can confirm this is still a problem, particularly the loop context that @challet referenced. I can put together a test case if needed, as this is causing me headaches.
Can confirm as now. (23.11.2017). Due to this issue cannot upgrade two of my projects to php 7+ :( Same behavior is with .phtml, so @sergeyklay Volt label can be removed, as it's affecting all kind of views.
I'll try to sort out
Can we get a status update regarding this issue? Is it being addressed and if so, when might we expect to see the fix?
Thank you for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please feel free to either reopen this issue or open a new one. We will be more than happy to look at it again! You can read more here: https://blog.phalconphp.com/post/github-closing-old-issues
With Phalcon 4 dropping PHP5 support, I believe this issue is becoming even more important. Is there any way one could possibly help to move this along?
Since this issue has not been fixed, I don't think it should have been closed by Mr. Stale Bot...
As the bug fixing can take some time, here is my workaround in the hope it helps someone: extend \Phalcon\Mvc\View\Engine\Volt and use it instead of the original class when creating voltService:
namespace My\Fix;
/*
* This class is a workaround for a bug in zephir
* Remove it when the bug is fixed, see https://github.com/phalcon/zephir/issues/1621
*/
class Volt extends \Phalcon\Mvc\View\Engine\Volt
{
public function render($templatePath, $_params__, $_mustClean__ = false)
{
if ($_mustClean__) {
ob_clean();
}
$compiler = $this->getCompiler();
$compiler->compile($templatePath);
$_compiledTemplatePath_ = $compiler->getCompiledTemplatePath();
unset($compiler);
unset($templatePath);
if (is_array($_params__)) {
foreach ($_params__ as $_key_ => $_value_) {
$$_key_ = $_value_;
}
}
require $_compiledTemplatePath_;
if ($_mustClean__) {
$this->_view->setContent(ob_get_contents());
}
}
}
The idea behind the fix is simple - I've just "copy-pasted" code from the zephir sources of the Volt class to PHP - in PHP it works as expected.
When the bux gets fixed simply replace \My\Fix\Volt with \Phalcon\Mvc\View\Engine\Volt and delete this class.
Thank you for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please feel free to either reopen this issue or open a new one. We will be more than happy to look at it again! You can read more here: https://blog.phalconphp.com/post/github-closing-old-issues
As I commented when Mr. Stale Bit attempted to close this issue last time, since this issue has not been fixed, I don't think it should have been closed by Mr. Stale Bot...
And with that said, when might we expect this issue to be addressed?
Thank you @kgrammer
As for when, not sure. I have a few issues I need to check first for this week and I will check this out soon. I have to identify first where it comes from and whether we need to make changes to Zephir.
Unfortunately, @niden I have the same problem. #13551
@niden, any news?
@yesworld Sorry I haven't had time to check this out. I will try but it won't be until the end of next week till I have some free time.
Thanks @zacek that's a great little work-around until this issue is resolved!
Thanks to latest fixes to zephir I guess this will be soon fixed.
I hope we managed to sort out with this issue finally here https://github.com/phalcon/cphalcon/pull/13606. All necessary changes are already in the appropriate branch. We will try to release the next version in the coming days. Thank you for your patience, the report, and for helping us make Phalcon better.
Most helpful comment
As the bug fixing can take some time, here is my workaround in the hope it helps someone: extend
\Phalcon\Mvc\View\Engine\Voltand use it instead of the original class when creating voltService:The idea behind the fix is simple - I've just "copy-pasted" code from the zephir sources of the
Voltclass to PHP - in PHP it works as expected.When the bux gets fixed simply replace
\My\Fix\Voltwith\Phalcon\Mvc\View\Engine\Voltand delete this class.