Du nouveau pour le traitement des champs xprofile dans BuddyPress 2.1

Publié le

Une importante amélioration vient d’être ajoutée au composant xprofile pour la version 2.1 de BuddyPress. Enfin pourrait-on dire, parce que quand même, ce lieu de passage obligé sur toute installation BudyPress était bien délaissé côté UX.

Jusqu’ici, les champs personnalisés ajoutés aux profils pouvaient être définis en admin comme étant facultatifs ou obligatoires. Seul un ID et l’input type permettait de les différencier et l’aspect linéaire s’appliquait à tous. Ou à aucun. Pauvres alternatives pour un designer n’est-ce pas ?

Quiconque a un jour construit un tel formulaire sait qu’un groupe de champs obligatoires qui aurait été rajouté ressemble, comme deux gouttes d’eau et aussi par défaut, à la partie de groupe de champs « Base », là où n’existe au départ que le fameux Name (nom d’utilisateur), le seul champ qui s’affiche immanquablement sur la page d’enregistrement. Rappelons que ce groupe de champ « Base » est également le seul qui est affiché sur la page d’enregistrement.

La problématique qui vient d’être levée résidait dans la façon dont les champs additionnels étaient affichés, mais également dans la manière dont les utilisateurs étaient informés en cas d’oubli (si le champ est obligatoire) ou comment on leur indiquait que ce champ nécessitait une valeur.
Un ID en CSS ne peut servir qu’une fois et s’applique par conséquent au seul élément qui utiliserait cet ID. En ajoutant une classe, on peut à présent jouer plus finement sur le style de ces champs, avec une seule déclaration de class et le cas échant l’ajout du ID pour faire la distinction.

Ces messages d’erreurs étaient quelque peu discrets et s’affichaient le plus souvent en en-tête du formulaire. Quand le formulaire est très court, passe encore, mais dès qu’un site utilise un formulaire avec des dizaines de champs, même réparti sur plusieurs onglets, ces messages ne sont plus lisibles quand on est en bas de page par exemple.

L’ajout de 2 classes CSS, une pour chaque type de champ (facultatif ou obligatoire) va désormais permettre de cibler proprement ces champs, de les répartir de façon plus structurée sur n’importe quel template et de mieux mettre en lumière n’importe quel message. Du moins pour les plus créatifs et les plus imaginatifs. 😉

A vous de jouer sur les typos et les couleurs, les pop-ups ou autre volets coulissants sur votre formulaire de profil.

La partie qui vient d’être ajoutée à bp-xprofile/bp-xprofile-template.php

// Set a class indicating whether the field is required or optional 
	if ( ! empty( $profile_template->field->is_required ) ) { 
		$css_classes[] = 'required-field'; 
	} else { 
		$css_classes[] = 'optional-field'; 
	} 

Un grand merci à @sandrine pour avoir pris le temps d’ausculter la structure à l’occasion d’un dev acrobatique et de donner sa solution. A @hdcms pour avoir posé la question et à @boone pour l’avoir intégré au Core.

J’ajoute que ce genre de situation existe dans d’autres parties de BuddyPress. Pour de nombreuses raisons, elles ne sont pas réglées alors qu’elles sont parfois présentes depuis des années. Quoiqu’il en soit, il est important que chaque utilisateurs ayant été confronté à une absence de class ou de ID sur des éléments HTML utilisés dans BuddyPress le signale, soit sur notre forum soit directement sur le Trac. Comme vous venez de le lire, c’est très facile à corriger et en retour, le gain de temps et l’amélioration de l’outil que cela engendre sont quasiment inestimables.

Mots-clés: , , ,


Un avis sur “Du nouveau pour le traitement des champs xprofile dans BuddyPress 2.1

  1. Merci à toi @dan pour diffuser aussi largement l’information à l’ensemble des utilisateurs de BP !

    Concernant l’amélioration de l’expérience utilisateur :
    – du formulaire d’enregistrement de nouveaux utilisateurs, il faut encore attendre une homogénéisation de la structure des différentes sections de champs qui composent ce formulaire, suivre le ticket #5739
    – du formulaire de mise à jour des champs des utilisateurs enregistrés, il faut également attendre la résolution du ticket #5738 pour avoir des messages d’erreurs spécifiques à chacun des champs plutôt qu’un message global.

Aller à la barre d’outils