Exigences relatives aux modules du marketplace des modèles HubSpot

Découvrez les exigences pour soumettre un module dans le marketplace des modèles. Ces exigences s'appliquent à la fois aux modules d'un thème et aux modules indépendants. 

Les modules ne doivent pas contenir la fonctionnalité HubDB, des appels à des fonctions sans serveur ou des champs d'objet CRM.

Les types de modules suivants ne doivent pas être créés en tant que modules indépendants.

• HTML
• Modules en pleine largeur
• Formulaires et formulaires à plusieurs étapes
• Modules d'espacement ou modules qui créent une structure de page hors interface utilisateur
• Modules qui dupliquent les fonctionnalités de module par défaut
• Modules commerciaux spécifiques

Découvrez les exigences relatives aux libellés des modules et au texte d'aide, aux champs et au contenu par défaut.

• Les modules doivent avoir des libellés descriptifs qui précisent l'objectif du module. Le libellé Hero banner avec défilement parallaxe est descriptif, alors que les libellés Hero banner et Galerie ne le sont pas. 
  
• Les libellés de module ne doivent pas contenir de chiffres, comme Hero banner 01.
  
• Les libellés de module ne doivent pas contenir d'abréviations, comme Col au lieu de Colonne.
• Les modules doivent contenir du texte d'aide en ligne (le cas échéant) pour indiquer plus en détail comment utiliser le module.
• Le module ne doit pas être nommé de la même manière qu'un module par défaut.

• Le champ par défaut ne peut pas inclure de texte lorem ipsum. 
• Le contenu du champ par défaut doit représenter l'objectif du champ :
  • Lors de l'inclusion des champs de menu, les modules doivent utiliser par défaut l'option de contenu Sélectionner un menu.
  • Lors de l'inclusion de champs de formulaire, les modules doivent utiliser par défaut l'option de contenu Sélectionner un formulaire.
  • Lors de l'inclusion de champs de sélecteur de blog, les modules doivent utiliser par défaut l'option de contenu Sélectionner un blog.
• Si l'ajout de contenu par défaut à un module n'est pas pertinent, utilisez plutôt un espace réservé de module pour aider le créateur de contenu à visualiser l'espace qu'il remplira.

