XF 2.2 Render anonymous template

Hi, there!
We're developing a portal to our forum. In this system, admins can create dynamically theirs columns using the XF template syntax or an existing template.
Here's a simple example:
onMKLKJ.png

Note: The Código field is saved to the database as a varchar.
Glossary (PT-BR to EN):
Conteúdo da Coluna = Column Content
Tipo de conteúdo = Content type
Código puro = Raw code
Código = Code

When the system calls the columns to load on the page, using {$column.content_raw|raw}, the result comes like this:
MNRtJSf.png

At this point okay, because XF templates are rendered by a template data that was retrieved from the xf_template table (not considering the work done by template modifications, obviously) on the backend. So it cannot render the string.
I know that you can render a template on the backend using the renderTemplate() method from the XF\Template\Templater class, but you need to pass as an argument the template name. In this case, the raw code does not belong to any template, it's just a XF template code block that needs to be rendered to HTML.


Is there a possibility to render template codes passing a string and the system parse it to a HTML content?
Example:
PHP:
$content = '<xf:avatar user="{$xf.visitor}" size="m" canonical="true" />';
$html = someFunctionToRenderTemplateCode($content); // Is this possible in XF?

If it's not possible, is there a security reason that does not allow to do this?

We're using XF 2.2.4.
 
Solution
If it's not possible, is there a security reason that does not allow to do this?

We're using XF 2.2.4.
I suspect it's not a security issue so much as a performance issue. Parsing templates on a per request basis is definitely less than ideal. Templates are pre-parsed (turned into PHP code), then saved to the templates directory as PHP files. Not only do you normally not parse the template with each request, you also have the added bonus of PHP being able to use it's internal OPcache where PHP doesn't need compile each PHP script on a per request basis (it's compiled just when the file changes and stored in-memory as bytecode).

You may want to consider rethinking how your portal system works. The UI could still be the same...
@AndyB Thanks for replying!
This thread is about BBCodes. In this case, we're talking about, literally, templates syntax. BBCodes are used only for posts. We need to find a method that makes the same but with template syntax.
Despite that, I have tried to use the render() method but it didn't work 🙁

Once again, thanks for your attention 🙂
 
If it's not possible, is there a security reason that does not allow to do this?

We're using XF 2.2.4.
I suspect it's not a security issue so much as a performance issue. Parsing templates on a per request basis is definitely less than ideal. Templates are pre-parsed (turned into PHP code), then saved to the templates directory as PHP files. Not only do you normally not parse the template with each request, you also have the added bonus of PHP being able to use it's internal OPcache where PHP doesn't need compile each PHP script on a per request basis (it's compiled just when the file changes and stored in-memory as bytecode).

You may want to consider rethinking how your portal system works. The UI could still be the same, but when the template code is saved, have it also save it as a template (if you are using entities, use the _postSave() method for that entity). Check the XF\Entity\HelpPage.php, as that's how it works... when you create a help page (and you can have an infinite number of them), it internally created a template that is prefixed with _help_page_.

If you go that route, you will make your site faster (the templates only need to be parsed/turned into PHP when they are changed, not every time they are viewed), and you will also be able to leverage PHP's OPcache system. As a bonus, it also solves your underlying problem (you can just call the template normally by the template name rather than trying to do it with an arbitrary string of template info).
 
Solution
I suspect it's not a security issue so much as a performance issue. Parsing templates on a per request basis is definitely less than ideal. Templates are pre-parsed (turned into PHP code), then saved to the templates directory as PHP files. Not only do you normally not parse the template with each request, you also have the added bonus of PHP being able to use it's internal OPcache where PHP doesn't need compile each PHP script on a per request basis (it's compiled just when the file changes and stored in-memory as bytecode).

You may want to consider rethinking how your portal system works. The UI could still be the same, but when the template code is saved, have it also save it as a template (if you are using entities, use the _postSave() method for that entity). Check the XF\Entity\HelpPage.php, as that's how it works... when you create a help page (and you can have an infinite number of them), it internally created a template that is prefixed with _help_page_.

If you go that route, you will make your site faster (the templates only need to be parsed/turned into PHP when they are changed, not every time they are viewed), and you will also be able to leverage PHP's OPcache system. As a bonus, it also solves your underlying problem (you can just call the template normally by the template name rather than trying to do it with an arbitrary string of template info).
Excellent solution!
I didn't thought that way. It could be so much better than try to render a code during the controller action.

Thanks for clarifying this context! :D
 
Top Bottom