Modulanforderungen für den HubSpot-Marketplace für Vorlagen

Last updated:

Hier erfahren Sie mehr über die Anforderungen, die beim Einreichen eines Moduls für den HubSpot-Marketplace für Vorlagen erfüllt sein müssen. Diese Anforderungen gelten sowohl für Module in einem Design als auch für unabhängige Module. 

Modulbeschränkungen

Module dürfen Folgendes nicht enthalten: HubDB, Aufrufe von serverlosen Funktionen oder das CRM-Objektfeld.

Die folgenden Modultypen sollten nicht als eigenständige Module gebaut werden

  • HTML
  • Module in voller Breite
  • Formulare und mehrstufige Formulare
  • Abstandshalter-Module oder Module, die eine Gliederung Ihrer Seite ohne UI erstellen
  • Module, die die Standardmodulfunktionalität duplizieren
  • Handelsspezifische Module

Modul-Content

Erfahren Sie mehr über die Anforderungen für Modul-Label und Hilfetext, Felder und Standard-Content.

Modullabel und Hilfetext

  • Die Module müssen aussagekräftige Label haben, die den Zweck des Moduls vermitteln. Das Label Hero-Banner mit Parallax Scrolling ist beschreibend, die Label Hero-Banner und Galerie dagegen nicht.
  • Modul-Label dürfen keine Zahlen enthalten, z. B. Hero-Banner 01.
  • Modul-Label dürfen keine Abkürzungen enthalten, z. B. Sp anstelle von Spalte.
  • Module müssen Inline-Hilfetext enthalten (sofern zutreffend), um die Verwendung des Moduls weiterzuleiten.
  • Das Modul darf nicht nach einem Standardmodul benannt werden.

Standard-Content

  • Das Standardfeld darf keinen Lorem ipsum-Text enthalten. 
  • Der Standardinhalt für ein Feld sollte Auskunft über dessen Zweck geben:
    • Beim Einfügen von Menüfeldern müssen Module als Standardinhaltsoption Menü auswählen verwenden.
    • Beim Einfügen von Formularfeldern müssen Module als Standardinhaltsoption Formular auswählen verwenden.
    • Beim Einfügen von Blog-Auswahlfeldern müssen Module als Standardinhaltsoption Blog auswählen verwenden.
  • Wenn das Hinzufügen von Standard-Content zu einem Modul keinen Sinn ergibt, verwenden Sie stattdessen einen Modul-Platzhalter, um dem Content-Autor zu helfen, den Bereich zu visualisieren, den er mit Inhalten füllt.

Modulsymbole

Module müssen ein benutzerdefiniertes Symbol enthalten, das dem Modul zugewiesen ist (und das Standardsymbol ersetzt). Verwenden Sie keine Unternehmenslogos als Symbole, z. B. Apple- oder Amazon-Logos. Erfahren Sie mehr über Modulsymbole.

Modulfelder

Überprüfen Sie unten die spezifischen Anforderungen für Module in einem Design und unabhängige Module
  • Module in einem Design:
    • Müssen Inline-Hilfetext und spezifische Standardinhalte für bestimmte Felder enthalten.
    • Ein Teil der Farb- und Logofelder des Designs muss von den Markeneinstellungen des Accounts übernommen werden:
      • Mindestens drei Farbfelder müssen Farben aus den Markeneinstellungen des Accounts erben. Zusätzliche Farbfelder können standardmäßig auf andere Farben festgelegt werden, einschließlich Schwarz und Weiß.
      • Mindestens ein Logofeld muss von den Markeneinstellungen des Accounts erben. Wenn Sie ein Bildfeld zum Rendern eines Logos verwenden, muss das Bildfeld nicht von den Markeneinstellungen erben. 
  • Module in einem Design und unabhängige Module:
    • Modulfeldnamen sollten den Zweck des Feldes beschreiben. Wenn beispielsweise ein Textfeld die Jobbezeichnung einer Person enthalten soll, wäre Jobbezeichnung eine passende Beschreibung, Bezeichnung jedoch nicht.
    • Alle Standardmodule von HubSpot müssen formatiert sein und in allen eingereichten Vorlagen korrekt angezeigt werden.

