Un modèle de site personnalisé peut être spécifié séparément pour chaque copie de langue d’un site de communauté.
Pour ce faire :
page-template
au noeud configuration
.Modèle par défaut :
/libs/social/console/components/hbs/sitepage/sitepage.hbs
Modèle personnalisé dans le chemin de recouvrement :
/apps/social/console/components/hbs/sitepage/template-name.hbs
Propriété : page-template
Type : String
Valeur : template-name
(aucune extension)
Noeud de configuration :
/content/community site path/lang/configuration
Par exemple : /content/sites/engage/en/configuration
Tous les noeuds du chemin d’accès recouvert doivent uniquement être de type Folder
.
Si le modèle personnalisé porte le nom sitepage.hbs, tous les sites de la communauté seront personnalisés.
Par exemple, vertical-sitepage.hbs
est un modèle de site qui entraîne l’emplacement des liens de menu verticalement vers le bas du côté gauche de la page, au lieu de horizontalement sous la bannière.
Get
FilePlacez le modèle de site personnalisé dans le dossier de recouvrement :
/apps/social/console/components/hbs/sitepage/vertical-sitepage.hbs
Identifiez le modèle personnalisé en ajoutant une propriété page-template
au noeud de configuration :
/content/sites/sample/en/configuration
Veillez à Enregistrer tout et répliquez le code personnalisé sur toutes les instances d’AEM (le code personnalisé n’est pas inclus lorsque le contenu du site de la communauté est publié à partir de la console).
La pratique recommandée pour la réplication du code personnalisé consiste à créer un package et à le déployer sur toutes les instances.
Une fois un site communautaire créé, il est possible d’exporter le site sous la forme d’un package AEM stocké dans le gestionnaire de packages et disponible pour téléchargement et chargement.
Elle est disponible à partir de la console Sites des communautés.
Notez que le contenu généré par l’utilisateur et le code personnalisé ne sont pas inclus dans le package du site de la communauté.
Pour exporter du contenu créé par l’utilisateur, utilisez l’outil de migration du contenu créé par l’utilisateur AEM Communities, un outil de migration open source disponible sur GitHub.
Depuis AEM Communities 6.3 Service Pack 1, l’icône Supprimer le site s’affiche en survolant le site de la communauté à partir de la console Communautés > Sites. Au cours du développement, si vous souhaitez supprimer un site de la communauté et recommencer à zéro, vous pouvez utiliser cette fonctionnalité. La suppression d’un site de communauté supprime les éléments suivants qui lui sont associés :
Pour identifier l’identifiant de site unique associé au site de la communauté, à l’aide de CRXDE :
Accédez à la racine de langue du site, par exemple /content/sites/*<site name>*/en/rep:policy
.
Recherchez le noeud allow<#>
dont le format est rep:principalName
rep:principalName = *community-enable-nrh9h-members*
.
L’ID de site est le troisième composant de rep:principalName
Par exemple, si rep:principalName = community-enable-nrh9h-members
Procurez-vous le projet communities-srp-tools de Github :
Contient un servlet permettant de supprimer tout le contenu généré par l’utilisateur de toute SRP.
Tout contenu généré par l’utilisateur peut être supprimé ou pour un site spécifique, par exemple :
path=/content/usergenerated/asi/mongo/content/sites/engage
Cela supprime uniquement le contenu généré par l’utilisateur (saisi lors de la publication) et non le contenu créé (saisi lors de la création). Par conséquent, les noeuds fantômes ne sont pas affectés.
Sur toutes les instances de création et de publication, à partir de la console de sécurité, recherchez et supprimez les groupes d’utilisateurs qui sont les suivants :
community
Par exemple, community-engage-x0e11-members
.
Dans la console principale :
Il n’existe pas d’outil permettant de supprimer de manière sélective les entrées de base de données d’un site spécifique de la communauté d’activation.
Lorsque tous les sites de la communauté sont supprimés, supprimez enablementdb et scormenginedb à l’aide de MySQL Workbench.