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 with all HubL tags. The
widget_data dict 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 parameters available in the template context, without actually rendering the HubL tag, you can allow users to make decisions in the content editor that affect 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 possible with this parameter.
First you must add
export_to_template_context=True to the HubL tag. Then you must use a
Below are a few applications of this concept.
export_to_template_context=True is not supported in custom modules, as it serves no real purpose for them. Here's why - you do not need to use
export_to_template_context to get the value of a module within a template, you can already access it. The other aspect is visual. If you need to visually hide the module's output you could build the module to not output anything, or include a boolean field that enables or disables whether the module is renders anything.
srcparameter is retrieved with the
widget_datatag and rendered as the source of a background image in a style tag.
While this is possible to do in coded templates, generally it is better to build a custom module to give users in the page editor the best experience. HubL tags like this show up as individual fields, whereas you may have multiple related fields. Using a custom module all of its fields display grouped in the page editor.
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 department via the UI and the heading changes without the user having to actually edit content.
This same functionality can actually be reproduced using a choice field inside of a custom module. The custom module UI actually makes choice options with both a value and a label pretty easy.
If you want to retrieve a parameter from a module or tag that is already rendering on a page, the module can be accessed within a dict named
export_to_template_context parameter is not required. The syntax is as follows:
content.widgetswon't access global modules.
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 your 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
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.
Thank you for your feedback, it means a lot to us.