[Problème] Comment intégrer les Champs Persos des Utilisateurs dans Système > Modèles d'Emails ?

[woluweb]

Est-ce que quelqu'un pourrait me guider ?

Je voulais insérer des Champs Personnalisés des Utilisateurs dans "Système > Modèles d'Emails" ("System > Mail Templates") en utilisant le shortcode traditionnel {field ID}... mais visiblement les Champs Personnalisés ne sont pas déclenchés.

Il y a quelque temps, j'avais écrit un article sur quelque chose de similaire, à savoir « Personnaliser les pages de résultats de recherche intelligente de Joomla 4 avec des images, des Champs Personnalisés et une nouvelle mise en page » : https://slides.woluweb.be/smartsearc...-custom-fields

Mais je n'ai aucune idée du fichier à éditer et des lignes à ajouter pour que {field ID} soit déclenché dans les Mail Templates.

Je prends l'exemple de {field X}, mais même si c'est une astuce qui insère directement *tous* les Champs Personnalisés quelque-part, ça me va aussi bien sûr.

Une idée ?

Merci !

PS : si on trouve une solution, je serai également heureux de l'ajouter à ma présentation sur les Champs Persos que je donne au #jdayusa25

[lefabdu51]

salut, est que tu peut verifier ceci pour moi? tu créer un module de contenu perso avec un texte html du type "test personnalisé" que tu charges dans ton template avec {loadmoduleid id du module}. Cela permettras de savoir si les plugins de contenu sont utilisables. Auquel cas, il y aurais une suite simple à cela (enfin simple pour un dev , pour moi ca sera lecture de la doc et ensuite grosse reflexion pour te donner le code a inclure dans une mise en page alternative du mod_custom)

[pmleconte]

Bonjour Marc,

