What I’m trying to do is render some HTML that is stored in HubDB. The tutorial I linked to says that I should be able to pull data from HubDB into a drag and drop template, or a coded email template.
If I use this code, the HTML tags are escaped when the email renders, resulting in the code being displayed as plain text:
{% set template = hubdb_table_rows(1234567, "email_name=welcome&site_domain="~contact.site_domain) %}
{{ template[0].html }}
However, when I specify the full query without using any contact properties, the HTML is not escaped and is rendered directly within the email template as expected:
{% set template = hubdb_table_rows(1234567, "email_name=welcome&site_domain=https://www.sitename.com") %}
{{ template[0].html }}
I see no reason why we should expect this to render the output differently depending on how the query is structured.This has to be a bug, right?
There is a section in there about using HTML from within the contact properties, which I figured would probably affect HubDB in the same way:
HTML that is included in a contact property will be escaped and rendered as a string instead of HTML. This is due to escaping being enabled by default within the new renderer. To render HTML in contact properties use the safe filter
{{ contact.property_with_html | safe }}
For anyone else who stumbles across this issue, using the 'safe' filter will allow your HTML to render, however any HubL code within that HTML will no longer work.
For me this is still a nuisance, as simply hard-coduing the HubDB query would allow both my HTML and HubL to render properly, but unfortunately that isn't an option, so I'm left to choose between HTML or HubL. I hope this is remedied soon.
Update 2: HubL code does actually render in test emails, just not in previews. This is effectively solved!
@MiaSrebrnjak, There's some critial information in the document provided to @ESmith77. I'm surprised there isn't a reference to these limitations in any of the docs. Can you have the appropiate team update the docs with the limitations?
The document was extremely helpful. Had issues with "Reusing variable names for results of HubDB or Custom Objects queries." Wish I had found it 2 hours ago?
Seriously. I was stuck for a couple of days on this issue and I had it solved within a minute of looking at that doc. I've also asked them to sort out their documentation. This is a common issue with Hubspot: Incomplete, vague, or inaccurate documentation.
Same here! Strugling with stange behavior that all makes sense now after looking at that document. From my testing, if you are using contact properties in your logic you can't use more than a single instance of a custom module. Even different custom modules that share a common field name results in the second module field showing the value from the first module. Having to re-think the entire setup.
FYI, I did figure out how to get a decent preview without HUBL code. This snippet allows you to add a block with static/default content to show in the editor and default preview.
{% if (is_in_previewer and !buffer_mode.isPreProcessedTemplate) or is_in_editor %}
preview content
{% else %}
contact preview and live send content
{% endif %}
There is a section in there about using HTML from within the contact properties, which I figured would probably affect HubDB in the same way:
HTML that is included in a contact property will be escaped and rendered as a string instead of HTML. This is due to escaping being enabled by default within the new renderer. To render HTML in contact properties use the safe filter
{{ contact.property_with_html | safe }}
For anyone else who stumbles across this issue, using the 'safe' filter will allow your HTML to render, however any HubL code within that HTML will no longer work.
For me this is still a nuisance, as simply hard-coduing the HubDB query would allow both my HTML and HubL to render properly, but unfortunately that isn't an option, so I'm left to choose between HTML or HubL. I hope this is remedied soon.
Update 2: HubL code does actually render in test emails, just not in previews. This is effectively solved!
Thank you for sharing @ESmith77! This is very helpful!
I realize that this isn't a solution for your specific use case, but I'll still go ahead and accept your answer as a solution, as this increases the visibility of your post in the Community and reaches more users who might be experiencing a similar issue.
I hope that's okay! If you'd prefer to leave this unsolved, please let me know!