Dans l’architecture de WordPress, certains fichiers sont peu documentés et c’est le cas de wp-mail.php, un script encore présent dans le noyau WordPress, mais très rarement utilisé aujourd’hui. Destiné à automatiser la publication de contenu à partir d’emails, il fait partie des fonctionnalités historiques du CMS. Dans cet article, nous vous proposons d’explorer en profondeur le rôle de ce fichier, son fonctionnement technique, son utilité réelle aujourd’hui et les raisons pour lesquelles il reste inclus dans WordPress malgré son obsolescence partielle. Que vous soyez développeur WordPress, administrateur système ou simplement curieux, voici tout ce qu’il faut savoir sur wp-mail.php.

wp-mail.php : Un outil pour publier du contenu par email

Le fichier wp-mail.php est l’un des composants les plus anciens de WordPress, introduit dès les premières versions du CMS (autour de WordPress 1.2, publié en mai 2004). Il incarne une approche ingénieuse, à une époque où les interfaces web n’étaient pas encore ergonomiques, et où la publication de contenu à distance nécessitait des solutions flexibles et accessibles. Son objectif : permettre à un utilisateur de publier automatiquement un article sur son site WordPress en envoyant un simple email à une adresse prédéfinie. Cette fonctionnalité repose sur un principe simple : interpréter le contenu d’un email comme un article. WordPress, via ce fichier, se connecte à une boîte aux lettres électronique grâce au protocole POP3 (Post Office Protocol version 3), récupère les messages entrants non lus, en extrait le corps du message, puis le publie dans la base de données WordPress comme un post de type post (article standard).

Qu’est-ce que le protocole POP3 ?

POP3 est un protocole standard utilisé pour récupérer les emails depuis un serveur distant. Contrairement à IMAP, qui conserve les messages sur le serveur, POP3 les télécharge puis les supprime généralement du serveur (sauf configuration spécifique). WordPress utilise une classe POP3 interne, définie dans le fichier class-pop3.php, pour établir cette connexion et lire les messages.

Voici un résumé des étapes techniques du processus :

1. Le script wp-mail.php est lancé, soit manuellement depuis une URL, soit automatiquement via une tâche cron côté serveur ;
2. Il charge l’environnement WordPress via wp-load.php, donnant accès à la configuration et aux fonctions du CMS ;
3. WordPress appelle la fonction get_pop3_class(), qui instancie un objet de la classe POP3 permettant de dialoguer avec la boîte mail ;
4. La fonction retrieve_post_from_mail() analyse chaque message disponible, en vérifie l’expéditeur (pour éviter les spams), puis en extrait le contenu, le sujet (comme titre), et publie le tout sous forme d’un article.

La publication par email via wp-mail.php est donc une automatisation d’un workflow de publication distant, où l’email devient le vecteur principal de contenu. Cette méthode était particulièrement utile avant l’introduction de l’éditeur visuel TinyMCE (WordPress 2.0) et bien avant Gutenberg (WordPress 5.0), qui ont transformé l’expérience de publication dans le navigateur.

Paramétrage dans l’administration WordPress

Les paramètres nécessaires à l’utilisation de wp-mail.php sont centralisés dans l’interface d’administration WordPress, plus précisément dans Réglages > Écriture. Ces réglages permettent de configurer les informations suivantes :

• Serveur de messagerie POP3 : généralement un serveur de type pop.votredomaine.com ou mail.votredomaine.com.
• Port : par défaut, POP3 utilise le port 110, mais le port 995 est courant pour les connexions sécurisées via SSL/TLS.
• Nom d’utilisateur : identifiant utilisé pour se connecter à la boîte mail, souvent une adresse email complète.
• Mot de passe : mot de passe associé à l’adresse email pour permettre la connexion POP3.
• Catégorie par défaut : catégorie dans laquelle seront classés les articles publiés par email.

Il est important de noter que ces réglages sont statiques et qu’il n’existe pas, en natif, de mécanisme de cryptage du mot de passe ou de gestion avancée des utilisateurs autorisés. Le contrôle de la publication repose essentiellement sur la vérification de l’expéditeur de l’email, ce qui peut poser des problèmes de sécurité en cas d’usurpation d’adresse ou de configuration laxiste du serveur de messagerie.

Pour la petite histoire du fichier wp-mail dans WordPress

La fonctionnalité de publication par email a été activement utilisée dans les versions 1.x et 2.x de WordPress, à une époque où les interfaces web étaient plus limitées. Avec l’arrivée de l’éditeur visuel (WordPress 2.0, 2005), la montée en puissance des plugins comme Jetpack, et surtout la sortie de l’application mobile officielle WordPress (2008), les usages ont changé. Dès WordPress 3.x (2010-2014), le fichier wp-mail.php est resté dans le noyau pour des raisons de rétrocompatibilité, mais il a cessé d’être mis en avant dans la documentation officielle. Depuis WordPress 5.x, avec l’introduction de Gutenberg et de l’API REST, la logique de publication distante s’est orientée vers des solutions plus sécurisées, plus souples et adaptées à l’écosystème moderne (API, JSON, OAuth, etc.).

