WordPress : la biographie reste après l’effacement des données personnelles

Pourquoi « Terminé » ne suffit pas pour la biographie

Une demande d’effacement des données personnelles est indiquée comme terminée dans WordPress. Pourtant, en rouvrant le profil, on retrouve le texte des Informations biographiques. C’est le symptôme décrit sur le forum WordPress.org. Sur un site qui affiche les biographies, le texte peut aussi rester visible dans l’encadré d’un article ou sur une archive d’auteur. Vérifiez séparément ces deux constats : une biographie encore stockée peut être absente du site public, et une biographie supprimée du profil peut rester visible ailleurs.

Le cœur distingue l’export de l’effacement. L’exporteur de profil sait lire la description du compte. Dans le cœur examiné, le gestionnaire d’effacement enregistré par défaut traite les données personnelles des commentaires ; aucun gestionnaire natif d’effacement du profil ne vide ce champ. La biographie native est une métadonnée du compte nommée description. La présence ou l’absence d’un commentaire n’a donc pas pour effet de déclencher son effacement. Une extension peut enregistrer ses propres traitements : le résultat observé avec une configuration donnée dépend aussi de ces traitements.

Prenez le statut de la demande pour ce qu’il indique : le parcours d’effacement a atteint son état final. Pour savoir ce qui a disparu, il faut vérifier les champs et les écrans visés. Si la demande ne concerne que la biographie, vous pouvez traiter ce champ indépendamment du compte, du nom d’affichage et de l’attribution des articles. Si elle vise aussi le nom, des commentaires ou des données d’extensions, ouvrez un contrôle distinct pour chaque source ; une biographie vide ne vous renseigne pas sur ces autres données.

1. Identifiez le compte via le canal de traitement habituel et relevez son identifiant interne. Deux auteurs peuvent avoir le même nom d’affichage ; une page publique ou un pseudonyme ne suffit pas à confirmer la cible.
2. Classez l’observation : « champ rempli dans le profil », « texte visible par un visiteur », ou les deux. Notez les URL concernées dans un dossier de suivi à accès restreint.
3. Repérez un article qui doit rester attribué au compte. Il servira de témoin après l’intervention. Notez le résultat attendu : la biographie disparaît, l’article reste consultable et attribué au même compte.

Reproduire le parcours avec un compte fictif

Utilisez une copie isolée de WordPress. Si vous souhaitez comprendre le rôle du thème ou d’une extension, gardez la même configuration que le site concerné sur cette copie. Interceptez les e-mails de recette dans une boîte de test avant de créer la demande. Si le courrier de la copie part encore vers l’extérieur ou si des extensions envoient des notifications à de vrais comptes, arrêtez ici et isolez-les. Le diagnostic n’a pas besoin du texte de la personne ni d’un export de ses données.

Dans la copie, créez un auteur de test avec un marqueur reconnaissable, par exemple BIO-RECETTE-741. Publiez un article de test attribué à ce compte uniquement dans la recette. Vérifiez si le thème expose le marqueur sur l’article ou sur l’archive de l’auteur. Un thème sans bloc biographique peut très bien produire un résultat public négatif avec un champ rempli. Ce résultat initial vaut comme témoin : il permet de distinguer une page qui n’a jamais affiché le champ d’une page réellement corrigée.

Un commentaire de test est facultatif. Si vous en ajoutez un pour comparer les mécanismes, associez-le à l’adresse fictive utilisée pour la demande. Un changement de données du commentaire accompagné d’une biographie intacte confirme deux chemins de traitement distincts sur cette copie. Laissez les autres valeurs du profil intactes et utilisez le même identifiant d’auteur tout au long du contrôle. Évitez l’effacement forcé pour ce scénario : le chemin normal est utile pour savoir à quel moment relire le champ.