fields.json- und module.html-Konfiguration

Um eine kompatible Funktionalität zwischen Designs und unabhängigen Modulen zu gewährleisten, müssen Module die Farb- und Schriftfelder erben, entweder durch die Definition von default_value_path oder property_value_paths oder durch die Definition beider Felder in der entsprechenden fields.json-Datei sowie durch Hinzufügen einer Referenz auf die Designfelder in der module.html-Datei. Erfahren Sie mehr über diese Anforderungen.

Modulcodequalität

Module müssen eigenständig sein.

Designmodule

Alle für Ihr Designmodul erforderlichen Dateien, wie CSS oder JavaScript, müssen im Designordner und im Designverzeichnis enthalten sein. Sie können die Funktion „Verknüpfte Dateien“ im Design-Manager verwenden. Wahlweise können Sie die Dateien mit den Funktionen require_js() oder require_css() mit einem relativen Pfad zur Datei einschließen.

Für gängige Bibliotheken wie slick.js können Sie sie mit den Funktionen require_js() oder require_css() mit einer absoluten URL zum CDN hinzufügen, in dem sie gehostet werden. 

Bitte beachten: Verwenden Sie keine absoluten URLs für Assets, die in Ihrem Entwicklungsportal enthalten sind, da portalübergreifende Verweise nicht aufgelöst werden. 

Unabhängige Module

Für unabhängige Module sollten alle CSS- und Javascript-Dateien entweder in module.css oder in module.js enthalten sein. Wahlweise können Sie die Dateien mit den Funktionen require_js() oder require_css() mit einer absoluten URL zum CDN hinzufügen, in dem sie gehostet werden. Die Funktion „Verknüpfte Dateien“ im Design-Manager kann nicht verwendet werden, da diese nur für Designmodule verfügbar ist. 

Da module.js im DOM vor allen require_js- oder require_css-Dateien enthalten ist, sollte Javascript im Abschnitt module.js mit der folgenden Anmerkung zurückgestellt werden:

JavaScript
document.addEventListener("DOMContentLoaded", function(){
// Put Javascript here
});

Alle Skripte und Dateien sollten im HTML-Head des Moduls gerendert werden. 

Code-Einschränkungen für unabhängige Module

Die folgenden Einschränkungen gelten nur für unabhängige Module:

  • Es wird empfohlen, nach Möglichkeit vanilla JS zu verwenden. Das Hinzufügen einer jQuery-Bibliothek zu einer Website, die nicht jQuery verwendet, kann möglicherweise zu Konflikten führen und die Website-Seite verlangsamen.
  • Wenn Sie eine jQuery-Bibliothek verwenden, nehmen Sie die Bibliothek über die require_js()-Funktion auf, sofern jQuery mit dem Kontrollkästchen (Boolesch) in den Portaleinstellungen deaktiviert ist, um Konflikte aus mehreren jQuery-Bibliotheken zu vermeiden. 
{% if not site_settings.include_jquery %} {{ require_js("https://code.jquery.com/jquery-3.7.0.min.js", "footer") }} {% endif %}

Kategorien

  • Alle unabhängigen Module müssen mindestens eine Kategorie haben. Module, die als Teil eines Designs übermittelt werden, müssen keine Kategorien haben. Es wird jedoch empfohlen, mindestens eine aufzunehmen. Erfahren Sie mehr über das Hinzufügen von Kategorien zu Modulen

Selektoren für Klassennamen

  • Jedem Klassennamen-Selektor muss der Modulname vorangestellt werden, wobei Leerzeichen durch Bindestriche ersetzt werden. Im Folgenden finden Sie beispielsweise die Datei module.html  für eine Schaltfläche example-button, wobei jeder Klassenname und der CSS-Selektor seinen Namen widerspiegeln.
