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

HTML5 : corriger l’erreur “The scrolling attribute on the iframe element is obsolete. Use CSS instead.”

Si, au détour d’une validation HTML de votre page, vous obtenez l’erreur suivante :

The scrolling attribute on the iframe element is obsolete. Use CSS instead.

… c’est que votre code contient un élément <iframe> avec un attribut scrolling.

Exemple classique :

<iframe src="https://example.com" scrolling="no"></iframe>Code language: HTML, XML (xml)

Cet attribut était utilisé pour indiquer si l’iframe devait afficher une barre de défilement. En HTML moderne, il est obsolète. Le standard HTML classe bien scrolling sur iframe parmi les fonctionnalités obsolètes, et les validateurs recommandent d’utiliser CSS à la place.

Le problème : l’attribut scrolling sur iframe

On trouvait souvent ce genre de code dans les anciennes intégrations :

<iframe
  src="https://example.com/embed"
  width="600"
  height="400"
  scrolling="no"
  frameborder="0"
></iframe>Code language: HTML, XML (xml)

Le validateur HTML signale alors une erreur, car scrolling ne fait plus partie des attributs conformes pour <iframe>. En clair, le navigateur peut encore l’interpréter par compatibilité, mais le code n’est plus valide.

La première correction consiste donc à supprimer l’attribut :

<iframe
  src="https://example.com/embed"
  width="600"
  height="400"
></iframe>Code language: HTML, XML (xml)

Mais cela ne suffit pas toujours à reproduire exactement l’ancien comportement. C’est là que CSS entre en scène.

Lire la suite

Sur un fond bleu clair, un texte noir indique "< ? PHP ?", avec une icône d'éléphant géométrique bleue remplaçant le deuxième "P". Il s'agit d'un clin d'œil au langage de programmation PHP, souvent rencontré dans les problèmes d'erreur preg_match ou de plage invalide dans la classe de caractères.

PHP : résoudre l’erreur “Creating default object from empty value”

Suite à une mise à jour de PHP, le fichier d’erreurs de mon site a commencé à afficher le message suivant :

PHP Warning: Creating default object from empty value in /wp-content/themes/skyminds/functions.php on line 1213

La ligne en question ressemblait à ceci :

$posts[0]->comment_status = 'closed';Code language: PHP (php)

À première vue, cette ligne semble anodine. Pourtant, elle suppose plusieurs choses : que $posts existe, que $posts est un tableau, que l’index 0 existe, et que $posts[0] est bien un objet.

Si l’une de ces conditions n’est pas vraie, PHP tente parfois de créer un objet par défaut à partir d’une valeur vide. C’est ce qui déclenche l’avertissement Creating default object from empty value.

Pourquoi cette erreur apparaît

Le problème vient généralement d’une assignation de propriété sur une variable qui n’est pas un objet valide.

Exemple simple :

$post = null;
$post->comment_status = 'closed';Code language: PHP (php)

Ou encore :

$posts = array();
$posts[0]->comment_status = 'closed';Code language: PHP (php)

Dans le second cas, $posts existe bien, mais $posts[0] n’existe pas. PHP ne peut donc pas modifier la propriété comment_status d’un objet absent.

La bonne correction dépend donc du type de donnée que vous manipulez : tableau, objet générique stdClass, instance de classe, ou objet WordPress comme WP_Post.

Correction rapide : vérifier que l’objet existe

La correction la plus prudente consiste à tester l’existence du premier élément avant de modifier sa propriété :

if ( isset( $posts[0] ) && is_object( $posts[0] ) ) {
    $posts[0]->comment_status = 'closed';
}Code language: PHP (php)

Cette version évite l’avertissement, car elle ne modifie comment_status que si $posts[0] existe et contient bien un objet.

Dans un thème WordPress, si l’on s’attend à recevoir un objet WP_Post, on peut être plus strict :

if ( isset( $posts[0] ) && $posts[0] instanceof WP_Post ) {
    $posts[0]->comment_status = 'closed';
}Code language: PHP (php)

C’est généralement préférable, car on vérifie le type exact attendu. WordPress documente WP_Post comme la classe utilisée pour représenter les objets d’articles retournés par des fonctions comme get_post().

Lire la suite

Postfix : résoudre l'avertissement "Untrusted TLS connection established" photo

Postfix : corriger “Untrusted TLS connection established”

Si vous possédez votre propre serveur email avec Postfix, vous pouvez parfois voir passer cet avertissement dans les logs lorsque Postfix établit une connexion TLS vers un serveur distant :

postfix/smtp[13461]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[64.233.166.27]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)Code language: JavaScript (javascript)

À première vue, le message peut inquiéter. Pourtant, il ne signifie pas forcément que la connexion n’est pas chiffrée. Il signifie plutôt que Postfix a bien établi une connexion TLS, mais qu’il ne considère pas le certificat du serveur distant comme vérifié ou digne de confiance.

En clair : la session est chiffrée, mais la chaîne de confiance du certificat n’a pas été validée comme Postfix l’attendait.

Comprendre le message “Untrusted TLS connection established”

Le log contient deux informations importantes :

  • TLS connection established : la connexion TLS a bien été établie ;
  • Untrusted : Postfix n’a pas pu valider la confiance du certificat présenté.

Donc le problème ne vient pas forcément du chiffrement lui-même. Il vient souvent de la vérification du certificat : bundle CA absent, chemin CA non déclaré, certificats racines non installés, certificat distant incomplet, ou niveau de sécurité TLS qui ne force pas la validation.

Postfix distingue la configuration TLS côté client SMTP, utilisée quand votre serveur envoie un mail vers un autre serveur, et la configuration TLS côté serveur SMTPD, utilisée quand un autre serveur ou client se connecte au vôtre. Dans les noms de paramètres, smtp_ concerne le client sortant, tandis que smtpd_ concerne le serveur entrant. La documentation TLS de Postfix sépare d’ailleurs clairement les deux rôles.

Vérifier les certificats racines du système

Sur Debian ou Ubuntu, commencez par vérifier que le paquet ca-certificates est installé. C’est lui qui fournit les certificats racines utilisés pour valider les chaînes TLS.

sudo apt update
sudo apt install ca-certificates
sudo update-ca-certificates

Ensuite, vérifiez que le répertoire des certificats existe :

ls -ld /etc/ssl/certs
ls -l /etc/ssl/certs/ca-certificates.crt

Sur Debian et Ubuntu, les deux chemins les plus fréquents sont :

/etc/ssl/certs
/etc/ssl/certs/ca-certificates.crt

Le premier est un répertoire de certificats hachés. Le second est un fichier bundle contenant les certificats racines.

Lire la suite