Les champs personnalisés, apparus avec la version Joomla 3.7.0, sont considérés comme une évolution majeure du CMS. Remplace-t-elle les extensions pour l'un des CMS les plus populaires, concurrent de Wordpress? Test et tuto.
Cela m'a pris du temps, mais je m'y suis mise. Faute à trop de travail (on ne va pas se plaindre hein?)
Je profite de la refonte complète du site tout-toutou.fr (en cours) qui m'est demandée, pour tester les champs personnalisés, afin de mettre en place le meilleur protocole adapté aux non-développeurs.
Car ne l'oublions pas, un CMS gratuit, c'est d'abord pour un public souhaitant le plus souvent gérer lui-même son site internet aussi facilement que possible.
Les champs personnalisés, ça sert à quoi?
Tout-toutou.fr est un terrain de jeu idéal pour tester les champs personnalisés, avec:
- un guide des races
- un annuaire
- des petites annonces
- une communauté.
Ces différentes rubriques utilisent une construction formatée, du type recette.
Les informations sont récurrentes, et doivent être organisées pour faciliter la lecture.
Habituellement, le webmaster spécialisé en CMS gratuit utilise une extension du type CCK (Content Construction Kit).
Même s'il sait coder
Inutile de réinventer la roue quand de bons outils sont déjà là.
Dans certains cas, un template peut suffire.
Par exemple certains templates de recette de cuisine pour Wordpress ou pour Joomla remplissent parfaitement ce rôle: structurer du contenu spécialisé.
Mais dans le cas d'un site comme Tout-toutou.fr, les grilles de mise en page et les données varient d'une rubrique à l'autre.
Un seul template ne répond pas à cette exigence.
Reste l'extension CCK.
Or l'objectif avoué des champs personnalisés de Joomla 3.7 et suivants, c'est de s'en passer.
Est-il atteint?
Test des champs personnalisés de Joomla
Et bien oui... et non.
Une évolution certaine
Les champs personnalisés de Joomla sont une vraie évolution.
Ils apportent encore plus de souplesse et de possibilités à une CMS déjà très puissant, en restant accessibles aux non développeurs ou rétifs aux solutions plus complexes (Magento, Drupal...).
Il leur faudra quand même un bon niveau d'expérience de ce CMS.
Rien d'insurmontable toutefois.
Grâce aux champs personnalisés, vous pouvez introduire dans vos articles de nombreux types de données: media, liste d'images, dates (parfait pour générer des évènements), listes, cases à cocher, bouton radio, texte sous différentes formes (champ strict ou éditeur, téléphone...)
Et même un champ "répétable" fort intelligent.
Attention, la documentation officielle le signale comme deprecated.
Utilisez-le avec modération, au risque de devoir reconstruire vos modèles s'il devait disparaître.
Mais avec des bémol
Grâce à ces champs personnalisés, le formulaire d'édition permet à l'utilisateur de rajouter des données structurées dans son article.
MAIS...
Le bémol, c'est que l'affichage en blog n'aime pas ça.
Mais alors, pas du tout.
L'ensemble des contenus "champs personnalisés" s'affiche sur l'interface "blog", qui en principe ne doit laisser voir que l'image et l'intro.
Pour éviter cet écueil, chacun de vos champs personnalisés devra être paramétré à "ne pas afficher automatiquement".
Résultat des champs en Vue blog
Démo avant / après réglage du paramètre d'affichage:
Champs réglés à "après l'affichage" |
Champs réglés à ne "pas afficher automatiquement".
|
Résultat des champs en Vue pleine page
Puisque vous l'avez réglé à ne "pas afficher automatiquement"... ben le champs spécifique, il ne s'affiche pas dans l'article en pleine page.
Logique.
C'est ce qu'on lui demande après tout.
Démo avant / après intégration des champs dans l'article:
Champs réglés à "ne pas s'afficher automatiquement" |
Champs intégrés dans le contenu |
Contourner le problème
Pour contourner le problème, vous aurez 2 solutions:
- Soit Programmer
- Soit intégrer en appelant les champs dans l'article
Programmer
Il s'agira de personnaliser votre fichier de template pour appeler les champs en question dans la construction des pages.
Là je vous le dis tout de suite: oubliez si vous avez plusieurs types de contenus (cf Tout-toutou.fr: annuaire, annonces, évènements etc.).
Il vous faudra mettre en place des boucles de conditions, pour pouvoir:
- mettre en page les données dans le template initial, au bon endroit
- afficher ou pas les titres h2, h3 etc. ou les éventuelles phrases de présentation suivant:
- la catégorie
- le niveau d'accès utilisateur
- si le champ est non vide - gérer le multilingue (c'est pas le plus dur)
Sans cela, toute la structure sémantique (titres, phrases) apparaîtra dans toutes les pages, même celles qui n'appellent pas les champs personnalisés.
Autant dire que vous devrez faire un développement à part entière, dans un tel cas.
Autre alternative: 1 template pour chaque typologie de rubrique.
Mais avec tout de même la nécessité de coder votre template de base.
Intégrer
Ceci reste la solution raisonnable pour éviter le CCK, ou le développement personnalisé.
Néanmoins, ce ne sera pas idéal si certains contenus structurés (par exemple des annonces), doivent être créés par les utilisateurs.
Quand bien même ils en auraient les compétences (simples), ils n'auront aucune envie de devoir "bidouiller" leurs pages en respectant le protocole d'intégration nécessaire.
Protocole expliqué dans le mini-tuto pour utiliser au mieux les champs personnalisés de Joomla, sans passer par un développement spécifique indispensable.
Conclusion du test
Si vous êtes dans le cas de Tout-toutou.fr, même avec seulement 2 rubriques spécialisées, autant faire le choix d'un CCK bien maîtrisé!
Tutoriel: utiliser les champs personnalisés de Joomla
Tutoriel à venir