Les modules doivent inclure une icône personnalisée attribuée au module (remplaçant l'icône par défaut). N'utilisez pas les logos d'entreprise comme icônes, tels que les logos Apple ou Amazon. Découvrez-en davantage sur les icônes de module.

• Pour les modules d'un thème :
  • Ils doivent contenir du texte d'aide en ligne et un contenu par défaut spécifique pour certains champs.
  • Une partie de la couleur du thème et de logo doit hériter des paramètres de marque du compte.
    • Au minimum, trois champs de couleur doivent hériter des couleurs des paramètres de marque du compte. Les champs de couleur supplémentaires peuvent être remplacés par défaut par d'autres couleurs, y compris le noir et le blanc.
    • Au moins un champ de logo doit hériter des paramètres de marque du compte. Si vous utilisez un champ d'image pour afficher un logo, le champ d'image n'a pas à hériter des paramètres de marque. 
• Pour les modules d'un thème et des modules indépendants :
  • Les noms des champs du module doivent décrire l'intention du champ. Par exemple, si un champ de texte est destiné à inclure l'intitulé du poste d'une personne, Intitulé de poste serait une description appropriée alors que Intitulé ne le serait pas.
  • Tous les modules par défaut de HubSpot doivent être stylisés et doivent s'afficher correctement sur tous les modèles soumis.

Pour garantir une fonctionnalité compatible entre les thèmes et les modules indépendants, les modules doivent hériter des champs de couleur et de police en définissant default_value_path ou property_value_path, ou les deux dans leurs fichiers fields.json et ajouter une référence aux champs du thème dans le fichier module.html. Découvrez-en davantage sur ces exigences.

Tous les fichiers nécessaires à votre module de thème, tels que CSS ou JavaScript, doivent être contenus dans le dossier du thème et inclus dans le répertoire du thème. Vous pouvez utiliser la fonction de fichier lié dans le gestionnaire de conception. Autrement, vous pouvez inclure les fichiers en utilisant les fonctions require_js() ou require_css() avec un chemin relatif vers le fichier.

Pour les bibliothèques courantes, telles que slick.js, vous pouvez les inclure à l'aide des fonctions require_js() ou require_css() avec une URL absolue vers le réseau de diffusion de contenu où ils sont hébergés. 

Pour les modules indépendants, tous les fichiers CSS et JavaScript doivent être contenus dans module.css ou module.js. Vous pouvez également inclure les fichiers à l'aide des fonctions require_js() ou require_css() avec une URL absolue vers le réseau de diffusion de contenu où ils sont hébergés. Il n'est pas possible d'utiliser la fonctionnalité de fichier lié dans le gestionnaire de conception, car elle n'est disponible que pour les modules de thème. 

Étant donné que module.js est inclus dans le DOM avant tout fichier require_js ou require_css, le JavaScript contenu dans la section module.js doit être différé à l'aide de l'annotation ci-dessous :

Tous les scripts et fichiers doivent être rendus dans l'en-tête du HTML du module. 

Les restrictions suivantes s'appliquent uniquement aux modules indépendants :

• Il est recommandé d'utiliser Vanilla JS dans la mesure du possible. L'ajout d'une bibliothèque jQuery à un site qui n'utilise pas jQuery peut potentiellement provoquer des conflits et ralentir la page du site Web.
• Si vous utilisez une bibliothèque jQuery, utilisez la fonction require_js() pour inclure la bibliothèque si jQuery est désactivé avec la case à cocher (booléen) dans les paramètres du portail afin d'éviter les conflits provenant de plusieurs bibliothèques jQuery. 

• Tous les modules indépendants doivent avoir au moins une catégorie. Il n'est pas obligatoire d'inclure des catégories pour les modules soumis dans le cadre d'un thème, mais il est recommandé d'en inclure au moins une. Découvrez-en davantage sur l'ajout de catégories à des modules. 

• Tout sélecteur de nom de classe doit être précédé du nom du module, en remplaçant les espaces par des traits d'union. Par exemple, ci-dessous se trouve le fichier module.html d'un bouton intitulé example-button, avec chaque nom de classe et sélecteur CSS reflétant son nom.

• Styles :
  • Les modules ne doivent pas avoir de groupe de style vide.
  • Le codage en dur des styles en ligne dans les modules est déconseillé. Au lieu de cela, utilisez des styles en ligne dynamiques en activant les champs pour contrôler le style.
• JavaScript
  
  • JavaScript doit pouvoir représenter plusieurs instances d'un module. Javascript dans JS Pane ne sera chargé qu'une fois par page, quel que soit le nombre d'occurrences de modules.
  • JavaScript doit référencer les éléments DOM par des noms de classe spécifiques pour garantir que les éléments extérieurs au module ne sont pas affectés par inadvertance.

Les exigences suivantes en matière d'organisation et de regroupement des champs doivent être respectées.

Onglet Contenu

• Lorsqu'il y a au moins un contrôle au sein d'un groupe de champs, tous les contrôles doivent être regroupés en catégories libellées selon leur fonction.
• Les champs de module ajoutés à l'onglet Contenu doivent permettre de personnaliser le contenu d'un module. Par exemple, les contrôles d'image, d'icône, de texte alternatif et de lien.

Onglet Styles

• Préréglages
• Texte
• Arrière-plan
• Bordure
• Survol
• Angle
• Espacement
• Alignement
• Groupes de styles personnalisés qui ne correspondent pas à ce qui précède
• Avancé

Les types de champs suivants doivent être contenus dans l'onglet Styles, le cas échéant :

• Alignement
• Image d'arrière-plan
• Bordure
• Couleur
• Police
• Dégradé
• Espacement 
• Alignement du texte

• Les options d'animation doivent toujours être positionnées à la fin de la liste des groupes de champs.
• Les options qui permettent aux créateurs de contenu d'ajouter des extraits de code ou des CSS doivent être regroupées à la fin de la liste des groupes de champs sous un champ intitulé Avancé. 
• Les contrôles doivent être uniformisés dans tous les modules. Par exemple, tous les éléments qui peuvent avoir un contrôle de rayon de bordure doivent proposer ce contrôle. Évitez de proposer des contrôles sur des modules qui sont absents sur d'autres.

• Les champs de module ajoutés à l'onglet Style doivent permettre de styliser le module. Par exemple :
  • Les options de style incluent la couleur, le style de texte, l'alignement, l'espacement, la bordure et le rayon d'angle.
  • Les animations incluent des effets au survol et concernant les diapositives.
  • Les préréglages incluent des thèmes sombres et clairs qui sont destinés à changer de nombreux styles en même temps.

Exemples d'organisation des champs

Préréglages

Les préréglages peuvent être utilisés lorsque vous souhaitez donner aux créateurs de contenu un ensemble limité d'options, souvent liées aux paramètres du thème. Par exemple, le module Icône inclus dans le thème Growth contient des préréglages pour les couleurs Dark et Light, ce qui permet une cohérence lorsqu'il est utilisé sur le site web. 

Regroupement multi-niveaux

Lorsque vous décidez de garder les champs de style au niveau supérieur ou de les imbriquer, tenez compte de l'exemple suivant.

Regroupement de champs individuels

Le module de bouton ci-dessous contient des groupes pour les préréglages, le texte, l'arrière-plan et plus encore. Bien que le groupe de champs Angle contienne uniquement le contrôle du rayon, il est toujours regroupé pour créer une expérience de création de contenu uniforme.

Le mappage d'alias vous permet de créer des mappages de champs dans un module afin de pouvoir déplacer, renommer ou remplacer ses champs sans affecter les pages utilisant le module. 

Par exemple, un module est utilisé sur une page en direct. Vous souhaitez déplacer certains champs dans l'onglet Styles, tels que la couleur ou la police, mais un créateur de contenu a déjà sélectionné des valeurs pour ces champs dans l'éditeur. Si vous deviez déplacer ces champs sans configurer de mappage d'alias, HubSpot ne serait pas en mesure de les déplacer et ils reviendraient à leurs valeurs par défaut, ce qui annulerait le style de la page en direct.

Au lieu de cela, vous pouvez ajouter une propriété aliases_mapping à un champ pour le mapper à un autre. Ensuite, lorsqu'une valeur n'a pas été définie pour le champ d'origine, HubSpot vérifiera si une valeur existe dans le champ mappé. Si aucune valeur n'existe dans le champ mappé, il utilisera la valeur par défaut à la place. Cette propriété peut être utilisée pour mapper les valeurs de champ entre différentes versions d'un module uniquement lorsque le type de données stockées de l'ancien champ est identique au type de données stockées du nouveau champ.

Pour une présentation visuelle de cette fonctionnalité, consultez la vidéo ci-dessous.

Pour migrer des champs existants vers des alias :

1. Créez de nouveaux champs et mappez-les à d'anciens champs à l'aide de la propriété aliases_mapping.
2. Supprimez l'ancienne définition de champ.
3. Mettez à jour le fichier module.html pour utiliser la nouvelle définition de champs.

Vous trouverez ci-dessous des exemples de mise en œuvre pour des changements simples et complexes :

• Mise en œuvre simple : mappage d'un champ de couleur à un autre champ de couleur.
• Mise en œuvre complexe : mappage d'un champ numérique au sous-champ size du champ de police pour contrôler la taille de police.

Dans des situations simples, le type de champ de l'ancien champ et le type de champ du nouveau champ doivent être les mêmes. Par exemple :

• Ancien champ de couleur vers nouveau champ de couleur. 
• Ancien champ de texte vers nouveau champ de texte.
• Ancien champ d'espacement vers nouveau champ d'espacement.

Vous trouverez ci-dessous un exemple d'utilisation de aliases_mapping lors du déplacement d'un champ de couleur de l'onglet Contenu du module vers l'onglet Styles.

Dans les situations plus complexes, vous pouvez également mapper des champs à des sous-champs ou à d'autres types de champs de module, à condition que le type de données soit le même et que le type de sous-champ du nouveau champ corresponde. Les sous-champs sont les propriétés de l'objet de valeur stocké dans le champ. Par exemple :

• Mappage d'un champ de texte enrichi à un champ de texte, car les valeurs des deux champs sont stockées sous forme de chaînes.
• Consolidez les champs de typographie, par exemple en passant d'un champ numérique pour la taille de police, à un champ de police (qui a un sous-champ de taille de police). Vous pouvez ajouter un alias pour le sous-champ size pour le mapper à l'ancien champ numérique en utilisant la notation par points.

Vous trouverez ci-dessous un exemple de modification de l'option de dimensionnement de police d'un champ numérique à un champ de police qui comporte un sous-champ de taille de police.