Parameter „export_to_template_context“
export_to_template_context
ist ein Parameter, der die Parameter eines HubL-Tags für die Vorlagenumgebung verfügbar macht, ohne dass das HubL-Tag tatsächlich gerendert wird. Dieser Parameter kann mit allen HubL-Tags verwendet werden. Das widget_data
-Dictionary wird verwendet, um diese Parameter abzurufen, sie in Variablen zu speichern und/oder sie in die Logik Ihrer Vorlage einzubinden.
Indem Sie die Parameter eines HubL-Tags im Vorlagenkontext verfügbar machen, ohne dass das HubL-Tag tatsächlich gerendert wird, können Sie den Benutzern die Möglichkeit geben, im Content-Editor Entscheidungen zu treffen, die sich auf die Darstellung der Vorlage auswirken. Angenommen, Sie möchten einen bestimmten Code-Block nur dann darstellen, wenn der Benutzer einen Wert in ein Feld eingibt. Dies ist mit diesem Parameter möglich.
Zuerst müssen Sie export_to_template_context=True
zum HubL-Tag hinzufügen. Dann müssen Sie einen widget_data.module.parameter_you_want_to_retreive
verwenden.
Im Folgenden finden Sie einige Anwendungen dieses Konzepts.
export_to_template_context=True
wird in benutzerdefinierten Modulen nicht unterstützt, da es für diese keinen wirklichen Zweck erfüllt. Das hat folgenden Grund: Sie müssen export_to_template_context
nicht verwenden, um den Wert eines Moduls in einer Vorlage abzurufen. Sie können bereits darauf zugreifen. Der andere Aspekt ist visueller Natur. Wenn Sie die Ausgabe des Moduls optisch ausblenden müssen, können Sie das Modul so erstellen, dass es nichts ausgibt, oder ein boolesches Feld einschließen, über das aktiviert oder deaktiviert wird, ob das Modul etwas ausgibt.
src
-Parameter wird mit dem widget_data
-Tag abgerufen und als Quelle eines Hintergrundbildes in einem style-Tag wiedergegeben.Dies ist zwar in Code-Vorlagen möglich, aber im Allgemeinen ist es besser, ein benutzerdefiniertes Modul zu erstellen, um den Benutzern im Seiten-Editor das beste Erlebnis zu bieten. HubL-Tags wie diese werden als einzelne Felder angezeigt, während Sie mehrere verwandte Felder haben können. Bei Verwendung eines benutzerdefinierten Moduls werden alle seine Felder im Seiten-Editor gruppiert angezeigt.
Das folgende Beispiel verwendet den Parameter export_to_template_context
in Verbindung mit einem Auswahlmodul, um eine Bannernachricht auf einer Karriereseite zu ändern. Der Benutzer wählt über die Benutzeroberfläche eine Abteilung aus und die Überschrift ändert sich, ohne dass der Benutzer den Inhalt tatsächlich bearbeiten muss.
Die gleiche Funktionalität kann mit einem Auswahlfeld innerhalb eines benutzerdefinierten Moduls reproduziert werden. Die Benutzeroberfläche des benutzerdefinierten Moduls macht die Auswahl von Optionen mit einem Wert und einem Label ziemlich einfach.
Wenn Sie einen Parameter von einem Modul oder Tag abrufen möchten, das bereits auf einer Seite gerendert wird, kann das Modul in einem Dictionary mit dem Namen widgets
aufgerufen werden. Der Parameter export_to_template_context
ist nicht erforderlich. Die Syntax lautet wie folgt:
Da verschiedene Felder Daten in unterschiedlichen Formaten speichern, ist es oft praktisch, Entwicklerinfo zu nutzen, um zu sehen, wie Sie auf die spezifischen Daten zugreifen, die Sie anzeigen möchten.
Blog-Vorlagen werden in der Regel für Blogs verwendet, können aber auch zum Erstellen verschiedener anderer Typen von Listings wiederverwertet werden. Dazu können Sie die oben beschriebenen Techniken anwenden.
Sie möchten zum Beispiel ein Listing-Layout mit Pressemitteilungen erstellen, die Ihr Unternehmen erhalten hat. Dabei soll über das Listing aber nicht zu Beiträgen verlinkt werden, sondern zu einer anderen Seite.
Sie können dieses Konzept unter academy.hubspot.com/projects in Aktion sehen. Die Listing-Seite für Projekte ist eine Blog-Listing-Vorlage, aber jeder Beitrag verlinkt zu einer regulären HubSpot-Seite. Der Content-Autor gibt den Ziel-Link im Editor an.
Im Header des Codes des einzelnen Blog-Beitrags definieren Sie ein Textfeld. Wenn Sie nicht möchten, dass der Text im Beitrag dargestellt wird, verwenden Sie export_to_template_context
.
Dieses Textfeld kann in jedem Blog-Beitrag bearbeitet werden. Als Nächstes müssen wir einen Link in unserem Listing definieren. Da die Widget-Daten jedoch nur im Kontext des Beitrags vorhanden sind, müssen wir eine andere Syntax verwenden, um die Widget-Daten abzurufen und den Link auszufüllen. In diesem Fall verwenden wir content.widgets.custom_blog_link.body.value
. Während die widget_data
für das Blog-Listing nicht verfügbar sind, wird der Wert dieses Feldes weiterhin im Kontext der Widgets der einzelnen Inhalte gespeichert.
Nachfolgend sehen Sie eine einfache Blog-Listing-Schleife, die diesen benutzerdefinierten Link bei jedem Beitrag darstellt. Wenn Sie dieses Verfahren anwenden, sollten Sie sicherstellen, dass Sie das Unterverzeichnis, das automatisch für jeden Blog-Beitrag erstellt wird, zu Ihrer robots.txt-Datei hinzufügen, um zu verhindern, dass diese leeren Beiträge von Google und anderen Crawlern gecrawlt werden.
Vielen Dank, dass Sie Ihr Feedback mit uns geteilt haben.