Comme il t'a été écrit sur mattermost, c'est prévu pour les contacts (j'ai trouvé dans components/com_contact/src/Controller/ContactController.php, dans la fonction _sendmail (ligne 244), il y a un appel aux com_fields.

Cependant, ce n'est pas le cas dans les appels aux mails templates de com_user.

Dans une précédente vie, tu avais fait l'éloge des plugins et, si je me rappelle bien, tu avais dit qu'un composant bien écrit devait avoir des plugins. Malheureusement, le composant com_mails n'a pas d'appel à des plugins avant l'appel à librairie MailTemplate et je n'ai pas trouvé comment modifier ce comportement standard.

Dans l'exemple que tu donnes (com_users.registration.admin.verification_request ), l'appel au mail template est fait dans components\com_sers\src\Model\RegistrationModel.ph p, dans la fonction activate. Dans cette fonction, il n'y a pas d'appel aux plugins

Pascal

[woluweb]

Bonjour Marc,

Comme il t'a été écrit sur mattermost, c'est prévu pour les contacts (j'ai trouvé dans components/com_contact/src/Controller/ContactController.php, dans la fonction _sendmail (ligne 244), il y a un appel aux com_fields.

Cependant, ce n'est pas le cas dans les appels aux mails templates de com_user.

Dans une précédente vie, tu avais fait l'éloge des plugins et, si je me rappelle bien, tu avais dit qu'un composant bien écrit devait avoir des plugins. Malheureusement, le composant com_mails n'a pas d'appel à des plugins avant l'appel à librairie MailTemplate et je n'ai pas trouvé comment modifier ce comportement standard.

Dans l'exemple que tu donnes (com_users.registration.admin.verification_request ), l'appel au mail template est fait dans components\com_sers\src\Model\RegistrationModel.ph p, dans la fonction activate. Dans cette fonction, il n'y a pas d'appel aux plugins

Pascal

Merci Pascal !
Je vois que tu es sur tous les dossiers

Si pour ce projet le client confirme qu'il souhaite avoir les champs personnalisés utilisateurs dans l'email, alors j'en profiterais bien pour que le développement sur mesure soit poussé dans Joomla même. J'imagine que le top du top serait de pouvoir utiliser le shortcode {field ID}, mais même une solution plus light me suffirait en ce qui me concerne.

Mais dans l'état actuel, si on éditait directement components\com_users\src\Model\RegistrationModel.p hp on pourrait injecter les Custom Fields (un peu comme j'ai fait dans mon Override de la Smart Search) ? Ou bien c'est plus complexe que ça ?

[pmleconte]

Bonsoir,

Peut-être une piste avec une présentation de Peter Martin : https://jug010.nl/images/presentatie..._corehacks.pdf voir la section 6 : Component with “own controller”

Il faut créer une surcharge sur com_user et modifier le default.php pour qu'il aille sur ton controller à la place de RegistrationController.php. Ensuite, tu dois pouvoir pointer sur ton model qui ajoutera les custom fields.

Pour l'instant, c'est de la théorie, mais, cela peut fonctionner en croisant fort les doigts....

Pascal

[woluweb]

Bonsoir,

Peut-être une piste avec une présentation de Peter Martin : https://jug010.nl/images/presentatie..._corehacks.pdf voir la section 6 : Component with “own controller”

Il faut créer une surcharge sur com_user et modifier le default.php pour qu'il aille sur ton controller à la place de RegistrationController.php. Ensuite, tu dois pouvoir pointer sur ton model qui ajoutera les custom fields.

Pour l'instant, c'est de la théorie, mais, cela peut fonctionner en croisant fort les doigts....

Pascal

waaaaaaah, comment t'arrives à remettre la main sur une info de 2012 !

Intéressant le coup de

<input type="hidden" name="task" value="my_own_controller.submit" />

Je vois Pe7er à Essen en Allemagne dans moins de 8 semaines (https://www.joomlacamp.de/).
Je sens qu'on va avoir une conversation intéressante

Tout grand merci pmleconte, une fois de plus !

[pmleconte]

Après quelques tests, cela fonctionne en ajoutant, pour com_user, dans le nouveau model :

          
 if (!empty($data['com_fields']) && $fields = FieldsHelper::getFields('com_users.user', $user, true, $data['com_fields'])) {
                $output = FieldsHelper::render(
                    'com_users.user',
                    'fields.render',
                    [
                        'context' => 'com_users.user',
                        'item'    => $user,
                        'fields'  => $fields,
                    ]
                );
                if ($output) {
                    $data['customfields'] = $output;
                }
            }
​

Les bons "endroits" sont dans la fonction activate et dans la fonction register.

Ce code récupère et concatène tous les champs personnalisés dans un champ CUSTOMFIELDS à ajouter soit dans le fichier de traduction pour chacun des messages que tu souhaites personnaliser, soit dans chaque modèle d'email de type utilisateur.
J'ai "un peu galéré" car il faut mettre customfields en majuscule sous la forme {CUSTOMFIELDS} et, si tu l'ajoutes dans les modèles d'email, les chaines de traduction telles que COM_USERS_EMAIL_REGISTERED_WITH_ADMIN_ACTIVATION_B ODY ne sont plus interprétées.

Note : si tu ajoutes des utilisateurs dans l'admin, il y a aussi un envoi de mail par le plugin user/joomla (fonction onUserAfterSave).

Remarque complémentaire sur les compatibilités avec les futures version Joomla : dans les fichiers controller et model que l'on crée, il y a pas mal de code deprecated in Joomla 6 et il faudra prévoir une mise à niveau.

Bonne journée,

Pascal

[pmleconte]

Encore moi,

Après quelques tests complémentaires, j'ai l'impression que Joomla ne sauvegarde pas les custom fields sur la création d'un nouvel utilisateur.

Peut-être me gourres-je ?

Pascal

[lefabdu51]

salut, tu as regarder cette table sql ? #_fields_values il me sembles que c est ici que sont stockées les valeurs des champs

[pmleconte]

La table fields_values ne contient pas les info. saisies sur la création d'un nouvel utilisateur en front. En backend, c'est OK.

Je cherche...

Pascal

[pmleconte]

C'est une histoire de droit sur les champs de type user.

Quand on est en mode "création", l'utilisateur de type public n'a aucun droit sur le champ.

Même s'il a le droit de saisir une valeur, il n'a pas le droit de modifier son contenu.

Dans le cas d'un champ du composant com_contact, il a les droits:



par contre, un champ de type User a :



En modifiant les droits du champ, c'est ok dans la base de données.

Pascal

[woluweb]

Waaaah, MERCI pmleconte !
Là j'ai de quoi faire

Yep effectivement, que ce soit pour com_content ou com_user, si les Utilisateurs doivent pouvoir éditer des champs persos en front-end il faut changer les ACL qui par défaut sont en "rouge".
Je me suis déjà fait surprendre plusieurs fois pcq quand je teste je suis Super User donc tout passe. Mais des Utilisateurs avec moins de droits ont les Champs Personnalisés "grisés" en front-end...

[pmleconte]

Bonjour,

Je viens de trouver une alternative J4/J5 "plus simple" pour utiliser un model personnalisé (c'est proposé par Sharky) : https://joomla.stackexchange.com/que...el/32099#32099

Pascal

[woluweb]

Mais il est inépuisable pmleconte !
Merci pour le tip !

[pmleconte]

Bonjour Marc,

Je pensais que tu savais que, quand on me donne un os à ronger, je reste dessus avec une certaine opiniâtreté ....

Bonne journée,

Pascal