1. Dans Comptes > Tous les comptes, modifiez l’auteur fictif. Enregistrez le marqueur dans Informations biographiques, puis rouvrez la fiche et vérifiez qu’il a été conservé.
2. Dans Outils > Effacer les données personnelles, créez une demande pour l’adresse fictive. Confirmez depuis le message intercepté, puis lancez l’effacement de la demande confirmée depuis le tableau de bord. Les libellés peuvent varier selon la traduction.
3. Attendez l’état final et relevez les éventuels messages sur les éléments conservés. Si le processus échoue ou reste en attente, consignez cet état séparément : vous n’avez pas encore testé le comportement après un effacement terminé.
4. Rouvrez le profil, puis contrôlez les mêmes URL en visite anonyme. Si la biographie est déjà vide, notez la configuration d’essai et recherchez le traitement supplémentaire qui a pu la modifier avant de conclure.

Vider le champ natif en conservant le compte

Sur une copie, commencez par le formulaire du profil : la modification y est limitée à un champ et la vérification est immédiate. Pour appliquer la même correction au cas traité par votre équipe, assurez-vous que cette modification fait partie de la demande validée et que votre compte peut modifier le profil concerné. Si l’écran vous renvoie à votre propre profil ou si le bouton d’enregistrement est indisponible, ne modifiez rien : faites intervenir la personne qui dispose du droit de modifier le compte cible.

La suppression du compte est une autre opération. Selon l’option choisie, elle peut supprimer ou réattribuer du contenu ; elle ne constitue pas un raccourci pour retirer une biographie tout en conservant l’auteur. De même, masquer l’encadré dans le thème peut réduire la visibilité sur une page, mais laisse la valeur native en base et peut la laisser disponible pour un autre modèle. Le bon premier geste est de vider le champ à la source, puis de mesurer les copies restantes.

En multisite, le profil WordPress et ses métadonnées utilisateur sont partagés au niveau du réseau. Le fait d’ouvrir l’administration d’un sous-site ne rend pas la biographie native propre à ce sous-site. Si le changement doit concerner un seul sous-site, vérifiez d’abord si le texte appartient à un champ local de thème ou d’extension. Faites valider la portée au niveau du réseau avant toute modification du profil partagé.

1. Ouvrez Comptes > Tous les comptes > Modifier pour l’identifiant vérifié. Dans la rubrique À propos de l’utilisateur, repérez Informations biographiques. Ne changez ni le rôle, ni l’adresse, ni le nom affiché.
2. Sélectionnez tout le contenu du champ, y compris les espaces ou les retours à la ligne, laissez-le vide et cliquez sur Mettre à jour le compte. Si un formulaire d’extension se trouve juste à côté, vérifiez que vous avez bien modifié le champ natif.
3. Quittez la fiche, puis rouvrez-la depuis la liste des comptes. Si le texte revient dès cette lecture, la source est encore alimentée : contrôlez le bon identifiant, l’enregistrement et un éventuel import ou mécanisme de synchronisation du profil.
4. Consultez l’article témoin dans une fenêtre privée. Vérifiez le nom affiché et l’attribution de l’article, puis la présence ou l’absence de la biographie au même emplacement qu’avant. Notez séparément le résultat du formulaire et celui de la page publique.

Suivre le texte lorsqu’il reste visible

Si le profil est vide mais que le texte apparaît encore, ouvrez d’abord l’URL exacte et identifiez l’élément qui contient le texte. Sur un article, il peut s’agir d’un encadré d’auteur dans le modèle, d’un bloc modifié à la main ou d’une citation dans le corps. Sur une fiche d’équipe, le texte peut venir d’un contenu WordPress indépendant du compte. Dans l’éditeur de site, quand le thème le propose, vérifiez le modèle utilisé par l’URL ; dans un constructeur de pages, vérifiez l’élément correspondant. Le même libellé « Biographie » peut renvoyer à des champs différents selon le modèle.