À ce jour, wp-mail.php continue d’être livré avec WordPress, mais il est considéré comme une fonctionnalité obsolète non officiellement dépréciée. Elle n’est pas activée par défaut et son usage est fortement déconseillé sur les sites en production sans sécurisation adaptée.

L’automatisation via tâche cron

Pour que la récupération des emails soit réellement automatique, il est nécessaire de configurer une tâche cron côté serveur (ou cron job) qui appelle régulièrement le fichier wp-mail.php. Par exemple :

*/10 * * * * wget -q -O - https://monsite.com/wp-mail.php > /dev/null 2>&1

Cette commande exécutera le script toutes les 10 minutes. Cependant, cette approche suppose que le fichier wp-mail.php soit accessible publiquement, ce qui représente un si le serveur email n’est pas correctement verrouillé ou si l’expéditeur est falsifié. Il est donc recommandé de restreindre l’accès à ce fichier via un fichier htaccess ou une configuration Nginx adaptée.

Analyse technique du fichier wp-mail.php

Le fichier wp-mail.php est un script PHP autonome situé à la racine de l’installation WordPress. Il est accessible via une simple URL, telle que https://monsite.com/wp-mail.php, et peut être exécuté manuellement ou via une tâche planifiée. Ce script a été conçu pour exécuter une fonction unique : se connecter à une boîte mail via le protocole POP3, lire les messages entrants, et transformer chaque email en un article WordPress. Sa structure est linéaire, sans interface utilisateur, et repose sur un enchaînement logique d’étapes automatisées. Chaque étape utilise des fonctions natives de WordPress ou des classes internes spécifiques au traitement des emails. Pour mieux comprendre son fonctionnement, voici une présentation technique sous forme de tableau, étape par étape :

Étape	Description technique
Chargement du cœur WordPress	Le fichier commence par inclure wp-load.php, ce qui permet d’initialiser l’environnement WordPress complet : accès à la base de données, chargement des fonctions et classes globales, configuration des options.
Chargement de la classe POP3	WordPress utilise la fonction get_pop3_class() pour instancier un objet de connexion au serveur de messagerie. Cette fonction renvoie une instance de la classe définie dans le fichier class-pop3.php, situé dans le dossier wp-includes.
Connexion à la boîte mail	Grâce aux identifiants (serveur, port, nom d’utilisateur, mot de passe) définis dans les réglages d’écriture, WordPress établit une connexion POP3 au serveur de messagerie. Il vérifie les messages non lus en attente dans la boîte.
Lecture des messages	Les emails sont parcourus un à un. Le corps du message est extrait, ainsi que l’expéditeur, le sujet (qui deviendra le titre de l’article) et éventuellement les pièces jointes. Cette opération est gérée par la fonction retrieve_post_from_mail().
Filtrage de sécurité	WordPress tente de vérifier si l’expéditeur de l’email est autorisé à publier. Cette vérification est sommaire et repose souvent sur une simple correspondance d’adresse email, ce qui peut être insuffisant contre l’usurpation.
Création de l’article	Si l’email est validé, un nouvel article est inséré dans la base de données via la fonction wp_insert_post(). Le contenu du message devient le contenu de l’article, le sujet devient le titre, et les métadonnées (catégorie, statut, etc.) sont automatiquement appliquées.
Suppression ou archivage du message	Après traitement, le message peut être supprimé de la boîte, ou marqué comme lu, selon les options du serveur. Cela évite les doublons lors des prochaines exécutions du script.
Aucun contrôle d’accès	Le fichier ne comporte aucune authentification. Il peut être lancé par toute personne ayant accès à son URL, ce qui constitue un risque de sécurité majeur. Un accès non filtré peut entraîner une publication non autorisée ou un déni de service (DoS).

Ce fonctionnement automatisé montre la logique simple mais rigoureuse du script. Toutefois, l’absence de mécanismes de sécurité modernes (comme une authentification par token, une protection par mot de passe ou un filtrage IP) rend l’usage de wp-mail.php peu recommandé dans un environnement de production non sécurisé. Il est conseillé de restreindre l’accès à ce fichier via un fichier .htaccess ou via la configuration du serveur web (Apache, Nginx) en interdisant les accès publics. Par exemple :

<Files wp-mail.php>
  Order deny,allow
  Deny from all
  Allow from 127.0.0.1
</Files>

Ou bien côté Nginx :

location = /wp-mail.php {
  allow 127.0.0.1;
  deny all;
}

Ce niveau de précaution est indispensable si le fichier doit être utilisé dans un contexte spécifique (automatisation interne, tests, maintenance). Pour tous les autres cas, l’utilisation d’outils modernes comme l’API REST WordPress ou des plugins sécurisés reste préférable.

Notez que si vous ne faites rien, vous pourrez observer en front-end ceci :

Pourquoi cette fonctionnalité est-elle devenue obsolète ?

Lors de ses débuts dans les années 2000, WordPress se voulait simple, adaptable et fonctionnel, même dans des environnements à connectivité réduite. Dans ce contexte, la possibilité de publier un article en envoyant un simple email représentait une avancée majeure. À l’époque, les smartphones n’étaient pas encore omniprésents, les interfaces administratives web étaient souvent peu ergonomiques, et de nombreux utilisateurs accédaient à Internet via des connexions lentes ou instables. Le script wp-mail.php répondait donc à un vrai besoin : permettre une publication distante, rapide, et sans interface graphique.

