HubL Reference

Table of contents
Close

export_to_template_context

export_to_template_context is a parameter that makes a HubL tag's parameters available to the template environment without actually rendering the HubL tag. This parameter can be used all HubL tags. The widget_data tag is used to retrieve these parameters, store them in variables, and/or incorporate them into your template's logic.

By making a HubL tag's parameter's available in the template context, without actually rendering the HubL tag, you can allow users to make decisions in the content editor that effect how the template renders. For example, let's say that you want to only render a certain code block, when the user gives a value to a field. This becomes is possible with this parameter.

First you must add export_to_template_context=True to theHubL tag. Then you must use a widget_data.module.parameter_you_want_to_retreive.


{% text "hubl_tag_name" label="Enter some text here", value="Default text to print", export_to_template_context=True %} 
{# Makes the parameters available to be stored and used in template logic #}

{{ widget_data.hubl_tag_name.parameter }} 
{# Prints the value of the HubL tag but can also be used in template logic #}


Below are a few applications of this concept.

Usage within custom modules

export_to_template_context=True is no longer supported in custom modules as the new module framework supports all HubL fields applicable.

User selectable background images

In this example, an image HubL tag is created, but then exported to the context of the template rather than rendered. The src parameter is retrieved with the widget_data tag, and render as the source of a background image in a style tag. This technique is applied on the homepage of Developers.HubSpot.com.
HubSpot Help article screenshot

{% image "background_image" label='Select a background image', 
src='http://cdn2.hubspot.net/hub/428357/file-2117441560-jpg/img/dev-bg-compressed.jpg', 
export_to_template_context=True %}
       
  
<!--Sample markup -->
<div class="bg-image-section" style="background:url('{{ widget_data.background_image.src }}'); background-size:cover; min-height: 500px;">
    <h1>Supercharge your app with HubSpot</h1>
    <h3>Build powerful integrations for a global community of users</h3>
</div>  
        
    

Choice field to render pre-defined markup

The following example uses the export_to_template_context parameter in conjunction with a choice module to change a banner message on a careers page. The user selects a departmet via the UI and the heading changes without the user having to actually edit content.


{% choice "department" label='Choose department', value='Marketing', choices='Marketing, Sales, Dev, Services' export_to_template_context=True %}
        
{% if widget_data.department.value == 'Marketing' %}

<h3>Want to join our amazing Marketing team?!</h3>
<h4>We have exciting career opportunities on the {{ widget_data.department.value }} team.</h4>

{% elif widget_data.department.value == 'Sales' %}

<h3>Are you a Sales superstar?</h3>
<h4>We have exciting career opportunities on the {{ widget_data.department.value }} team.</h4>        
        
{% elif widget_data.department.value == 'Dev' %}
        
<h3>Do you love to ship code?</h3>
<h4>We have exciting career opportunities on the {{ widget_data.department.value }} team.</h4>
        
{% else %}
        
<h3>Want to work with our awesome customers?</h3>
<h4>We have exciting career opportunities on the {{ widget_data.department.value }} team.</h4>
        
{% endif %}      
    

Retrieving params from modules that already render on template

If you want to retrieve a parameter from a module that is already rendering on a page, the module can be accessed within a dict named widgets. The export_to_template_context parameter is not required. The syntax is as follows:


{{ content.widgets.name_of_module.body.parameter }}

{{ content.widgets.my_text.body.value }}

Printing HubL module info on blog listing

While blog templates are generally used for blogs, they can also be repurposed to create various other types of listings. You can use the techniques described above to achieve this.

For example, you may want to create a listing layout of press that you company has received, but rather than linking to posts, you want the listing to link to another page.

You can see this concept in action at academy.hubspot.com/projects. The projects listing page is a blog listing template, but each post links to a regular HubSpot page. The content creator specifies the destination link in the editor.

Within the head of the individual blog post's code, you would define a text field. If you don't want  the text to render on the post, you would use export_to_template_context.


{% text "custom_blog_link" label="Link to external press item", export_to_template_context=True %}

This text field is editable in each blog post. Next, we would need to define a link in our listing. But because the widget_data only exists in the context of the post, we need to use different syntax to fetch the widget data to populate the link. In this case, we would use content.widgets.custom_blog_link.body.value. While the widget_data is not available to the blog listing, the value of that field is still stored within the context of the individual content's widgets.

A basic blog listing loop that renders this custom link with each post is shown below. If using this technique, you would want to ensure that you add the subdirectory automatically created for each blog post to your robots.txt file to prevent those empty posts from being crawled by Google and other crawlers.


{% for content in contents %}
<a href="{{ content.widgets.custom_blog_link.body.value }}">
    Click here to see this press feature!
</a>
{% endfor %}