Pour départager une copie et une source active, comparez la page telle que la voit un visiteur à une réponse fraîche du même modèle dans la recette. Utilisez le contournement de cache prévu par votre hébergeur s’il est disponible et que vous pouvez confirmer ce qu’il contourne. Une fenêtre privée élimine l’essentiel de l’historique local, mais le cache du site ou du CDN reste commun aux visiteurs. Une chaîne de requête ajoutée à l’URL n’est pas une preuve de contournement : certaines couches l’ignorent. Si vous ne pouvez pas obtenir de réponse fraîche de manière sûre, faites vérifier la couche de cache par la personne qui la gère.

Un profil natif vide et un texte présent sur une réponse fraîche orientent vers une deuxième source. Éditez cette source identifiée : champ d’une extension de membres, fiche d’équipe, bloc réutilisé ou copie écrite dans un article. Sur la recette, vous pouvez remplacer provisoirement son texte fictif par un autre marqueur pour voir quelles pages suivent cette modification. Cette comparaison est plus précise que de désactiver tous les composants. Si une réponse fraîche n’a plus le texte mais que le visiteur le reçoit encore, purgez les URL touchées après avoir corrigé leur source et suivez le diagnostic des caches WordPress.

1. Relevez une URL où le texte était visible et une URL témoin où il ne l’était pas. Comparez les réponses sans utiliser une session d’administration comme témoin de la vue publique.
2. Si le texte subsiste dans une réponse fraîche, localisez sa source par un marqueur différent en recette. Corrigez cette source et vérifiez à nouveau l’URL avant de purger.
3. Si le texte ne subsiste que dans une ancienne réponse, purgez la page et les surfaces reliées qui contenaient cette copie, puis ouvrez-les comme un nouveau visiteur. Si une page reste positive, reprenez son diagnostic plutôt que d’élargir la purge au hasard.

Contrôler le champ avec WP-CLI sans afficher la valeur

Cette variante sert lorsque vous avez un terminal autorisé sur la copie, quand plusieurs fiches se ressemblent ou lorsque vous voulez répéter le contrôle sans recopier le texte. Elle vérifie que l’identifiant correspond à un compte puis indique seulement si la métadonnée native est vide après retrait des espaces en bordure. Elle ne liste pas les comptes, ne lit pas les champs des extensions et ne décide pas si la donnée est visible publiquement. Une valeur inattendue est signalée comme erreur : conservez cette distinction avec le résultat « vide ».

Enregistrez le code ci-dessous sous /chemin/prive/verifier-bio.php, hors de la racine publique. Remplacez le dossier, l’URL et l’identifiant fictifs dans la commande wp --path="/chemin/recette" --url="https://recette.example.test" eval-file "/chemin/prive/verifier-bio.php" 123. Vérifiez d’abord l’installation et l’environnement en suivant le guide sur le ciblage de WP-CLI. L’option --url choisit le contexte du site ; elle n’isole pas les données utilisateur d’un sous-site en multisite. Cette commande charge WordPress. Ne l’exécutez pas sur une cible incertaine et n’ajoutez pas --skip-wordpress, car le script utilise les fonctions de WordPress.

Un résultat BIO_PRESENTE indique qu’il reste un contenu stocké, même si un thème l’ignore. BIO_VIDE signifie que le champ lu ne contient plus de texte utile à ce contrôle. Après l’enregistrement du profil, relancez la même commande et comparez les deux états. Si vous obtenez une erreur ou si une extension alimente la biographie à partir d’une autre valeur, revenez au contrôle de la fiche et du composant concerné. Évitez d’utiliser une commande qui affiche directement la métadonnée : le contenu finirait dans le terminal ou dans une trace d’exécution.

<?php
$id = filter_var($args[0] ?? null, FILTER_VALIDATE_INT, [
    'options' => ['min_range' => 1],
]);
if (count($args) !== 1 || $id === false) {
    WP_CLI::error('Indiquez un seul ID de compte entier et positif.');
}
if (!get_userdata($id)) {
    WP_CLI::error('Compte introuvable sur cette installation.');
}
$description = get_user_meta($id, 'description', true);
if (!is_string($description)) {
    WP_CLI::error('Format inattendu pour la biographie native.');
}
WP_CLI::log(trim($description) === '' ? 'BIO_VIDE' : 'BIO_PRESENTE');

