HTML5 : corriger l'erreur "The frameborder attribute on the iframe element is obsolete. Use CSS instead." photo

HTML : corriger les valeurs rel non reconnues par le validateur W3C

Publié le 13 mai 2026 by Matt Biscay · Lecture: 6 minutes

Sur votre site ou blog, vous avez peut-être ajouté un lien vers un profil social, une page d’auteur, une page de vérification ou un service externe.

Le problème, c’est que certains services demandent parfois d’ajouter une valeur particulière dans l’attribut rel. Or toutes les valeurs ne sont pas forcément reconnues par le validateur HTML.

Vous pouvez alors obtenir une erreur de ce type dans le validateur W3C :

Keyword publisher is not registered

Ou, selon le cas :

The string publisher is not a registered keyword or absolute URL.

Cette erreur signifie que la valeur utilisée dans rel n’est pas reconnue comme un type de lien HTML valide ou comme une extension enregistrée.

Ancien exemple : Google+ et rel=”publisher”

À l’époque, Google+ proposait d’ajouter un lien de ce type vers une page éditeur :

<a
  title="Google+"
  href="https://plus.google.com/114535411372700844744"
  rel="publisher nofollow"
>Google+</a>Code language: HTML, XML (xml)

Le validateur HTML pouvait alors renvoyer :

Keyword publisher is not registered

Google+ n’existe plus, et rel="publisher" n’a plus d’intérêt pratique pour un site moderne. Il vaut donc mieux remplacer cet exemple par un cas actuel : les liens de vérification de profil, notamment avec Mastodon.

WordPress : récupérer les emails des utilisateurs et commentateurs

Publié le 12 mai 2026 by Matt Biscay · Lecture: 8 minutes

Voici plusieurs méthodes pour récupérer la liste des adresses email des utilisateurs et des commentateurs d’un site WordPress.

On peut le faire directement en SQL, avec WP-CLI, ou en exportant un fichier CSV. La meilleure méthode dépend de votre accès au serveur, du volume de données, du besoin exact, et du contexte dans lequel vous voulez utiliser ces emails.

Petite précision avant de commencer : une adresse email est une donnée personnelle. Techniquement, l’export est simple. Juridiquement, l’usage doit rester conforme au consentement donné par les personnes et à votre politique de confidentialité. Pour une newsletter ou de la prospection, on ne mélange pas “a commenté un article en 2014” avec “a demandé à recevoir mes emails marketing”. La CNIL rappelle que, pour les particuliers, la prospection par email nécessite en principe un consentement préalable, libre, spécifique, éclairé et univoque. CNIL : prospection commerciale par courrier électronique

Emails des membres WordPress

Dans WordPress, les utilisateurs enregistrés sont stockés dans la table wp_users si le préfixe de base de données est wp_. Cette table contient notamment la colonne user_email. La documentation du schéma de base WordPress liste bien wp_users comme table des utilisateurs. WordPress Codex : Database Description

La requête SQL la plus simple pour récupérer les emails des membres est :

SELECT DISTINCT user_email
FROM wp_users
WHERE user_email <> ''
ORDER BY user_email ASC;Code language: HTML, XML (xml)

La clause DISTINCT évite les doublons. Le GROUP BY n’est pas nécessaire ici, car on ne fait pas d’agrégation. DISTINCT suffit.

Si votre préfixe WordPress n’est pas wp_, adaptez le nom de table :

SELECT DISTINCT user_email
FROM monprefix_users
WHERE user_email <> ''
ORDER BY user_email ASC;Code language: HTML, XML (xml)

BIND9 : supprimer le message "success resolving after reducing the advertised EDNS UDP packet size to 512 octets" des logs photo

BIND9 : corriger les logs EDNS UDP packet size 512

Publié le 11 mai 2026 by Matt Biscay · Lecture: 6 minutes

Voici un autre message croisé dans les logs de BIND9, généralement dans /var/log/daemon.log, /var/log/syslog ou via journalctl :

named: success resolving DOMAIN after reducing the advertised EDNS UDP packet size to 512 octets
named: success resolving DOMAIN after disabling EDNSCode language: HTTP (http)

Ce message signifie que BIND a réussi à résoudre le domaine, mais seulement après avoir réduit la taille UDP EDNS annoncée, ou après avoir désactivé EDNS pour cette requête.

Autrement dit : la résolution finit par fonctionner, mais le chemin réseau ou le serveur DNS distant ne gère pas correctement les requêtes EDNS avec une taille UDP plus grande.

À l’époque, je m’étais contenté de masquer la catégorie de logs correspondante. Aujourd’hui, je préfère commencer par comprendre le problème, puis réduire le bruit seulement si le comportement est connu et sans impact.

Comprendre EDNS et la limite historique de 512 octets

Le DNS historique sur UDP utilisait une taille de message limitée à 512 octets. EDNS, pour Extension Mechanisms for DNS, permet notamment d’annoncer une taille UDP plus grande et d’ajouter des options modernes au protocole DNS.

BIND peut donc envoyer des requêtes avec EDNS même si DNSSEC n’est pas activé. EDNS ne sert pas uniquement à DNSSEC, même si DNSSEC en dépend fortement pour transporter des réponses plus volumineuses.

Le problème apparaît lorsqu’un serveur autoritaire, un firewall, un routeur, une middlebox ou un lien réseau gère mal ces paquets UDP plus grands. BIND essaie alors une taille plus petite, parfois jusqu’à 512 octets, ou finit par désactiver EDNS pour obtenir une réponse.

L’ISC indiquait déjà que les versions supportées de BIND envoient des requêtes avec EDNS activé par défaut, et que certains équipements ou serveurs cassés peuvent provoquer ces messages de repli. Lire ISC Knowledge Base : BIND log messages about disabling EDNS.