How do you supply a list of values to a Volt template?

I tried Phalcon Volt addExtension to extend the variables available to a Volt template run through the Volt compiler. I tested several combinations of code without success. I then tested addFunction. addFunction appears to create a PHP format string in the template. What should I try next?

The following code adds <?= \x\y::listNames() ?> to the compiled template. $this->volt->addFunction('listNames', '\x\y::listNames');

What I actially want to do is execute the function and return an array in the compiled template.

I switched to the following code. It puts the list of values in the compiled template as a list created at compile time, not execution time. $this->volt->addFunction('listNames', function () { return $this->listNames(); });

Finally I used the following line. $this->volt->addFunction('listNames', function () { return '$names = \x\y::listNames();'; }); This produced the following line in the compiled code. < ?= $names = \x\y::listNames(); ?>

edited Jun '17

Part of the problem is Volt generating short strings, < ?=, instead of < ?php. Volt generates the proper PHP wrapper for for loops but not for assignments. Is there a way to make Volt generate proper PHP wrappers.


I found a way to make the extension work. I had to look through the compiler code to find what is expected as input to addExtension and what is expected as output. The class summary page is misleading.

I found a way to get arround the short tags for the assignments. Messy but it works.

edited Jun '17

I'll be honest, whenever I try to make use of public static methods, I just use PHP code directly in the volt template. Something usually similar to this:

<?php echo Project\Namespace\Class::SomeMethod(); ?>

It works just as intented.


Hello Jak, I want to limit/prevent the use of PHP in templates. It might be ok for experienced administrators but not in templates edited by content authors.

I have the following code working to add an extension prior to compilation. The extension could be varied depending on the user editng the content.


The extension contains code similar to the following. I can then supply only what is needed and is authorrised. $abc could be the admin version or the content author version.

public function compileFunction($name, $arguments, $funcArguments)
    if ($name == 'abc')
        return '$junk ?>' . "\n"
            . '<?php $abc = new \Ab\C();';


Your mention of PHP code in templates produces the question: How do you stop people inserting PHP code in a template?

Hi Peter, I don't honestly know how to limit PHP code within the template withou building that functionality from scratch. The templates themselves compile directly into PHP and are stored in the cache, so I don't see why you would go out of your way to block PHP in the views.

That said, it sounds to me like you need to separate your areas of concern just a little more. You really should have your Controller handle this and pass it as a variables. Ideally, the view should not "compile" anything just format and fill based upon templating functions.

I suppose you could build a plugin that checks your volt files before they are compiled... your know like a strpos() looking for things like ("<?", "<?php"). That might be easiest. Unless of course someone else knows a better way.


Hello Jak, I am not using a view for the user edited templates. They are things like email templates. The editor can access what they are authorised to access. introducing PHP in the template could let them bypass the restrictions. The editors cannot access the compiled templates. The restriction on PHP would be applied on input to the compile.

I am experimenting with addExtension. I can add extra functions to Volt based on the editor's access level. The generated PHP could also check the access level for whoever uses the compiled template. For example, an editor might be authorised to see all users. the user sending the email through a template might be only able to see their connected users.

I will convert to Phalcon 3.2 then revisit the compiler controls.