Le site peut envoyer des notifications personnalisées selon différents critères. Ces notifications sont gérées par le plugin Notifications de Bracket Space (gratuit) et son extension Conditionals (payant).
Elles sont différentes des notifications natives de WordPress. Elles servent aux admins pour être informés des modifications faites par les contributeurs (chargés de com’, annie) non-admins.
Fonctionnement
On choisit :
- un déclencheur (une action sur le site)
- un type de notification (mail, SMS, etc.)
- un ou plusieurs destinataires
- une condition de déclenchement
Selon le déclencheur, le résultat va être différent ou ne pas marcher.
Problèmes connus
La doc n’est pas aidante
La documentation est orientée développeurs. Y’a pas de documentation utilisateur décente, notamment sur les merge tags, qui sont essentiels pour les déclenchement conditionnels.
Ça affecte directement l’écriture des règles. Il faut beaucoup d’essai-erreurs sans comprendre ce qui ne va pas avant d’arriver à écrire une règle qui marche. D’où les règles sont bizarres.
Le déclencheur / la condition ne fonctionne pas
- Voir supra : La doc n’est pas aidante.
- Voir infra : Astuces
On reçoit les mails en plusieurs fois
Le déclencheur « Article mis à jour » se lance quand un article est modifié, du point de vue de WordPress. Les mails arrivent donc à chaque événement WordPress, même s’ils ne sont pas significatifs pour l’utilisateur.
Le déclencheur n’est PAS l’action utilisateur de faire « Mettre à jour » l’article. C’est le simple fait de modifier l’article d’une quelconque façon, qui compte pour un événement aux yeux de WordPress.
Si on va dans les modifications récentes du site, on voit qu’elles sont souvent réunies en « événements similaires », pour n’afficher que ce qui est signifiant pour l’utilisateur. Ben le plugin de notif ne fait pas ça.
Astuces
Attention au « ou » inclusif
Si on met une condition complexe, le ou est inclusif. Les résultats peuvent être déroutants.
Exemple : On veut envoyer un mail quand l’utilisateur qui publie n’est pas X, Y ou Z.
On écrit :
Appliquer le déclencheur si ( l’utilisateur qui publie n’est pas X ou n’est pas Y ou n’est pas Z )
Mais quand X publie, le mail est quand même envoyé. C’est logique, car le calcul est le suivant :
- Il est FAUX que ce n’est pas X qui publie
- Il est VRAI que ce n’est pas Y qui publie
- Il est VRAI que ce n’est pas Z qui publie
- Au total : (faux ou vrai ou vrai) = VRAI
- La condition entre parenthèse est VRAIE
- On applique le déclencheur
À l’inverse, si on écrit autrement ça marche :
Ne pas appliquer le déclencheur si (l’utilisateur qui publie est X, ou Y, ou Z)
Quand X publie, aucun mail ne part. C’est logique : le calcul total aboutit toujours à une condition VRAIE, puisqu’il est au moins vrai que X a publié l’article. Mais cette fois-ci, on ne déclenche le mail que si la condition est fausse.
Déso pour le cours de logique.
Déclencheur basé sur le rôle de l’utilisateur
Apparemment c’est l’intitulé du rôle qu’il faut mettre :
- ❌ administrator
- ✅ Administrateur / administratrice
Déclencheur à la publication
Ne fonctionne que si l’article est public. Il faut utiliser le déclencheur dédié à la publication privée si on veut déclencher quand l’article est publié en privé.
Laisser un commentaire