Décider si la correction peut être clôturée

Il faut un résultat distinct pour le stockage, l’affichage et l’intégrité du site. Sur la fiche, la valeur doit rester vide après une nouvelle ouverture. Sur les pages où la biographie était visible, le visiteur ne doit plus recevoir le texte, même dans le code source de la page si le thème le conserve dans un bloc masqué. Le lien auteur et les articles qui doivent être conservés doivent encore fonctionner. Si une page échoue à l’un de ces contrôles, la fiche de suivi doit dire lequel. Un résultat positif sur deux surfaces ne permet pas de déduire l’état de la troisième.

Selon le site, vérifiez également les pages paginées de l’auteur, les variantes de langue, les gabarits mobiles qui chargent une réponse différente ou la fiche de membre qui présente la même personne. Les flux et autres sorties de publication ne reproduisent pas forcément le contenu de la page visible. Ne contrôlez que les sorties réellement proposées par le site, par exemple celles recensées avec la méthode de vérification des flux WordPress. Ne réutilisez pas un ancien export de données comme test de l’état courant : c’est une copie créée à une autre date. Inutile de générer un nouvel export complet si la question porte seulement sur le champ natif.

Pour le suivi, notez la date, les rôles utilisés, l’identifiant interne dans le dossier autorisé, le statut de la demande et les résultats « présent » ou « absent » par surface. Utilisez la valeur fictive pour les captures de recette. Dans le cas réel, n’ajoutez ni texte de biographie ni export ni adresse dans des captures et des journaux partagés. Si une copie externe est encore visible, documentez son propriétaire et son statut séparément : vider le profil WordPress ne retire pas une page contrôlée par un tiers.

1. Vérifiez le champ après réouverture et répétez le contrôle public après la purge ou après le délai de cache prévu, avec une session sans compte.
2. Vérifiez au moins un article attribué au compte et sa destination d’auteur. Si l’auteur a changé ou si l’article a disparu, arrêtez et examinez le changement effectué avant de déclarer le cas clos.
3. Distinguez ce que vous avez vérifié, ce qui dépend d’une extension et ce qui reste à traiter hors du site. Si la demande couvre d’autres données, poursuivez les contrôles correspondants dans le même dossier.

Prévoir le retour arrière sans republier la biographie

Sur la recette, vous pouvez remettre le marqueur fictif dans la fiche pour confirmer le lien entre source et affichage, puis l’effacer à nouveau avant de terminer. Sur un site réel, si le mauvais compte a été modifié ou si un contenu a été touché, arrêtez les changements et faites valider la correction par la personne responsable du traitement. Pour un problème de mise en page, réparez le modèle ou la condition d’affichage : restaurer la biographie pour masquer un défaut visuel republierait le texte.

Une restauration plus large peut réintroduire une biographie déjà retirée. Quand une restauration est nécessaire pour un autre incident, contrôlez la copie isolée et repassez les corrections pertinentes avant sa remise en service. Les sauvegardes, les journaux ou les exports précédents suivent leur propre périmètre de traitement : le statut de WordPress ne permet pas d’en déduire l’état. Ne créez pas une nouvelle copie de la donnée pour démontrer qu’elle a été supprimée du profil.

Si le champ se remplit à nouveau alors que le bon compte a été modifié, recherchez qui écrit la valeur : synchronisation de membres, import planifié ou extension de profil. Une nouvelle purge ne bloquera pas cette écriture. En cas de doute, transmettez un cas réduit en recette, avec le marqueur fictif, l’heure du retour de la valeur, les composants actifs qui gèrent les profils et les surfaces touchées. L’équipe pourra reproduire le problème sans avoir besoin du texte personnel.