Si vous saisissez des informations incorrectes dans les formulaires de commentaires (nom, adresse électronique, etc.), wordpress renvoie une page vide avec le message d'erreur correspondant. J'ai fait des recherches sur Internet, mais je n'ai pas trouvé de moyen de personnaliser cette réponse.
Quelqu'un sait-il comment faire ?
Pour ce problème particulier, j'ai fini par modifier \wp -comments-post.php directement - le moteur du thème ne vous permet pas de le personnaliser.
La description courte de ce que j'ai fait est de contourner l'utilisation de "wp_die()" et de faire en sorte que le script exécute "my_wp_die()" dans les scénarios où le commentaire du blog n'est pas validé.
Voici un exemple séquentiel :
1) L'utilisateur arrive sur la page de l'article (en invoquant single.php dans votre thème).
2) L'utilisateur saisit des informations dans les champs de commentaires (qui peuvent être validés ou non).
3) Le formulaire est envoyé à "wp-comments-post.php" avec l'URL de l'article comme paramètre afin de renvoyer les résultats de la validation à une page qui a les visuels appropriés (encadré : je n'ai pas pu utiliser une bibliothèque de modèles extérieurs que j'ai écrite et qui est intégrée dans le thème au lieu de dupliquer le modèle de mon site dans le thème) et les champs du formulaire de l'utilisateur.
4) wp-comments-post.php fera appel à my_wp_die() lorsqu'il n'y a pas de validation (y compris une vérification des doublons à partir de /comment.php:fonction wp_allow_comment() ), ou my_wp_success() si le commentaire est valide et est publié.
5) wp-comments-post.php renverra l'utilisateur à l'URL de l'article (permalien d'origine).
6) single.php dans le thème affichera le message d'erreur/succès et le nouveau commentaire.
Je n'ai rien trouvé sur la personnalisation de la page d'erreur de manière simpliste, mais un rapide coup d'œil à wp-comments-post.php m'indique que lorsqu'il y a une erreur, la fonction suivante est exécutée wp_die qui génère la page d'erreur. Il semble prendre des arguments qui contrôlent la sortie de la page d'erreur mais je n'ai pas pu trouver de détails sur ce que ces options pourraient être. En modifiant un peu wp_die, vous devriez être en mesure d'afficher votre propre page d'erreur personnalisée. Je ne sais pas si cela vous aidera mais c'est un point de départ.
Dans le même ordre d'idées, vérifiez que votre page d'erreur s'affiche correctement dans Internet Explorer. Je ne le mentionne que parce que j'ai récemment rencontré ce problème et que j'ai malheureusement passé plusieurs heures à le résoudre.
En bref, la page d'erreur générique que WordPress génère (par exemple, après l'échec de la validation du "commentaire de l'utilisateur") est envoyée au navigateur avec un code d'état HTTP de "500 Internal Server Error". Curieusement, Internet Explorer (avant la version 7) ignore les pages d'erreur envoyées avec "500". si la page représente moins de 512 octets. Le message d'erreur générique de Microsoft "This page cannot be displayed" s'affiche à la place.
Les responsables de WordPress connaissent ce problème et ont écrit la fonction wp_die() de manière à ce que la page d'erreur soit supérieure à 512 octets. Malheureusement, ils ont négligé de tenir compte des serveurs web qui utilisent la compression gzip (c'est-à-dire qu'ils réduisent la taille de la page web avant de l'envoyer sur le réseau) pour des raisons de performances. Internet Explorer 5/6 n'affiche pas les pages d'erreur génériques de WordPress (v2.7 et antérieures) si le serveur web utilise la compression gzip.
Si cela peut aider d'autres personnes qui rencontrent ce problème, j'ai rédigé un article de blog décrivant le problème de manière plus détaillée (avec des captures d'écran), y compris un lien vers le bogue WordPress que j'ai ouvert et des instructions pour une solution de contournement temporaire qui peut être utilisée jusqu'à ce que le bogue soit correctement corrigé. Voir http://www.clintharris.net/2009/ie-512-byte-error-pages-and-wordpress/ pour plus d'informations.
J'étais moi-même en train de me poser la question, la dernière version de WP ne semble pas avoir d'autres améliorations pour autant que je puisse voir.
Cependant, ma solution a été d'effectuer une validation de formulaire côté client en Javascript. Il suffit d'attacher un gestionnaire d'événements au bouton "submit" (par exemple, avec submit.onclick), puis de le lier à votre fonction de validation JS pour vérifier les données et fournir un retour d'information en cas d'échec (comme une bordure rouge autour du champ de formulaire incriminé).
N'oubliez pas d'utiliser preventDefault si les données ne sont pas validées, afin que le formulaire ne soit pas soumis !
Bien sûr, le formulaire sera toujours soumis si Javascript n'est pas activé, et dans ce cas, l'utilisateur verra toujours la page d'erreur WP par défaut. Pour contourner ce problème, vous pourriez utiliser une option PHP comme indiqué précédemment, mais je pense que cela demande plus de travail.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