Mais avec l’évolution du web, cette solution technique a progressivement perdu de sa pertinence. Plusieurs facteurs ont contribué à son obsolescence :

• Dépendance au protocole POP3 : POP3, utilisé pour interroger les boîtes mail dans wp-mail.php, est un protocole ancien, non conçu pour des accès simultanés ou une gestion évoluée des messages. Il a été largement supplanté par IMAP, qui permet de gérer les messages directement sur le serveur de manière synchrone et multi-client, ou par des solutions API comme Gmail API, bien plus modernes et sécurisées ;
• Nécessité d’une tâche planifiée (cron job) : Contrairement aux flux en temps réel permis aujourd’hui par les webhooks ou les API REST, wp-mail.php ne s’exécute que sur appel direct. Cela impose une configuration manuelle d’un cron job sur le serveur, une opération technique que la majorité des utilisateurs WordPress ne sont pas capables ou autorisés à mettre en place (notamment sur des hébergements mutualisés) ;
• Instabilité du contenu des emails : Les emails peuvent contenir une variété de formats (HTML, texte brut, encodages variés, pièces jointes, signatures automatiques, réponses en chaîne, etc.). Cette diversité rend difficile l’extraction fiable du contenu pertinent pour générer un article cohérent. Le script retrieve_post_from_mail() tente de gérer ces cas, mais reste limité et sujet à des erreurs ou à des comportements imprévus ;
• Vulnérabilité au spam et à l’usurpation d’adresse : Le système repose sur la vérification de l’adresse de l’expéditeur pour autoriser ou non la publication. Or, cette méthode est fragile, car une adresse email peut facilement être falsifiée. Sans authentification robuste, aucun mécanisme de validation de jeton (token) ni journalisation des accès, le fichier est exposé à des risques d’exploitation par des tiers malveillants ;
• Émergence des applications mobiles WordPress : Depuis 2008, WordPress propose une application mobile officielle pour Android et iOS. Ces applications offrent une interface conviviale pour publier, gérer les commentaires, modifier les articles et même recevoir des notifications. Elles ont rendu obsolète le besoin de publication par email, en fournissant une solution mobile native, intuitive et sécurisée ;
• Évolution de la philosophie de WordPress : Le CMS a adopté une approche plus modulaire et orientée développeurs, avec l’introduction de l’API REST (WordPress 4.7, 2016), qui permet de gérer toutes les données du site à distance, de manière structurée, sécurisée et conforme aux standards modernes. Cette API a remplacé dans de nombreux cas l’usage de scripts externes comme wp-mail.php.

Face à ces limitations, l’équipe de développement de WordPress n’a pas supprimé wp-mail.php mais l’a laissé en place pour des raisons de rétrocompatibilité. Cela signifie qu’un utilisateur qui s’appuie sur cette fonctionnalité depuis des années ne verra pas son site cassé lors d’une mise à jour. Cependant, aucune évolution significative n’a été apportée à ce script depuis plusieurs versions majeures, et la documentation officielle de WordPress ne fait plus mention de son usage recommandé. Dans les faits, wp-mail.php est considéré comme une fonctionnalité dépréciée de fait, bien que non déclarée comme telle dans le code source. Cela signifie qu’elle est tolérée, mais son usage est déconseillé dans les environnements modernes, en particulier pour les sites exposés au public. Son maintien dans le noyau WordPress relève aujourd’hui davantage d’un souci de compatibilité historique que d’un véritable besoin fonctionnel.

Pour ceux qui souhaitent mettre en place un système de publication automatique ou à distance, il existe aujourd’hui des solutions bien plus robustes :

• Utiliser l’API REST de WordPress, avec authentification par cookie ou token JWT ;
• Intégrer des services tiers comme Zapier, Make (ex-Integromat) ou IFTTT pour automatiser la publication à partir d’emails ou de formulaires Gravity forms par exemple ;
• Développer un plugin sur mesure, qui intègre une couche de sécurité, de validation et de journalisation

Le fichier wp-mail.php de WordPress est un vestige des débuts du CMS (un peu comme le fichier xmlrpc par exemple) pensé pour permettre la publication d’articles via un simple envoi d’email. Bien que techniquement fonctionnel, son usage est devenu marginal face à l’évolution des pratiques, des outils mobiles et des exigences de sécurité. Il constitue néanmoins un exemple intéressant de script WordPress autonome, manipulant directement la base de données et les mécanismes de publication. Si vous êtes développeur ou administrateur, vous pouvez encore l’utiliser pour des cas très spécifiques, notamment dans des environnements restreints ou pour des systèmes automatisés à des fins internes. Toutefois, il est essentiel de protéger son accès (via un fichier .htaccess ou des règles côté serveur) et d’en comprendre les limites. Pour les besoins modernes, des alternatives comme les API REST de WordPress ou les plugins de publication distants sont fortement recommandées.