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 classatoffset 20 session.phponline 278Code language:JavaScript(javascript)
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.3Code language:JavaScript(javascript)
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 escapedCode language:JavaScript(javascript)
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 upstreamCode language:JavaScript(javascript)
Solution: augmenter la taille des entêtes
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.
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 PHP 7.4, 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.
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: arrayfunctionet_builder_get_google_fonts(){ returnarray(); }
functionet_get_google_fonts(){ returnarray(); }
// add fonts : logo (Comfortaa:700) and site (Open+Sans:400,700). No subsets.
add_action( 'wp_enqueue_scripts', 'sky_logo_add_google_fonts' );
functionsky_logo_add_google_fonts(){
wp_enqueue_style( 'sky-logo-google-fonts', 'https://fonts.googleapis.com/css?family=Comfortaa:700|Open+Sans:400,700', false );
}
Code language:PHP(php)
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 :
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.Code language:JavaScript(javascript)
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):
aptinstallphp7.2-mysqlCode language:CSS(css)
On édite chacun des VirtualHosts sous Nginx, en éditant cette ligne:
Si tout va bien, il suffit de supprimer PHP7.1, ses dépendances et ses fichiers de configuration:
aptpurgephp7.1-*Code language:CSS(css)
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.
Aujourd’hui, nous sautons le pas et passons du serveur Apache au serveur NginX (à prononcer “engine X”) pour booster les performances générales du site.
Cela fait quelques serveurs que je monte pour d’autres en utilisant nginx et force est de constater que c’est beaucoup plus réactif qu’Apache et cela prend moins de temps à configurer pour optimiser les réglages.
Je pars du principe que c’est une nouvelle installation mais si vous aviez déjà votre site qui tournait sous Apache, certaines étapes seront juste optionnelles.
Ce tutoriel vise un serveur Debian mais est adaptable sans problème à ses dérivés comme Ubuntu ou Mint.
Etape 1 : NginX
Nous allons installer la dernière version du serveur nginx, avec le support pour HTTP2, depuis les dépôts Sury :
nano /etc/apt/sources.listCode language:PHP(php)
et nous ajoutons :
# SURY, post-Dotdeb
deb https://packages.sury.org/php/ stretch main
deb https://packages.sury.org/nginx-mainline/ stretch main
deb https://packages.sury.org/mariadb/ stretch mainCode language:PHP(php)
Nous allons d’abord configurer toutes les options qui nous sont primordiales : compression des fichiers statiques, implémentation SSL, types mime… afin de gagner du temps (et éviter les erreurs) dans l’étape suivante.
1. Nous voulons un site rapide donc nous allons compresser tout ce qui peut l’être. On crée un nouveau fichier :
nano /etc/nginx/snippets/gzip-config.conf
et on y met :
# MATT : add more mime-types to compress
types {
application/x-font-ttf ttf;
font/opentype ott;
}
# MATT : gzip all the things!
gzip on;
gzip_disable "msie6";
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_min_length 256;
gzip_buffers 168k;
gzip_http_version 1.1;
#gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;# Compress all output labeled with one of the following MIME-types.
gzip_types
application/atom+xml
application/javascript
application/json
application/ld+json
application/manifest+json
application/rss+xml
application/vnd.geo+json
application/vnd.ms-fontobject
application/x-font-ttf
application/x-web-app-manifest+json
application/xhtml+xml
application/xml
font/opentype
image/bmp
image/svg+xml
image/x-icon
text/cache-manifest
text/css
text/plain
text/vcard
text/vnd.rim.location.xloc
text/vtt
text/x-component
text/x-cross-domain-policy;
# text/html is always compressed by gzip module# don't compress woff/woff2 as they're compressed alreadyCode language:PHP(php)
J’ai ajouté deux types mime qui ne sont pas dans la configuration de base d’NginX et étendu la liste des types de fichiers à compresser. Certains types le sont déjà donc c’est inutile de gaspiller des ressources en essayant de les compresser.
Ce tutoriel aborde le passage de PHP7.0 à PHP7.1 sur une Debian stable (Jessie).
L’opération prend une vingtaine de minutes, en comptant les opérations de vérifications (pre-flight checks en anglais).
La retraite PHP chez Dotdeb
Guillaume Plessis, qui maintient Dotdeb, a récemment annoncé que pour des raisons personnelles et professionnelles, Dotdeb ne fournira plus les mises à jour de PHP passé la version 7.0.
Je comprends sa décision : c’est chronophage et il faut pouvoir être en mesure de répondre aux commentaires et attentes d’une foule de personnes qui utilisent ce dépôt. Pas toujours simple. Merci Guillaume pour tout le travail accompli !
Vérification de la compatibilité PHP7.x sous WordPress
Si votre site tourne sous WordPress, il existe un plugin très utile – PHP Compatibility Checker – qui permet de vérifier que la mise à jour n’impactera pas votre site.
Je pense notamment aux plugins dont certains peuvent être assez vieillots et dont les fonctions peuvent être maintenant obsolètes.
Lancez-le avant de faire la mise à jour. S’il rapporte des warnings, ce n’est pas un problème. Si ce sont des erreurs par contre, mieux vaut y jeter un oeil avant de mettre à jour votre serveur.
Nouveau dépôt PHP : Ondrey Sury
Si l’on veut PHP7.1, il faut donc changer de dépôt et utiliser celui d’Ondrey Sury.