J’ai récemment joué avec l’API de YouTube pour pouvoir récupérer diverses informations sur les vidéos afin d’ajouter au site les données structurées idoines.
Il se trouve qu’en local, lorsque l’on utilise file_get_contents(), on peut obtenir une erreur de ce type lorsque le serveur n’est pas configuré avec le bundle de certificats OpenSSL:
Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed in ...php on line 2
Warning: file_get_contents(): Failed to enable crypto in ...php on line 2
Warning: file_get_contents(https://........f=json): failed to open stream: operation failed in ...php on line 2
Si cela vous arrive, plusieurs solutions s’offrent à vous.
Méthode 1: configuration de PHP côté machine/serveur
1. Vérifiez qu’OpenSSL est bien installé sur votre machine (il devrait l’être sur le serveur!).
2. Ajoutez cette ligne à la configuration de PHP, dans votre php.ini:
openssl.cafile=/usr/local/etc/openssl/cert.pem
3. Redémarrez le service PHP.
Méthode 2 : une fonction qui utilise curl au lieu de file_get_contents()
Au lieu de m’embêter à configurer OpenSSL ou à toucher à PHP dans un conteneur docker (Local), il se trouve que l’on peut réécrire la fonction file_get_contents() avec une fonction maison qui utilise curl.
Voici la fonction en question:
/*
Custom CURL function that mimicks file_get_contents()
@returns false if no content is fetched
Matt Biscay (https://mattbiscay.com)
*/
function sky_curl_get_file_contents( $URL ){
$c = curl_init();
curl_setopt( $c, CURLOPT_RETURNTRANSFER, 1 );
curl_setopt( $c, CURLOPT_URL, $URL );
$contents = curl_exec( $c );
curl_close( $c );
if( $contents ) :
return $contents;
else:
return false;
endif;
}
La fonction retourne false si la requête échoue, ce qui est très utile pour éviter de faire des appels à des valeurs d’un tableau qui n’existe pas. On peut alors réfléchir à un autre moyen de peupler les champs de données structurées (mais c’est un sujet à aborder une autre fois).
Gravity Forms garde en base de données toutes les entrées des formulaires. Sur un site qui génère énormément de demandes (formulaire de contact, demandes d’informations, formulaire de commande ou pré-commande…), cela signifie des milliers d’enregistrements dans la base de données, ce qui n’est pas toujours souhaitable, pour des raisons de stockage et de performance.
Supprimer les entrées des formulaires Gravity Forms
Si vous avez besoin de supprimer les entrées créées par Gravity Forms une fois que le message a été envoyé, vous pouvez utiliser cette fonction:
// Delete all entries from form ID 1.
add_action( 'gform_after_submission_1', 'sky_remove_form_entry' );
function sky_remove_form_entry( $entry ) {
GFAPI::delete_entry( $entry['id'] );
}
Dans l’exemple ci-dessus, on ne supprime que les entrées du formulaire qui a l’ID 1. Si vous souhaitez supprimer toutes les entrées de tous les formulaires Gravity Forms d’un site, il suffit d’enlever le _1de la cible de l’action gform_after_submission:
// Delete all entries from all forms.
add_action( 'gform_after_submission', 'sky_remove_form_entry' );
function sky_remove_form_entry( $entry ) {
GFAPI::delete_entry( $entry['id'] );
}
Garder les fichiers uploadés lors de la suppression des entrées
Attention: supprimer les entrées Gravity Forms revient également à supprimer les fichiers qui auront été uploadés via les formulaires. C’est tout à fait normal puisqu’ils font partie des champs du formulaire.
Pour garder les fichiers uploadés, même si les entrées associées sont supprimées, il faut utiliser le filtre gform_field_types_delete_files:
Supprimer les fichiers associés à un champ upload particulier
Si vous souhaitez supprimer tous les fichiers qui auront été uploadés via un champ upload particulier, il suffit de préciser ce champ dans le tableau $field_types avant de le passer à gform_field_types_delete_files:
Gravity Forms permet de créer rapidement des formulaires avec des logiques conditionnelles sous WordPress.
Dans les options de Gravity Forms, il existe une option qui ajoute un champ caché au formulaire, “honeypot”, qui permet d’éviter le spam mais qui doit être activé manuellement pour chaque formulaire, ce qui peut être rapidement fastidieux selon le nombre de formulaires que vous avez sur le site.
Voici comment activer et ajouter le champ honeypot à tous vos formulaires, automatiquement:
<?php
/**
* Enforce anti-spam honeypot on all Gravity forms.
*
* @param array $form The current form to be filtered.
*
* @return array
*/
add_filter( 'gform_form_post_get_meta', __NAMESPACE__ . '\\sky_enforce_gravity_forms_anti_spam_honeypot' );
function sky_enforce_gravity_forms_anti_spam_honeypot( $form ): array {
$form['enableHoneypot'] = true;
return $form;
}
Lors de la mise à jour d’un site vers PHP 7.4, je suis tombé sur cette erreur :
preg_match(): Compilation failed: invalid range in character class at offset 20 session.php on line 278
Depuis PHP 7.3, le moteur PCRE – qui est responsable de la gestion des expressions régulières – a été migré vers PCRE2.
Or, il s’avère que PCRE2 est plus strict dans la validation des pattern et c’est la raison pour laquelle, après la mise à jour de PHP, certaines expressions régulières ne peuvent plus être compilées correctement.
Voici un exemple d’expression régulière qui fonctionnait avant PHP7.3:
preg_match('/[\w-.]+/', ''); // this will not work in PHP7.3
Voici maintenant le même exemple mais qui sera désormais valide sous PHP 7.3 et les versions ultérieures :
preg_match('/[\w\-.]+/', ''); // the hyphen needs to be escaped
Comme vous pouvez le constater dans le deuxième exemple, il faut maintenant échapper le tiret (hyphen) avec un backslash.
Une fois la modification faite, plus d’erreur à ce niveau.
Si vous souhaitez sauter le pas, voici un petit tuto pour l’installation.
Étape 1 : installer le dépôt d’Ondrej
Dans le terminal, installez le dépôt d’Ondrej. Il est très souvent mis à jour et permet de bénéficier de pas mal de paquets à jour, même sur des distributions anciennes:
add-apt-repository ppa:ondrej/php
Étape 2 : installation de PHP 7.4
J’ai juste repris la liste des paquets PHP7.3 déjà installés puis changé le numéro de version.
Note: il vous reste ensuite à modifier php.iniainsi que votre pool PHP selon vos besoins.
Étape 3: modification du server block
L’étape finale est la modification de votre server block. Sous NginX, éditez le fichier de configuration de votre site pour pointer vers le socket de PHP7.4:
Lors de la mise en ligne d’un nouveau site, je suis tombé sur une page qui ne fonctionnait pas et donnait une erreur 502 avec ce message dans les logs:
upstream sent too big header while reading response header from upstream
Si votre serveur utilise NginX, il suffit d’ajouter ces deux lignes à votre server block pour que tout rentre dans l’ordre:
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
L’augmentation de la taille des buffers permet d’envoyer toutes les données d’un coup d’un seul, ce qui résout l’erreur.
Il ne reste plus ensuite qu’à relancer le serveur NginX:
A l’heure où la grande majorité des sites internet sont passés à HTTPS, il n’est pas rare de constater que PHP ne sert toujours pas les cookies de session avec les directives “HttpOnly” et “Secure”.
Pourtant, les directives sont bien disponibles dans le fichier php.ini, il suffit donc de les activer.
Cela ne s’applique pas à tous les cookies créés par les plugins ou applications du site. Il faudrait pour cela que le serveur, nginx, possède nativement le module nginx_cookie_flag_module.
Je travaille actuellement sur un projet Codeable qui nécessite de passer de PHP5.6 à PHP7.2. Le site en question est une boutique WooCommerce avec un thème custom qui est hébergé chez WPEngine. Jusque là, tout va bien.
Lors de la migration sur un serveur PHP7.2, le site de developpement (Staging) affiche alors un message d’avertissement sur toutes les pages :
Parameter 1 to wp_default_styles() expected to be a reference, value given
Parameter 1 to wp_default_scripts() expected to be a reference, value given
Après avoir passé un bon moment à éliminer les causes (plugins et thème), il se trouve que c’est un bug de WordPress 4.9.8 (la dernière version en date) dont il est question dans le ticket #44979.
Voici la solution temporaire à ce problème :
éditez /wp-includes/script-loader.php
retirez le caractère & de l’argument des fonctions wp_default_scripts() et wp_default_styles()
sauvegardez le fichier
rechargez le site, les deux messages d’avertissement ont disparu.
Voilà, ce n’est qu’un hotfix mais ce bug devrait être corrigé dans la prochaine version de WordPress – version 4.9.9 – qui sortira prochainement.
Au départ, ce serveur n’avait qu’un seul site – celui que vous lisez en ce moment ;) – mais au fil du temps, plusieurs sites sont venus s’installer dans son giron.
Au début, nous n’avions donc besoin d’une seule configuration PHP – www.conf par défaut – qui est un pool (ou conteneur) selon la terminologie PHP.
Ce fichier de configuration dicte le nombre de threads PHP à lancer, les permissions, etc.
Afin de monter en charge et fournir à chaque site les ressources qui lui sont nécessaires, adoptons la stratégie “un site, un pool”.
Mise en place du nouveau pool PHP
Pour être sûr de partir d’une base éprouvée, copions notre pool de départ dans un nouveau fichier :
Aujourd’hui, le logo de SkyMinds fait peau neuve ! Plus discret, plus moderne aussi. J’en ai profité pour mettre en place toute une liste de modifications cosmétiques que j’ai trop longtemps repoussées.[no_toc]
Nouveau logo !
Mise à jour des templates du thème enfant
L’avantage d’un thème enfant sous WordPress, c’est que l’on ne perd pas ses modifications lorsque le thème parent se met à jour. Le thème enfant, c’est tout simplement la base, l’étape qui vient juste après l’installation d’un nouveau thème.
Or, au fil des mois ans, il se trouve que le thème parent évolue et que les fichiers du thème enfant (modifiés) ne sont plus exactement à jour. J’en ai donc profité pour reprendre les nouveaux fichiers et y apporter mes modifications.
Concaténation des appels des fichiers de police
En analysant les fichiers du thème, je me suis rendu compte qu’on pouvait gagner pas mal de temps de chargement grâce à une épuration du nombre de polices utilisées sur le site. Au lieu d’en avoir deux (Open Sans et Droid Sans), il n’y en aura plus qu’une : Open Sans. Elle est légère, classique et facile à lire.
Le problème, c’est que Divi charge pas mal de versions de cette police par défaut : 300, 400, 700… en normal, italic et gras et avec des subsets exotiques comme le cyrillique, le grec ou le vietnamien. Clairement, on doit pouvoir mieux faire !
Divi : suppression des subsets Google Fonts
On commence par virer les subsets exotiques. Rendez-vous dans Divi > Theme options > General > désactivez Google Fonts subsets. Vous venez d’économisez 400KB.
Divi : suppression de toutes les Google Fonts et chargement de l’unique nécessaire
C’est pénible d’avoir tous les grammages d’une police chargés pour rien. Voici ce que j’utilise pour tout virer dans un premier temps, puis ajouter uniquement ce dont j’ai réellement besoin:
/*
|-----------------------------------------------------------------------
| Plugin Name: Sky Remove DIVI Google Fonts and add what we need
| Plugin URI: https://www.skyminds.net/?p=29578
| Author: Matt Biscay
| Author URI: https://www.skyminds.net/
|-----------------------------------------------------------------------
*/
// remove all Divi fonts, we'll just load what we need
// @return: array
function et_builder_get_google_fonts() { return array(); }
function et_get_google_fonts() { return array(); }
// add fonts : logo (Comfortaa:700) and site (Open+Sans:400,700). No subsets.
add_action( 'wp_enqueue_scripts', 'sky_logo_add_google_fonts' );
function sky_logo_add_google_fonts() {
wp_enqueue_style( 'sky-logo-google-fonts', 'https://fonts.googleapis.com/css?family=Comfortaa:700|Open+Sans:400,700', false );
}
Kaboom! On vient de se retirer une sacrée épine du pied. Il faudra juste relire la feuille de style pour être sûr que l’on utilise bien soit du font-weight 400 (regular), soit du 700 (bold). Pensez également à vérifier votre critical CSS.
Amélioration de la section Auteur
A la fin de chaque article se trouve la section de l’auteur, qui comprend une courte description ainsi que des liens vers ses profils sociaux. J’ai profité de la police du thème pour remplacer les noms des réseaux par des icônes. C’est purement cosmétique mais je trouve cela plus joli.
Cela m’a permis de me rendre compte que le site n’utilise absolument pas Font Awesome – ce que je trouve totalement fou. J’aime tellement cette police que j’ai acheté la version professionnelle pour mes développements… et ne l’utilise pas moi-même !
J’ai troqué le bleu clair pour un beige. A voir sur la durée.
Nouveau logo
Et enfin, last but not least, j’ai troqué mon logo image contre un logo font. Cela faisait pas mal de temps qu’il me trottait dans la tête l’idée de le changer. J’ai d’abord commencé, comme d’habitude, par tenter de créer des logos images avant de changer mon fusil d’épaule et considérer la possibilité d’utiliser une Google Font pour le générer à la volée.
Après quelques recherches, j’ai finalement opté pour la police Comfortaa en 700. C’est plutôt moderne par rapport au logo précédent qui avait la particularité d’être un dégradé de plusieurs couleurs (rose, violet, bleu, vert), avec des ligatures à certaines lettres.
Celui-ci sera donc beaucoup plus clean et professionnel. Je pense d’ailleurs le réutiliser sur d’autres supports de personal branding.
Lorsque le site est servi via HTTPS, toutes les ressources – même les ressources oEmbed automatiquement générée par WordPress – qui composent une page doivent également être servies via une connexion chiffrée aussi.
Il se trouve que je mets des vidéos Youtube et consorts de temps en temps : elles ne s’affichaient plus en https, étant servies par défaut en http.
Le changement vers HTTPS est en marche mais tous les services oEmbed n’ont pas encore adopté le chiffrement des connexions.
Servir les vidéos Youtube en HTTPS
Au lieu d’utiliser Youtube.com, nous allons utiliser la version cookie-less de Youtube, à savoir youtube-nocookie.com : cela permet d’éviter les cookies pisteurs de Google et donc offre plus de sécurité et de respect de la vie privée.
J’utilise ce système depuis des années sur SkyMinds donc je me suis dit qu’il était bien temps de le partager dans ces colonnes.
Le code permet donc de remplacer youtube.com par youtube-nocookie.com dans le code généré par l’oEmbed WordPress.
Ce code est à ajouter dans votre utility plugin (ou à défaut le fichier functions.php de votre thème WordPress).
Le premier code remplace toutes les occurences des médias HTTP pour HTTPS :
<?php
/* Force HTTPS rewrite for oEmbeds
* Source : https://wordpress.stackexchange.com/questions/40747/how-do-i-embed-youtube-videos-with-https-instead-of-http-in-the-url
*/
add_filter( 'embed_oembed_html', 'sky_embed_oembed_html' );
function sky_embed_oembed_html( $html ) {
return preg_replace( '@src="https?:@', 'src="', $html );
}
Le second code modifie tous les appels à youtube.com et les remplace par youtube-nocookie.com, ce qui empêche la création de cookies pisteurs :
Cela a l’air tout bête mais cela permet de faire respecter un peu plus notre droit au refus de se faire pister à tout bout de champs sur le net.
Le petit plus : on charge également moins de cookies, qui ne sont pas des ressources cachables par essence donc on améliore un peu aussi le temps de chargement de la page.
PHP 7.2 accroît fortement les performances des versions précédentes, notamment au travers de plusieurs améliorations en matière de sécurité. Ainsi, l’algorithme Argon2 qui sert au hachage sécurisé des mots de passe corrige les défauts des algorithmes actuels. Celui-ci permet notamment un taux de remplissage plus élevé de la mémoire.
PHP 7.2 intègre désormais dans son noyau la bibliothèque de cryptographie Sodium, utilisée pour le chiffrement authentifié, est désormais une extension de base et les performances de la bibliothèque pour la cryptographie sur les courbes elliptiques ont été améliorées.
Niveau programmation
Au-delà de Sodium, PHP 7.2 vient avec des améliorations et nouvelles fonctionnalités comme :
la possibilité de convertir des clés numériques dans les objets et tableaux lors de cast.
les clés numériques sont maintenant mieux appréhendées lors de cast d’un tableau en objet et d’objet en tableau (cast explicite ou par la fonction settype()) ;
le comptage d’objets non dénombrables. Un E_WARNING sera émis lors de la tentative d’utilisation de la fonction count() sur un type non dénombrable ;
HashContext en tant qu’objet ;
ajout d’Argon2 à l’API pour le hachage de mot de passe ;
amélioration des constantes TLS ;
la suppression de l’extension Mcrypt. L’extension MCrypt a maintenant été déplacée du noyau vers PECL. Étant donné que la bibliothèque mcrypt n’a pas eu de mises à jour depuis 2007, son utilisation est fortement découragée. Au lieu de cette extension, soit OpenSSL ou l’extension sodium doit être utilisé.
Les fonctions Deprecated (déconseillées) et supprimées pour PHP 8.0:
__autoload
$php_errormsg
create_function()
mbstring.func_overload
(unset) cast
parse_str() sans le second argument
gmp_random()
each()
assert() avec un argument string(texte)
$errcontext
La conversion des clés numériques dans les distributions objet/tableau résout un problème rencontré avec le moteur open source Zend Engine qui fait tourner PHP 7. Dans certaines situations, les tables de hachage de tableaux pouvaient contenir des chaînes numériques alors que les tables de hachage d’objets pouvaient contenir des clés entières, ce qui empêchait le code PHP de retrouver les clés. Le correctif apporté par PHP 7.2 convertit les clés des tables de hashage des tableaux et des tables de hachage des objets sont converties dans les bons formats, de sorte que les chaînes de format numériques personnalisées sont traduites en clefs entières, résolvant le problème d’inaccessibilité.
Les typages explicites d’objets ou « type hints » corrigent une situation dans laquelle un développeur ne peut pas déclarer une fonction supposée recevoir un objet en tant que paramètre ou déclarer qu’une fonction doit retourner un objet. Le correctif utilise l’objet comme type de paramètre et type de retour. HashContext en tant qu’objet, migre l’extension de hachage pour utiliser une extension objet pour les contextes de hachage au lieu d’utiliser des ressources. A noter aussi une nouvelle alerte ajoutée pour l’appel de la fonction count avec un paramètre scalaire ou nul, ou un objet qui n’implémente pas l’interface « Countable »
Mise à jour vers PHP7.2
Cela n’a pris que quelques minutes :
apt update && apt upgrade
Résultat :
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
php7.1-cli php7.1-curl php7.1-fpm php7.1-gd php7.1-json php7.1-mbstring php7.1-opcache
php7.1-readline php7.1-xml php7.1-xmlrpc
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
libargon2-0 libsodium23 php7.2-cli php7.2-common php7.2-curl php7.2-fpm php7.2-gd php7.2-json
php7.2-mbstring php7.2-opcache php7.2-readline php7.2-xml php7.2-xmlrpc
The following packages will be upgraded:
php-common php-curl php-fpm php-gd php-mbstring php-xml php-xmlrpc php7.1-cli php7.1-common
php7.1-curl php7.1-fpm php7.1-gd php7.1-json php7.1-mbstring php7.1-mcrypt php7.1-mysql
php7.1-opcache php7.1-readline php7.1-soap php7.1-xml php7.1-xmlrpc php7.1-zip
22 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
Need to get 8,656 kB of archives.
After this operation, 19.7 MB of additional disk space will be used.
A ce stade, nous avons php7.1 et php7.2 installés séparément sur le serveur.
On installe les paquets manquants (toujours les deux mêmes):
apt install php7.2-mysql
On édite chacun des VirtualHosts sous Nginx, en éditant cette ligne:
fastcgi_pass unix:/run/php/php7.2-fpm.sock;
On relance NginX et PHP:
service php7.2-fpm restart && service nginx restart
Si tout va bien, il suffit de supprimer PHP7.1, ses dépendances et ses fichiers de configuration:
apt purge php7.1-*
Test de votre code sous PHP 7.2
Vous hésitez encore à sauter le pas ? Copiez-collez votre code sur le site d’3v4l, vous saurez immédiatement si cela produit des erreurs de type Notice.
Bonne mise à jour !
Sommaire de la série Monter un serveur dédié de A à Z