<style> {% scope_css %} {# Button wrapper #} {% if module.styles.group_alignment.alignment %} .example-button-wrapper { text-align: {{ module.styles.group_alignment.alignment.horizontal_align }}; } {% endif %} {# Button #} .example-button { {% if module.styles.group_background.color.color %} background-color: rgba({{ module.styles.group_background.color.color|convert_rgb }}, {{ module.styles.group_background.color.opacity / 100 }}); {% endif %} } {% end_scope_css %} </style> {% end_require_css %} {##### Module HTML #####} <div class="example-button-wrapper"> <a href="{{ href }}" class="example-button" {% if module.button_link.open_in_new_tab %}target="_blank"{% endif %} {% if rel %}rel="{{ rel|join(" ") }}"{% endif %} > {{ module.button_text }} </a> </div>

Stile und JavaScript

  • Stile:
    • Module dürfen keine leere Stilgruppe enthalten.
    • Das Hartcodieren von Inline-Stilen innerhalb von Modulen wird nicht empfohlen. Verwenden Sie stattdessen dynamische Inlineformatvorlagen, indem Sie Felder zur Steuerung von Stilen aktivieren.
  • JavaScript
    • JavaScript muss immer mehrere Instanzen eines Moduls darstellen können. JavaScript im JS-Fenster wird nur einmal pro Seite geladen, unabhängig davon, wie häufig ein Modul vorkommt.
    • JavaScript sollte DOM-Elemente anhand von modulspezifischen Klassennamen referenzieren, um sicherzustellen, dass Elemente außerhalb des Moduls nicht unbeabsichtigt betroffen sind. JavaScript:
Beim Erstellen von Modulen können Sie die integrierte Variable EMEA DACH (DE) Asset Marketplace | Module requirements verwenden. Diese Variable ruft die Instanz-ID des Moduls ab (kann nur im Fenster „HTML+HubL“ verwendet werden), um beim CSS- und JS-Markup für komplexe Module zu helfen. Erfahren Sie mehr darüber in der Entwicklerdokumentation.

Feldstruktur

Es müssen die folgenden Anforderungen an die Feldstruktur und -gruppierung erfüllt sein.

Registerkarte „Content“

  • Wenn es innerhalb einer Feldgruppe mindestens ein Steuerelement gibt, müssen alle Steuerelemente in nach ihrer Funktion gekennzeichneten Kategorien gruppiert werden.
  • Modulfelder, die der Registerkarte Content hinzugefügt wurden, müssen Möglichkeiten bereitstellen, den Content eines Moduls anzupassen. Zum Beispiel Steuerelemente für Bilder, Symbole, ALT-Texte und Links.

Registerkarte „Stile“

Die Modulstil-Feldgruppen müssen konsistent sein und einem Muster folgen. Nachfolgend finden Sie eine empfohlene Reihenfolge für Ihre Stilfeldgruppen. Diese Gruppen können sich auf der obersten Ebene befinden oder dürfen nur mit einer direkt darunterliegenden Gruppe verschachtelt sein. Leere Gruppen können auch entfernt werden:
  • Voreinstellungen
  • Text
  • Hintergrund
  • Rahmen
  • Zeigen auf
  • Ecke
  • Abstand
  • Ausrichtung
  • Benutzerdefinierte Stilgruppen, die nicht zu den oben genannten passen
  • Erweitert

Die folgenden Feldtypen müssen auf der Stile-Registerkarte enthalten sein, falls vorhanden:

Wenn Sie Felder von der Registerkarte Content zur Registerkarte Stile verschieben, erfahren Sie, wie Sie die Aliaszuordnung verwenden, um die Formatierung für Module beibehalten, die bereits auf Live-Seiten verwendet werden.
  • Die Animationsoptionen sollten immer am unteren Rand der Feldgruppenliste positioniert werden.
  • Optionen, die es Content-Autoren ermöglichen, Code-Snippets oder CSS hinzuzufügen, sollten am Ende der Feldgruppenliste unter einem Feld Erweitert gruppiert werden. 
  • Die Steuerelemente sollten über alle Module hinweg standardisiert werden. Zum Beispiel sollten alle Elemente, die ein Steuerelement für den Rahmenradius haben können, dieses Steuerelement anbieten. Es ist nicht ratsam, Steuerelemente für einige Module anzubieten und für andere nicht.
  • Modulfelder, die der Registerkarte Stil hinzugefügt werden, müssen Möglichkeiten zum Bearbeiten des Modulstiels bieten. Zum Beispiel:
    • Stiloptionen wie Farbe, Textstil, Ausrichtung, Abstand, Rahmen und Eckenradius.
    • Animationen wie Hover- und Slide-In-Effekte.
    • Voreinstellungen wie dunkle und helle Designs, bei denen viele Stile gleichzeitig geändert werden.

Beispiele für Feldorganisation

Voreinstellungen

Voreinstellungen können verwendet werden, um die Optionen für Content-Autoren zu begrenzen, da einige Optionen an die Designeinstellungen gebunden sind. Zum Beispiel enthält das im Growth-Design enthaltene Modul Symbol Voreinstellungen für Dunkel und Hell, um der Website ein konsistentes Erscheinungsbild zu geben, sofern es auf die gesamte Website angewendet wird. 

Multi-Level-Gruppierung

Wenn Sie noch nicht wissen, ob Sie Stilfelder auf der obersten Ebene halten oder verschachteln möchten, sollten Sie sich das folgende Beispiel ansehen.

Das im Growth-Design enthaltene Modul Symbol führt alle Stile auf der obersten Ebene auf, da es sich um eine Komponente handelt. Daher wirken sich alle Stiloptionen auf diese eine Komponente aus. 

growth-theme-icon-module

Das im Growth-Design enthaltene Modul Sprecherkarte enthält mehrere Komponenten: das Bild der Karte und den Textinhalt. Modulstile werden daher nach Komponente gruppiert, damit der Styling-Prozess jeder Komponente für den Content-Autor verständlicher ist.

growth-theme-speaker-card

Gruppieren von einzelnen Feldern

Das Schaltflächenmodul unten enthält Gruppierungen für Voreinstellungen, Text, Hintergrund und mehr. Obwohl die Feldgruppe Ecke nur das Steuerelement „Eckenradius“ enthält, ist sie dennoch gruppiert, um ein einheitliches Erlebnis bei der Content-Erstellung zu schaffen.

module-requirements-2_1button-styles

 

Aliase

Mit Aliaszuordnung können Sie Feldzuordnungen in einem Modul erstellen, sodass Sie seine Felder verschieben, umbenennen oder ersetzen können, ohne dass sich dies auf Seiten auswirkt, die das Modul verwenden. 

Ein Modul wird beispielsweise auf einer Live-Seite verwendet. Sie möchten einige Felder zur Registerkarte Stile verschieben, z. B. Farbe oder Schriftart, aber ein Content-Autor hat bereits Werte für diese Felder im Editor ausgewählt. Wenn Sie diese Felder verschieben, ohne eine Aliaszuordnung einzurichten, kann HubSpot diese Felder nicht verschieben und sie werden auf ihre Standardwerte zurückgesetzt, was die Formatierung auf der Live-Seite rückgängig macht.

Stattdessen können Sie einem Feld eine aliases_mapping-Eigenschaft hinzufügen, um es einem anderen Feld zuzuordnen. Wenn dann kein Wert für das ursprüngliche Feld festgelegt wurde, prüft HubSpot, ob ein Wert im zugeordneten Feld vorhanden ist. Wenn auch im zugeordneten Feld kein Wert vorhanden ist, wird stattdessen der Standardwert verwendet. Diese Eigenschaft kann nur verwendet werden, um Feldwerte zwischen verschiedenen Versionen eines Moduls zuzuordnen, wenn der gespeicherte Datentyp des alten Feldes mit dem gespeicherten Datentyp des neuen Feldes übereinstimmt.

Eine visuelle Übersicht über diese Funktion erhalten Sie unten im Video.

So migrieren Sie vorhandene Felder zu Aliasen:

  1. Erstellen Sie neue Felder und ordnen Sie sie mithilfe der aliases_mapping-Eigenschaft alten Feldern zu.
  2. Entfernen Sie die alte Felddefinition.
  3. Aktualisieren Sie die module.html-Datei so, dass die neue Felddefinition verwendet wird.

Bitte beachten:

  • Es ist nicht möglich, Felder eines anderen Datentyps einander zuzuordnen. Beispielsweise können Sie einem Bildfeld kein Hintergrundfarbverlauffeld zuordnen. Der gespeicherte Wert muss ein gültiger Wert für den Typ des neuen Feldes sein.
  • Beim Erstellen eines neuen Feldes mit einer Alias-Zuordnung zu einem alten Feld sollten die Standardwerte und die erforderlichen Eigenschaften beider Felder gleich sein.

Nachfolgend finden Sie Beispiele für die Umsetzung sowohl einfacher als auch komplexer Änderungen:

  • Einfache Umsetzung: Zuordnen eines Farbfeldes zu einem anderen neuen Farbfeld.
  • Komplexe Umsetzung: Zuordnen eines Zahlenfeldes zum size-Unterfeld eines Schriftartfeldes, um die Schriftartgröße zu steuern.

Einfache Umsetzung

In einfachen Situationen sollten der Feldtyp des alten Feldes und der Feldtyp des neuen Feldes gleich sein. Zum Beispiel:

  • Altes Farbfeld zu neuem Farbfeld. 
  • Altes Textfeld zu neuem Textfeld.
  • Altes Abstandfeld zu neuem Abstandfeld.

Unten sehen Sie ein Beispiel für die Verwendung von aliases_mapping beim Verschieben eines Farbfeldes von der Registerkarte Content des Moduls zur Registerkarte Stile.

Example of a v0 module

[ { "label": "Button Color", "name": "old_button_color_field", "type": "color", "required": true, "default": { "color": "#FFFFFF", "opacity": 100 } } ]

Example of a v1 module

[ { "label": "Styles", "name": "styles", "type": "group", "tab": "STYLE", "children": [ { "label": "Button Color", "name": "new_button_color_field", "type": "color", "required": true, "aliases_mapping": { "property_aliases_paths": { "new_button_color_field": ["old_button_color_field"] } }, "default": { "color": "#FFFFFF", "opacity": 100 } } ] } ]

Complex implementation

In komplexeren Situationen können Sie Felder auch Unterfeldern oder anderen Modulfeldtypen zuordnen, sofern der Datentyp der gleiche ist und der Unterfeldtyp des neuen Feldes übereinstimmt. Unterfelder sind die Eigenschaften innerhalb des gespeicherten Wertobjekts des Feldes. Zum Beispiel:

  • Zuordnen eines Rich-Text-Feldes zu einem Text-Feld, da die Werte in beiden Feldern als Zeichenfolgen gespeichert werden.
  • Das Konsolidieren von Typografiefeldern, z. B. Wechsel von einem Zahlenfeld für die Schriftgröße zu eine, Schriftartfeld (das ein Unterfeld für die Schriftgröße aufweist). Sie können einen Alias für das size-Unterfeld hinzufügen, um es mithilfe der Punktnotation dem alten Zahlenfeld zuzuordnen.

Nachfolgend finden Sie ein Beispiel für die Änderung der Schriftgrößenoption von einem Zahlenfeld in ein Schriftartfeld mit einem Unterfeld für die Schriftgröße.

Example of a v0 module

[ { "name": "my_number_field", "label": "Number field", "required": false, "locked": false, "display": "text", "step": 1, "type": "number", "min": null, "max": null, "inline_help_text": "", "help_text": "", "default": null } ]

Example of a v1 module

[ { "name": "my_font_field", "label": "font_field", "required": false, "locked": false, "inline_help_text": "", "help_text": "", "load_external_fonts": true, "type": "font", "aliases_mapping": { "property_aliases_paths": { "my_font_field.size": ["my_number_field"] } }, "default": { "size": 12, "font": "Merriweather", "font_set": "GOOGLE", "size_unit": "px", "color": "#000", "styles": {} } } ]

War dieser Artikel hilfreich?
Dieses Formular dient dazu, Feedback zu unserer Entwicklerdokumentation zu sammeln. Wenn Sie uns Ihre Meinung zu HubSpot-Produkten mitteilen möchten, teilen Sie diese bitte im Ideenforum der Community.